【レポート】【初級】クラウド大規模移行の始め方 ～成功の秘訣は企画・評価・立案フェーズにあり～ #AWSSummit

みなさま Xin chao。
2019/6/12(水)～14(金) の期間で開催されている、AWS Summit 2019 Tokyo からセッションをレポートします。
このレポートは、「【初級】クラウド大規模移行の始め方 ～成功の秘訣は企画・評価・立案フェーズにあり～」です。

概要

クラウド利用にも慣れ始め、大規模移行を検討する段階に来られたお客様、この先の進め方に不安はありませんか？大規模移行では、コスト、技術と制約、移行順序などの様々な要素を考慮した移行計画立案が成功の秘訣です。本セッションでは、この移行計画の立て方を、企画・評価・立案の観点で、説明いたします。企画フェーズのTCO分析、評価フェーズの移行対象と移行可否の分析、立案フェーズの移行戦略策定について、AWSプロフェッショナルサービスの移行支援経験を元に、“安全で迅速な”クラウド移行のベストプラクティスを紹介します。

• AWS への大規模以降の全体像と、その中のシステム移行計画の具体的な進め方を理解していただいて、皆様の活動に活かしてていただくこと

スピーカー

アマゾン ウェブ サービス ジャパン株式会社 プロフェッショナルサービス本部 コンサルタント 黒田 賢一 様

レポート

AWS への大規模以降の全体像

AWS への大規模移行とは

• 移行は手段であり、目的は「ビジネス価値の享受」
  • 俊敏性/開発の生産性
  • データセンター統廃合
  • コスト削減

AWS への大規模移行の全体像

• 移行準備 - 移行先の基盤準備も重要
  • 企画フェーズ
  • 評価フェーズ
  • 立案フェーズ
• 移行実施
• CCoE (＝Cloud Center of Excellence) も重要

移行先の基盤準備

• セキュリティ策定
• 運用モデル策定
• インフラ標準化策定

インフラ標準化の例 (ネットワーク構成)

• 拠点とデータセンターのプライベートネットワークを AWSにセキュアに拡張

インフラ標準化の例 (ネットワークサービス)

• VPC
• DX など

システム移行計画

• 企画フェーズ
  • ビジネス価値の定義
  • 情報収集と分析
• 評価フェーズ
  • 移行難易度判断 / 移行パターン
  • システムごとのビジネス価値の充足度分析
• 立案フェーズ
  • 移行タイミング判断
  • システム間の関連性
  • 移行計画概要立案

移行計画の企画フェーズ

企画フェーズ概要

• 保有するシステムのすべて、もしくは大部分をAWSへ移行した場合に、ビジネス価値をどの程度享受できる可能性があるのか把握し、クラウド既往の意思決定を行う
  • ビジネス価値の定義
  • 情報取集と分析
  • 「コストを削減したい」では社内コンセンサスが取れない

ビジネス価値の定義

• 具体的な目標の設定 - クラウド移行の成否の判断基準となる
  • eg) TCO を 5年で 20%削減
  • eg) 5年でデータセンターを 4つから 2つに削減
• ビジネス価値の優先付け
• 検討範囲 (全社レベル / 事業部レベル / 個別システム) を明確にする

既存システムの情報収集と分析 (情報収集)

• お客様が管理しているサーバー台帳をいただき 不足部分はヒアリング
• ツールを用いて情報収集する
  • TSOLogic
  • AWS Application Descovery Service
• ビジネス的な特性 (システム更改時期など) はヒアリングを実施する

既存システムの情報収集と分析 (分析)

• 収集した情報を分析し、ビジネス価値を享受できるか判断する

移行計画の評価フェーズ

評価フェーズ概要

• 移行対象システムの評価を様々な観点で行い 移行計画立案のための準備を行う
  • 移行難易度判断 / 移行パターン
  • システムごとのビジネス価値の充足性分析

移行難易度の判断

	項目1	項目2	項目3	項目4
システムA		〇		△
システムB				〇

eg) 項目4 : OS が AWS 側で用意されていない → 回避策 : OS を変更する

移行パターンの評価 (6つの移行パターン)

• Re-Host (単純移行) - オンプレサーバーを AWS へ
• Re-Platform (プラットフォーム再編) - バージョンアップ
• Refactor (再設計) - コンテナサーバーレス
• Re-Purchase (再購入) - SaaS
• Retire (使用停止)
• Retain (保持) - 移行してもビジネス価値を生まない

Re-Host とは

• 同一構成のまま 単純移行する
• ルールを用いて簡単に移行可能
• eg) サーバー＋ディスク → EC2＋EBS

Re-platform とは

• アプリケーションのコアアーキテクチャを変更せず プラットフォームを再構築
• eg) LB＋Web＋DB → ELB＋EC2＋RDS

Refactor とは

• 拡張性や俊敏性などのクラウドのメリットを享受するためにアプリケーションの改修を行う
• eg) Web＋DB → S3＋Cognito＋API Gateway＋Lambda＋DynamoDB

移行パターンの評価

	大方針の選定例
Re-Host	プラットフォームの再構築が難しい
Re-Platform	OSやミドルウェアのサポート切れが近い
Refactor	システムの更新頻度が非常に高い

システムごとのビジネス価値の充足度分析

• AWS への移行によって どれだけビジネス価値を充足するかをシステムごとに評価する
  • コスト削減
  • 俊敏性 / 開発の生産性
• 移行の実現可能性の評価軸として 様々な指標を設定可能

移行計画の立案フェーズ

立案フェーズ概要

• 移行計画の概要を立案し、具体的な移行プロジェクト計画を立てる
  • 移行タイミング判断
  • システム間の関連性
• 移行計画概要立案

移行タイミング

• ビジネス価値を考慮して 移行タイミングを検討する

システム間の関連性

• システム間の関連性を考慮する必要がある
  • 他システムとの関連性/依存度が高い → 別々のタイミングで移行すると 一部がオンプレ 一部が AWS など 問題を起こすリスクが高くなるので同じタイミングで移行
  • 他システムとの関連性/依存度が低い → 初期に移行し 経験を積む
• データ収集ツールによって、システム間の依存度を把握することもできる

移行計画概要立案

• 評価フェーズと立案フェーズの結果から移行計画概要を立案する
  • 評価フェーズ
  • 移行難易度判断 / 移行パターン
  • システムごとのビジネス価値の充足性分析
  • 立案フェーズ
  • 移行タイミング判断
  • システム間の関連性

まとめ

• 移行は手段であり、目的は「ビジネス価値の享受」
  • 企画：享受したいビジネス価値を定義 と 実現可能性の判断
  • 評価：各システムごとに多角的な分析
  • 立案：いくつかの事項を考慮と 移行計画概要立案
• 最終的に 移行計画概要を立案する

感想

ついつい AWS への移行という「手段」が「目的」となってしまいがちですが、あくまで目的は「ビジネス価値の教授」であるということを、改めて考えさせられたセッションでした。