システム移行ガイド(AWS編)

システムをガバメントクラウドに移行する際に必要となるプロセスにおいて、検討すべきAWSサービスを理解するための文書である。

システム移行の全体像

システム移行においては、現在の状態を把握し、移行計画を検討し、実行に移すプロセスが必要である。
それぞれのプロセスにおいて、AWSの活用を含めて検討が必要なタスク(図1の橙字)を本書に示す。

図:01 システム移行の全体像

移行におけるAWSサービスの活用

全体管理

オンプレミス環境からクラウドへデータを移行する際には、アプリケーションポートフォリオと移行戦略に基づいた計画を立て、実行する必要がある。複数のコンポーネントを移行するとなると、ビジネスゴール、ITコスト、生産性の向上などを考慮した上で継続的な移行の管理が必要となる。そのような移行の全体管理をする場合に活用できるサービスを以下に示す。

• AWS Migration Hub
  AWS Migration Hubを使用すると、既存のサーバーを1か所検出することで、AWSおよびパートナーの複数ソリューション間における移行計画の迅速な策定、実行、および各アプリケーションの移行ステータスの追跡を含む全ての移行段階を1つのダッシュボードで一元的に管理することができる。また、オンプレミスサーバおよびアプリケーションに関する情報をインポートをすることでより詳細な情報の収集ができ、アプリケーション移行のステータスを追跡することもできる。AWS Migration Hubを使用することで、大規模な移行に伴う手動作業の省略ができ、AWSのすべてのユーザーが無料で利用できることから時間とコストの削減もできる。
  • AWS Migration Hubの概要、使用開始方法については以下を参照すること。
    [AWSドキュメント：AWS Migration Hub とは?]
    https://docs.aws.amazon.com/ja_jp/migrationhub/latest/ug/whatishub.htmlopen_in_newOpens in new tab
  • AWS Migration Hubの特徴については以下を参照すること。
    [AWS：AWS Migration Hub の特徴]
    https://aws.amazon.com/jp/migration-hub/features/open_in_newOpens in new tab

　

インフラ資産把握

オンプレミス環境からクラウドへデータを移行する際、既存システムの情報が整理・更新・可視化がされていない場合や、既存システムのインフラやアプリケーションから何をクラウドへ移行するのかの情報が必要な場合がある。このような既存システムの効率的な情報の収集が必要な場合に活用できるサービスを以下に示す。
なおガバメントクラウドでは既存のライセンスをクラウドに持ち込むBYOLは原則禁止となる。

• AWS Application Discovery Service
  AWS Application Discovery Serviceを使用すると、AWSとは別のIT環境で稼働するサーバーの設定、使用状況および動作のデータをスナップショットとして取得し、そのデータを基にAWSへの移行計画をサポートすることができる。AWS Application Discovery Serviceの特徴としては、AWSへの転送中およびデータストアに保管中のデータの暗号化によってデータを保護することができること、AWS Migration Hubと統合されていることから移行の進捗の追跡を簡素化できること、およびAmazon Athenaを利用して収集したデータを分析することでシステムのパフォーマンスや依存関係を確認できるといったことが挙げられる。また、AWS Application Discovery ServiceにはVMware環境に対応したエージェントレス型と、WindowsとLinuxに対応したエージェント型がある。エージェントレス型の処理可能データ量は10GB/日までの上限があり、上限に達すると翌日まで処理ができなくなるという制限がある。エージェントベース型は処理可能データ量が10GB/日までであることに加え、AWS認定パートナーのみが利用可能であるという制限がある。
  • AWS Application Discovery Serviceの概要については以下を参照すること。
    [AWS：AWS Application Discovery Service]
    https://aws.amazon.com/jp/application-discovery/open_in_newOpens in new tab
  • AWS Application Discovery Serviceの特徴については以下を参照すること。
    [AWS：AWS Application Discovery Service の特徴]
    https://aws.amazon.com/jp/application-discovery/features/?nc=nsb&pg=lnopen_in_newOpens in new tab

　

経済性評価

