このエントリは2020/07/01現在の情報に基づいています。将来の機能追加や変更に伴い記載内容との乖離が発生する可能性があります。

以前、Helidon MPをAzure Web Appにデプロイし実行するというエントリを記述した。

HelidonベースのアプリケーションをAzure App Serviceにデプロイする
https://logico-jp.io/2020/06/29/deploy-helidon-applications-to-azure-app-service/
Deploying Helidon Applications to Azure App Service
https://logico-jp.io/2020/06/29/deploying-helidon-applications-to-azure-app-service-in-english/

Helidon MPはMicroProfileに準拠しており、MicroProfileにはHealth Check仕様があってAPIも存在する。そのため、Azure Web AppのHealth Check機能から、MicroProfileのHealth Check APIを参照するようにすれば、わざわざWeb AppsのHealth CheckのためにAPIを作成する必要がない。

Azure Web AppのHealth Check機能とは

The Health Check feature is used to prevent unhealthy instance(s) from serving requests, thus improving availability. The feature will ping the specified health check path on all instances of your webapp every 2 minutes. The instance is considered healthy if it responds within 2 minutes with 200-299 status code. If an instance does not respond accordingly and consecutively after 5 pings, the instance is considered “unhealthy” and our service will stop routing requests to it. This documentation applies to App Service and App Service Environments.

Overview – Health Check (Preview)
https://github.com/projectkudu/kudu/wiki/Health-Check-(Preview)#overview

つまり、

• 2分ごとにWeb Appの全インスタンスに対し、指定したhealth check pathへping
  • 2分以内に2xxのHTTPステータスが返る場合はOK (healthy)
  • 5回連続で2xxのHTTPステータスが返らない場合はNG (healthyではない)
• healthyでないと判断した場合には、ロードバランサーのルーティング対象から外す

というしくみ。ドキュメントは以下を参照。

Health Check (Preview)
https://github.com/projectkudu/kudu/wiki/Health-Check-(Preview)

日本語＋Spring Bootでの説明はこちらがわかりやすい。

Azure App Service でHealth Checkを試す。
https://qiita.com/miginohou/items/7ab84314079d9e21a612

テストで使うアプリケーション

今回は、Helidon MP (2.0.1) のQuickstart Applicationを使う。他のMicroProfile実装のフレームワークを使う場合、Eclipse MicroProfile Starterを使ってプロジェクトを作成することになろう。その場合、以下のエントリに記載の通り、Health Check機能を有効化しておくこと。

MicroProfile Health Check
https://kodnito.com/posts/microprofile-health-check/
https://logico-jp.io/2019/03/07/microprofile-health-check/

プロジェクトが作成できたらビルドし、Web Appにデプロイしておく。デプロイの方法は以下を参照。

HelidonベースのアプリケーションをAzure App Serviceにデプロイする
https://logico-jp.io/2020/06/29/deploy-helidon-applications-to-azure-app-service/
Deploying Helidon Applications to Azure App Service
https://logico-jp.io/2020/06/29/deploying-helidon-applications-to-azure-app-service-in-english/

Web AppのHealth Checkの構成

構成手順は先ほどのQiitaの記事がわかりやすいが、順を追って記載しておく。

1. Azure Resource Explorerを開く。画面表示が少々遅い場合があるが、そのときはコーヒーでも飲んで待機する。

Azure Resource Explorer
https://resources.azure.com/

2. Resource Explorerの左側のメニューで subscriptions > (対象のサブスクリプション) > resourceGroups > (対象のリソースグループ) > providers > Microsoft.Web > sites > (対象のAppService) > config > web を開く。

以下は実際に開いてみた例。このJSONをこれから変更していく。その前に、画面右上方のRead Only/Read/Writeの設定を切り替える。デフォルトではRead Onlyになっているので、Read/Writeを選択しておく。

続いて、【Edit】（黄色でマークした場所）をクリックして編集可能な状態にする。

その上で、healthCheckPath を検索する。何も設定していなければ、以下のようにnullになっているはず。この例では139行目にある。

この項目を、Health Check APIのパスに変更する。Helidon MPの場合、/healthがそれに該当するので、/healthと指定する。

編集が終わったら、上にスクロールして、【Patch】もしくは【PUT】をクリックして設定変更を反映する。完了したら、Read/WriteからRead Onlyに戻しておくと安全。

以上で設定は終了。

試してみる

5回にわたってHTTP Pingが成功しない状態が続いた場合に、リクエストの振り分け先から除外され、異常なインスタンスは自動的に再起動される。HTTP Pingの成否は、特定のURIに対してGETリクエストを送り、2分以内に200番台のステータスコードで応答があるか否かで判断する。【メトリック】で新しいグラフを作成してみると、Health Check Statusがどのように推移しているかがわかる。プロセスが落ちたり、/healthからの応答がない場合には再起動がかかる。

Helidon SEではどうなのか

実はHelidon SEでも同じリソースパス (/health) が利用できるので、上記のやり方を踏襲できる。