Go to Qiita Advent Calendar 2024 Top
LoginSignup
15
10

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@tsurunoqiita(Yuma Tsurugasaki)inNTT DATA P&S TSG Cloud Community

オンプレからのAWS移行手法と移行戦略

Last updated at Posted at 2024-11-11

0.はじめに

NTTデータの鶴ヶ崎です。
公共分野の技術戦略組織に所属しており、普段はクラウド（主にAWS）を用いたシステム構築等を行っています。

公共分野では2024年6月に閣議決定されたデジタル社会の実現に向けた重点計画にて、政府情報システムをガバメントクラウド上に構築することが求められているため、オンプレシステムからのクラウドリフトやネイティブサービスへのクラウドシフトの流れがあります。

上記流れに加え、以前AWSさん主催の研修に参加したのでその時の学びを定着させる意味でも、クラウド移行に関しての手法や戦略についてまとめようと思います。
※研修資料でなく、代替のBlackBelt資料を使用してまとめてます。

目次

1.AWS移行のステップ

AWS移行のステップとして大きく分けて3つあります。以下で順に説明していきます。
参考：移行戦略 (7R) の概要(AWS 移行準備シリーズ)　P8
Step1. Assess（評価）
Step2. Mobilize（移行準備（計画化・基盤化））
Step3. Migrate & Modernize（移行 & モダナイズ）
image.png

1.1.Step1 Assess(評価)

参考：移行戦略 (7R) の概要(AWS 移行準備シリーズ)　P9
image.png
Assessではお客様情報の収集、技術・ビジネス観点での調査やアセスメントを行い評価します。その後、AsIs、ToBeを示しクラウド移行することのビジネスメリットを整理・分析したレポートであるビジネスケースの作成が必要です。

1.1.1.AWSにおける移行パスと移行戦略

上記画像の移行方法検討にてAWSが提供する7Rという移行パスを使用して移行方針を検討します。以下で順に説明します。

AWSでは移行戦略 (7R) の概要(AWS 移行準備シリーズ)というタイトルで移行戦略についてまとめられており、その中で7Rという移行パス（参考：P16、17）があります。
image.png
image.png

7つの移行パスを順に説明します。

①リロケート(Relocate)

VMware上の稼働環境を、OSやアプリに変更を加えずそのまま移行
現行がVMware、移行後もVMwareの場合のパス
VMware Cloud on AWS を移行先環境として利用

②リホスト(Rehost)
参考：移行戦略 (7R) の概要(AWS 移行準備シリーズ)　P24

image.png
OSやアプリに変更を加えずそのままEC2に置き換え
とにかく素早くAWSに移行したい場合に選択するパス

③リプラットフォーム(Replatform)
参考：移行戦略 (7R) の概要(AWS 移行準備シリーズ)　P25

image.png
アプリに変更を加えず、プラットフォームのみ最適化し移行
リホスト(Rehost)と似ており、システム全体の構成が一緒で一部基盤をマネージドに変えるパス
上記の例だとDBをRDSに置き換え、等
デジタル庁のGCASガイドで示されるR1(Replatform)はリプラットフォーム(Replatform)に該当

④リファクタ(Refactor)
参考：移行戦略 (7R) の概要(AWS 移行準備シリーズ)　P26

image.png
アプリも含めて最適化し、全てマネージドサービスに移行
移行時のコスト・時間はかかるが、移行完了すればマネージドサービスのメリットを受けられる
デジタル庁のGCASガイドで示されるR2(Rebuild)はリファクタ(Refactor)に該当

⑤リパーチェス(Repurchase)

image.png

SaaS(ServiceNow等)やパッケージの適用を伴って移行

⑥リテイン(Retain)

image.png

システムをAWSに移行せず保持
移行における課題（リファクタリング工数や特定の機能／デバイスの利用）が大きい場合に一度移行を取りやめ、環境を保持

⑦リタイア(Retire)

image.png
システムをAWSに移行せず、廃止
不要となったシステムが検出された場合には、移行せずに廃止を実施

AWSによると7割の案件がリホストやリプラットフォームを移行パスとして選択しているそうです。（参考：移行戦略 7R) の概要(AWS 移行準備シリーズ)　P22）
上記7つの移行パス考慮すると、例えば以下の戦略が考えられます

  • システム全体を1つの移行戦略対象にせず、システムをグループ化しグループごとに移行戦略を策定
  • 一時的にリホストし、その後リファクタの2段階移行も
    　⇒PJ的に2回案件が走るので案件側にもメリット

1.1.2.ビジネスケースの作成