オンプレミス環境からクラウドへ移行する際に方向性のあるビジネスケースを作成するため、現状の分析や目標を定義して、費用対効果の高い俊敏性のある移行準備計画を立てる必要がある。そのような場合に活用できるサービスを以下に示す。

• AWS Migration Evaluator
  Migration Evaluatorを使用すると、データ収集に加え、組織が実行しているオンプレミスのシステムを評価し、AWSへの移行の際のコストを予測することですべての段階の移行計画と方向性のあるビジネスケースの作成をサポートする。Migration Evaluatorの機能であるQyuck Insihtsを使用すと、AWSで再ホストするための予測コストと、インフラストラクチャおよびソフトウェアライセンスごとのコスト内訳を示すことが可能である。Migration Evaluatorは現在、ストレージアプライアンス、メインフレーム、ルーターなどのネットワークデバイスのモニタリングやレポート向けには設計されていない。
  • Migration Evaluatorの概要については以下を参照すること。
    [AWS：Migration Evaluator]
    https://aws.amazon.com/jp/migration-evaluator/open_in_newOpens in new tab
    [AWS：Migration Evaluator の特徴]
    https://aws.amazon.com/jp/migration-evaluator/features/open_in_newOpens in new tab

　

アーキテクチャの検討

アーキテクチャの検討の際にはReplatform、Rebuild、Repurchaseの3パターンを意識した検討を行うこと。Rehost(リフト＆シフト)ではガバメントクラウドを利用できない。
Replatform、Rebuildの基本形のアーキテクチャはサンプルIaCファイルを参照すること。
また移行テストについてはAWSの責任範囲は実施しないなど移行パターンに合わせて必要なテストのみ実施し、移行にかかるコストを最適化すること。

図:02 ガバメントクラウドへの移行パターン

Replatform

Replatformにおいて活用可能なAWSサービスを以下に示す。
表:01 ReplatformにおけるAWSサービスの活用（主要なサービスを太字で示す）

データベースのエディション

オンプレミス環境にて特定のデータベース管理システム（以下DBMS）を使用している既存のアプリケーションをAWSのクラウド上に移行する際に、AWS上でそのままサポート機能を使用できるDBMSおよび各エディションと、AWS上ではサポート機能が使用できなくなるDBMSおよび各エディションがある。
Amazon RDSはAWSのクラウド上でDBMSのセットアップ、運用、スケーリングをするフルマネージド型のデータベースサービスであり、複数のDBエンジンから選択・デプロイできる。
現在一般的に使用されているDBMSをAmazon RDS上にデプロイしたデータベースの中で、有償ライセンスであり、かつ堅牢性の高い製品には、Oracle DatabaseをデプロイしたAmazon RDS for Oracleと、SQL ServerをデプロイしたAmazon RDS for SQL Serverの2つの製品がある。
各エディションによってはAWS上でのサポートがされていない場合があるため、それぞれAWS上で使用可能なエディションについては以下のサイトを参照すること。

• Amazon RDS for Oracleでサポートされるエディションについては以下サイト内の「Amazon RDS for Oracle では、Oracle Database のどのエディションを利用できますか?」を参照すること。
  [AWS：Amazon RDS for Oracle のよくある質問]
  https://aws.amazon.com/jp/rds/oracle/faqs/open_in_newOpens in new tab
• Amazon RDS for SQL Serverでサポートされるエディションについては以下サイト内の「Q: Amazon RDS for SQL Server はどの SQL Server Edition をサポートしていますか?」を参照すること。
  [AWS：Amazon RDS for SQL Server のよくある質問]
  https://aws.amazon.com/jp/rds/sqlserver/faqs/open_in_newOpens in new tab

Rebuild

Rebuildにおいて活用可能なAWSサービスを以下に示す。
表:02 RebuildにおけるAWSサービスの活用（主要なサービスを太字で示す）

データベースの見直し

Rebuildにおける最適なデータベースへの変更を行う上で活用可能なAWSのデータベースサービスを以下に示す。
表:03 RebuildにおけるAWSデータベースサービスの活用

運用管理・セキュリティの検討

