Q5 — AWS SAP-C02 第1章

第 5/75 問 | ← 第1章

Q80. ある企業が、オンプレミスの注文処理プラットフォームをAWSクラウドにリファクタリングしようとしています。このプラットフォームには、VMのフリート上でホストされるWebフロントエンド、フロントエンドとバックエンドを接続するRabbitMQ、および注文を処理するコンテナ化されたバックエンドシステムを実行するKubernetesクラスターが含まれます。企業はアプリケーションに対して大きな変更を加えたくありません。これらの要件を満たし、かつ運用上のオーバーヘッドが最も少ないソリューションはどれですか？

正解: A. WebサーバーVMのAMIを作成します。そのAMIとApplication Load Balancerを使用するAmazon EC2 Auto Scalingグループを作成します。オンプレミスのメッセージキューを置き換えるためにAmazon MQをセットアップします。注文処理用のバックエンドをホストするためにAmazon Elastic Kubernetes Service（Amazon EKS）を設定します。

解説

正解は： A. WebサーバーVMのAMIを作成します。そのAMIとApplication Load Balancerを使用するAmazon EC2 Auto Scalingグループを作成します。オンプレミスのメッセージキューを置き換えるためにAmazon MQをセットアップします。注文処理用のバックエンドをホストするためにAmazon Elastic Kubernetes Service（Amazon EKS）を設定します。 選択肢Aは、オンプレミスの注文処理プラットフォームをAWSクラウドへリファクタリングするという要件を、最も少ない運用オーバーヘッドで満たすソリューションです。 WebサーバーVMのAMI（Amazon Machine Image）を作成することで、既存の環境を容易に複製でき、アプリケーションへの変更を最小限に抑えながら互換性を確保できます。 そのAMIとApplication Load Balancerを用いたAmazon EC2 Auto Scalingグループを作成すれば、需要に応じてWebフロントエンドのスケーリングを自動化できます。Application Load Balancerは着信トラフィックを複数のインスタンスに分散させ、高可用性とスケーラビリティを保証します。 オンプレミスのRabbitMQメッセージキューを置き換えるためにAmazon MQを導入すると、さまざまなメッセージングパターンをサポートするマネージド型メッセージブローカーサービスを利用でき、アプリケーションの大幅な変更を必要とせずにフロントエンドとバックエンド間のシームレスな統合が可能になります。 注文処理用のバックエンドをホストするためにAmazon Elastic Kubernetes Service（Amazon EKS）を設定すれば、コンテナ化されたデプロイと管理が可能になり、Kubernetesオーケストレーションのメリットを活かしつつ、運用上の負担を最小限に抑えることができます。 このソリューションにより、オンプレミスの注文処理プラットフォームをAWSクラウドへスムーズに移行でき、運用面での変更も最小限に抑えられます。また、高可用性、スケーラビリティ、および既存アプリケーションとの互換性も維持されます。 選択肢B（カスタムAWS Lambdaランタイムの使用）は、Lambda上でWebサーバー環境を模倣するという追加の複雑さを導入しており、本シナリオでは不必要です。 選択肢C（EC2インスタンスのフリート上へのKubernetesのインストール）は、Kubernetesクラスターの構築・管理に追加の運用作業を要し、不要なオーバーヘッドを発生させます。 選択肢D（Amazon SQSをAmazon MQの代わりに使用）は、RabbitMQの直接的な代替とはならず、アプリケーション側でのより大規模な変更を余儀なくされる可能性があります。 したがって、本シナリオにおいて最適なソリューションは選択肢Aです。