アプリケーションのステータスチェック

アプリケーションのステータスチェックは、Amazon EC2 で実行されているアプリケーションのパフォーマンスと状態をモニタリングするのに役立ちます。アプリケーションのステータスチェックを使用すると、設定可能なパスとポートを介してアプリケーションをモニタリングすることで、アプリケーションのヘルス障害を検出して対応できます。例えば、アプリケーションのステータスチェックを使用して、ウェブサーバーが想定したポートをリッスンし、新しい接続を受け入れていることを確認できます。

アプリケーションのステータスチェックは、設定可能なパスとポートでアプリケーションの HTTP および HTTPS レスポンスをモニタリングします。これらは 60 秒ごとに実行され、Amazon EC2 Auto Scaling と統合されるため、アプリケーションに障害があるインスタンスの置き換えを自動化できます。

アプリケーションのステータスチェックの仕組み

アプリケーションのステータスチェックは、インスタンスのネットワークポートでリッスンしているエンドポイントに HTTP または HTTPS リクエストを 60 秒ごとに送信します。AWS は、レスポンスコードを設定したステータスコードマッチャーと比較します。チェックは、連続して一定回数のリクエストが失敗した後に障害ありとマークされ、連続して一定回数のリクエストが成功した後に再び正常とマークされます。両方のカウントはデフォルトで 2 に設定され、設定可能です。詳細については、「評価しきい値」を参照してください。

再起動中、アプリケーションのステータスチェックは、オペレーティングシステムの再起動中にアプリケーションがヘルスチェックリクエストに応答できないため、インスタンスが再び利用可能になるまで失敗を報告します。

ネットワークアーキテクチャ

アプリケーションのステータスチェックは、Amazon EC2 アプリケーションステータスチェックサービスから発信されます。インスタンスに到達するために、AWS は VPC にマネージド Elastic Network Interface (ENI) を作成します。AWS は、インスタンスが関連付けられているソースサブネットとセキュリティグループの組み合わせごとに 1 つの ENI を作成します。AWS は、アプリケーションのステータスチェックで最初にその組み合わせが必要になったときにマネージド ENI を作成し、残りのアプリケーションステータスチェックで不要になった場合は削除します。マネージド ENI は、インスタンスの ENI 制限にはカウントされませんが、アベイラビリティーゾーンごとに適用されるアカウントのリージョンごとのネットワークインターフェイスクォータにはカウントされます。詳細については、「Amazon VPC クォータ」を参照してください。

デフォルトでは、Amazon EC2 は、この設定が利用可能になる前にマネージドリソースがなかったアカウントのコンソールおよび API リストオペレーションからこれらのマネージドネットワークインターフェイスを非表示にします。可視性を変更するには、「マネージドリソースの可視性設定」を参照してください。

AWS は、関連付けられたインスタンス間でソースサブネットとセキュリティグループの組み合わせごとに 1 つのマネージドネットワークインターフェイスを作成します。マネージドインターフェイスの数は、モニタリング対象インスタンスが使用する個別のサブネットとセキュリティグループの組み合わせの数に応じて増加します。モニタリング対象インスタンスを少数のサブネットとセキュリティグループの組み合わせに統合すると、マネージドインターフェイスの数が減少します。例えば、1 つのセキュリティグループを使用する 2 つのサブネットにまたがる 200 のインスタンスは、2 つのマネージドインターフェイスを生成します。これら 2 つのサブネット全体で 3 つのセキュリティグループを使用する同じ 200 個のインスタンスは、最大 6 つのマネージドインターフェイスを生成します。各インターフェイスは、1 つのサブネットとセキュリティグループの組み合わせに対応します。

アプリケーションのステータスチェックは、VPC 内のプライベートな視点からインスタンスに到達します。スコープは、インスタンスの IP アドレスのプロパティではなく、チェックの送信元を記述します。AWS は VPC 内のサブネットにマネージド ENI を作成し、プライベートネットワークパス経由でインスタンスに到達します。