運用管理・セキュリティの検討の際はマネージドサービスを活用することで、最小限のリソース利用やミドルウェアライセンスの削減、運用工数の削減などを意識した検討を行うこと。
なお、ガバメントクラウドにおいてAWS ShieldはAdvancedティアが使用できる。

表:04 運用管理・セキュリティにおけるAWSサービスの活用（主要なサービスを太字で示す）

バッチ処理の見直し

利用者はクラウド移行による制限の解放（ストレージ容量、物理サーバ、ミドルウェアの機能、外部システム連携など）の観点でバッチ処理の在り方を見直し、クラウドに最適化されたバッチ処理を検討すること。

※マスタデータメンテナンスはACID特性を持つデータベースのために発生する処理のため、データベースの種類を見直すという観点もある。その場合は本書の「データベースの見直し」を参照すること。
図:03 バッチ処理の見直しとクラウド最適化

バッチ処理のモダン化に活用できるAWSサービスを以下に示す。

表:05 バッチ処理におけるAWSサービスの活用（主要なサービスを太字で示す）

バックアップの見直し

利用者はバックアップをソフトウェアやジョブ、運用で実現するような方式を見直し、マネージドサービスを活用することでクラウドに最適化されたバックアップを検討すること。

図:04 バックアップの要件とクラウドでの実現例

移行方式の検討

移行要件の整理

移行方式の検討はビジネス、技術双方の観点での要件を整理し、要件を満たす移行方式を検討すること。
また移行要件の優先順位を整理し、より優先度の高い要件を満たす移行方式を検討すること。
移行における要件例を以下表に示す。

表:06 移行要件例

移行方式の検討

整理した移行要件を踏まえ、システム移行方式、データ移行方式、業務切り替え方式を検討すること。
政府機関においてはシステム一括移行、データ一括同期、ユーザー/ロケーション/業務順次切替えのパターンが多いと想定されるが、対象システムに適した移行パターンを以下フローチャートにて検討すること。
また移行方式によっては旧環境と新環境のネットワーク接続が必要なケースもあるため、ネットワークの接続方法については以下ドキュメントを参照すること。

• ネットワーク接続方法(AWS編)
• 国の行政機関におけるネットワーク接続(AWS編)※
  ※ GCASガイド（メンバー専用ページ）で公開しているドキュメントのため、GCASアカウントを取得の上、参照すること。

ガバメントクラウドの移行とGSSの移行を並行して検討している場合は、どちらの移行を先行すべきか、あるいは同時移行可能か検討すること。

図:05 移行方式検討フローチャート

• システム移行方式
  • システム並行稼働
    新環境にアーキテクチャを構築後、データを移行して旧環境と新環境を並行稼働させる。新環境が安定稼働後、旧環境を切り離すことでシステム移行が完了する。
    可用性要求が高い大規模システムの場合は並行稼働ありを選択するケースが多い。
    またモダナイゼーションされたアーキテクチャの運用に不安がある場合などは、いつでも旧環境に戻せることがメリットとなる。
  • サブシステム順次移行
    サブシステムや機能毎に分割をして順次移行する。全てのサブシステムや機能が移行完了することでシステム移行が完了する。
    一括だと開発スケジュールがタイトになるような大規模システムの場合は順次移行ありを選択するケースが多い。
    また新しい法律に係る機能を新環境にてモダンアーキテクチャで構築するなど、既存のシステムの影響を最小限にしながらモダナイゼーションを推進できる。
  • システム一括移行
    システムを1回の移行作業で全て移行する方式。
    移行にかかるコストを抑えたい場合や、移行期間が短い場合に適した方式である。

表:07 システム移行方式比較

