299-AWS SAP AWS 「理論・実践・一問道場」AWS Systems Manager

type

status

date

slug

summary

理論

AWS EC2の高可用性アーキテクチャとスケーラビリティの実現方法

AWSで高可用性とスケーラビリティを実現するためには、適切なインフラストラクチャの設計が不可欠です。特に、Amazon EC2やAmazon Auroraなどのサービスを活用することで、アプリケーションの負荷に応じた柔軟な対応が可能になります。ここでは、EC2インスタンスのスケーラビリティを高め、ダウンタイムを減少させるための方法について紹介します。

1. EC2インスタンスのオートスケーリング

オートスケーリングは、アプリケーションのトラフィックや負荷に応じて、インスタンスを自動的に追加または削除するAWSの機能です。これにより、CPU使用率が高くなる場合に自動的に新しいインスタンスを起動し、トラフィックが減少するときにはインスタンスを縮小できます。

ポイント:

CPU使用率のモニタリング: EC2インスタンスのCPU使用率を監視し、一定のしきい値を超えるとスケーリングをトリガーする設定を行います。

Auto Scalingグループ: 複数のインスタンスをグループ化し、そのグループに基づいてスケーリングを行う設定をします。

2. Amazon Auroraの高可用性とスケーラビリティ

Amazon Auroraは、リレーショナルデータベースの管理をAWSが提供するサービスで、MySQLやPostgreSQLと互換性があります。高可用性、スケーラビリティ、そして自動バックアップ機能が組み込まれており、アプリケーションのパフォーマンスを向上させるために重要です。

Auroraの特長:

Multi-AZ展開: データベースインスタンスが複数のアベイラビリティゾーンに展開されるため、障害時にもアプリケーションの可用性を確保できます。

AuroraのAuto Scaling: Auroraは、ワークロードに応じて自動的に読み取り専用のインスタンスを追加することができ、リードスループットを向上させます。

Aurora Global Databaseを使用すれば、複数のリージョンでデータベースをレプリケートし、災害復旧を実現できます。

3. AMI (Amazon Machine Image) と Systems Managerを活用したパッチ管理

手動でパッチをインストールする場合、ダウンタイムが発生するリスクがあります。AWS Systems Managerを活用すれば、インスタンスのパッチを自動的に適用できます。特に、SSM (AWS Systems Manager) Agentを使用することで、インスタンスにリモートでアクセスし、パッチや構成の管理を一元化できます。

SSMを使用したパッチ管理のメリット:

ダウンタイムの削減: インスタンスを手動で停止せずにパッチを適用できます。

セキュリティとコンプライアンス: 定期的なパッチ適用を自動化することで、セキュリティリスクを低減できます。

4. AWS Auto Scalingと負荷分散 (Elastic Load Balancer)

*Elastic Load Balancer (ELB)**を使って、複数のEC2インスタンスにトラフィックを分散することができます。これにより、単一のEC2インスタンスに過度な負荷がかかるのを防ぎ、可用性を高めることができます。

ELBとAuto Scalingの連携:

トラフィック分散: ELBは、リクエストを適切にEC2インスタンスにルーティングします。

スケーリングポリシーの設定: Auto Scalingグループで設定したポリシーに基づき、ELBがトラフィックの負荷を新しいインスタンスに分配します。

5. マルチAZおよびマルチリージョン戦略

高可用性を確保するためには、複数のアベイラビリティゾーン(AZ)やリージョンにわたる展開が重要です。特に、Amazon Aurora Global DatabaseやCross-Region Replicationを使用することで、リージョン間での災害復旧も可能になります。

マルチAZの利点:

耐障害性: アベイラビリティゾーン障害にも耐えられる。

データの冗長化: データベースインスタンスのレプリケーションにより、データ損失を防ぎます。

マルチリージョンの利点:

災害復旧: 主要リージョンがダウンしても、別のリージョンから迅速にリカバリ可能。

地理的な最適化: ユーザーに最も近いリージョンでアプリケーションを提供できます。

まとめ

AWSのサービスを駆使して高可用性とスケーラビリティを実現するためには、Auto Scaling、Elastic Load Balancer、Auroraの可用性機能、そしてAWS Systems Managerなどの管理ツールを組み合わせることが効果的です。これらのサービスを適切に設計し、リソースを自動でスケールすることで、アプリケーションのパフォーマンスを最適化し、ダウンタイムを最小限に抑えることが可能です。

実践

略

一問道場

問題 #299

トピック 1

ある企業のソリューションアーキテクトが、数年前にデプロイされたAWSのワークロードを評価しています。

