他クラウドのマネージドサービスをAWSのマネージドサービスに移行する際の勘所
他クラウドのマネージドサービスをAWSのマネージドサービスに移行する際の勘所
1．はじめに
一昔前はオンプレミス環境からAWSにシステムを移行することが多かったが、ここ数年は、オンプレミス環境からではなく、Azure、GCPなどの他クラウドサービスからAWSにシステムを移行する機会にも度々出会うようになってきた。
例えば、持株会社とそのグループ会社という関係がある中で、グループ会社においてとあるシステムをAzure上に構築したが、その後、持株会社が「グループとしてクラウドサービスはAWSを採用する」という方針を決定し、グループ会社各社はAWSを利用することになり、AzureからAWSへの移行対応が必要になった、というようなケースが挙げられる。
他クラウドサービスの仮想マシンで稼働していたシステムをAWSの仮想マシンサービスであるEC2に移行する、いわゆる「Lift & Shift」の移行であれば、オンプレミス環境のサーバーからAWSのEC2に移行するときと同様の考え方で移行を進めることができる。
しかし、他クラウドサービスのマネージドサービスを利用しているシステムをAWSのマネージドサービスに移行する際には、「Lift & Shift」の移行とは異なり、はじめに「他クラウドのマネージドサービスをAWSのどのマネージドサービスに置き換えるか」の検討を行う必要がある。
本稿では、他クラウドサービスのマネージドサービスを利用しているシステムをAWSのマネージドサービスに移行する際に、「他クラウドのマネージドサービスをAWSのどのマネージドサービスに置き換えるか」の検討を行う際の勘所について、具体例を交えて説明を行う。
2. 他クラウドのマネージドサービスをAWSのどのマネージドサービスに置き換えるかの検討
他クラウドのマネージドサービスをAWSのどのマネージドサービスに置き換えるかの検討を行う際には、以下のような課題がある。
・同じ分野のマネージドサービスであっても、クラウドサービスごとに機能が異なる部分がある。
・AWSにおいて、同じ分野のマネージドサービスで、複数のマネージドサービスが存在する場合がある。
上記課題がある中で、AWSのどのマネージドサービスに置き換えるかの検討を行う際に、どのようなことを考える必要があるかについて、具体的な例として、AzureのマネージドサービスからAWSのマネージドサービスへ移行する例を2例挙げて説明する。
例1. データベースのマネージドサービスの場合
Azureにおいて、データベースPostgreSQLのマネージドサービスである「Azure Database for PostgreSQL(フレキシブルサーバー)」を利用しており、災対環境へのデータ保管のために「geo冗長バックアップ」という別リージョンにバックアップを自動的にレプリケートする機能を利用している場合を例として、AWSに移行する際にどのマネージドサービスを利用するかの検討を行う。
AWSにおいて、データベースPostgreSQLのマネージドサービスは、
・Amazon RDS for PostgreSQL(以降RDS for PostgreSQL)
・Amazon Aurora PostgreSQL(以降Aurora PostgreSQL)
の2つがある。
RDS for PostgreSQLには、Azureのgeo冗長バックアップと同等の機能として、「クロスリージョン自動バックアップレプリケーション」という機能があるが、Aurora PostgreSQLには、バックアップを別リージョンに自動的にコピーする機能はなく、グローバルデータベースという機能でデータ自体のレプリケーションを行う機能はある。
このように、同じ分野のマネージドサービスであっても、実現できる機能が異なることがある。
| RDS for PostgreSQL | Aurora PostgreSQL | |
|---|---|---|
| 他リージョンへのバックアップ レプリケーションの可否 |
○ | × |
| バックアップまたはデータを他リージョンへのレプリケーションした際のRPO | 25分程度※ | 1秒未満 |
| 災対環境のAWS利用料のコスト | 低 | 高 |
※AWSのドキュメントには明確な数値情報がなく、AWSサポートの回答から得られたRPOの値である。
また、この数値は必ずしもすべての状況で保証されるものではない。
災対環境へのデータ保管について、現行システムと同等の機能を満たすようにする場合には、RDS for PostgreSQLを採用するが、AWSへのシステム移行に合わせて、災対環境のRPOを現行システムより改善する要件がある場合には、コスト増を許容できるかの判断を行った上で、Aurora PostgreSQLを採用するかを決定する。
AWS環境に移行する際の、災対環境のRPO、災対環境の維持コストといった要件を確認した上で、採用するマネージドサービスを決定する必要がある。
例2. コンテナのマネージドサービスの場合
Azureにおいて、コンテナ化されたアプリケーションを実行するマネージドサービスである「Azure App Service」を利用している場合を例として、AWSに移行する際にどのマネージドサービスを利用するかの検討を行う。
AWSにおいて、コンテナのマネージドサービスは、
・Amazon ECS(以降ECS)
・Amazon EKS(以降EKS)
の2つがある。
- ECSとEKSには、それぞれ以下のような特徴がある。
- ・ECS
- ・kubernetesを利用しない分、学習コストが低い
- ・EKSと比較して、運用負荷が低い
- ・EKS
- ・kubernetesを利用するため、kubernetesの知識がない場合は学習コストが非常に高い
- ・EKSのバージョンアップのペースが速く、バージョンアップに追随していくための運用負荷が高い
| ECS | EKS | |
|---|---|---|
| 学習コスト | 低 | 高 |
| 運用負荷 | 低 | 高 |
ECSとEKSの特徴を理解した上で、どちらを採用するかの検討を行う必要がある。
EKSを採用する場合は、
・担当者の技術レベルでEKSを利用してシステムを構築、運用することが可能か？
・担当者がkubernetesの知識がない場合は、移行プロジェクト開始までにkubernetesの知識を習得する十分な時間を確保することが可能か？
・EKSのバージョンアップに追随していくことができる運用体制(EKSを熟知した技術者を迎え入れる、担当者を増員するなど)を用意することが可能か？
を検討した上で採用するかを決定する必要がある。
上記の検討項目に1つでも疑問符がつくような状態で、かつアプリケーションの要件でkubernetesを利用するという要件がないのであれば、学習コスト、運用負荷の低いECSを採用するという判断をすべきである。
他クラウドのマネージドサービスをAWSのどのマネージドサービスに置き換えるかの検討を行う際の判断材料について
例1では、災対環境のRPO、災対環境の維持コストの要件を元に判断
例2では、担当者の技術レベル、運用時の負荷を元に判断
であったように、単純に非機能要件だけで判断はできず、コストも考慮した上で判断する場合や、担当者の技術レベル、運用負荷によって判断を行うなど、マネージドサービスによって判断材料はケースバイケースである。
3. 終わりに
他クラウドのマネージドサービスをAWSのどのマネージドサービスに置き換えるかの検討を行う際には、他クラウドのマネージドサービスで実現している機能について事前に理解していることが大前提となる。
AWS環境への移行対応について、現行システムを構築・運用していない外部のベンダーに依頼する場合や、自社で現行システムを構築したが、構築担当者が異動や退職をしており、現行システムの設計内容・設定内容を把握している者がいない場合は、まずは
・現行システムの設計ドキュメントの確認や、現行システムの実機の設定内容の確認
・現行システムで利用しているマネージドサービスの公式ドキュメントの確認
を行い、現行システムのマネージドサービスで実現している機能について十分に理解をすることが必要である。
現行システムのマネージドサービスで実現している機能について十分に理解をしないまま、AWSのどのマネージドサービスに置き換えるかの検討を行った場合、「移行前のクラウドサービスではできていたことが、AWSに移行したらできなくなった」ということが発生する可能性が高くなる。
そのようなことが起きないよう、現行システムのマネージドサービスで実現している機能について十分に理解をした上で、AWSのどのマネージドサービスに置き換えるかの検討を行い、さらに移行前にPoCを行い、採用したマネージドサービスの機能で問題がないことを確認すると、安心してAWSへシステムを移行することができるだろう。
著者：渡辺 剛
2011年にAWSに初めて触れる。以降、enterpriseCloud+（eC+）の立ち上げへの参画、お客様のAWS環境の構築、AWSへの移行プロジェクトに携わる。
