ゴール設定

AWS移行の意義や目的を明確にする

いつまでに何を完了させるのか、スケジュールを決定する

フェーズごとのアウトプットを決定する

フェーズごとの体制、役割を決定する

現状構成の洗い出し

対象とするシステムや機器を明らかにする

アプリケーション間のデータフローを明らかにする

ビジネスインパクト観点で優先度を付ける

優先度と依存関係からサーバーをグルーピングする

自社要員のスキルセットを明らかにする

移行ワークショップ開催

ファンクショナルデザインワークショップ

テクニカルデザインワークショップ

マイグレーションデザインワークショップ

セキュリティデザインワークショップ

デプロイ・プロビジョニングワークショップ

運用モデルワークショップ

あるべき像の定義

叩き台になる「理想のアーキテクチャ」を作成する

叩き台に対して実現性を議論する

データ移行方式案を作成する

スキルが不足している部分は要員トレーニングの計画を立てる

課題抽出

移行戦略の策定

PoC (概念実証)、技術検証の計画

要員トレーニング実施

移行対象の決定

カットオーバー要件定義

マスタースケジュールの作成

費用の算出

技術検証

設計

要件定義

アーキテクチャ設計

パラメーター設計

構築

テスト

テスト設計

テスト実行

テスト結果レビュー

移行

移行計画の立案

移行リハーサルの実施

カットオーバー

タスク以外のこと

参考

AWS移行～移行を成功させるタスクリスト作り

AWS移行を成功させるためにどのようなタスクをこなしていけばよいでしょうか？答えのない問いに挑戦してみます。

#AWS

#移行

#クラウド移行

吉井亮

2020.09.28

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

こんにちは。
ご機嫌いかがでしょうか。
"No human labor is no human error" が大好きなネクストモード株式会社の吉井です。

AWS移行を計画しているお客様から「標準的なタスクリストはないか？」「何から手を付けてよいか教えてほしい」といったお問い合わせを頂戴することがあります。
そのようなお問い合わせに少しでも役に立てるようリストしてみました。
このタスクリストをベースに肉付けやブレークダウンをしていけば、それなりなWBSが出来ることと思います。

ゴール設定

古くから「段取り八分」という通り、ITプロジェクトも段取りが肝です。
ゴール設定は段取りのうちです。

AWS移行の意義や目的を明確にする

AWS移行によって得られる効果は何でしょうか。最新技術の導入、コスト削減、伸縮性、CI/CDの導入、運用自動化の実現など様々な効果が見込めます。意義や目的を明確にしておきましょう。

いつまでに何を完了させるのか、スケジュールを決定する

フェーズレベルの大まかなスケジュールで構いません。
最終的なゴールから逆算してスケジュールを決定します。

フェーズごとのアウトプットを決定する

意味あるアウトプットを定義します。
あるフェーズのアウトプットは次のフェーズのインプットになるよう定義します。

フェーズごとの体制、役割を決定する

フェーズのアウトプットを正しく出すための体制と役割を決定します。
自社で全てを完結しなくても大丈夫です。必要に応じてAWSパートナーのリソースを活用します。

現状構成の洗い出し

現状構成の理解を深めることがAWS移行成功の鍵になります。
この項目も段取り八分のうちです。

対象とするシステムや機器を明らかにする

移行対象を明確にすることは今後の議論を進めていくうえで重要です。
対象に抜け漏れがあると移行計画自体が進まなくなる可能性もあります。
必要な情報を収集します。

機器名称
役割
ホスト名
サーバースペック
OS (バージョンも含める)
ミドルウェア (バージョンも含める)
アプリケーション (バージョンも含める)
直近3ヶ月のパフォーマンスメトリクス
サーバー間の依存関係

移行対象としないシステムや機器についても同様です。
AWSとオンプレミスの接続などアーキテクチャに大きく影響してきます。

オンプレミスサーバーの情報を自動収集するツールがAWSから提供されているので、これを活用することも検討します。
AWS Application Discovery Service (ADS)

アプリケーション間のデータフローを明らかにする