AWS マネージドネットワークパスでは、ヘルスチェックトラフィックは、ターゲットインスタンス (またはローカルゾーンターゲットの親アベイラビリティーゾーン) と同じアベイラビリティーゾーン内の AWS マネージド Amazon EC2 インスタンスから発信されます。トラフィックは AWS 内部ネットワークを経由し、パブリックインターネットを経由しません。詳細については、Amazon Web Services ウェブサイトの「Amazon VPC のよくある質問」を参照してください。

カスタマーマネージドネットワークパスでは、ソースサブネットを選択すると、ターゲットとは異なるアベイラビリティーゾーンからチェックを実行できます。詳細については、「クロスアベイラビリティーゾーンのモニタリング」を参照してください。

AWS マネージドネットワークパスとカスタマーマネージドネットワークパス

アプリケーションのステータスチェックは、ヘルスチェック ENI のソースサブネットとセキュリティグループ、およびターゲットインスタンスの宛先サブネットとセキュリティグループを選択するユーザーを決定する 2 つのオンボーディングモードをサポートします。

モードを選択するには、create コマンドに --health-check-paths パラメータを含めるか省略します。--health-check-paths パラメータを省略すると、AWS は送信元と送信先のサブネットとセキュリティグループ (AWS マネージドネットワークパス) を選択します。--health-check-paths パラメータを含める場合は、ユーザーがそれら (カスタマーマネージドネットワークパス) を管理します。

IP バージョン

各アプリケーションステータスチェックは、単一の IP バージョン (IPv4 または IPv6) に関連付けられます。IPv4 と IPv6 の両方でインスタンスをモニタリングするには、2 つの個別のアプリケーションステータスチェックを作成し、両方をインスタンスに関連付けます。

IPv4 と IPv6 の両方について、VPC 内からインスタンスに到達することを確認します。

ステータス値を確認する

個々のチェックは、以下のいずれかのステータスを報告します。

インスタンスについて報告された全体的なアプリケーションステータスは、すべての個々のチェック結果を集計します。全体的なステータスは、以下のいずれかの値です。

集約

各アプリケーションステータスチェックをインスタンスの全体的なステータスに含めるか除外するかをマークできます。デフォルトでは、チェックは included です。

アプリケーションステータスチェックの開始方法

前提条件

アプリケーションのステータスチェックを作成する前に、以下があることを確認してください。

ステップ 1: アプリケーションを設定する

チェックの作成時に指定するポートと HTTP パスで HTTP または HTTPS リクエストに応答するようにアプリケーションエンドポイントを設定します。ステータスコードマッチャーに含まれているレスポンスコードを返し、アプリケーションが正常であることを示します。

送信先インスタンスのセキュリティグループで、アプリケーションのステータスチェックで使用される送信元セキュリティグループからのインバウンドトラフィックがチェックポートで許可されていることを確認します。マネージドネットワークパスの場合、AWS はチェックの作成時にソースセキュリティグループを提供します。カスタマーマネージドネットワークパスでは、チェックを作成するときにソースセキュリティグループを指定します。

ステップ 2: チェック定義を作成する

AWS CLI を使用してアプリケーションのステータスチェックを作成します。

Console

1. Amazon EC2 コンソールの https://console.aws.amazon.com/ec2/ を開いてください。

2. ナビゲーションペインの [インスタンス] で、[アプリケーションのステータスチェック] を選択します。

3. [アプリケーションのステータスチェックの作成] を選択します。

4. [ヘルスチェックロジック] で、以下を設定します。

   • [プロトコル]: [HTTP] または [HTTPS] を選択します。

   • [ポート]: アプリケーションがリッスンするポートを入力します。

   • [パス] (オプション): リクエストする HTTP パスを入力します。例: /healthcheck。

   • [IP バージョン]: [IPv4] または [IPv6] を選択します。

   • [デバイスインデックス]: チェックするネットワークインターフェイスデバイスインデックス。デフォルトは 0 です。

5. [コントロールとしきい値] で、[タイムアウト] を設定し、オプションで [ステータスコードマッチャー]、[失敗しきい値]、[成功しきい値]、[初期化猶予期間] を設定します。チェック間隔は 60 秒に固定されています。

6. [集約] で、チェックをアプリケーション全体のステータスに反映させ、Amazon EC2 Auto Scaling を動作させる場合は [含まれています] を選択し、全体的なステータスに影響を与えずにチェックを報告する場合は [除外されています] を選択します。

