444-AWS SAP AWS 「理論・実践・一問道場」ヘルスチェック

type

status

date

slug

summary

理論

1. Amazon EC2 とターゲットグループのヘルスチェック

ヘルスチェックは、アプリケーションやインスタンスの稼働状況を監視する重要な手段です。ターゲットグループのヘルスチェックが失敗すると、オートスケーリングが自動的にインスタンスを交換することがあります。

ヘルスチェックの設定を適切に行うことが大切で、シンプルなページや応答時間の長いページではなく、アプリケーションの重要な機能を評価するエンドポイントに設定するべきです。

2. RDS と読み取りレプリカ

Amazon RDS MySQLでは、データベースの読み取り負荷を分散するために読み取りレプリカを使用することができます。これにより、読み取り要求を複数のインスタンスに分散させ、プライマリデータベースへの負荷を軽減できます。

書き込み負荷が問題である場合、読み取りレプリカは効果がありません。データベースのスケーリングやパフォーマンス改善には、適切な監視と対策が求められます。

3. CloudWatch アラーム

Amazon CloudWatchは、AWSリソースのパフォーマンスや状態を監視し、アラームを設定して通知を受けることができます。特に、RDSインスタンスが高負荷の状態にある場合にアラームを設定することで、早期に問題を検出し、対応ができます。

CloudWatchは、メトリクスを監視することで、アプリケーションのパフォーマンスを改善し、障害の予兆を検出できます。

4. ElastiCache の導入

Amazon ElastiCacheは、インメモリキャッシュサービスで、アプリケーションのバックエンドデータベースへのアクセス負荷を軽減できます。キャッシュを使用することで、読み取り性能が向上し、データベースの負荷を大幅に削減できます。

特に、頻繁にアクセスされるデータや計算結果をキャッシュすることで、応答時間が短縮され、全体的なアプリケーションのパフォーマンスが向上します。

5. オートスケーリング

オートスケーリングは、アプリケーションの負荷に応じて自動的にインスタンス数を調整する機能です。ターゲットグループのヘルスチェック結果を元に、スケーリングが実行されますが、バックエンドのデータベース層のパフォーマンスが低下していると、インスタンスのスケーリングでは効果が出ないことがあります。

高負荷の問題がデータベース層にある場合、データベース層のスケーリングやキャッシュの導入など、他の手段で負荷を軽減する必要があります。

まとめ

アプリケーションの可用性とパフォーマンスを最適化するためには、データベース層への負荷軽減が重要です。読み取りレプリカやElastiCacheを使用して、データベースへの負荷を分散・削減しましょう。

CloudWatchを利用して、RDSインスタンスのパフォーマンスを監視し、問題が発生する前にアラームを設定して通知を受けることが、迅速な対応に繋がります。

ヘルスチェックを適切に設定し、アプリケーション全体の機能性を評価することで、可用性を保ちつつパフォーマンスの向上を図れます。

実践

略

一問道場

質問 #444

ある公共の小売ウェブアプリケーションは、アプリケーションロードバランサー (ALB) を使用して複数のアベイラビリティゾーン (AZ) に展開された Amazon EC2 インスタンスをフロントエンドとして使用し、バックエンドには Amazon RDS MySQL のマルチ AZ 配備を利用しています。ターゲットグループのヘルスチェックは HTTP を使用し、商品カタログページを指しています。オートスケーリングは ALB のヘルスチェックに基づいてウェブフリートのサイズを維持するように設定されています。最近、このアプリケーションで障害が発生しました。オートスケーリングは障害中にインスタンスを継続的に交換しましたが、後の調査でウェブサーバーのメトリクスは正常である一方、データベース層が高負荷にあり、クエリ応答時間が大きく遅延していたことが判明しました。

このアプリケーションの可用性と機能性の監視能力を改善し、将来の成長に備えるために、次の変更を2つ選ぶべきです。

A. Amazon RDS MySQL に読み取りレプリカを構成し、ウェブアプリケーションで単一のリーダーエンドポイントを使用して、バックエンドのデータベース層への負荷を軽減します。