現在、アプリケーション層はステートレスで、1つの大きなAmazon EC2インスタンス上で動作しており、このインスタンスはAMIから起動されています。

アプリケーションはデータをMySQLデータベースに保存しており、このデータベースも1台のEC2インスタンス上で動作しています。

アプリケーションサーバーのEC2インスタンスはCPU使用率が頻繁に100%に達し、その結果、アプリケーションが応答しなくなることがあります。また、手動でパッチを適用しており、この作業が原因で過去にダウンタイムが発生しました。

企業は、このアプリケーションを高可用性にする必要があります。

最小限の開発時間で要件を満たすためのソリューションはどれですか？

A. アプリケーション層を既存のVPC内でAWS Lambda関数に移行します。Application Load Balancerを作成してLambda関数間でトラフィックを分散します。また、Lambda関数をスキャンするためにAmazon GuardDutyを使用します。データベースはAmazon DocumentDB（MongoDB互換）に移行します。

B. EC2インスタンスタイプをより小型でGraviton対応のものに変更します。既存のAMIを使ってAuto Scalingグループのローンチテンプレートを作成します。Application Load Balancerを構築して、Auto Scalingグループ内のインスタンス間でトラフィックを分散します。また、Auto ScalingグループがCPU使用率に基づいてスケールするように設定します。データベースはAmazon DynamoDBに移行します。

C. アプリケーション層をDockerを使ったコンテナに移行し、Amazon Elastic Container Service（Amazon ECS）で実行します。ECSはEC2インスタンス上で動作させます。Application Load Balancerを作成して、ECSクラスター内のトラフィックを分散します。ECSクラスターがCPU使用率に基づいてスケールするよう設定します。データベースはAmazon Neptuneに移行します。

D. AWS Systems Managerエージェント（SSMエージェント）を導入した新しいAMIを作成します。このAMIを使ってAuto Scalingグループのローンチテンプレートを作成し、小型のインスタンスを使用します。Application Load Balancerを作成して、Auto Scalingグループ内のインスタンス間でトラフィックを分散します。また、Auto ScalingグループがCPU使用率に基づいてスケールするように設定します。データベースはAmazon Aurora MySQLに移行します。

解説

この問題の焦点は、アプリケーションを高可用性にしつつ、開発コストを最小限に抑えることです。それぞれの選択肢について検討してみましょう。

A. AWS LambdaとAmazon DocumentDBへの移行

評価:

AWS Lambdaはステートレスなアプリケーションに適しており、インフラの管理を減らせます。しかし、既存のアプリケーションをLambda関数に移行するには、大幅なコード変更が必要です。
また、データベースをAmazon DocumentDBに移行することも開発コストが高く、MySQLとの互換性を損なう可能性があります。

結論: 大幅なコード変更が必要なため「開発時間が最小限」という要件に合いません。

B. Graviton対応の小型インスタンスとDynamoDBへの移行

評価:

Graviton対応のインスタンスを使用することでコスト効率は向上しますが、現在のCPU負荷を解消するためには小型インスタンスでは不十分です。
データベースをDynamoDBに移行する場合、リレーショナルデータベースであるMySQLから非リレーショナルデータベースへの移行が必要になり、大規模なアプリケーション変更が必要です。

結論: DynamoDBへの移行には高い開発コストがかかるため、不適切です。

C. DockerとAmazon ECSへの移行

評価:

Dockerを使ってアプリケーションをコンテナ化し、ECSで実行することでスケーラビリティを向上できます。
ただし、アプリケーションをコンテナに移行するには開発時間がかかり、データベースをAmazon Neptuneに移行することも大きな変更を必要とします。

結論: 大幅な設計変更が必要なため、「最小限の開発時間」に合致しません。

D. Auto ScalingグループとAurora MySQLへの移行

評価:

Auto Scalingグループを使用することで、CPU使用率に応じてインスタンスを自動的にスケールアウト/スケールインできます。これにより、現在の高負荷状態を解消し、高可用性を実現します。
新しいAMIにAWS Systems Managerエージェントを含めることで、手動パッチ作業を自動化し、ダウンタイムを削減できます。
Aurora MySQLは既存のMySQLと互換性があるため、データベース移行の開発コストを最小限に抑えつつ、高可用性とスケーラビリティを提供します。

結論: 最小限の開発時間で高可用性を実現できる最適な選択肢です。

正解: D

理由:

Auto ScalingグループとAurora MySQLを組み合わせることで、最小限の開発コストで高可用性とスケーラビリティを達成できます。

AWS Systems Managerエージェントを使用することで、運用タスクの効率化も可能です。