7. [ヘルスチェックパス] では、Amazon EC2 がインスタンスのサブネットにヘルスチェックネットワークインターフェイスを配置できるように [ネットワークパスを指定しない (推奨/デフォルト)] を選択したままにするか、[ネットワークパスを指定する (アドバンスド)] を選択して、ソースサブネット、セキュリティグループ、および送信先を自分で定義します。

8. (オプション) [名前タグ] と他の [タグ] を追加します。

9. [アプリケーションのステータスチェックの作成] を選択します。

AWS CLI

AWS マネージドネットワークパスを使用するには、--health-check-paths パラメータを省略し、AWS で送信元サブネットと送信先サブネット、およびセキュリティグループを選択します。

aws ec2 create-application-status-check \
        --protocol https \
        --port 443 \
        --path "/health" \
        --status-code-matcher "200"

カスタマーマネージドネットワークパスを使用するには、--health-check-paths パラメータを含めます。各ヘルスチェックパスには、ソース (ヘルスチェック ENI のサブネットとセキュリティグループ) と 1 つ以上の送信先 (ターゲットインスタンスのサブネットとセキュリティグループ) が含まれます。

aws ec2 create-application-status-check \
        --protocol https \
        --port 443 \
        --path "/health" \
        --status-code-matcher "200" \
        --health-check-paths '[{"Source":{"SubnetId":"subnet-111","SecurityGroupId":"sg-aaa"},"Destinations":[{"SubnetId":"subnet-222","SecurityGroupId":"sg-bbb"}]}]'

ステップ 3: チェックをインスタンスに関連付ける

チェックを、インスタンス ID またはタグでモニタリングするインスタンスに関連付けます。

Console

1. ナビゲーションペインの [インスタンス] で、[アプリケーションのステータスチェック] を選択し、チェックを選択します。

2. [ステータスチェックの関連付けを管理] を選択し、[リソース ID による関連付けの管理] または [タグによる関連付けの管理] を選択します。

3. Auto Scaling グループ内のすべてのインスタンスに関連付けるには、[タグによる関連付けの管理] を選択し、タグキーとして aws:autoscaling:groupName を入力し、値として Auto Scaling グループ名を入力します。

4. 関連付ける を選択してください。

AWS CLI

インスタンス ID 別:

aws ec2 associate-application-status-check \
        --application-status-check-id asc-1234567890abcdef0 \
        --instance-ids i-0123456789abcdef0

タグ別:

aws ec2 associate-application-status-check \
        --application-status-check-id asc-1234567890abcdef0 \
        --target-tag-associations Key=Environment,Value=production

Auto Scaling グループ内のすべてのインスタンスに関連付けるには、aws:autoscaling:groupName システムタグを使用します。

aws ec2 associate-application-status-check \
        --application-status-check-id asc-1234567890abcdef0 \
        --target-tag-associations Key=aws:autoscaling:groupName,Value=my-asg

関連付けオペレーションと関連付け解除オペレーションは、インスタンスごとの成功と失敗の結果を返します。一部のインスタンスを関連付けられない場合 (チェックが既に関連付けられている場合など)、それらのインスタンスは失敗した結果に理由と共に表示されます。

ステップ 4: 結果を表示する

インスタンスごとのアプリケーションのヘルスステータスを表示します。

Console

1. Amazon EC2 コンソールの https://console.aws.amazon.com/ec2/ を開いてください。

2. ナビゲーションペインで、[インスタンス] を選択してください。

3. インスタンスを選択し、[ステータスとアラーム] タブを選択します。

4. [アプリケーションのステータスチェック] で、全体的なステータスと、関連する各チェックの個々のステータスを確認します。

AWS CLI

aws ec2 describe-application-status \
        --instance-ids i-0123456789abcdef0

レスポンスには、アプリケーション全体のステータス、関連する各チェックのチェックステータス、失敗したチェックのアプリケーションから返された HTTP ステータスコードが含まれます。

レスポンスの例:

{
        "ApplicationStatuses": [
            {
                "InstanceId": "i-0123456789abcdef0",
                "ApplicationStatus": {
                    "Status": "ok",
                    "Details": [
                        {
                            "ApplicationStatusCheckId": "asc-1234567890abcdef0",
                            "Status": "passed",
                            "Reason": {
                                "Code": "ResponseCodeMatched",
                                "StatusCode": 200,
                                "Protocol": "HTTP"
                            }
                        }
                    ]
                }
            }
        ]
    }

チェック定義 (インスタンスごとのステータスではなく) を表示するには、describe-application-status-checks を使用します。このコマンドは、プロトコル、ポート、HTTP パス、ステータスコードマッチャーの設定など、アプリケーションのステータスチェックの設定を返します。

設定オプション

アプリケーションのステータスチェックでは、いくつかの設定パラメータを使用できます。このセクションでは、パラメータ名から動作が自明でないパラメータについて説明します。パラメータと検証ルールの完全なリストについては、「Amazon EC2 API リファレンス」の「CreateApplicationStatusCheck」と「AssociateApplicationStatusCheck」を参照してください。

評価しきい値

起動猶予期間

IP スコープ

デバイスインデックス

集約、IP バージョン、ヘルスチェックパス (送信元サブネットと送信先サブネット、セキュリティグループ) については、このページの前半にある独自のセクションで説明します。

デフォルト設定

AWS マネージドネットワークパスでは、アプリケーションのステータスチェックは以下のデフォルトを使用します。

Amazon EC2 Auto Scaling の統合

Amazon EC2 Auto Scaling は、チェックが集計に含まれている限り、全体的なアプリケーションステータスが impaired と報告されるインスタンスを自動的に終了して置き換えます。アプリケーションのステータスチェックをグループ内のインスタンスに関連付ける以外に、Auto Scaling グループの設定は必要ありません。

Amazon EC2 Auto Scaling は、個々のチェックステータスではなく、インスタンスの全体的なステータスを使用します。excluded とマークされたチェックは、Amazon EC2 Auto Scaling アクションを実行しません。suppressed 状態のチェックは、Amazon EC2 Auto Scaling アクションを実行しません。

チェックの InitializationGracePeriodSeconds パラメータを使用して、アプリケーションのステータスチェックが開始される前に新しいインスタンスが起動するための時間を確保します。猶予期間が短すぎると、アプリケーションがトラフィックを処理する準備が整う前に、新しいインスタンスが終了して Amazon EC2 Auto Scaling に置き換えられる可能性があります。

チェックの InitializationGracePeriodSeconds は、インスタンスが起動してからチェックがアプリケーションの評価を開始するまでの時間を設定します。アプリケーションの起動時間をカバーするように設定し、アプリケーションの起動中にチェックが impaired をレポートしないようにします。Auto Scaling グループのヘルスチェックの猶予期間は別途設定されます。インスタンスがサービスに入ってから、Amazon EC2 Auto Scaling がヘルスチェックの失敗によりインスタンスを終了するまでの時間を設定します。

Amazon EC2 Auto Scaling でのヘルスチェックの仕組みに関する詳細については、「Amazon EC2 Auto Scaling ユーザーガイド」の「Auto Scaling グループのインスタンスのヘルスチェック」および「Auto Scaling グループでのアプリケーションステータスチェックの使用」を参照してください。

デプロイ、インプレースパッチ適用、置換の処理

デプロイ、インプレースパッチ適用、およびその他のメンテナンスオペレーションは、アプリケーションを一時的に停止または再起動することがあります。この間、アプリケーションはヘルスチェックリクエストに応答できないため、アプリケーションのステータスチェックは失敗を報告します。インスタンスが Auto Scaling グループにあり、アプリケーションのステータスチェックが集約に含まれている場合、中断が予想される場合でも、Amazon EC2 Auto Scaling はこれらのインスタンスを終了して置き換えることがあります。

オプション A: チェックを抑制する

期間がわかっている制限付きメンテナンスウィンドウには抑制を使用します。抑制はインスタンスレベルで適用されます。期間を指定するか、これを省略して、抑制を無効にするまでチェックを抑制します。

AWS CLI

aws ec2 enable-application-status-check-suppression \
        --instance-ids i-0123456789abcdef0 \
        --duration-seconds 3600