ビジネスケース作成に活用できる情報収集やレポーティングのためのツールを紹介します。

  • Cloud Adoption Readiness Tool (CART)

    • クラウド準備状況を簡易的にチェックすることのできるアセスメントツール
    • Cloud Adoption Framework（CAF）と呼ばれるフレームワークに基づいた47個の質問による評価
      ※CAF：AWSへのクラウド導入にあたり、組織が持つスキルとプロセスにどのような変革が必要かを示すフレームワーク。技術観点だけでなく、経営層・HR(人事)・統制（監査）等の6つのパースペクティブで成り立つ
    • お客様自身がセルフサービスで実施可能
      ※英語形式のためお客様と一緒に回答推奨
    • ビジネスケース作成のための情報取集で使用
      　

  • Migration Readiness Assessment (MRA)

    • CAFに基づくCARTよりも詳しい80個の質問
    • 1日がかりのワークショップ形式でお客様と実施すること推奨
    • AWS担当 や AWSパートナー経由で提供可能
    • AWS Migration Acceleration Program(MAP)適用には必須
      ※MAP：AWSに申請して審査が通れば、移行PJに対してAWSが資金面、技術面で支援してくれるサービス。ただし、移行コンピテンシー認定パートナー(MCP)を持っているパートナーのみが対象。申請内容は移行計画書、等でWAベースで書かれていることが重要。
    • ビジネスケース作成のための情報取集で使用
      　

  • AWS Application Discovery Service (ADS)
    image.png

    • 現行ITシステムのインベントリ情報収集サービス
    • ビジネスケース作成のための情報取集で使用
      　

  • Migration Portfolio Assessment (MPA)

    • システムのポートフォリオ（負荷情報等）を持ってる場合、AWS移行後のコスト試算だけを算出してくれる
    • AWSパートナー企業はAPNポータルから利用可能
    • ビジネスケース作成のための分析・レポーティングで使用
      　

  • AWS Migration Evaluator（旧TSO Logic）
    image.png

    • 迅速かつ低コストで移行元環境の情報収集、レポーティングを実施
      • ノードのシステム負荷情報を吸い上げるため、EC2へ移行時の予測価格をAWS Pricing Calculator算出可能
      • サーバを用意してるけど使ってないゾンビサーバの特定可能
    • AWS専任担当者を通じて提供（お客様のみ/パートナー企業のみでのセルフ利用は不可）
    • ビジネスケース作成のための分析・レポーティングで使用

1.2.Step2 Mobilize(移行準備(計画化・基盤化))

参考：移行戦略 (7R) の概要(AWS 移行準備シリーズ)　P10
image.png
Assessフェーズでの調査を受けてより詳細なビジネスケースとプロジェクト計画書を作成します。
AssessフェーズとMobilizeフェーズでのビジネスケースの違いは以下です。

  • Assessフェーズ：AWS移行を実施するかしないかの判断のためのビジネスケース
  • Mobilizeフェーズ：AWS移行をするとして、詳細な松竹梅でのビジネスケース
    • Mobilizeフェーズでは以下の整理、より良い設計のためのAWS Well-Architected Frameworkの使用が推奨されています
      • よくある技術課題（ノックアウト条件）への対応
      • セキュリティ検討（ネットワーク保護をどのように実施するか、暗号化要件は何か、等）
      • 移行計画
      • 現行運用モデルの整理と移行後運用モデルのアップデート方針

ビジネスケース作成に活用できる情報取集やレポーティングのためのツールを紹介します。
　

1.3.Step3 MigrateとModernize(移行とモダナイズ)

参考：移行戦略 (7R) の概要(AWS 移行準備シリーズ)　P11
image.png
Mobilizeで作成したプロジェクト計画を実行します。Migrateは主にリホスト、Modernizeは主にリファクタです。また、Modernizeは移行作業または移行後の一部として実行されるケースが多いです。

