« AWS Summit 「無料で体験!AWS TestDrive コーナー」のご案内 | メイン | [OpsJAWS] RDSイベントの監視 »

[OpsJAWS] 死活監視 (General)

死活監視の目的

システム全体として正常にサービスを提供できていることに加え、障害時に原因を早期に切り分けるために、システムを構成する個々のコンポーネント、サービスそれぞれが正常に稼働していることを監視する必要がある。AWSの各種機能を利用して構築されたシステムにおいて、どのように死活監視を行うべきかを明らかにする。

WEBシステム全体の死活監視

WEBシステムにおいては、WEBリクエスト監視やWEBシナリオ監視を設定し、ユーザー視点でシステムが正常に稼働していることを監視することが必要となる。この際、監視経路が実際にユーザーがシステムを利用する経路と同じになるように設定することが望ましい。監視には、Amazon CloudWatchをベース考えに必要に応じ、監視ツールを導入する、もしくはMSPなどの監視サービスを利用する。WEBシステムが同構成の複数のWEBサーバからなる場合、Route53によるヘルスチェック機能も有効な手段となる。

[監視対象]

監視項目

監視方法

取得方法詳細

優先度

監視目的

WEBリクエスト監視

監視ツール/

監視サービスのWEBリクエスト監視機能

サービスサイトURLへのhttp/httpsリクエスト応答

WEBシステムのインフラレイヤ正常性監視

WEBシナリオ

監視

シナリオに沿ってログインやサービスサイトのページ遷移、ダミーデータ登録を伴うWEBサービス監視

WEBシステムのアプリケーションレイヤの正常性監視

Route53ヘルスチェック

CloudWatch

HealthCheckStatus

HealthCheckPercentageHealthy

WEBシステムのインフラレイヤ正常性監視

[対処方法]

後述の、WEBシステムを構成する各要素、AWSサービスの正常性監視結果を元に障害発生箇所を切り分け、適切な復旧処置を実施する(下記参照)。

AWSサービスの死活監視

利用中のAWSサービスの正常性は、AWS Service Health Dashboardで確認できる。AWS Service Health Dashboardでは各リージョン毎のAWSサービスの正常性、性能低下、障害情報、障害復旧情報が確認できる。更新情報はRSSで配信されるため、監視するためには、RSSフィードを取得する機能を監視システムに実装する必要がある。

[監視対象]

監視項目

監視方法

取得方法詳細

優先度

監視目的

AWSサービス正常性

Service Health Dashboardからの情報取得

RSSフィードを購読し、AWS ServiceHealthDashboardの更新状況を監視する

システムで利用中のAWSサービス正常性監視

個々のAWSサービスの死活監視

  • Amazon Route 53の死活監視

Amazon Route 53はSLAで100%の使用可能時間割合を目標としている高可用性で設計されたマネージドサービスで、WEBリクエスト監視を通じRoute53の死活監視も行えるためRoute53単体での死活監視は不要である。

  • Amazon CloudFrontの死活監視

Amazon CloudFront自身の死活監視はWEBリクエスト監視またはRoute53のヘルスチェックで行える。Route53をDNSサービスとして使用している場合は、Route53のフェールオーバー機能と連携して可用性を高められるので、HealthCheckを活用することが望ましい。

またCloudWatch経由でリクエスト数やHTTPレスポンスコードの発生率のメトリックスを取得し、リリクエスト数の推移、稼働状況を監視することで、想定の範囲内の動作か異常動作かを確認する。

[監視対象]

監視項目

監視方法

取得方法詳細

優先度

監視目的

Route53ヘルスチェック

CloudWatch

HealthCheckStatus

HealthCheckPercentageHealthy

WEBシステムのンフラレイヤ正常性監視

CloudFrontリクエストエラー率

CloudWatch

TotalErrorRate

4xxErrorRate

5xxErrorRate

WEBサイト/WEBアプリケーションの正常性監視

[対処方法]

Route 53のHealthCheck機能と連携し異常となった場合にCloudFrontにトラフィックを流さないように構成しておく。Route 53ではHealthCheckで異常になった場合に対象のIPアドレスを返さないようにする機能があるためRoute 53にPrimary(CloudFrontのFQDN)、Secondary(オリジンサーバのIP)を登録することで異常時には自動でSecondaryの方にトラフィックが流れ、可用性を高めることが可能。

CloudWatchで取得したCloudFrontのメトリックは障害原因調査のために利用する。

  • Elastic Load Balancing (ELB) の監視

ELBの死活監視ではELB自身の状態と、ELBと配下のEC2インスタンスとの接続の正常性についてもCloudWatch経由で取得して監視する。

[監視対象]

監視項目

監視方法

取得方法詳細

優先度

監視目的

ELBリスナー生成エラー数

CloudWatch

HTTPCode_ELB_4XX

HTTPCode_ELB_5XX

不正な形式のリクエスト数やリクエスト数に対するELB容量が十分であるかを監視

ELB-EC2接続エラー数

CloudWatch

BackendConnection

Errors

HealthyHostCount UnHealthyHostCount HTTPCode_Backend_2XX HTTPCode_Backend_3XX HTTPCode_Backend_4XX HTTPCode_Backend_5XX 

ELB-EC2間接続の正常性監視

[対処方法]

バックグラウンドEC2インスタンス側の正常性確認と合わせて原因を調査を実施する。

  • Auto Scalingの監視

死活監視という観点でAutoScalingを監視する場合は、予期せぬScale Inが引き起こされないように、AutoScalingPolicyに設定された最低台数値とInserviceとなっているEC2インスタンス台数を監視する。主に作業時の設定ミスや自動運用での設定反映失敗などの検知が目的となる。