• データ移行方式
  データ移行のために業務が停止する時間はデータ移行の前処理、データ移行時間、データ移行後に新環境でサービスを開始するための後処理の時間を合計した時間となる。さらに移行失敗時の切り戻しを含める点を注意すること。
  データの物理移行について、AWSはオンプレと違いユーザーがAWSのデータセンターに入館できないため、オンプレに比べると移行期間が長くなる点を留意すること。
  ネットワーク経由でのデータ転送について、旧環境のネットワークの仕様などで転送速度がブロッカーとなる場合は、GSSにデータを持ち込み転送速度の速いGSSネットワーク経由で新環境にデータ転送する方式も検討すること。
  また旧環境ネットワークのブラックボックス化やGSSの仕様などにより新旧環境のネットワークトラブルが想定されるため、早めのプロトコル疎通確認や転送速度の確認を実施すること。
  • データリアルタイム同期
    サービス停止時間は無し。
    新旧環境はアプリケーションレベルで同期、稼働状態とし、旧環境を停止することでシステム停止なく移行が完了。
  • データ事前同期
    サービス停止時間は中。
    新環境への切替え前に新旧環境のデータを同期する。旧環境の停止、データの差分同期、新環境への切替えによって移行が完了。
  • データ一括同期
    サービス停止時間は大。
    旧環境を停止後にバックアップデータを取得し新環境へ転送。新環境でバックアップデータからリストアし起動することで移行が完了。
• 業務切り替え方式
  • ユーザー/ロケーション/業務順次移行
    特定の部門や地域を先行して移行する。先行移行に問題がない事を確認した後、先行移行以外の移行を実施することで移行が完了する。
    部門や地域によってシステムの影響度が違うケースなどは影響度の少ない部門や地域を先行移行することで、リスクを抑えた移行が可能となる。
  • ユーザー/ロケーション/業務一括移行
    全ての部門や地域を一括で移行する。
    移行にかかるコストを抑えたい場合や、移行期間が短い場合に適した方式である。

　
表:08 ユーザー/ロケーション/業務切り替え方式比較

データベース移行

データベースのクラウド移行においては、インターネットまたはDirect ConnectやVPNなどのローカルネットワークを通して移行を行うのが一般的である。 リレーショナルデータベース、データウェアハウス、NoSQLデータベース、その他様々な種類のデータベースをAWSに移行する際に使用できるサービスを以下に示す。

• AWS Database Migration Service
  AWS Database Migration Service（以下AWS DMS）を使用すると、オンプレミス環境からAWS クラウドへ1回限りのデータベース移行を実行できる。AWS DMSを使用する際は、AWS Schema Conversion Tool（AWS SCT）を用いてデータベーススキーマを新しいプラットフォームに変換後、あらかじめRDSやAuroraなどのマネージドデータベースサービスを用意した上でデータ移行を実行する。AWS DMSを使用すると、データベースの1回限りの移行後は、継続的な変更をレプリケートすることも可能である。
  また、特徴としては、ドライバーやアプリケーションのインストールが不要なこと、異なるデータベース間の移行が可能なこと、切り替えの際のダウンタイムを最小限に抑えられることが挙げられる。AWS DMSはVPCにレプリケーションインスタンスを作成することでソースデータストアへの接続、ソースデータの読み取り、ターゲットデータストが使用できるようにデータのフォーマットをする。レプリケーションインスタンスを作成する際のネットワーク設定には、すべてのデータベース移行コンポーネントが1つのVPCにある設定、多重VPCでの設定、AWS Direct ConnectまたはVPNを使用したVPCへのネットワークの設定、インターネットを使用したVPCへのネットワークの設定、VPCにないRDS DBインスタンスでVPC内のDBインスタンスへの設定など、数種類の方法を利用できる。
  • AWS Database Migration Serviceの概要については以下を参照すること。
    [AWSドキュメント：AWS Database Migration Service とは?]
    https://docs.aws.amazon.com/ja_jp/dms/latest/userguide/Welcome.htmlopen_in_newOpens in new tab

　

データ移行

データをクラウドに移行するにはネットワークの状態に応じて移行方法やAWSサービスを選択する必要がある。
インターネット、Direct ConnectやVPNなどのローカルネットワーク、オフライン、それぞれで活用可能なAWSサービスを以下に示す。

オンラインデータ転送

インターネットを経由でのオンライン接続を使用して、大規模なデータをAWSに移行する際に活用できるフルマネージドサービスを以下に示す。

