HTTP Session Architecture Pattern

Transcript

1. Java Platform Advocate 伊藤ちひろ HTTPセッションのアーキテクチャパターン 2022年 5月13日 1

2. 目次 • 認識あわせ • アーキテクチャについて • 付録 ◦セッションを使うコードのサンプル ◦Red Hat製品による環境構築方法

   注意：ベンダーの特定製品に限定する話ではなく、一般論の話です

3. 認識あわせ：HTTPセッションとは • RFCで仕様化されていない • デファクトスタンダードな実装がある ◦HTTPセッションは以下の ID から判別される。 ▪Cookieに付与されたセッション ID

   ▪URLに付与されたセッション ID （非推奨） ◦APサーバはセッションIDからHTTPセッションを取得 ▪該当するセッションIDの情報がないとセッションは使えない • JavaではHttpSessionなどの仕様が透過的に上記を行う APサーバ Load Balancer Client jsessionid=001 jsessionid=001 001の セッション 情報

4. 認識あわせ：HTTPセッションの扱い方 • デファクトスタンダードに則る方式 ◦Javaが仕様で提供するAPIが使える。 ▪セッションの永続化方法を変えてもアプリの変更は不要 ◦格納先のデータストアはミドルウェアで設定 • 自分たちで実装する方式 ◦複数のリクエストを跨がって使う情報をセッションと勝手に呼ぶ方式 ◦他のデータアクセスと同様に自ら情報の読み書きを実装

   ▪RDBMS、RHDG、Memcached、Redis、ファイル、オブジェクトなど ◦性能や可用性は実装方法に依存 APサーバ Load Balancer Client セッション 情報

5. 認識あわせ：コネクションの負荷分散について APサーバ1 APサーバ2 Load Balancer Client アルゴリズムに よって振り分け • 注：コネクションとリクエストおよび負荷は異なる物です

   • コネクションの新規確立をアルゴリズムに従って振り分ける • コネクションを再利用したリクエストは振り分けられない ◦コネクションを再利用するとリクエストは偏る • スティッキーセッションでは前と同じサーバへ接続する ◦スティッキーセッションを使うとリクエストは偏る • 処理毎に負荷が異なるため負荷を均等にすることは不可能

6. 認識あわせ：Javaのセッションの永続化で気にするべき指標 • Javaの標準APIが使えるかどうか • リクエストの負荷分散に対応しているかどうか • どの様な障害に耐えられるか • セッション数の増加がAPサーバに及ぼす影響（GCやIOボトルネックなど） •

   セッションを用いた処理の速度（ネットワークなどのI/Oを含むか） • 構成の難易度

7. デファクトに則るセッション永続化のアーキテクチャについて • おおきく５種類のアーキテクチャがありトレードオフがある。 ◦何もしない ◦スティッキーセッションのみ ◦APサーバのクラスタリング＋セッション複製＋スティッキーセッション ◦セッション外部化 ◦スティッキーセッション＋セッション外部化＋キャッシュ 注意：各ベンダーの製品が組める構成についてはベンダーへお問い合わせ下さい

8. 何もしない APサーバ1 APサーバ2 Load Balancer 001の セッション 情報 jsessionid=001 Client

   50%の確率 でこちら セッション情 報がない • 負荷分散がし易い • 複数のAPサーバの構成だとセッション情報が使えない ◦ただし、１台構成だとセッション情報が使える ◦初めて複数台構成にすると陥ることが非常に多い 赤字：メリット、青字：デメリット

9. スティッキーセッションのみ APサーバ1 APサーバ2 Load Balancer 001の セッション 情報 jsessionid=001 server=1

   Client 2回目以降 必ずこちら 1. 初回にアクセスしたサーバ情報を付与（図の server=1） 2. クライアントは以降のリクエストでそのサーバの情報を使用 3. LBはそのサーバの情報から接続先を判断 • セッションを使用した処理ができる ◦必ずセッション情報がある APサーバへ接続できる • 初回リクエストはLBによって負荷分散されるが、 以降のリクエストは初回と同じサーバへアクセスされ分散しない • ヒープに格納する場合は GCが起きやすく、ディスクの場合は I/Oが頻発 • APサーバが停止するとセッション情報は消失する 赤字：メリット、青字：デメリット

10. クラスタリング＋セッション複製＋スティッキーセッション APサーバ1 APサーバ2 Load Balancer 001の セッション 情報 jsessionid=001 server=1

    Client 通常はこちら 1. 初回にアクセスしたサーバとバックアップのサーバの情報を付与 2. クライアントは以降のリクエストでそのサーバの情報を使用 3. LBはそのサーバの情報から接続先（プライマリ）を判断 • セッションを使用した処理ができる ◦スティッキーセッションでプライマリへ接続しないといけません • APサーバが停止してもそのバックアップがセッション情報を引き継ぐ • 初回リクエストはLBによって負荷分散されるが、 以降のリクエストは初回と同じサーバへアクセスされ分散しない • ヒープに格納する場合は GCが起きやすく、ディスクの場合は I/Oが頻発 • セッション情報の複製に時間が掛かる上、倍のリソースが必要 赤字：メリット、青字：デメリット 001の セッション 情報 バックアップ プライマリの 障害時はこちら 注意：複製されているからどこへアクセスしても良いだろうと思いスティッキーセッションを導入し忘れるケースが良くあります。 APサーバの実装によりますが、通常はプライマリにアクセスし、プライマリの障害時のみバックアップへアクセスしましょう プライマリ