アプリケーション間のデータフロー、依存関係を明らかにすることがAWS上のアーキテクチャを構成する際の助けになります。
サーバーレス、マイクロサービス、マネージドサービス、疎結合、ステートレスなどのクラウド最適化を検討する際にデータフローの有り無しで成果が大きく変わります。

ビジネスインパクト観点で優先度を付ける

移行対象に優先度を設定します。
色々な要素があると思います。正解は無いので自社のモノサシで判断します。

戦略的、技術的な優先度
- デプロイを高速化して自社サービスの競争力を強化したい
- 自社要員の運用負荷が高まっており自動化によって負荷をさげたい
- 最新技術を導入してエンジニアのモチベーションを向上させたい
既存IT資産の制約
- 既存契約データセンターの契約期限が迫っている
- 既存ハードウェアの保守切れが迫っている
- レガシー技術の廃止が決まっている
セキュリティの強化
- 外部攻撃を受けておりAWSで対策を強化したい
- 既存契約のハウジングサービスではセキュリティ要件を満たせない

優先度と依存関係からサーバーをグルーピングする

AWSとオンプレミスのハイブリットになる場合、レイテンシーの問題、接続性の問題等が発生しないよう依存関係のあるサーバーはまとめて移行します。
ハイブリットや順次移行を計画している場合はグルーピングを適切に行うことが大切です。

自社要員のスキルセットを明らかにする

AWS移行するということは自社要員のスキルセットもオンプレミスとは異なるものになります。
クラウド最適化されたアーキテクチャを構築するためにも、運用を自動化して効率化していくうえでもAWSスキル習得は必須です。
AWS公式トレーニングを受講したり、AWSパートナーにレクチャーを依頼するなど外部に頼る方法も検討するためにも現時点でのスキルセットは明らかにしておきましょう。

AWS Migration Readiness Assessment (MRA) というツールがAWSから提供されています。
社組織のクラウドに対する準備状況を評価することが可能です。
いくつかの質問に答えていくと分析されたレポートが出力されます。
今のところ、AWS本体かAWSパートナーの支援が必要なツールとなっているようです。興味があれば何れかに相談ください。
簡易版が提供されているので、気になる方はまず簡易版をお試しください。
https://cloudreadiness.amazonaws.com/#/cart

移行ワークショップ開催

ワークショップを開催します。
AWSに対する理解が個人個人で異なる場合、知識や用語の統一をここで行っておきます。
例えば、「S3にファイルを保管して」といった議論をするにしても、S3に詳しい人と全く知らない人とでは思い描いているイメージが異なり、そもそも議論にならないことが発生すると不幸です。

ワークショップは社内でAWSに詳しい人(いわゆるCCoE)が主導したり、AWSパートナーを招いて開催します。

ファンクショナルデザインワークショップ

アプリケーション機能、業務面から現状構成とAWSを比較し、「こういうサービスを使うと利点がある」という検討をします。
AutoScaling構成をとりたいのでアプリケーションをストートレスにしよう、1機能1サーバーの原則に従い機能を分割しよう、といったことを検討します。

テクニカルデザインワークショップ

インフラ面から現状構成とAWSを比較し、「こういうサービスを使うと利点がある」という検討をします。
監視はCloudWatchに寄せる、バックアップサーバーは廃止、RDBMSはRDSを使うなどテクニカル要素の検討を行います。

マイグレーションデザインワークショップ

データコンバージョン、サーバーインテグレーションなど移行方式をします。
AWSにはSMS、DMS、SCT、ADS、Migration Hub、CloudEndure、VM Import/Export といったマイグレーション支援ツールがあります。
ツールを使った効率的な移行方式を検討します。

セキュリティデザインワークショップ

自社のセキュリティ要件、社内規定、業界標準など収集し
AWSのどのサービスを使って規制をかけるのかを検討します。

AWSのセキュリティ系サービスは充実しています。フル活用しましょう。

デプロイ・プロビジョニングワークショップ

インフラリソースやアプリケーションのデプロイ方式をクラウド最適化することを検討します。
アプリケーションの制約がある場合は平坦な道のりではないと思いますが、思い切って新しい技術を取り入れてみることをお薦めします。