B. ターゲットグループのヘルスチェックを商品カタログページではなく、シンプルな HTML ページに変更し、Amazon Route 53 のヘルスチェックを商品ページに設定してアプリケーション全体の機能性を評価します。また、サイトに障害が発生した場合には Amazon CloudWatch アラームで管理者に通知します。

C. ターゲットグループのヘルスチェックを Amazon EC2 ウェブサーバーの TCP チェックに変更し、Amazon Route 53 のヘルスチェックを商品ページに設定してアプリケーション全体の機能性を評価します。また、サイトに障害が発生した場合には Amazon CloudWatch アラームで管理者に通知します。

D. 高負荷の状態にある Amazon RDS インスタンスを回復させるアクションを設定した Amazon RDS 用の Amazon CloudWatch アラームを構成します。

E. Amazon ElastiCache クラスターを構成し、ウェブアプリケーションと RDS MySQL インスタンスの間に配置して、バックエンドのデータベース層への負荷を軽減します。

解説

A. Amazon RDS MySQL に読み取りレプリカを構成し、ウェブアプリケーションで単一のリーダーエンドポイントを使用して、バックエンドのデータベース層への負荷を軽減します。

評価: 読み取りレプリカを使用することで、データベースの読み取り負荷を分散できますが、このケースではアプリケーションで発生している高負荷の問題が「クエリ応答時間の遅延」に関係しているため、読み取りレプリカが解決するのは読み取りの負荷軽減に限られます。書き込み負荷が問題である場合、この変更だけでは効果が薄いです。

B. ターゲットグループのヘルスチェックを商品カタログページではなく、シンプルな HTML ページに変更し、Amazon Route 53 のヘルスチェックを商品ページに設定してアプリケーション全体の機能性を評価します。また、サイトに障害が発生した場合には Amazon CloudWatch アラームで管理者に通知します。

評価: ヘルスチェックの対象を簡単なページに変更することは、インスタンスが正常に稼働しているかどうかを確認するための一歩ではありますが、アプリケーションのバックエンド（特にデータベースのパフォーマンス）の問題を特定するには不十分です。商品ページに対するRoute 53のヘルスチェックは機能的には有効ですが、根本的なデータベースのパフォーマンス問題に対処することはできません。

C. ターゲットグループのヘルスチェックを Amazon EC2 ウェブサーバーの TCP チェックに変更し、Amazon Route 53 のヘルスチェックを商品ページに設定してアプリケーション全体の機能性を評価します。また、サイトに障害が発生した場合には Amazon CloudWatch アラームで管理者に通知します。

評価: TCP チェックはEC2インスタンスの稼働状況を確認するには有効ですが、アプリケーションのパフォーマンスやバックエンドデータベースの状態を反映するものではありません。商品ページに対するRoute 53のヘルスチェックは有効ですが、この変更もデータベース層の問題には対応していません。

D. 高負荷の状態にある Amazon RDS インスタンスを回復させるアクションを設定した Amazon RDS 用の Amazon CloudWatch アラームを構成します。

評価: RDSの高負荷状態に対するアラームを設定することは非常に重要です。これにより、高負荷が発生した際に早期に検出し、対応策を取ることができます。データベースのパフォーマンスに関する問題を迅速に把握し、適切な対処が可能となります。これは非常に有効な変更です。

E. Amazon ElastiCache クラスターを構成し、ウェブアプリケーションと RDS MySQL インスタンスの間に配置して、バックエンドのデータベース層への負荷を軽減します。

評価: ElastiCacheを導入することで、頻繁に読み込まれるデータをキャッシュし、データベース層へのアクセス負荷を軽減できます。これにより、データベースの負荷が軽減され、クエリ応答時間が短縮されるため、アプリケーションのパフォーマンスが向上します。これは非常に効果的な変更です。

結論:

アプリケーションの可用性と機能性を改善するために適切な変更は、D (RDSインスタンスに対するCloudWatchアラームの設定) と E (ElastiCacheの導入) です。この2つの変更がデータベースのパフォーマンスを改善し、アプリケーション全体の可用性を向上させるために有効です。