• AWS DataSync
  オンプレミスからNFS、SMB、HDFS、セルフマネージドオブジェクトストレージ、AWS Snowcone、Amazon S3、Amazon EFS、Amazon FSx for Windows File Server、Amazon FSx for Lustre、Amazon FSz for OpenZFS、そして Amazon FSx for NetApp ONTAPとの間、およびAWSストレージサービス間で簡潔、自動、高速にデータ転送を行いたい場合はAWS DataSyncの使用を推奨する。AWS DataSyncを使用すると、アクティブなデータセットの移行や、オンプレミスのストレージ容量を解放するためにデータをアーカイブすること、ビジネス継続性のためにデータをレプリケートすること、分析や処理のためにクラウドにデータを転送することが可能になる。また、データ暗号化や整合性検証をすることによって安全なデータ転送を行えることや、ファイル転送の際にAWS独自のプロトコルだけでなく、一般的なプロトコルも使用できることが特徴である。通常、AWS DataSyncは開いているファイルを制限なく転送可能だが、開いているファイルに書き込みが行われた場合には整合性検証の不一致を検出するため注意する必要がある。
  AWS DataSyncを使用すると、インターネットを経由したAWSへのデータ転送、またはAWS Direct Connectを経由したデータ転送が可能である。
  • AWS DataSyncの概要については以下を参照すること。
    [AWSドキュメント：AWS DataSync の概要]
    https://docs.aws.amazon.com/ja_jp/datasync/latest/userguide/what-is-datasync.htmlopen_in_newOpens in new tab

　

オンラインデータ転送およびローカルネットワークデータ転送

インターネットおよびローカルネットワークを経由した接続を使用して、データをAWSに移行する際に活用できるサービスを以下に示す。

• AWS Transfer Family
  オンプレミス環境からAmazon S3やAmazon EFSに、AWSで提供されているSFTP、FTPS、FTP、およびAS2のプロトコルを使用してAmazon S3やAmazon EFSとの間でファイルの送受信を行いたい場合は、AWS Transfer Familyの使用を推奨する。AWS Transfer Familyはリアルタイムでスケーリングが可能なフルマネージド型のサービスであり、サーバーおよびストレージなどのインフラストラクチャの管理や、オンプレミスのサーバーへの新規ツールの導入も不要である。また、データの共有方法を変更せずにファイル転送のワークフローの変更が可能であり、転送されたデータをAWSのサービスにそのまま統合できる。ただし、プロトコルの性質上、データ転送には時間を要するので大量のデータ転送には向いておらず、小規模なファイル転送やデータ移行での使用を推奨する。SFTP、FTPS、およびAW2のプロトコルはパブリックエンドポイントやVPCエンドポイントからインターネットを経由したアクセスが可能である。FTPはインターネットを経由した接続はできず、AWS Direct ConnectまたはVPN経由での内部アクセスのみが可能である。
  • AWS Transfer Familyの概要については以下を参照すること。
    [AWSドキュメント：AWS Transfer Family とは?]
    https://docs.aws.amazon.com/ja_jp/transfer/latest/userguide/what-is-aws-transfer-family.htmlopen_in_newOpens in new tab

　

オフラインデータ転送

インターネットやローカルネットワークを経由せずに、オフラインで大規模なデータをAWSに移行する際に活用できるサービスを以下に示す。

• AWS Snow Family
  ネットワーク経由の転送だと時間がかかってしまう大規模なデータを転送したい場合には、ファミリー専用ハードウェアを使用してAWS上に大量のデータを送付できるAWS Snow Familyの使用を推奨する。また、データセンターの設置が困難な厳しい環境や、ネットワーク接続が不安定な場所でもオペレーションの運用が可能になる。AWS Snow FamilyにはAWS Snowcone、AWS Snowball、AWS Snowmobileの3種類があり、ここでは日本のリージョンで利用可能なAWS SnowconeとAWS Snowballの概要とユースケースを以下に示す。