11. データストア (DS) セッション外部化 APサーバ1 APサーバ2 Load Balancer 001の セッション 情報

    jsessionid=001 Client • セッションをAPサーバに永続化せず、データストアに永続化 ◦APサーバが停止してもセッションを用いた処理は継続できる • リクエスト時に必要に応じてデータストアから読む ◦読み書きの通信が発生するため遅延が生じスループットは低下 • APサーバより強固なデータストアが停止しないと消失しない 赤字：メリット、青字：デメリット

12. データストア (DS) スティッキーセッション＋セッション外部化＋キャッシュ APサーバ1 APサーバ2 Load Balancer 001の セッション 情報

    jsessionid=001 server=1 Client 1. APサーバがセッションのキャッシュを持つ 2. 初回にアクセスしたサーバ情報を付与 3. クライアントは以降のリクエストでそのサーバの情報を使用 4. LBはそのサーバの情報から接続先を判断 5. キャッシュをもつサーバの障害時は他 APサーバがデータストアから読む 001の セッション キャッシュ • APサーバが停止してもセッションを用いた処理は継続できる • APサーバより強固なデータストアが停止しないと消失しない • キャッシュを使うためデータストアからの読み込みは不要で高速 • APサーバ障害時は通信による遅延が生じスループットは低下 • セッション情報とそのキャッシュの一貫性を保つのが難しい 赤字：メリット、青字：デメリット

13. まとめ 独自実装 何もしな い スティッキー セッション クラスタリング+ セッション複製+ スティッキーセッ ション

    セッション 外部化 セッション外部化＋ スティッキーセッション＋ キャッシュ セッションのAPI 未使用 利用不可 利用可 利用可 利用可 利用可 リクエストの 負荷分散 実装依存 できる 新規のみ 既存は不可 新規のみ 既存は不可 できる 新規のみ 既存は不可 セッションの 永続性 実装依存 該当無し AP障害で 消失 APの単一障害に 耐える APの全障害に 耐える APの全障害に耐える APサーバの リソース消費量 実装依存 該当無し 多い かなり多い 少ない 少ない セッションを 使用した処理の 速度 実装依存 該当無し 高速 高速 低速 高速 （AP障害時は低速） 構成難易度 実装依存 該当無し 低い 中程度 中程度 高い 赤字：メリット、青字：デメリット

14. 14 付録

15. 実装例：Java EE 5以前の Servlet API public void doGet(HttpServletRequest request, HttpServletResponse

    response) throws ServletException, IOException { // 引数はセッションが無いときにセッションを新規作成するかどうかです。 HttpSession session = request.getSession(false); if(session == null) { // セッションが無いときの処理 } else { // セッションがあるときの処理 } }

16. 実装例：Java EE 6以降の CDI // セッションとして使われることを指定 @SessionScoped public class Counter

    implements Serializable { private static final long serialVersionUID = 1L; private int value; public int getValue() { return value; } public void countUp() { this.value++; } } @Path("/count") public class CountEndpoint { // セッションを注入（≒取り出す） @Inject private Counter counter; @GET @Path("count") public String getClichedMessage() { counter.countUp(); return "counter=" + counter.getValue(); } }

17. 構成方法：JBoss EAPでのセッション複製 1. アプリケーションにおけるセッションレプリケーションの有効化 2. JBoss EAPをHA構成で構築 参考：JBoss EAP 設定ガイド

    - WEB アプリケーションのクラスター化

18. 構成方法：JBoss EAPでRHDGへセッション外部化＋キャッシュ 1. リモートキャッシュコンテナの設定 2. HotRodストアを設定 参考：JBoss EAP 設定ガイド -

    HTTP セッションの RED HAT DATA GRID への外部化

19. 構成方法：Red Hat OpenShiftでスティッキーセッション - 有効化（デフォルト） - haproxy.router.openshift.io/disable_cookies=false - 無効化 -

    haproxy.router.openshift.io/disable_cookies=true

20. その他：セッションでよくある性能トラブル時に必要な情報 登場人物は例です クライアント Load Balancer APサーバ セッション 格納先 サービスやRDB 必要な情報

    処理待ちの時間はキューの長さとス レッド使用数から算出 フレームワークが 処理中の時間 HTTPリクエスト HTTPリクエスト HTTレスポンス HTTレスポンス アプリケーションが 処理中の時間 セッションの読み込み セッションの格納 REST API/SQL など REST API/SQL など 通信などの読み書き時間 通信などの読み書き時間 振り分けの記録と コネクション数の記録 クライアントから見た 処理時間 MBeanやJFRを用いて上記の処理時間を取ることを推奨します。

21. linkedin.com/company/red-hat youtube.com/user/RedHatVideos facebook.com/redhatinc twitter.com/RedHat 21 Red Hat is the world’s

    leading provider of enterprise open source software solutions. Award-winning support, training, and consulting services make Red Hat a trusted adviser to the Fortune 500. Thank you