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

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

公共分野では2024年6月に閣議決定された[デジタル社会の実現に向けた重点計画](https://www.digital.go.jp/policies/priority-policy-program)にて、政府情報システムをガバメントクラウド上に構築することが求められているため、**オンプレシステムからのクラウドリフトやマネージドサービスへのクラウドシフトの流れがあります**。

上記流れに加え、以前AWSさん主催の研修に参加したのでその時の学びを定着させる意味でも、**AWS移行に関しての手法や戦略について、実案件での移行判断に役立つようにまとめようと思います**。
※研修資料でなく、[代替のBlackBelt資料](https://pages.awscloud.com/rs/112-TZM-766/images/AWS-Black-Belt_2023_Migration-7R_1208_v1.pdf)を使用してまとめてます。


## 目次
- [1.AWS移行のステップ](#1aws移行のステップ)
    - [1.1.Step1 Assess(評価)](#11step1-assess評価)
        - [1.1.1.AWSにおける移行パスと移行戦略](#111awsにおける移行パスと移行戦略)
        - [1.1.2.ビジネスケースの作成](#112ビジネスケースの作成)
    - [1.2.Step2 Mobilize(移行準備(計画化・基盤化))](#12step2-mobilize移行準備計画化基盤化)
    - [1.3.Step3 MigrateとModernize(移行とモダナイズ)](#13step3-migrateとmodernize移行とモダナイズ)
        - [1.3.1.オンライン移行](#131オンライン移行)
        - [1.3.2.オフライン移行](#132オフライン移行)
- [2.おわりに](#2おわりに)
- [参考URL](#参考url)

## 1.AWS移行のステップ
AWS移行のステップとして大きく分けて3つあります。以下で順に説明していきます。
参考：[移行戦略 (7R) の概要(AWS 移行準備シリーズ)](https://pages.awscloud.com/rs/112-TZM-766/images/AWS-Black-Belt_2023_Migration-7R_1208_v1.pdf)　P8
**Step1**. Assess（評価）
**Step2**. Mobilize（移行準備（計画化・基盤化））
**Step3**. Migrate & Modernize（移行 & モダナイズ）
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3879343/307864ca-371c-c588-bb0a-4b6d20820700.png)

### 1.1.Step1 Assess(評価)
参考：[移行戦略 (7R) の概要(AWS 移行準備シリーズ)](https://pages.awscloud.com/rs/112-TZM-766/images/AWS-Black-Belt_2023_Migration-7R_1208_v1.pdf)　P9
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3879343/3d9c890b-7a3f-c50c-55f3-87debc83b2d2.png)
Assessでは**お客様情報の収集、技術・ビジネス観点での調査やアセスメントを行い評価**します。その後、**AsIs、ToBeを示しクラウド移行することのビジネスメリットを整理・分析したレポートであるビジネスケースの作成が必要**です。

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

AWSでは[移行戦略 (7R) の概要(AWS 移行準備シリーズ)](https://pages.awscloud.com/rs/112-TZM-766/images/AWS-Black-Belt_2023_Migration-7R_1208_v1.pdf)というタイトルで移行戦略についてまとめられており、その中で**7Rという移行パス**（参考：P16、17）があります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3879343/c8ee2898-a52d-f865-c4a1-909a333df0f8.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3879343/5bbff5c0-2ac0-2698-a197-60a25d0bb7c1.png)

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

:::note info
①リロケート(Relocate)
:::
**VMware上の稼働環境を、OSやアプリに変更を加えずそのまま移行**
**現行がVMware、移行後もVMwareの場合**のパス
VMware Cloud on AWS を移行先環境として利用

:::note info
②リホスト(Rehost)
参考：[移行戦略 (7R) の概要(AWS 移行準備シリーズ)](https://pages.awscloud.com/rs/112-TZM-766/images/AWS-Black-Belt_2023_Migration-7R_1208_v1.pdf)　P24
:::
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3879343/3111d77e-7110-d486-318a-c54d1b8eac0b.png)
**OSやアプリに変更を加えずそのままEC2に置き換え**
とにかく**素早くAWSに移行したい場合に選択**するパス

:::note info
③リプラットフォーム(Replatform)
参考：[移行戦略 (7R) の概要(AWS 移行準備シリーズ)](https://pages.awscloud.com/rs/112-TZM-766/images/AWS-Black-Belt_2023_Migration-7R_1208_v1.pdf)　P25
:::
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3879343/078b06f1-8d6c-4cd4-718c-f76782a23f8d.png)
**アプリに変更を加えず、プラットフォームのみ最適化し移行**
リホスト(Rehost)と似ており、システム全体の構成が一緒で**一部基盤をマネージドに変える**パス
上記の例だと**DBをRDSに置き換え**、等
**デジタル庁の[GCASガイド](https://guide.gcas.cloud.go.jp/general/overview-explanation/)で示されるR1(Replatform)はリプラットフォーム(Replatform)に該当**

:::note info
④リファクタ(Refactor)
参考：[移行戦略 (7R) の概要(AWS 移行準備シリーズ)](https://pages.awscloud.com/rs/112-TZM-766/images/AWS-Black-Belt_2023_Migration-7R_1208_v1.pdf)　P26
:::
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3879343/9c056243-1381-4e38-a7fa-0e2ed7540bb7.png)
**アプリも含めて最適化し、全てマネージドサービスに移行**
**移行時のコスト・時間はかかるが、移行完了すればマネージドサービスのメリットを受けられる**
**デジタル庁の[GCASガイド](https://guide.gcas.cloud.go.jp/general/overview-explanation/)で示されるR2(Rebuild)はリファクタ(Refactor)に該当**

:::note info
⑤リパーチェス(Repurchase)
:::
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3879343/58105f51-7b84-7a62-529e-b9cb9ab66c08.png)

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

:::note info
⑥リテイン(Retain)
:::
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3879343/a3fb9d58-f7a8-bab8-88da-9a6aeb590692.png)

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

:::note info
⑦リタイア(Retire)
:::
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3879343/c932f705-50bc-4f56-f0b9-f990ec72b38c.png)
**システムをAWSに移行せず、廃止**
不要となったシステムが検出された場合には、移行せずに廃止を実施


:::note info
AWSによると**7割の案件がリホストやリプラットフォーム**を移行パスとして選択しているそうです。（参考：[移行戦略 7R) の概要(AWS 移行準備シリーズ)](https://pages.awscloud.com/rs/112-TZM-766/images/AWS-Black-Belt_2023_Migration-7R_1208_v1.pdf)　P22）
上記7つの移行パス考慮すると、例えば以下の戦略が考えられます
- システム全体を1つの移行戦略対象にせず、**システムをグループ化しグループごとに移行戦略を策定**
- **一時的にリホストし、その後リファクタの2段階移行**も
　⇒PJ的に2回案件が走るので案件側にもメリット
:::

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

- [Cloud Adoption Readiness Tool (CART)](https://cloudreadiness.amazonaws.com/#/cart)
    - **クラウド準備状況を簡易的にチェック**することのできるアセスメントツール
    - [Cloud Adoption Framework（CAF）](https://aws.amazon.com/jp/cloud-adoption-framework/)と呼ばれるフレームワークに基づいた**47個の質問による評価**
    ※CAF：**AWSへのクラウド導入にあたり、組織が持つスキルとプロセスにどのような変革が必要かを示すフレームワーク**。技術観点だけでなく、経営層・HR(人事)・統制（監査）等の6つのパースペクティブで成り立つ
    - お客様自身がセルフサービスで実施可能
※**英語形式のためお客様と一緒に回答推奨**
    - ビジネスケース作成のための情報取集で使用
　
- Migration Readiness Assessment (MRA)
    - CAFに基づくCARTよりも詳しい**80個の質問**
    - **1日がかりのワークショップ形式でお客様と実施すること推奨**
    - AWS担当 や AWSパートナー経由で提供可能
    - [AWS Migration Acceleration Program(MAP)](https://aws.amazon.com/jp/migration-acceleration-program/)適用には必須
    ※MAP：AWSに申請して審査が通れば、移行PJに対してAWSが資金面、技術面で支援してくれるサービス。ただし、移行コンピテンシー認定パートナー(MCP)を持っているパートナーのみが対象。申請内容は移行計画書、等でWAベースで書かれていることが重要。
    - ビジネスケース作成のための情報取集で使用
　
- [AWS Application Discovery Service (ADS)](https://www.youtube.com/watch?v=6SyBevYgEDI)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3879343/c6ccc7d8-52f1-84e6-19a4-072277711682.png)

    - **現行ITシステムのインベントリ情報収集サービス**
    - ビジネスケース作成のための情報取集で使用
　
- Migration Portfolio Assessment (MPA)
    - **システムのポートフォリオ（負荷情報等）を持ってる場合、AWS移行後のコスト試算だけを算出**してくれる
    - AWSパートナー企業はAPNポータルから利用可能
    - ビジネスケース作成のための分析・レポーティングで使用
　
- [AWS Migration Evaluator（旧TSO Logic）](https://aws.amazon.com/jp/migration-evaluator/)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3879343/97df09dd-8c65-3e77-4e99-48c25d57f1d1.png)

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

### 1.2.Step2 Mobilize(移行準備(計画化・基盤化))
参考：[移行戦略 (7R) の概要(AWS 移行準備シリーズ)](https://pages.awscloud.com/rs/112-TZM-766/images/AWS-Black-Belt_2023_Migration-7R_1208_v1.pdf)　P10
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3879343/c677fc20-37c1-0066-67d8-7fbf7723a3ae.png)
Assessフェーズでの調査を受けて**より詳細なビジネスケースとプロジェクト計画書を作成**します。
AssessフェーズとMobilizeフェーズでのビジネスケースの違いは以下です。
- Assessフェーズ：**AWS移行を実施するかしないかの判断**のためのビジネスケース
- Mobilizeフェーズ：AWS移行をするとして、**詳細な松竹梅**でのビジネスケース
    - Mobilizeフェーズでは以下の整理、より良い設計のための[AWS Well-Architected Framework](https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/framework/welcome.html)の使用が推奨されています
        - よくある技術課題（ノックアウト条件）への対応
        - セキュリティ検討（ネットワーク保護をどのように実施するか、暗号化要件は何か、等）
        - 移行計画
        - 現行運用モデルの整理と移行後運用モデルのアップデート方針

ビジネスケース作成に活用できる情報取集やレポーティングのためのツールを紹介します。
　
- [AWS Migration Hub](https://aws.amazon.com/jp/migration-hub/)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3879343/168a47e3-1754-ff03-c2f9-41a1263edd8b.png)

    - **移行の進行状況を1つのダッシュボードで追跡管理**可能
    - Assessフェーズでご紹介した[AWS Application Discovery Service (ADS)](https://www.youtube.com/watch?v=6SyBevYgEDI)や[AWS Migration Evaluator（旧TSO Logic）](https://aws.amazon.com/jp/migration-evaluator/)、自前の仕組みで収集したデータを吸い上げる

### 1.3.Step3 MigrateとModernize(移行とモダナイズ)
参考：[移行戦略 (7R) の概要(AWS 移行準備シリーズ)](https://pages.awscloud.com/rs/112-TZM-766/images/AWS-Black-Belt_2023_Migration-7R_1208_v1.pdf)　P11
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3879343/49e1b2f1-8aeb-cf34-649f-b8b85d7a2760.png)
**Mobilizeで作成したプロジェクト計画を実行**します。Migrateは主にリホスト、Modernizeは主にリファクタです。また、Modernizeは移行作業または移行後の一部として実行されるケースが多いです。
#### 1.3.1.オンライン移行
- [AWS Application Migration Service (AWS MGN)](https://aws.amazon.com/jp/application-migration-service/)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3879343/9b51f50b-ebcd-f758-8818-1bb05ba72ca6.png)

    - **最小限のダウンタイムでサーバのリホストによるクラウド移行**を実現
    - 移行対象サーバをグループ化し、**グループごとの移行も可能**
    - 4ステップでサーバを移行可能です
        1. 移行元サーバにエージェントをインストール
            エージェントインストールによりレプリケーションがスタート
        1. 継続的なレプリケーション
            サーバ全体を暗号化された通信でAWS上のレプリケーションサーバにレプリケート
            この際、レプリケーションサーバに紐づくEBSボリューム、EBSスナップショットを作成
            レプリケーションにはTCP Portを開ける必要あり
        1. テストの実行
            移行先環境（上記1,2と別VPC想定）にてカットオーバーと同プロセスでテストインスタンス起動テスト
            スナップショットに対して、EC2インスタンスとして使えるような変換作業をコンバータインスタンスが行う
            ※コンバータインスタンスは必要なときにだけ自動起動、終わると自動停止
        1. カットオーバーの実行
            移行本番の作業として、3と同様コンバータインスタンスがレプリケーションされているデータに基づいてサーバ起動
　
- [AWS Database Migration Service (AWS DMS)](https://aws.amazon.com/jp/dms/)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3879343/c4df490d-0c10-0569-9c8f-2d05d5cb3cc6.png)

    - **同種、異種間のDBをダウンタイムなし（約10秒間で1回sync）移行**可能
    - 異種間の移行ではスキーマ変換を提供
    ※**DB移行の検証（データが移行されてるか）まで実施するが、SQL出力までは検証されない**（DBエンジンごとの方言は考慮されない）
　
- [AWS Schema Conversion Tool (SCT)](https://aws.amazon.com/jp/dms/schema-conversion-tool/)
    - **スキーマコンバートなどのDB移行をサポートする無償のデスクトップアプリケーション**
    - コンバートが失敗したときの詳細を出力可能
    - 手動移行の場合の工数見積もりのレポートを出力可能
　
- [AWS Transfer Family](https://aws.amazon.com/jp/aws-transfer-family/?nc=sn&loc=0&refid=2f43f961-f97e-405b-a54f-b3d290fb3d9f&trkcampaign=builders-online-series)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3879343/376512dd-a528-b846-ceaa-8fecd8736b59.png)

    - **シンプルで安全かつスケーラブルなファイル転送により、データの管理と共有を容易に実現**
    - FTPサーバのマネージドサービス
    - FTPサーバなのでネット上どこからでもアクセス可能のため、複数拠点からデータ移行可能
    - 転送スピードは速くはない
    - [Amazon S3](https://aws.amazon.com/jp/s3/)または[Amazon Elastic File System(EFS)](https://aws.amazon.com/jp/efs/)にファイル転送
　
- [AWS DataSync](https://aws.amazon.com/jp/datasync/)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3879343/36414a64-476c-7029-2991-e2c047179641.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](https://aws.amazon.com/jp/snowball/)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3879343/0ac78c79-421b-de79-4dc4-ee1a08d3e4d5.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](https://aws.amazon.com/jp/storagegateway/)を使用することで、S3用のメタデータにエンコードできる
　
- [AWS Snowcone](https://aws.amazon.com/jp/snowcone/)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3879343/0fac3499-e05e-f06e-d3b3-92fdb27a6719.png)

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

:::note info
**オンライン、オフライン移行の選択指針**
- **オンライン**が好ましい
    - より早くデータを移行したい
    - 帯域幅の信頼性が高く、データがオンラインですぐに移動可能
    - [Direct Connect（DX）](https://aws.amazon.com/jp/directconnect/)接続を迅速に導入できる
- **オフライン**が好ましい
    - ネットワークの帯域が限られている、または不安定
    - 移動中にデータをオフラインにできる
    - AWSでデータが使えるようになるまで数日単位で待てる
:::

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

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

## 参考URL
- [移行戦略 (7R) の概要(AWS 移行準備シリーズ)](https://pages.awscloud.com/rs/112-TZM-766/images/AWS-Black-Belt_2023_Migration-7R_1208_v1.pdf)