セルフヒーリング

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

プローブの使用と設定

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

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

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

プロパティ名	Description
`initialDelaySeconds`	コンテナ起動後、プローブが開始されるまでの秒数。
`periodSeconds`	プローブがタイムアウトするまでの秒数。デフォルトは10で、最小は1。
`timeoutSeconds`	プローブを実行する頻度（秒単位）。デフォルトおよび最小値は 1。
`successThreshold`	失敗した後、プローブが成功したとみなされるための最小連続成功回数。デフォルトおよび最小値は `1`。活性のためには `1` でなければならない。
`failureThreshold`	Liferay Cloudが失敗したプローブをあきらめるまでに繰り返す回数です。活性プローブの場合、あきらめるとサービスが再起動する。準備プローブの場合、あきらめると、プローブは失敗としてマークされる。デフォルトは `3`で、最小値は `1`。

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

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

デフォルト値を変更するには、 lcp.json ファイルを変更します。 LCP.jsonによるコンフィギュレーションを参照してください。

準備プローブ

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

tip

「Liferay」サービス（/c/portal/layout）に対する準備プローブのパスは、インスタンスのホームページ（デフォルトでは/web/guest/home）へのリダイレクトを使用します。リダイレクト処理では、別のリクエストが追加されるため、プローブの応答時間が長くなります。応答時間を短縮し、準備プローブの効果を高めるために、インスタンス内のページをより直接的に指すようにパスを設定します。

プローブが200または300の範囲のHTTP応答を受信すると、アプリケーションを正常とマークします。サービスのコンテナのライフサイクル全体に渡って実行され、（クラッシュなどにより）インスタンスが稼働していない場合には失敗します。

プローブがパスに何度もpingを実行し（LCP.json内のプローブの failureThreshold フィールドで設定可能）、有効な応答を得られない場合（プローブの失敗）、サービスは自動的に再起動します。準備プローブが失敗した場合は、サービスの起動時に問題が発生しているか、サービスがクラッシュして回復していない可能性があるか、プローブの設定に対して反応が遅すぎるため、調整が必要であるかを示しています。

各サービスの 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" "-"

準備プローブ構成の調整

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

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