セルフヒーリング

Liferay Cloudのセルフヒーリング機能は、サービスやアプリケーションが応答しなくなったことを検知し、応答しなくなったサービスを回復させるための手順を自動的に開始します。 このプラットフォームでは、プローブを使ってサービスを監視しています。

プローブの使用と設定

Liferay Cloudでは、アプリケーションを管理するために組み合わせて使用する 2 つのプローブが用意されています。

• Liveness Probe：サービスが動作しているかどうかを示します。
• Readiness Probe ：サービスがリクエストを受け取る準備ができているかどうかを示します。

各プローブは、以下のオプションで設定できます。

プローブが障害を検出すると（つまり、ステータスチェックで成功メッセージを返さないと）、プローブは自動的に障害に対処するためのアクションを起こします（サービスの再起動や、インスタンスからトラフィックをリダイレクトするなど）。 プローブ自体はシステムダウンを引き起こしません。プローブは自動的に問題を検出し、応答しようとします。

活性プローブと準備プローブは、環境に関係なくすべてのサービスに展開されます。 通常、顧客は、ニーズに基づいて値を調整する必要がない限り、プローブを変更する必要はありません。 たとえば、システム管理者は、initialDelaySeconds 値を 増やして、起動プロセスを長くすることができます。

デフォルト値を変更するには、 lcp.json ファイルを変更します。 LCP.json による構成 の記事を参照してください。

準備プローブ

準備プローブは、URL リクエスト (パス/ポート) を使用して、サービスが正しく実行されていることを検証します。 このプローブは、設定できるパスを繰り返しpingします（例えば、 /c/portal/layout のための Liferay サービス）。 多くの場合、準備プローブは、アプリケーション内の軽量なHTTPサーバーです。

プローブが200または300の範囲のHTTP応答を受信すると、アプリケーションを正常とマークします。 これは、サービスのコンテナのライフサイクル全体にわたって実行され、インスタンスがもうライブでない場合は失敗します (たとえば、クラッシュが原因)。

プローブがパスを何回か ping しても (s failureThreshold LCP.json内のフィールドで設定可能)、有効な応答が得られない場合 (プローブの失敗)、サービスは自動的に再起動します。 活性プローブが失敗した場合、それはサービスの起動中に問題が発生している、サービスがクラッシュして回復できない可能性がある、またはプローブの構成に対して応答が遅すぎるため調整する必要がある可能性があることを示しています。

各サービスの LCP.json ファイルには、次の構成が含まれています。

{
   "livenessProbe": {
      "httpGet": {
         "path": "/status",
         "port": 3000
      },
      "initialDelaySeconds": 40,
      "periodSeconds": 5,
      "successThreshold": 5
   }
}

活性プローブ構成の調整

活性プローブの最適な構成は、デプロイしたカスタマイゼーションや、サービスの予想される立ち上げ時間によって異なります。 パス の値は、サービスが稼働していることを最もよく示すルートを設定してください。 liferay サービスの場合、これはメインサイトのホームページへのパス ( /web/guest/homeなど) になるか、ナビゲーションから非表示になっていて読み込みに時間のかかるページになる場合があります。

liferay サービスのパスは、適用される可能性のあるモジュールやカスタマイズのため、パスの調整が必要になる可能性がある唯一のサービスです。 代わりにpingを行うカスタムOSGiモジュールやサーブレットを作成することができます。例えば、サービスが稼働中であることを知らせるリクエストを受け入れる前に、他のカスタムモジュールがアクティブであることを確認します。

活性プローブの構成内のその他の値 (initialDelaySeconds、 periodSeconds、 successThreshold、 timeoutSeconds、および failureThreshold) も、サービスの一般的なパフォーマンスに合わせて調整する必要があります。 initialDelaySeconds の値は、サービスが起動するまでの時間を考慮して設定する必要があります。 例えば、 liferay サービスが起動時に余分なタスクを実行している場合、活性チェックを実行するのに時間がかかることがあります。

timeoutSeconds と failureThreshold の値は、サービスがハングアップから回復できず、再起動しなければならないと考えても問題ない程度の長さにする必要があります。 これらの値は、サービスのリクエストへの応答の一般的なパフォーマンスに適していない場合は、必要に応じて調整する必要があります。