• AWS Snowcone
  AWS Snow Familyの中で最も小さい転送デバイスであり、8TB（Snowcone SSDの場合は14TB）のストレージが使用可能である。物理デバイスを出荷することでオフラインで、またはAWS DataSyncを利用してオンラインでAWSにデータを一括転送する。安全性と堅牢性が高く、従来のデータセンタの外での使用に特化している。Snowconeを使用すると、AWS DataSyncを使用してインターネットを経由したオンラインでのデータ収集、処理、AWSへの移行ができることに加え、オンプレミスネットワークに接続してAWS OpsHubを使用することで1台のデバイスで最大8TBまで、複数のデバイスを用いれば大量のデータセットのオフライン転送も可能である。
  • AWS Snowconeの概要については以下を参照すること。
    [AWSドキュメント：AWS Snowcone とは?]
    https://docs.aws.amazon.com/ja_jp/snowball/latest/snowcone-guide/snowcone-what-is-snowcone.htmlopen_in_newOpens in new tab
• AWS Snowball
  AWS SnowballはAmazon S3とオンサイトのデータストレージロケーションの間で、物理ストレージデバイスを用いて大量のデータ転送を行える安全で堅牢なデバイスを提供するサービスである。提供されるデバイスはAWS KMSで保護された物理的に頑丈なものであり、データストレージ間のSnowballの輸送は地域の配送業者が行う。物理的なデバイスであることから、オフラインでのデータ移行を行う。例えば、250TBの大規模データのAmazon S3へのアップロードは1-2.5日で完了し、運搬も含めると10日ほどで移行を完了させることが可能である。ただし、それぞれの転送ファイルが個別に暗号化されるため、個々の転送ファイルが小さすぎるなど、全体のデータセットに対してファイルが多数ある場合はデータ転送速度が低下する。このような場合にはSnowballクライアントで取り込む前にtarまたはzipでファイルをまとめることを推奨する。
  AWS Snowballサービスによって提供されるエッジコンピューティングおよびデータ転送サービスがSnowball Edgeである。頑丈な環境、モバイル環境、または切断された環境でコンピューティングを行う必要がある場合、または高速オンライン転送サービスを使用するための帯域幅が利用できない場合でのローカルデータ処理および収集をサポートする。 Snowball EdgeにはSnowball Edge Compute OptimizedとSnowball Edge Storage Optimizedの2種類のデバイスタイプがある。Snowball Edge Compute Optimizedは42TBのストレージ容量、52個のvCPU、208GiBのメモリおよびGPUのオプションがあり、機械学習、フルモーション動画分析、分析、ローカルコンピューティングスタックなどでの使用に推奨される。
  一方Snowball Edge Storage Optimizedは80TBのストレージ容量、40個のvCPU、80GiBのメモリを提供しているため、大規模なデータ移行、定期的な転送ワークフローおよび高容量を必要とするローカルコンピューティングの際に使用することが推奨される。
  • AWS Snowballの概要については以下を参照すること。
    [AWSドキュメント：AWS Snowball]
    https://aws.amazon.com/jp/snowball/open_in_newOpens in new tab
  • AWS Snowball Edgeの概要については以下を参照すること。
    [AWSドキュメント：AWS Snowball Edge とは]
    https://docs.aws.amazon.com/ja_jp/snowball/latest/developer-guide/whatisedge.htmlopen_in_newOpens in new tab

　

アプリケーション移行

アプリケーションはマイクロサービスやAPI、コンテナなどのモダナイゼーションを前提とするが、モダナイゼーションへの段階的移行などの理由でリビルドせずに移行する場合は、アプリケーション移行サービスを活用し作業工数の削減や移行期間の短縮を図ること。アプリケーションを移行する際に活用できるサービスを以下に示す。

• AWS Mainframe Modernization
  AWS Mainframe ModernizationはオンプレミスのメインフレームワークロードをAWSの可用性が高いマネージドなランタイム環境に移行して、モダナイズおよび実行のためのインフラストラクチャとソフトウェアを提供するマネージドツールである。AWS Mainframe Modernizationではメインフレームの機能と互換性を残したリプラットフォームと、コードとデータ変換を自動化した自動リファクタリングの2つの主要な移行パターンをサポートしている。
  • AWS Mainframe Modernizationの概要については以下を参照すること。
    [AWSドキュメント：AWS Mainframe Modernizationとは?]
    https://docs.aws.amazon.com/ja_jp/m2/latest/userguide/what-is-m2.htmlopen_in_newOpens in new tab

改訂履歴