【ネスレ様ご登壇事例】【レポート】AWS コンサル事例でわかる クラウド時代の移行プロジェクトの進め方 #AWSSummit

AWS Summit Tokyo 2018。Day2 で開催された『【ネスレ様ご登壇事例】AWS コンサル事例でわかる クラウド時代の移行プロジェクトの進め方』についてレポートします。

スピーカー

• 鈴木 直さん
  • アマゾン ウェブ サービス ジャパン株式会社 プラクティスマネージャー
• 日比 裕介さん
  • ネスレ日本株式会社 Eコマース本部 EC & デジタルシステム部

セション概要

クラウド時代において、これまでと同じようなプロジェクトの進め方を適用したりしていませんか。クラウド移行プロジェクトを効果的、効率的に進めていくた めには、クラウドの特徴を理解した進め方が必要になります。当セッションでは、「基本」として、構成変更の容易性や Infrastructure as Code による自動化などといったクラウドの特徴を活かした移行プロジェクトの進め方を説明し、「実践」として、エンタープライズ企業において短期間で成功裏に実 現したクラウド移行プロジェクトの事例をご紹介します。

制約とプロジェクト

従来、ハードウェア面、ソフトウェア面において以下のような制約の上で、構築・開発をされてきた。

• ハードウェアの制約
  • システムリソース
  • マニュアルオペレーションを前提とした人的リソース
  • 建物のスペース
• ソフトウェアの制約
  • リソース拡張や、変更の制約
  • 時限利用が困難
  • 生産性の限界
  • 働き方の制約

ハードウェア、ソフトウェアの制約が、そのままプロジェクト移行の制約になる。

クラウドの特性を活かせていますか？

• アジリティ
• フレキシビリティ
• スケーラビリティ

クラウドは、すべての制約を取り払うわけではないが、大きな利点があるはず。にもかかわらず、従来とまったく同じやりかたをしていませんか？

クラウドの特性とプロジェクトの進め方

プロジェクトには以下の４つのフェーズがあり、それぞれのフェーズでクラウドの特性を活かした、プロジェクトの進め方がある。

• 要件定義
• 設計
• 構築
• テスト

作りながら要件と設計を固める

オンプレミスではリソースの導入や変更が簡単に行えないため、机上でしっかりと要件定義、設計していた

• AWS の実際の環境を使いながら、要件、設計を進める
• 実際の環境を使うことで、（サイジング、キャパシティなどの）推測は排除されていく
• 逆に時間がかかるんじゃないの？　というお声をいただくこともある。
  • ボトムアップで網羅的にやると、たしかに時間はかかる。時間を書けすぎない工夫は大事
    • AWSサービスの選択肢を念頭に
    • ベストプラクティスからはじめる（AWS Well-Architected）
    • これらを使って、要件定義、設計の期間を短縮する

インフラのコード化による変更容易性の実現

• 作りながらすすめると、後からの変更が大変じゃないの？
  • マネジメントコンソール や AWS CLI からの手作業は、数台規模であれば、それほど大きな変化はないかもしれない
  • 規模の増加により、変更作業の時間増加、ミスが増加する
  • 変更作業のコード化
  • AWS ではインフラのコード化環境自体を安価に即座に容易することが可能
  • AWS CodeCommit
  • AWS CloudFormation
  • AWS OpsWorks
  • はじめて作るときは学習コストはかかるが、後から「やって良かった！」になるはず

必要なときにリソースを拡張する

• ニーズに応じてリソースを拡張、縮小させる効果は、プロジェクト期間中でも同じ
• 拡張させることで作業時間が短縮できるのであれば、一時的にリソースのスケールアップ、スケールアウトを検討する
• ただしコストの観点から、通常時はテストが実施できる最小限のリソースで起動しておく
  • 時間のかかるビルド作業や、データ変換作業時のみ、インスタンスタイプをアップ
  • 負荷テスト（本番同等の環境を準備する）
  • データの大量コピー
  • ステージング環境を準備する

テストの範囲を見定める

• 責任共有モデルをテスト範囲の判断に利用する
  • AWS のプラットフォーム自体をテストして、時間を費やさない
    • 起動、停止、オートスケールなど