1.3.1.オンライン移行

  • AWS Application Migration Service (AWS MGN)
    image.png

    • 最小限のダウンタイムでサーバのリホストによるクラウド移行を実現
    • 移行対象サーバをグループ化し、グループごとの移行も可能
    • 4ステップでサーバを移行可能です
      1. 移行元サーバにエージェントをインストール
        エージェントインストールによりレプリケーションがスタート
      2. 継続的なレプリケーション
        サーバ全体を暗号化された通信でAWS上のレプリケーションサーバにレプリケート
        この際、レプリケーションサーバに紐づくEBSボリューム、EBSスナップショットを作成
        レプリケーションにはTCP Portを開ける必要あり
      3. テストの実行
        移行先環境（上記1,2と別VPC想定）にてカットオーバーと同プロセスでテストインスタンス起動テスト
        スナップショットに対して、EC2インスタンスとして使えるような変換作業をコンバータインスタンスが行う
        ※コンバータインスタンスは必要なときにだけ自動起動、終わると自動停止
      4. カットオーバーの実行
        移行本番の作業として、3と同様コンバータインスタンスがレプリケーションされているデータに基づいてサーバ起動
        　

  • AWS Database Migration Service (AWS DMS)
    image.png

    • 同種、異種間のDBをダウンタイムなし（約10秒間で1回sync）移行可能
    • 異種間の移行ではスキーマ変換を提供
      ※DB移行の検証（データが移行されてるか）まで実施するが、SQL出力までは検証されない（DBエンジンごとの方言は考慮されない）
      　

  • AWS Schema Conversion Tool (SCT)

    • スキーマコンバートなどのDB移行をサポートする無償のデスクトップアプリケーション
    • コンバートが失敗したときの詳細を出力可能
    • 手動移行の場合の工数見積もりのレポートを出力可能
      　

  • AWS Transfer Family
    image.png

    • シンプルで安全かつスケーラブルなファイル転送により、データの管理と共有を容易に実現
    • FTPサーバのマネージドサービス
    • FTPサーバなのでネット上どこからでもアクセス可能のため、複数拠点からデータ移行可能
    • 転送スピードは速くはない
    • Amazon S3またはAmazon Elastic File System(EFS)にファイル転送
      　

  • AWS DataSync
    image.png

    • オンプレからAWSストレージサービスへデータ移行
    • オンプレ側にAWS DataSync Agentが必要
    • AWS DataSync Agent(オンプレ側)とAWS DataSync(AWS側)の転送スピードが速い（10倍くらい転送効率が変わると研修講師が仰ってました）
      • VPC内のEC2にAgentを導入し、同じくVPC内のEC2にデータ移行するのはAWS上をデータが移動するだけのため、転送スピードの恩恵を受けにくい
    • 移行元データの削除は実施されないため、別途削除作業が必要
      ※Datasyncがファイル整合性チェックはするので、そのまま削除可能

1.3.2.オフライン移行

  • AWS Snowball Edge
    image.png

    • ハードウェアアプライアンスによるオンプレからクラウドへ回線に依存しない大量データ移行サービス
    • ケーブルにハードウェアアプライアンスを繋いでデータを入れる
    • これまでは容量が80TBだったが、210TBの新型がある
    • NFS、S3 APIの2種類のプロトコルを事前に選ぶ必要がある
    • 移行元メタデータが消えてしまうため注意
      • データの置き場所によってメタデータの形式は様々
        • Linux(NFS)メタデータ
          • タイムスタンプ
          • UserID、GroupID
          • POSIXパーミッション
        • Windows（SMB）メタデータ
          • タイムスタンプ
          • オーナーとグループセキュリティID(SIDs)
          • 標準ファイル属性（Read-Only(R)やArchive(A)など)
          • NTFS directory access lists(DACLs)
          • NTFS system access control lists(SACLs)
        • オブジェクトストレージ
          • 各実装によって独自のメタデータ(x-amz-server-side-encriptionなど)
      • Linux(NFS)メタデータはS3ユーザ定義メタデータと親和性高いので移行可能
      • Windows（SMB）メタデータを移行させるにはAWS Storage Gatewayを使用することで、S3用のメタデータにエンコードできる
        　

  • AWS Snowcone
    image.png

    • 小型、ポータブル、高耐久でセキュアなエッジ処理、データ移行向けデバイス
    • 8TBのストレージ容量
    • NFSプロトコル専用
    • Snowball Edgeと同様、移行元メタデータが消えてしまうため注意

オンライン、オフライン移行の選択指針

  • オンラインが好ましい
    • より早くデータを移行したい
    • 帯域幅の信頼性が高く、データがオンラインですぐに移動可能
    • Direct Connect（DX）接続を迅速に導入できる
  • オフラインが好ましい
    • ネットワークの帯域が限られている、または不安定
    • 移動中にデータをオフラインにできる
    • AWSでデータが使えるようになるまで数日単位で待てる

2.おわりに

クラウド移行をご検討中の方の参考になれば幸いです。

※本ブログに記載した内容は個人の見解であり、所属する会社・組織とは関係ありません。また、誤った情報が含まれる可能性もありますのでご留意ください。

参考URL

15
10
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
15
10

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?