[レポート] ENT308-S: クラウドへの転換を加速する、実績のある方法論 #reinvent

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

本記事はAWS re:Invent 2018のセッション「ENT308-S: Proven Methodologies for Accelerating Your Cloud Journey」のレポートです。

In this session, learn how to accelerate your journey to the cloud while implementing a cloud-first strategy and without sacrificing the controls and standards required in a large, publicly-traded enterprise. Benefit from the insights developed from working with some of the most recognized brands in the world. Discover how these household names leverage automation, CI/CD, and a modular approach to workload design to ensure the consistent application of their security and governance requirements. Learn which approaches to use when transforming workloads to cloud-native technologies, including serverless and containers. With this approach, business users can finally receive properly governed resources without delaying or disrupting their need for agility, flexibility, and cloud scale. This session is brought to you by AWS partner, 2nd Watch.

オンプレミスからクラウドへの転換時にありがちな問題とその対策についての発表でした。

スピーカー

  • Travis Greenstreet - Principal Cloud Consultant, 2nd Watch
  • Ian Willoughby - Chief Architect, 2nd Watch

レポート

一般的なクラウド移行への道

一般的にオンプレミスからクラウドへの移行はこのような曲線で恩恵を得られるが、時期によって効果が変わる。 PoCの段階から、実際の構築までは順調にクラウドの恩恵を受けられる。

マイグレーションの検討のタイミングから、ガバナンスやセキュリティに関する検討などを行うタイミングで一旦クラウドの恩恵を失うタイミングがあるが、マイグレーションが進んで以降はまたクラウドの恩恵を受けられるようになる。

ここでは、各フェーズでの課題と、その対策について紹介する。

ナレッジと経験の不足

課題

クラウドのための準備や、知るべきことがたくさんある。 何から手をつければ成功に近づけるのだろうか?

対策

  • 経営者サイドからの推進
  • CCoE(クラウド専門組織)の設立
  • スタッフの教育
  • クラウドファースト戦略での開発
  • 成功に対するKPIのための計測

オンプレミスに構築された既存のインフラの不明点

オンプレミスにおけるワークロードはたくさんあるが、認識されていない情報がある。

  • アプリケーション間の相互依存
  • ネットワークスループット
  • 実際のサーバの要求事項

など。

対策

現状のワークロードの評価は効果的なマイグレーションの計画においてコストの最小化とリスクの認識のため重要である。

  • 既存環境の評価のためにツールを使う
  • アプリケーションへのオーナーへのインタビュー
  • リスクレベルのアサイン
  • 共有するためのアセスメントレポートの作成
  • マイグレーション計画とスケジュールの作成

保証がない

一般的ではない方法だったり、ガバナンスがなかったり、コストやセキュリティ対する考察なしでインフラがデプロイされてしまい、自力で行う実験がチャレンジングな計画と化してしまう。

対策

以下を含むクラウドのセキュリティポリシーを作ろう。

  • 業界のコンプライアンスに対する要求
  • 既存のコーポレートガバナンス
  • CISベンチマーク

ランディングゾーンを構築しよう。

  • アカウント戦略
    • 本番環境と開発環境を分けるなど
  • 主要なコンポーネントのデザイン
  • 既存の一般的なアーキテクチャの参照
  • 設定の管理

リスク管理からくる停滞

デプロイメントを繰り返すにつれてリスク管理についての心配事が増え、マイグレーションが止まる。

対策

クラウドの準備には学習と安全性の確保が必要である。 重要な要素の設計フェーズでは人を巻き込み、以下のようなプラットフォームへのアクセスを提供しよう。

  • AWS Config
  • CloudTrail
  • Log access
  • IAM Roles and Federation

監視について

  • CloudTrailのログやメールによるアラートは持っているが、オペレーションに精通していなかったり、分析や対応への対策がない。
  • たくさんのデータストリームがあるが、それらを全て監視することができない

対策

ログを集約、可視化、分析するためのプラットフォームを使おう。

GuardDutyについて

  • GuardDutyは危険の兆候を判断するためにログを分析する。
  • 脅威が検出された場合、SNSで通知する。

可視化について

Visualizing Amazon GuardDuty findingsで、ElasticsearchとKibanaによるAmazon GuardDuty Findingsを可視化するためのクイックスタートのテンプレートが利用可能。

最後に

少人数のやっていき精神だけで戦うのは途中で負荷が偏って辛くなったり諦めてしまうようなケースが多々あるような気がします。 クラウドに関わらず大規模なアーキテクチャの転換がある場合に、組織構造から検討する必要があるというところは本当にその通りだなと思いました。