クラウドとツールで、物理的制約から開放する

• クラウドにより、物理的なスペースから開放され、どこからでもアクセスが容易に
  • プロジェクトルームに行かないと見れないドキュメント、紙媒体の資料
  • 口頭ベースの指示や報告
  • 一箇所に集まって仕事をするという暗黙的なルール
    • コミュニケーションツール（Amazon Chime）
  • クラウドの接続の容易正を活かして、働き方を変えていただきたい！

その他

• PoCをやる。ただし、既に Proof（証明） されているものをあらためて検証しない
• セキュリティチームとの合意は早いフェーズで実施する
• アプリチームとインフラチームで一緒に議論
• 新機能リリースの動向を常にチェックする
• オペレーションマニュアルの作成に時間をかけない
  • スクリーンショットベースのマニュアルは、すぐに陳腐化するので時間をかけない

これらの点を考慮し、プロジェクトにも以下のクラウド特性を持ち込む。

• アジリティ
• フレキシビリティ
• スケーラビリティ

実践：お客様事例

プロジェクトの概要

• 移行対象はECサイトの一部。移行前は香港で稼働しているラックスペースのオンプレミス環境
• プロジェクト期間は、2017年11月〜2018年４月まで

AWS 利用にいたった背景

• 拡張性とスピード
  • アプリの新規のリリースを迅速に行いたい
• 性能改善
  • 香港のサイトにあったため、地理的なレイテンシがある
• 運用効率化
  • 日本ローカルで運用自動化
• TCO削減

プロジェクトの特徴と工夫

特徴

• 変更に強い基盤の要求
  • コードベースでのインフラ構築
• 継続的なシステム改善
  • マネージドサービスの機能を利用した作業時間の短縮
• ステークホルダーが地理的に分散
  • 働く場所を制限しない、コミュニケーション
• コードベースでのインフラ構築
  • 環境の変更作業の時間短縮、運用への影響度を減少
    • プロジェクト途中で、AWS アカウントを分けることになったが AWS CloudFormation で１時間の作業で終わった
  • 環境の複製構築が短時間で実現
    • 同一構成の別環境の用意を約２時間で出来た
  • 作業ミスの減少
    • グローバルで定められたポリシー上、セキュリティグループはアウトバウンドの制御まで必要であり、ルールが 250もあった
    • AWS CloudFormation で変更が容易に、安全に行えた
• マネージド・サービスを活用し、作業期間の短縮
  • ローリングアップデートにより、オートスケーリンググループの EC2 を順次更新していく
  • AutoScaling の機能を利用することで機能開発、テスト時間を短縮
  • サービス停止なしでアプリケーションのコード更新
    • AWS 移行前はコードの更新毎にサービスを停止していた
  • マネージド・サービスを活用することで、運用管理自体の構築期間を短縮

働く場所を制限しないコミュニケーション

• 今回のプロジェクトでは、神戸、東京、スイス、バルセロナ、オーストラリア、ウクライナ などの場所に分散しているが、以下のようなツールで解消することが出来た。
  • AWS 環境の利用
  • Amazon Chime/Slack
  • タスク管理は JIRA
  • ドキュメントは Confluence
    • ロケーション、ベンダーをまたいだチームの一体感の
    • コミュニケーションコストの減少
    • 構築作業の短縮への寄与
    • 移動時間やスペース賃料などの関節費用も削減
    • 全員が一同に介して作業したのは、本番移行時の１度のみ

まとめ

従来のシステム開発では、ハードウェア、ソフトウェアの制約から、プロジェクトの進め方にも制約があった。クラウドの特徴を活かした、プロジェクトの進め方がある。

さいごに

「オンプレミスと同じ考え方で移行を検討していませんか？」 という問いは、ハッとさせられた聴講者も多かったのではないでしょうか。あらゆる制約から解放されたにもかかわらず、移行計画・手法はそのまま、というユーザは少なくないように思います。新たな移行計画・手法を検討する際の、良いヒントを与えていただけたセッションだったと思います。

以上！大阪オフィスの丸毛（@marumo1981）でした！