[監視対象]

監視項目

監視方法

取得方法詳細

優先度

監視目的

Auto Scaling Groupの最低EC2インスタンス数

CloudWatch

GroupDesiredCapacity

予期せぬScale Inによるサービス停止の防止

Auto Scaling Groupの正常EC2インスタンス台数

CloudWatch

GroupInServiceInstances

 

必要な台数分のEC2インスタンスが確保出来ているかの確認

[対処方法]

GroupMinSize値の予期せぬ縮小を検知した場合は必要最低限の値まで引き上げる。異常となるEC2インスタンスの数が多い場合は障害未然防止のために原因調査を行う。

  • Amazon EC2 の監視

サーバ死活監視としては、Ping応答やEC2ステータス監視、ELBからのヘルスチェックなどいくつか監視方法が存在する。EC2インスタンスがAutoScaling構成になっている場合、1台1台のEC2インスタンスの死活監視に注力するのではなく、Group全体でサービス提供できる状態になっているかどうかを監視し、監視項目を減らし運用負荷を下げることが望ましい。

AutoScaling構成の場合の死活監視は、AutoScalingやELBのヘルスチェック機能を活用して必要なEC2が稼働しているかを監視する。一方サーバ内のプロセス監視には、監視ツールや監視サービスを使用し、OSから情報を取得して監視する。

[監視対象]

監視項目

監視方法

取得方法詳細

優先度

監視目的

AutoScaling Group所属のEC2死活監視

CloudWatch

GroupInServiceInstances

GroupDesiredCapacity

必要な台数分のEC2インスタンスが確保出来ているかの確認

ELB配下のEC2死活監視

CloudWatch

HealthyHostCount

UnHealthyHostCount

必要な台数分のEC2インスタンスが確保出来ているかの確認

AutoScalingGroup/ELB未登録のEC2の正常性監視

CloudWatch

StatusCheckFailed

StatusCheckFailed_Instance

StatusCheckFailed_System

EC2インスタンスと(インスタンスの稼働する)仮想サーバーホストの正常性監視

サーバプロセス監視

監視ツール/

監視サービス

OSコマンドを実行して監視対象プロセスの稼働状況を確認

サーバプロセスの正常稼働を確認

[対処方法]

AutoScalingGroupに登録されているEC2の場合、AutoScaling機能により自動で復旧されるため対処は不要となる。障害となったEC2インスタンスを調査したい場合はCLIなどでサスペンドをかけることで一時的にAutoScalingの動きを停止することが可能。

非AutoScalingGroupのEC2インスタンスでStatusCheckFailed_Systemとなった場合には該当EC2のStop & Startを実施することで物理ホストが移動し復旧するケースが多い。これを自動で行うAutoRecovery機能を活用し非AutoScalingGroupのEC2についても自動での復旧が可能。

サーバ内正常性監視で異常が検知された場合、監視ツールや監視サービスの自動アクション機能でプロセスの再起動や復旧スクリプト実行を行うことで自動で障害復旧が可能となる。ツールやサービスによってはランブックオートメーションの機能で、単発のコマンド実行だけでなく、複数のコマンドを実行することでより複雑な障害復旧手順を自動化することが可能なものもある。

  • Amazon EBSの監視

死活監視の観点ではディスクアクセス(Write/Read)が行えていることを監視するべきだが、Write/Read異常が発生するとプロセスダウン、やOSやアプリケーションなどのログ監視異常として検知できるため特段の監視は行わない。

  • S3の監視

S3とデータ転送を行うアプリケーション側の監視に兼ねる。またはCloudFrontのオリジンサーバとしてS3を活用している場合はWEBリクエスト監視を行う。

  • Amazon RDSの監視

APIを実行しRDSインスタンスのステータスを監視する。加えてアプリケーションがDBにアクセスできることを監視するために、ダミーSQLを発行してDBへのアクセスを監視する。またRDSが障害時の切り分け情報として使用するために、APIを実行してRDSインスタンスに発生したイベント情報を収集して監視する。

[監視対象]

監視項目

監視方法

取得方法詳細

優先度

監視目的

DBインスタンスステータス

その他

AWS APIs

DescribeDBInstances

DBインスタンスステータスの正常性監視

SQLリクエスト監視

監視ツール/

監視サービス

ダミーSQLを発行してDBにアクセスできることを確認

アプリケーションからDBにアクセスできる状態であるかを確認する

RDSイベント

その他

AWS APIs

DescribeEvents

RDSのイベント情報を収集し障害調査に利用する。

[対処方法]

Multi-AZ構成の場合マスタが障害になった場合自動でスレーブにフェイルオーバする。この際エンドポイントは変わらないためアプリケーション側での対処は必要なし。Single-AZ構成の場合、バックアップとして取得したスナップショットからリストアして復旧する。またはDBエンジンによってはリードレプリカをマスタに昇格させることも可能。この際エンドポイントは変更になるためアプリケーション側で接続先を修正する必要がある。

  • 構造

Sample2

Sample3

  • 注意点

上述の通り、Route 53のヘルスチェック機能とフェイルオーバー機能の連動や、ELBヘルスチェックとAutoScalingの連動、EC2インスタンスステータスチェックとAutoRecover機能の連動など死活監視と自動復旧機能を組み合わせることで高品質、低コストの運用を行うことが可能。監視設計する際は対応する復旧方法まで考慮する。

その他運用カテゴリはこちらを参照。

コメント

Featured Event

2017年9 月

          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30