OpenResty Edge で Sticky Cookie を有効にする方法（セッションアフィニティ）

Sticky Cookie が OpenResty Edge でセッションアフィニティを保つ仕組み

OpenResty Edge の Sticky Cookie は、各クライアントを同じバックエンドのアップストリームサーバーに固定するため、1 つのセッション内のすべてのリクエストが同じホストに届きます。OpenResty Edge が Sticky Cookie を発行することで、同じクライアントからの後続のリクエストは同じサーバーに戻ります。これにより、Nginx の設定を一切変更したりゲートウェイをリロードしたりすることなく、セッションアフィニティ（セッション維持）を実現できます。有効化はページルール内のスイッチ 1 つで行え、アップストリームクラスターレベルでも個々のサーバーレベルでも設定できます。本チュートリアルでは、Sticky Cookie を有効にし、リクエストが 1 台のバックエンドに固定されることを確認したうえで、無効にしてトラフィックがラウンドロビンに戻る様子を確認します。

まず、Sticky Cookie を有効にした状態で 2 つのリクエストを送信すると、それらが同じバックエンドサーバーに送信されることが確認できます。

その後、Sticky Cookie を無効にした状態で2つのリクエストを送信すると、今度は 2 つのリクエストが異なるバックエンドサーバーに送信されることが観察できます。

アップストリームで Sticky Cookie を有効にする（サーバーレベルのアフィニティ）

OpenResty Edge の Admin Web コンソールにアクセスしましょう。これは当社のコンソールのサンプルデプロイメントです。各ユーザーは独自のローカルデプロイメントを持っています。

以前のサンプルアプリケーション、test-edge.com を引き続き使用します。

そのアプリケーションに移動します。

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

すでにアップストリームが定義されています。

このアップストリームには現在 1 つのアップストリームサーバーがあります。

2 つのアップストリームサーバーが必要です。もう 1 つサーバーを追加しましょう。

「Add a new upstream server」ボタンをクリックします。

アップストリームサーバーのホスト名を入力します。

アップストリームサーバーが利用可能かどうか確認します。

オープンソースの OpenResty のデフォルトホームページが返されていることが確認できます。これは期待通りの結果です。

アップストリームを保存します。

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

以前のチュートリアルでリバースプロキシのページルールを設定しました。

このページルールを編集し、Sticky Cookie を有効にします。

Sticky Cookie のスイッチをオンにします。

アップストリームサーバーがアップストリームクラスター内にあるため、ここではサーバーレベルの Sticky Cookie を使用することを選択します。

サーバーレベルを選択します。

ここで Sticky Cookie の有効期限を設定できます。

デフォルト値の 0 を使用します。これは決して期限切れにならないことを意味します。

このページルールを保存します。

次に、リクエストの分布を確認するための動的メトリクスを作成します。 なお、Sticky Cookie の設定にはこのステップは必須ではありません。Sticky Cookie 機能は動的メトリクスに依存しません。

「New Metric」ボタンをクリックします。

この動的メトリクスを「Upstream Server Request Count」と名付けます。

説明を追加します。

レポート間隔を 10 秒に設定します。

Metric SQL 文を入力します。これはアップストリームサーバーアドレスを選択します。

すべてのリクエストから。

そして、アップストリームサーバーアドレスでグループ化して表示するように設定します。

このメトリクスを保存します。

いつものように、先ほどの変更をプッシュするために新しいバージョンをリリースする必要があります。

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

リリースします！

新しいバージョンがすべてのゲートウェイサーバーに同期されました。

先ほどの変更がすべてのゲートウェイクラスターとサーバーにプッシュされました。

これらの設定変更にはサーバーのリロード、再起動、またはバイナリアップグレードは必要ありません。そのため、非常に効率的でスケーラブルです。

Sticky Cookie のテスト：すべてのリクエストが同じバックエンドに届く

では、2 つのリクエストを送信してみましょう。最初のリクエストを送信します。

2 つ目のリクエストを送信します。

すべてのリクエストが正常に送信されました。

動的メトリクスに記録されたデータを確認してみましょう。

棒グラフを選択します。

すべてのリクエストが同じアップストリームサーバーに送信されたことが確認できます。

以下の画像が示すとおりです。

Sticky Cookie を無効にしてラウンドロビンに戻す

次に、Sticky Cookie を無効にした場合のデモンストレーションを行います。

まずメトリクスデータをクリアします。

ここで確認が必要です。

クリア作業が完了しました。では Sticky Cookie を無効にしましょう。

このページルールを再度編集します。

「Sticky Cookie」スイッチをオフにします。

負荷分散ポリシーが「Round Robin」であることに注意してください。

ページルールを保存します。

いつものように、先ほどの変更をプッシュするために新しいバージョンをリリースする必要があります。

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

リリースします！

新しいバージョンがすべてのゲートウェイサーバーに同期されました。

再テスト：リクエストが複数のバックエンドに分散する

次に、再び2つのリクエストを送信します。

最初のリクエストを送信します。

2 つ目のリクエストを送信します。

すべてのリクエストの送信が完了しました。

動的メトリクスを再確認します。

棒グラフをクリックします。

この 2 つのリクエストがそれぞれ異なるアップストリームサーバーにアクセスしたことが確認できます。

以下の画像が示すとおりです。

Sticky Cookie を使用すると、OpenResty Edge はクライアントをアップストリームクラスターまたは個々のアップストリームサーバーに固定します。Nginx の設定もリロードも不要で、セッション維持を実現できます。Sticky Cookie は単一のアップストリーム内でトラフィックを固定します。ユーザーをリージョンやデータセンター間でルーティングするには、グローバルサーバーロードバランシングの仕組みをご覧ください。また、HTTP 以外のサービスについては、OpenResty Edge の TCP ロードバランシングをご覧ください。

よくある質問

スティッキーセッションとセッションアフィニティの違いは何ですか？

どちらも同じ動作を指します。つまり、セッションが続く間、クライアントを 1 台のバックエンドに固定することです。「セッションアフィニティ」（セッション維持とも呼ばれます）は目的であり、Sticky Cookie はそれを実現する仕組みです。このデモでは、OpenResty Edge が Sticky Cookie を発行することで、同じクライアントからのすべてのリクエストが同じアップストリームサーバーに戻ります。

Sticky Cookie はどのようなときに使うべきですか？

あるクライアントからのリクエストを同じバックエンドサーバーに届け続ける必要があるときに Sticky Cookie を使用します。デモではその効果が直接確認できます。Sticky Cookie を有効にすると 2 つのリクエストが同じアップストリームサーバーに届き、無効にすると同じ 2 つのリクエストがラウンドロビンによって異なるサーバーに分散されます。

サーバーレベルとクラスターレベルの Sticky Cookie の違いは何ですか？

サーバーレベルの Sticky Cookie はクライアントを個々のアップストリームサーバーに固定し、クラスターレベルの Sticky Cookie はクライアントをアップストリームクラスターに固定します。本チュートリアルではアップストリームサーバーが 1 つのアップストリームクラスター内にあるため、各クライアントを同じ個別サーバーに保つためにサーバーレベルを選択します。

Sticky Cookie の有効期限 0 は何を意味しますか？

有効期限は Sticky Cookie が有効である期間を制御します。デフォルト値の 0 は Cookie が決して期限切れにならないことを意味し、クライアントは同じバックエンドサーバーに無期限に固定されます。一定期間後にアフィニティをリセットしたい場合は、0 以外の値を設定してください。

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 以上のオープンソースソフトウェアライブラリを執筆しております。

翻訳

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