AWS OpsWorks スタックが正常なインスタンスを不意に起動したり再起動しないようにするにはどうすればよいですか?

自動ヒーリングは、インスタンスが Amazon EC2 ヘルスチェックに合格した場合でも、スタック内にある異常なインスタンスまたは失敗したインスタンスを再起動します。スタックのレイヤー設定では、自動ヒーリングがデフォルトで有効化されています。自動ヒーリングでは以下のイベントが発生します。

• OpsWorks スタックエージェントが約 30 秒ごとにキープアライブを送信します。サービスが 5 分たってもキープアライブを受信しない場合、サービスがインスタンスを異常としてマークします。AWS OpsWorks Stacks API によって起動されたインスタンスのレイヤーで自動ヒーリングが有効化されている場合、この API がインスタンスを停止し、起動します。
• インスタンスが Amazon Elastic Block Store (Amazon EBS) によってバックアップされている場合、AWS OpsWorks API が基盤となる Amazon EC2 インスタンスを停止し、再起動します。インスタンスがインスタンスストアによってバックアップされている場合、インスタンス停止時点で基盤となる Amazon EC2 インスタンスが終了されます。その後、そのインスタンスは OpsWorks スタックがインスタンスを再び起動するときに再度作成されます。詳細については、「自動ヒーリングを使用した、失敗したインスタンスの置き換え」を参照してください。
• インスタンスが Amazon EC2 で起動され、OpsWorks スタックに登録されている場合、AWS OpsWorks API がインスタンスを停止し、再起動します。登録されたオンプレミスインスタンスが AWS OpsWorks ヘルスチェックに合格しなかった場合、そのインスタンスは connection-lost としてマークされますが、再起動されません。詳細については、「登録されたインスタンスの管理」を参照してください。
  

自動ヒーリングの兆候について Amazon EC2 StopInstances API コールの出力をチェックする

1.    AWS CloudTrail コンソールを開きます。

2.    [イベント履歴] を選択します。

3.    フィルターで [イベント名] を選択します。詳細については、「CloudTrail イベントのフィルタリング」を参照してください。

4.    検索ボックスで [StopInstances] を選択します。

5.    フィルターで [リソース名] を選択します。

6.    検索ボックスに EC2 インスタンス ID を入力して、タイムスタンプをメモしておきます。

OpsWorks スタックがそのインスタンスを停止した場合、Amazon EC2 StopInstances API が以下の出力を表示します。

"invokedBy": "opsworks.amazonaws.com"

自動ヒーリングの兆候について AWS OpsWorks StopInstances API コールの出力をチェックする

1.    CloudTrail コンソールを開きます。

2.    [イベント履歴] を選択します。

3.    フィルターで [イベント名] を選択します。

4.    検索ボックスで [StopInstances] を選択します。

5.    フィルターで [リソース名] を選択します。

6.    検索ボックスに OpsWorks インスタンス ID を入力して、タイムスタンプをメモしておきます。

7.    Amazon EC2 でインスタンスが停止されたときの StopInstance API コールを検索して、タイムスタンプをメモしておきます。

注意: API コールを見つけられない場合は、自動ヒーリングがインスタンスに適用されています。

以下に留意してください。

• OpsWorks スタックが管理するインスタンスは、Amazon EC2 ではなく、AWS OpsWorks API を使って設定してください。
• 管理対象インスタンスが、OpsWorks スタックサービスと一貫した状態であることを確認してください。
  注意: 例えば、インスタンスが Amazon EC2 で停止されると、OpsWorks スタックがそのインスタンスのエージェントからの信号を期待していることから、インスタンスは異常としてマークされます。OpsWorks スタックはその後インスタンスの自動ヒーリングを行いますが (有効化されている場合)、OpsWorks スタックのステータスが Amazon EC2 のステータスと一致しないため、インスタンスがフリーズする可能性があります。この状態が発生した場合は、--force フラグを使用して、stop-instance コマンドでインスタンスを停止してください。

スタック内の自動ヒーリングイベントをリッスンするための CloudWatch ルールを作成する

1.    (オプション) インスタンスに自動ヒーリングが適用されるときに通知を受け取るには、通知をセットアップします。

2.    OpsWorksAutoHealingNotifier という名前の SNS トピックを作成してから、エンドポイントをそのトピックにサブスクライブします (E メールアドレスまたは電話番号など)。

3.    CloudWatch Events ルールを作成してから、SNS トピックをターゲットとして設定します。

4.    ルール設定内で、以下のパターンを使用して自動ヒーリングイベントをリッスンするための CloudWatch ルールをセットアップします。

{
  "source": [
    "aws.opsworks"
  ],
  "detail": {
    "initiated_by": [
      "auto-healing"
    ]
  }
}

5.    設定を保存するには、[ルールの作成] を選択します。

インスタンスのログファイルを使用してトラブルシューティングを行う

1.    Linux の /var/log/aws/opsworks にあるログファイルを表示するには、SSH を使用してインスタンスに接続します。Windows の C:\ProgramDataOpsWorksAgent\var\logs にあるログファイルを表示するには、RDP を使用してインスタンスに接続します。

2.    以下のログファイルのトラブルシューティングを行います。
エージェントによる OpsWorks へのキープアライブ信号の返信試行のうち、正常に行われたもの、または失敗したものについて opsworks-agent.keep_alive.log をチェックします。。詳細については、「VPC でのスタックの実行」を参照してください。
システムが CPU 負荷とメモリ をどのように処理しているかについて、opsworks-agent.statistics.log をチェックします。使用されたメモリの量、および CPU と負荷のメトリクスが高いかどうかを確認できます。。
エージェントが停止または開始された時間など、インスタンスで実行されているエージェントの全体的な正常性のレポートについて opsworks-agent.log をチェックします。
インスタンス上のエージェントによって行われたコマンドのうち、正常に行われたもの、または失敗したもののレポートについて opsworks-agent.process_command.log をチェックします。

注意: これらのログファイルは、インスタンス上のルートデバイスが Amazon EBS によってバックアップされている場合に限り、維持されます。インスタンスストアでバックアップされているインスタンスは、OpsWorks の StopInstance API コールで終了され、これが原因でログが失われます。

3.    システムレベルのログをチェックして、自動ヒーリングが提供されたときのインスタンスの全体的な正常性を判断します。

注意: エージェントに自動ヒーリングイベントが原因の問題がある場合、ログがシステムレベルの情報 (例えば「メモリ不足」エラー) を省く可能性があります。

OpsWorks スタックが管理対象インスタンスの自動ヒーリングを行わないようにする

• インスタンスが VPC ルートテーブルのインターネットゲートウェイまたは NAT を使ってインターネットに接続できることを確認してください。
• インスタンス、セキュリティグループ、および VPC ACL のレベルでポート 443 のロックを解除します。
  注意: VPC への変更、または間違った方法で作成された VPC は、インスタンスのインターネット経由での OpsWorks スタックとの通信を妨げる場合があります。
• インスタンスに余分な負荷がかかっていてもアプリケーションが機能するように、アプリケーションにインスタンスレベルのリソース (メモリおよび CPU など) が十分あることを確認してください。
  注意: 余分な負荷に備えておくことがベストプラクティスです。例えば、ライフサイクルイベントはインスタンスに予期しない負荷をかける場合があります。
• CloudWatch のメトリクスとアラームを使用して、インスタンスに高負荷の　CPU、メモリ、またはネットワークトラフィックがある場合に警告するようにします。
  アプリケーションに対して自動ヒーリングが機能しない場合は、レイヤー設定で自動ヒーリングを無効化してください。