OpenResty Edge でゲートウェイサーバーの自動ヘルスチェックを有効にする

OpenResty Edge は、ゲートウェイサーバー自体——つまりアップストリームのバックエンドではなく、ロードバランサーノードそのもの——の健全性を自動的にチェックする機能を提供します。各ノードは設定可能な間隔で HTTP による探査を受けます。チェックに失敗したノードの IP は、DNS 解決と SSL セッションの分散キャッシュから自動的に除外され、復旧すると自動的に解決プールへ戻ります。この除外は DNS レベルで行われ、グローバルサーバーロードバランシング（GSLB）のルーティング決定と同じレイヤーで機能します。

新しいページルールの作成

OpenResty Edge の Web 管理コンソールを開きます。これはコンソールのサンプルデプロイメントです。各ユーザーは独自のデプロイメントを持ちます。

まず、「Applications」ページに移動します。

「test-edge.com」という名前のアプリケーションを事前に準備しました。

このアプリケーションの設定をクリックします。

「Page Rules」ページに移動します。

ここで新しいルールを追加できます。

このページルールには、条件を指定する必要があります。

文字列の値として「/status」を入力します。

新しいアクションを追加します。

「output response body」を選択します。

レスポンスボディを「healthy」に設定します。リクエストの URI が「/status」の場合、レスポンスボディとして「healthy」を出力します。

「Create」ボタンをクリックしてこのルールを作成したら、この新しい変更をプッシュするために公開する必要があります。

このボタンをクリックします。

公開します。

変更がすべてのゲートウェイサーバーに同期されました。

ヘルスチェックの有効化

ゲートウェイクラスターページに再度アクセスしましょう。

これが今日使用するクラスターです。

IP アドレスをコピーするボタンをクリックします。

ターミナルで、curl コマンドを使用してゲートウェイサーバーにリクエストを送信します。

レスポンスボディが「healthy」であることが確認できます。

このクラスターの設定を変更するボタンをクリックし、ヘルスチェックを有効にします。

HTTP プロトコルを使用します。

HTTP リクエストホストをアプリケーション名に設定します。

リクエスト URI として「/status」を入力します。

レスポンスボディが「healthy」に一致することを要求します。

デモを迅速に行うために、リクエスト間隔を 3 秒に短縮します。

最後に、これらの設定を保存します。

テスト結果

ターミナルに切り替えます。まずサーバーを停止します。

サービスが停止しました。

リストを更新すると、このノードが現在赤色で表示されていることがわかります。これはオフライン状態を示しています。このノードの IP は DNS 解決および SSL セッション ID の分散キャッシュから削除されます。これが DNS レベルの自動フェイルオーバー（DNS failover）であり、新しいクライアントは障害ノードへ振り分けられなくなります。ルーティング決定の詳細は OpenResty Edge の GSLB 設定をご参照ください。

「Details」をクリックして詳細を表示します。

赤い部分をクリックすると、障害の詳細情報を確認できます。

詳細を閉じたら、ゲートウェイサーバーを再起動します。

サーバーが正常に復帰しました。

リストを再度更新します。ノードの状態が緑色に戻りました。

さらに、特定のパーティション内のすべてのゲートウェイクラスターとサーバーに対してヘルスチェックを有効にすることもできます。

このパーティションを編集するボタンをクリックします。

このボタンでヘルスチェックを有効にできます。

ここでのヘルスチェックはゲートウェイサーバー自体を対象としており、アップストリームのバックエンドサーバーやオリジンサーバーは対象外です。後者は別の機能です。

よくある質問

ロードバランサー自体のヘルスチェックはどうすればよいですか？

OpenResty Edge では、ゲートウェイクラスターまたはパーティションの設定でヘルスチェックを有効にします。各ゲートウェイノード——つまりロードバランサー自体——が HTTP で探査されます。リクエストホスト、「/status」などのリクエスト URI、期待するレスポンスボディ、探査間隔を設定でき、チェックに失敗したノードは自動的に DNS 解決から除外されます。

ゲートウェイノードがヘルスチェックに失敗するとどうなりますか？

そのノードはゲートウェイサーバー一覧で赤色表示になり、IP アドレスが DNS 解決と SSL セッション ID の分散キャッシュから削除され、新しいトラフィックはルーティングされなくなります。失敗の詳細はコンソールで確認できます。ノードが再びチェックに合格すると、緑色に戻り自動的に解決プールへ復帰します。

これはアップストリーム（バックエンド）のヘルスチェックと同じものですか？

いいえ。本記事で説明したヘルスチェックは、クライアントトラフィックを受け取るゲートウェイサーバー自体を監視するものです。アップストリームのバックエンドサーバーやオリジンサーバーに対するヘルスチェックは、OpenResty Edge の別の機能です。

ヘルスチェックでは何を探査できますか？

探査は HTTP リクエストで、リクエストホスト、リクエスト URI、一致を期待するレスポンスボディ、探査間隔（本デモでは 3 秒）を設定できます。「healthy」などの固定レスポンスボディを直接出力するページルールと組み合わせることで、バックエンドを介さずに各ゲートウェイノードに軽量なヘルスチェックエンドポイントを公開できます。

OpenResty Edge について

OpenResty Edge は、マイクロサービスと分散トラフィックアーキテクチャ向けに設計された多機能ゲートウェイソフトウェアで、当社が独自に開発しました。トラフィック管理、プライベート CDN 構築、API ゲートウェイ、セキュリティ保護などの機能を統合し、現代のアプリケーションの構築、管理、保護を容易にします。OpenResty Edge は業界をリードする性能と拡張性を持ち、高同時接続・高負荷シナリオの厳しい要求を満たすことができます。K8s などのコンテナアプリケーショントラフィックのスケジューリングをサポートし、大量のドメイン名を管理できるため、大規模ウェブサイトや複雑なアプリケーションのニーズを容易に満たすことができます。

著者について

章亦春（Zhang Yichun）は、オープンソースの OpenResty^® プロジェクトの創始者であり、OpenResty Inc. の CEO および創業者です。

章亦春（GitHub ID: agentzh）は中国江蘇省生まれで、現在は米国ベイエリアに在住しております。彼は中国における初期のオープンソース技術と文化の提唱者およびリーダーの一人であり、Cloudflare、Yahoo!、Alibaba など、国際的に有名なハイテク企業に勤務した経験があります。「エッジコンピューティング」、「動的トレーシング」、「機械プログラミング」 の先駆者であり、22 年以上のプログラミング経験と 16 年以上のオープンソース経験を持っております。世界中で 4000 万以上のドメイン名を持つユーザーを抱えるオープンソースプロジェクトのリーダーとして、彼は OpenResty^® オープンソースプロジェクトをベースに、米国シリコンバレーの中心部にハイテク企業 OpenResty Inc. を設立いたしました。同社の主力製品である OpenResty XRay（動的トレーシング技術を利用した非侵襲的な障害分析および排除ツール）と OpenResty Edge（マイクロサービスおよび分散トラフィックに最適化された多機能ゲートウェイソフトウェア）は、世界中の多くの上場企業および大企業から高い評価を得ております。OpenResty 以外にも、章亦春は Linux カーネル、Nginx、LuaJIT、GDB、SystemTap、LLVM、Perl など、複数のオープンソースプロジェクトに累計 100 万行以上のコードを寄与し、60 以上のオープンソースソフトウェアライブラリを執筆しております。

翻訳

英語版の原文と日本語訳版（本文）をご用意しております。読者の皆様による他の言語への翻訳版も歓迎いたします。全文翻訳で省略がなければ、採用を検討させていただきます。心より感謝申し上げます！