カスタマイズ (カスタム モジュール、スクリプトなど) がサービスの起動と応答時間に及ぼす可能性のある影響を認識し、それに応じてライブネス プローブの構成を調整する必要があります。 構成したinitialDelaySecondsの値は、起動に失敗した場合に合理的な時間内にサービスを停止し、再起動するのに有用である必要がありますが、プローブがサービスを再起動する速度が速すぎて、正常に起動できないほど短くしないように設定してください。 timeoutSeconds、periodSeconds、およびfailureThresholdは、サービスを強制的に再起動する前に、自ら回復してオペレーションを再開するために十分な時間を与えるだけの長さが必要です（再起動をあまり早く行うと活性プローブの失敗の原因を見つける妨げになる場合があるためです）。

準備プローブ

準備プローブは、活性プローブのようにアドレスにpingをするか、実行可能なコマンドを使ってサービスの可用性を確認します。 コマンドが正しい終了コードで戻る場合、コンテナは正常としてマークされています。 それ以外の場合は、異常と判断され、トラフィックは障害のあるインスタンスから遠ざけられます。

準備プローブが失敗した場合は、設定したコマンドを実行する際にサービスがタイムアウトしたことを示しています。 これは、サービスの動作が遅すぎてチューニングが必要であること、トラフィックが多くてすべてのリクエストに対応できないこと、あるいは実行中のコマンドに問題があることを示しています。

準備プローブがサービスの準備ができていることを検出するとすぐに、サービスはトラフィックを受信する可能性があります。 サービスの準備ができていないことをプローブが検知すると、新しいトラフィックの受信を停止します。 ただし、準備プローブはサービスを再起動しません。 活性プローブ のみが、サービスを強制的に再起動します。

各サービスの LCP.json ファイルには、次の構成が含まれています。

{
   "readinessProbe": {
      "exec": {
         "command": ["cat", "/tmp/healthy"]
      },
      "initialDelaySeconds": 40,
      "periodSeconds": 5
   }
}

以下は、準備プローブのサンプルログで、 webserver サービスに展開されています。 ログには、Googleサーバーが特定のパス nginx_statusが 継続的にヒットしていることが示されています。

Oct 04 12:05:51.821 build-14 [webserver-5547c96447-hbrr6] 10.138.0.69 - - [04/Oct/2019:19:05:51 +0000] "GET /nginx_status HTTP/1.1" 200 117 "-" "kube-probe/1.12+" "-"
Oct 04 12:05:53.001 build-14 [webserver-5547c96447-hbrr6] 10.138.15.249 - - [04/Oct/2019:19:05:53 +0000] "GET /nginx_status HTTP/1.1" 200 115 "-" "GoogleHC/1.0" "-"
Oct 04 12:05:53.083 build-14 [webserver-5547c96447-hbrr6] 10.138.0.13 - - [04/Oct/2019:19:05:53 +0000] "GET /nginx_status HTTP/1.1" 200 115 "-" "GoogleHC/1.0" "-"
Oct 04 12:05:53.293 build-14 [webserver-5547c96447-hbrr6] 10.138.15.251 - - [04/Oct/2019:19:05:53 +0000] "GET /nginx_status HTTP/1.1" 200 115 "-" "GoogleHC/1.0" "-"

準備プローブ構成の調整

準備プローブは、リクエストを受信するためのサービスの可用性を適切に評価するコマンドを実行する必要があります。 サービスのインスタンスのリクエストへの応答が遅すぎて、それ以上のトラフィックを遮断する必要がある場合（可能であれば他のインスタンスにリダイレクトする）、設定された実行コマンドもこの遅さを経験し、適切に応答できるようにする必要があります。 ウェブサーバーなどのサービスは、デフォルトでは、サービスの準備状況を確認するために特定のアドレスにのみ ping を実行します。 しかし、サービスの応答性を確認するためにカスタムスクリプトを実行するなど、別のコマンドを作成してもいいでしょう。

必要に応じて、他の設定値（initialDelaySeconds、 periodSeconds、 timeoutSeconds、 successThreshold）も調整する必要があります。 サービスが、時間がかかってもより多くのリクエストに対応できるようにしたい場合（例えば、リクエストに対応するための作業に時間がかかることが予想される場合）、より長いタイムアウトを設定する必要があります。 サービスがリクエストに素早く応答する必要がある場合や、代わりにタイムアウトする必要がある場合は、構成でより短いタイムアウトを設定する必要があります。