095-AWS SAP AWS 「理論・実践・一問道場」Lift-and-shift

type

status

date

slug

summary

理論

1. クラウド移行戦略

クラウドへの移行において、最小の変更で最大の効果を得るためには、現在使用している技術スタックにできるだけ近いクラウドサービスを選ぶことが重要です。

Lift-and-shift: 既存のシステムを最小限の変更でクラウドに移行し、クラウドのスケーラビリティや可用性を利用します。

Replatforming: 必要に応じて、既存システムを少し変更してクラウドサービスに最適化します。

2. Amazon EC2とAuto Scaling

AWSのEC2インスタンスは、従来の仮想マシン（VM）と非常に似た機能を提供します。EC2を使用することで、既存のオンプレミスVMからクラウド環境に移行する際に最小限の変更で移行が可能です。

EC2 Auto Scaling: これは、負荷に応じてインスタンス数を自動的にスケーリングできるサービスです。これにより、スケーラビリティを確保しつつ、効率的なコスト管理を実現します。

3. Amazon MQとAmazon SQS

メッセージングシステムに関しては、AWSにはいくつかの選択肢があります。

Amazon MQ: RabbitMQやActiveMQなどの既存のメッセージングシステムと互換性があり、これらのシステムを使用している場合は、Amazon MQへの移行がスムーズです。Amazon MQは、フルマネージドのメッセージングサービスであり、インフラの管理が不要になります。

Amazon SQS: よりシンプルでスケーラブルなキューイングサービスで、より高度な機能（トピックベースのメッセージングやメッセージの順序保証など）が必要ない場合に有効です。

4. Amazon EKS（Elastic Kubernetes Service）

コンテナ化されたアプリケーションをクラウドに移行する際、Amazon EKSを使用すると、AWS上でマネージドKubernetes環境を簡単に構築できます。これにより、コンテナの管理が大幅に簡素化され、スケーラブルなバックエンドシステムの構築が可能になります。

EKSの利点: AWSのマネージドサービスなので、Kubernetesのインフラ管理が不要で、デプロイメントやスケーリングの作業が自動化され、運用の負担が軽減されます。

5. AWSの移行における運用オーバーヘッドの最小化

AWSへの移行時に運用オーバーヘッドを最小化するためには、できるだけ自動化されたマネージドサービスを活用することが重要です。特に、以下のようなサービスを利用することで、運用の効率化が可能です。

Amazon EKSやAmazon MQは、インフラの管理やスケーリングを自動化し、開発者や運用者がコードに集中できる環境を提供します。

Amazon EC2 Auto Scalingは、負荷の変動に応じて自動的にスケールアップ・スケールダウンできるため、運用の手間を減らし、コストを最適化できます。

実践

略

一問道場

問題 #95

トピック 1

ある会社が、自社のオンプレミスの注文処理プラットフォームをAWSクラウドにリファクタリングしています。このプラットフォームには、WebフロントエンドがVMのクラスターでホストされ、RabbitMQがフロントエンドとバックエンドを接続するために使用され、Kubernetesクラスターがコンテナ化されたバックエンドシステムを実行して注文を処理しています。この会社は、アプリケーションに大きな変更を加えたくありません。

最も運用オーバーヘッドが少ない方法はどれですか？

A. WebサーバーVMのAMIを作成し、AMIとアプリケーションロードバランサーを使用するAmazon EC2オートスケーリンググループを作成します。Amazon MQを設定して、オンプレミスのメッセージングキューを置き換えます。注文処理バックエンドをホストするためにAmazon Elastic Kubernetes Service（Amazon EKS）を設定します。

B. Webサーバー環境を模倣するカスタムAWS Lambdaランタイムを作成し、フロントエンドWebサーバーを置き換えるためにAmazon API Gateway APIを作成します。Amazon MQを設定して、オンプレミスのメッセージングキューを置き換えます。注文処理バックエンドをホストするためにAmazon Elastic Kubernetes Service（Amazon EKS）を設定します。

C. WebサーバーVMのAMIを作成し、AMIとアプリケーションロードバランサーを使用するAmazon EC2オートスケーリンググループを作成します。Amazon MQを設定して、オンプレミスのメッセージングキューを置き換えます。注文処理バックエンドをホストするために、異なるEC2インスタンスのクラスターにKubernetesをインストールします。

D. WebサーバーVMのAMIを作成し、AMIとアプリケーションロードバランサーを使用するAmazon EC2オートスケーリンググループを作成します。Amazon Simple Queue Service（Amazon SQS）を設定して、オンプレミスのメッセージングキューを置き換えます。注文処理バックエンドをホストするためにAmazon Elastic Kubernetes Service（Amazon EKS）を設定します。

解説

Aの解説:

Aの選択肢では、以下のアーキテクチャを採用しています：

Amazon EC2 Auto Scalingグループ: これは、既存のVMをAMI（Amazon Machine Image）として作成し、クラウド環境で同様の自動スケーリングと負荷分散を提供します。これにより、オンプレミス環境でのVMの管理に慣れている場合、最も少ない変更でクラウドに移行できます。

Amazon MQ: RabbitMQの代替としてAmazon MQを使用することで、メッセージングのインフラをクラウドネイティブに移行できます。Amazon MQは、RabbitMQに似た機能を持っており、移行がスムーズです。

Amazon EKS: コンテナ化されたバックエンドシステムをKubernetesに対応するAmazon EKSに移行することで、運用がシンプルになります。AWSが提供するマネージドKubernetesサービスなので、Kubernetesの管理が簡素化され、運用負担が軽減されます。

この構成は、オンプレミス環境に近い状態でクラウド移行ができるため、最小限の変更で運用でき、運用オーバーヘッドを最小化できます。

Bの解説:

Bの選択肢では、AWS LambdaとAPI Gatewayを使ってアーキテクチャを変更しますが、これは以下の理由で運用オーバーヘッドが高くなります：

Lambdaのカスタムランタイム作成: Webサーバーの代わりにLambdaを使用するには、カスタムランタイムを作成して、既存のアプリケーションに合わせる必要があります。これには開発コストと運用の負担が増えます。

API Gateway: API Gatewayをフロントエンドとして利用するには、LambdaとAPI Gatewayの組み合わせに合わせたアーキテクチャ設計が必要です。この変更は、既存のWebアプリケーションと大きな違いがあり、運用オーバーヘッドが増加します。

Cの解説:

Cの選択肢では、EC2インスタンスにKubernetesを手動でインストールして管理しますが、これには以下の問題があります：

Kubernetesの手動管理: Kubernetesを自分で管理する場合、AWSのEKSのようなマネージドサービスを利用するよりも、運用やスケーリング、障害対応などの手間が大きくなります。EKSを使う方が管理が簡単です。

Dの解説:

Dの選択肢では、メッセージングキューとしてAmazon SQSを使いますが、Amazon MQの方がRabbitMQと同様のメッセージング機能を持っているため、より自然な移行が可能です。SQSはシンプルなメッセージングサービスですが、RabbitMQのような高度な機能を必要とする場合には適していません。

結論:

Aは、既存のインフラとの互換性を保ちながら、クラウドネイティブなサービス（EKSやAmazon MQ）を活用して、最小限の運用オーバーヘッドで移行を実現できる最適な選択肢です。