レスポンスは、インスタンスごとに、抑制の開始時刻と終了時刻を返します。部分的に成功する可能性があります。一部のインスタンスは抑制に失敗し、理由と共にレスポンスに表示される場合があります。

抑制ウィンドウの有効期限が切れる前にチェックを再開するには:

aws ec2 disable-application-status-check-suppression \
        --instance-ids i-0123456789abcdef0

抑制されている間、インスタンスの全体的なアプリケーションステータスは suppressed を報告します。Amazon EC2 Auto Scaling は suppressed インスタンスでは動作しません。

オプション B: 集約からチェックを除外する

チェックで個々のステータスの評価とレポートを継続するが、全体的なステータスに影響を与えたり、Amazon EC2 Auto Scaling アクションをトリガーしたりしない場合は、チェックの集計設定を excluded に設定します。これは、新しいチェックバージョンをロールアウトしたり、置き換えのリスクを伴わずに変更を検証したり、テレメトリを運用に影響を与えずに継続したい場合など、存続期間の長いシナリオに役立ちます。

詳細については、「集約」を参照してください。

オプション C: チェックの関連付けを解除する

存続期間の長い削除または無期限の削除には、関連付け解除を使用します。

aws ec2 disassociate-application-status-check \
        --application-status-check-id asc-1234567890abcdef0 \
        --instance-ids i-0123456789abcdef0

タグで関連付けた場合は、インスタンスからタグを削除して関連付けを解除します。関連付けを解除すると、インスタンスの全体的なアプリケーションステータスが not-applicable を報告します。

デプロイガイダンス

デプロイは、抑制を必要とする最も一般的なメンテナンスシナリオです。デプロイツールにデプロイ前フックとデプロイ後フックがある場合に抑制を使用すると、デプロイの開始前にチェックを抑制し、デプロイの完了後に抑制を無効にできます。

一般的なパターンは以下のとおりです。

デプロイツールにフックがない場合は、デプロイを呼び出す CI/CD パイプラインから抑制を行います。

新しいアプリケーションステータスチェックのテスト

新しいアプリケーションステータスチェックがインスタンスレベルのモニタリングに反映され始める前に、本番環境でそのチェックを検証できます。チェックを作成するときに集約設定を excluded に設定し、予想されるステータスと HTTP レスポンスコードがレポートされることを確認します。準備ができたら、設定を included に変更して、チェックがインスタンスの全体的なステータスに反映され、Amazon EC2 Auto Scaling と統合されるようにします。

高度なネットワーキング

アプリケーションのステータスチェックは、指定した (または AWS がユーザーに代わって選択する) ソースサブネットとセキュリティグループのマネージド ENI から発信されます。単一ソース設定が提供するよりも高い可用性を必要とするワークロード、または Local Zones または Outposts で実行されるワークロードの場合は、以下のパターンを検討してください。

クロスアベイラビリティーゾーンのモニタリング

アベイラビリティーゾーンの冗長性については、複数のアベイラビリティーゾーンからヘルスチェックを実行できます。カスタマーマネージドネットワークパスでは、--health-check-paths パラメータを使用して、同じ送信先インスタンスに到達する 2 つの異なるアベイラビリティーゾーンにソースがあるヘルスチェックパスを定義します。2 つのアベイラビリティーゾーンからモニタリングすると、1 つのアベイラビリティーゾーンが使用できなくなっても、インスタンスのヘルスレポートが継続されます。

以下の例では、ソースが異なるアベイラビリティーゾーンにあり、どちらも同じ送信先インスタンスに到達する 2 つのヘルスチェックパスを持つチェックを作成します。

aws ec2 create-application-status-check \
        --protocol https \
        --port 443 \
        --path "/health" \
        --status-code-matcher "200" \
        --health-check-paths '[{"Source":{"SubnetId":"subnet-source-az1","SecurityGroupId":"sg-healthcheck"},"Destinations":[{"SubnetId":"subnet-app-az1","SecurityGroupId":"sg-app"}]},{"Source":{"SubnetId":"subnet-source-az2","SecurityGroupId":"sg-healthcheck"},"Destinations":[{"SubnetId":"subnet-app-az2","SecurityGroupId":"sg-app"}]}]'