運用モデルワークショップ

現行運用ドキュメントを見ながら、AWSで改善・省力化できる箇所を検討します。
AWS移行を契機にモダンな運用モデルを取り入れて、システムにも担当者にも優しい運用を目指します。

あるべき像の定義

叩き台になる「理想のアーキテクチャ」を作成する

ワークショップで検討、議論、勉強した知識から仮の構成図を作成します。
最初の実現度は70～80％程度でも大丈夫です。
叩きながら完成を目指します。

叩き台に対して実現性を議論する

叩き台となるアーキテクチャをベースに実現性を議論します。
仕様上の無理がないこと、アプリケーション改修が発生する場合は人的・時間的に無理がないことを確認します。
知見の無い技術に対しては技術検証を計画します。

データ移行方式案を作成する

継続的データ同期を採用して停止時間を最小にするのか、
静止点を確保して確実なデータ移行を行うのか、
2つを組み合わせてより良い移行方式を採用するか、様々な方式から選択します。

スキルが不足している部分は要員トレーニングの計画を立てる

アーキテクチャの実現性を議論していていると、スキル不足も浮き彫りになってくると思います。
不足している部分はトレーニングを実施しスキル習得を目指します。

AWSやAWSパートナーの外部トレーニングは有用です。
AWSは自習型のワークショップやBlackbelt、リファレンスアーキテクチャ、ベストプラクティスが多く用意されています。外部受講せずともスキル習得は可能です。

AWSスキルだけではなく、プロジェクトマネジメントやITILなど幅広く計画しておくと役に立つと考えます。

課題抽出

あるべき像が固まった段階で、実現性が不透明な事項、移行を阻害する事項、決めておかなければならない事項を洗い出し、影響度と緊急度を定義します。

移行戦略の策定

段取り八分の最終段階です。

PoC (概念実証)、技術検証の計画

抽出した課題のうち技術的課題を解決するための技術検証を行います。
解決できない場合は代替案を検討することになります。

要員トレーニング実施

計画したトレーニングを実施します。
効果的なトレーニングになることを祈っています！

移行対象の決定

移行対象を確定します。
これまでのタスクのなかで移行対象の絞り込みは完了しているはずです。
ここでは初期費用・月額費用を算出するために対象を確定します。

カットオーバー要件定義

移行にさいして制約や前提条件を掘り起こします。
移行期間中の停止許容時間、切り戻し条件、現行システムを稼働していられる最終期限なども定義しておきます。

マスタースケジュールの作成

これまでのタスクで全体的なスケジュールが見えていると思います。
マスタースケジュールとしてドキュメントにまとめておきます。

費用の算出

AWS利用料金の算出をします。
Savings Plans などの割引も考慮にいれます。

追加ソフトウェアが必要な場合は初期費用と保守費用を見積もります。

設計フェーズ以降で外部ベンダーの協力を得る場合は作業費用を見積もります。

カットオーバー後のシステム運用を外部ベンダーへ委託する場合は初期作業費用と月額費用を見積もります。

技術検証

検証計画に従って検証を行います。
可能な限り本番環境に近い環境で行うと良い結果が出ると思います。
検証結果を評価できるように各種メトリクスを取得しながら行います。

検証実施後は評価を行います。
事前に設定したKPIを満たしているか、ファンクション実装に問題はないか、継続的な運用に無理がないかなど、本稼働を想定して関係者で評価します。

設計

これ以降は一般的なITシステムでのタスクになりますので皆様よくご存知の工程になるかと思います。

要件定義

現行システムがある前提なので、ゼロから要件を掘り起こす必要はないと思いますが、AWSへ移行して変更になる要素があるはずなので今一度要件は整理しておくと良いと思います。

アーキテクチャ設計

ベストプラクティスが凝縮された AWS Well-Architected を参考にして設計を行います。
AWS Well-Architected フレームワークにはAWS上でシステムを効果的に稼働させるための設計原則や概念が記載されています。
この設計原則に従うだけでのかなりの効果が得られるはずです。