AWSへの移行プロジェクトを始めてみよう【Builders Online】
オンプレサーバからAWSへの移行を考えている方も結構いるのではないでしょうか。
私もその中の1人で、どのようにしたら、うまく移行できるかというヒントを得られればと思いセッションを受講しました。
セッション内容
何のために移行するのか?
ただクラウド移行をしたいと申請しても、なかなか承認しにくい。
承認を得るために、やるべきこと
- 自社の目標(中期経営計画や部門戦略や目標など)をきちんと確認する
- 次の移行目的の6つの柱と自社の目標を突合する
- コストダウン
- 耐障害性
- 俊敏性
- 運⽤負荷低減
- グローバル展開
- イノベーション
- 上記の目的に合わせたKPIを設定する
移行をどう計画すればよいか?
いきなりクラウドネイティブを目指すのではなく、リフト&シフトを検討する
やるべきこと
- アプリを分類してグループ化する(評価軸案:業務別、特性別)
- 影響度評価をしてアプリの移行順序を決める(評価軸案:移行メリット、プロジェクトリスク)
クラウドをどのような構成にすればよいか?
7R(Rehost、Relocate、Replatform、Refactor、Retire、Retain、Repurchase)で考える
- Rehost/Relocate:単純移行
- Replatform:PFの更新
- 単純移行と比較してAWSのメリットを受けられる量が増える
- Refactor: アプリケーションの書き換え
- 最初からトライするのはあまりおすすめしない。
- アプリの書き換えが必要である
AWSには、2つのフレームワークがある
- CAF(Cloud Adoption Framework)
- 6つの軸で移行を判断する
- Well-Architected Framework
- 設計の考え方におけるベストプラクティス
- 6つの評価軸
移行に便利なツールはどれか?
- サーバー移行
- AWS Application Migration Service(MGN)
- 物理マシンおよび仮想マシンを移行する
- AWS Application Migration Service(MGN)
- DB移行
- AWS Database Migration Service(DMS)
- データベースを最小限のダウンタイムで移行できる
- AWS Database Migration Service(DMS)
- データ移行
- AWS DataSync
- オンプレミスのファイルをクラウドへ転送する
- AWS Snowball Edge / AWS Snowcone
- 物理筐体でオンプレミスのファイルをクラウドへ大量のデータ転送する
- AWS DataSync
移行プロジェクトをどう進めるのか?
オンプレでは制約が多く、机上検討がとても大事だった。
一方で、 AWSへ移行できれば、制約から解放されて、次のように進めることができる
- 実験を繰り返すことが可能
- 動くものを確認しながら進められる(試す、計測する)
- 従量課金
- インフラの構成や設定をコード化で再現が簡単になる
まとめ
AWS Snowball Edge / AWS Snowconeの物理配送が、とても印象的でした。
AWSで物理筐体を用意していることに驚きました。
次回はIoTプラットフォーム関連のセッションを記事にします。
ディスカッション
コメント一覧
まだ、コメントがありません