ローカルゾーン

AWS Local Zones で実行されているインスタンスの場合、マネージド Elastic Network Interface (ENI) は Local Zone ではなく親 AWS リージョンにあります。親リージョンとローカルゾーンインスタンス間のヘルスチェックトラフィックは、ローカルゾーンサービスリンクを経由するため、追加のデータ転送料金が発生する場合があります。

ベストプラクティス

トラブルシューティング

アプリケーションのステータスチェックで障害が報告されても、アプリケーションが正常であると予想される場合は、以下の点を確認してください。

理由コード

describe-application-status レスポンスには、各チェックの理由が含まれます。理由には、アプリケーションによって返される HTTP ステータスコード (数値) と、チェックに使用されるプロトコルが含まれます。返されたステータスコードがステータスコードマッチャーに含まれている場合はチェックが passed とマークされ、含まれていない場合は failed とマークされます。

理由には、理由コードと、HTTP レベルの結果の場合はプロトコルと返された HTTP ステータスコードも含まれます。理由には、以下のフィールドが含まれています。

返された HTTP ステータスコードを使用して、チェックが失敗した理由を特定します。一般的な例をいくつか示します。

完全な ApplicationStatusReason 構造については、「Amazon EC2 API リファレンス」の「ApplicationStatusReason」を参照してください。

よくある問題

アプリケーションのステータスチェックをモニタリングする

アプリケーションのステータスチェックは、以下の 3 つの方法でモニタリングできます。

アラームによる自動化には CloudWatch メトリクスを使用します。インスタンスのステータスを既にクエリしている場合は describe-instance-status を使用します。チェックごとの詳細な可視性を確認するには describe-application-status を使用します。

セキュリティおよびアクセス許可

AWS は、サービスにリンクされたロールを通じてアプリケーションのステータスチェックに使用されるネットワークインターフェイスを作成および管理します。サービスがこれらの ENI を作成するために IAM のセットアップは必要ありません。サービスにリンクされたロールは、EC2ApplicationStatusChecksServiceRolePolicy AWS マネージドポリシーを使用します。

アプリケーションのステータスチェックを自分で作成、関連付け、記述、削除、および抑制するには、IAM ユーザーまたはロールに対応する Amazon EC2 アクセス許可が必要です。アクションの完全なリストについては、「Amazon EC2 API リファレンス」を参照してください。

インスタンスのセキュリティグループは、設定したポートでヘルスチェックソースセキュリティグループからのインバウンドトラフィックを許可する必要があります。AWS マネージドネットワークパスでは、AWS はソースセキュリティグループを提供します。カスタマーマネージドネットワークパスでは、ソースとして指定したセキュリティグループを使用します。

料金

アプリケーションのステータスチェックは、以下のコンポーネントで請求されます。

クォータ

アプリケーションのステータスチェックは、AWS サービスクォータの対象となります。クォータ名、デフォルト値、および説明については、「AWS 一般的なリファレンス」の「Amazon EC2 エンドポイントとクォータ」を参照してください。

マネージドネットワークインターフェイスに影響する AWS サービスクォータに加えて、アプリケーションのステータスチェックには以下のサービスクォータがあります。使用状況の確認とクォータの引き上げリクエストは、Service Quotas コンソールで行えます。

これらのクォータでは、ターゲットは 1 つのヘルスチェックがモニタリングする 1 つのインスタンスです。複数のヘルスチェックがインスタンスをモニタリングする場合、各インスタンスとヘルスチェックのペアは個別のターゲットとしてカウントされます。関連付けは、ヘルスチェックに関連付ける単一のタグルールまたは単一のインスタンス ID です。各ルールまたはインスタンス ID は、解決されるインスタンスの数に関係なく、1 つの関連付けとしてカウントされます。

ほとんどのクォータの増加は、自動的に承認されます。アカウントあたりのターゲット数を増やすには、リクエストと手動承認が必要です。

クォータに達する前に通知されるように、アプリケーションステータスチェックのクォータ使用状況に Amazon CloudWatch アラームを作成することをお勧めします。Service Quotas は AWS/Usage 名前空間の使用状況メトリクスを CloudWatch に発行します。これを使用してアラームを作成できます。