Upgrade to Pro — share decks privately, control downloads, hide ads and more …

HTTP Session Architecture Pattern

HTTP Session Architecture Pattern

JavaでHTTPセッションを使用するときに検討されるアーキテクチャのパターンを紹介します。

Chihiro Ito

May 13, 2022
Tweet

More Decks by Chihiro Ito

Other Decks in Technology

Transcript

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

    View full-size slide

  2. 目次
    ● 認識あわせ
    ● アーキテクチャについて
    ● 付録
    ○セッションを使うコードのサンプル
    ○Red Hat製品による環境構築方法
    注意:ベンダーの特定製品に限定する話ではなく、一般論の話です

    View full-size slide

  3. 認識あわせ:HTTPセッションとは
    ● RFCで仕様化されていない
    ● デファクトスタンダードな実装がある
    ○HTTPセッションは以下の ID から判別される。
    ■Cookieに付与されたセッション ID
    ■URLに付与されたセッション ID (非推奨)
    ○APサーバはセッションIDからHTTPセッションを取得
    ■該当するセッションIDの情報がないとセッションは使えない
    ● JavaではHttpSessionなどの仕様が透過的に上記を行う
    APサーバ
    Load Balancer
    Client
    jsessionid=001
    jsessionid=001
    001の
    セッション
    情報

    View full-size slide

  4. 認識あわせ:HTTPセッションの扱い方
    ● デファクトスタンダードに則る方式
    ○Javaが仕様で提供するAPIが使える。
    ■セッションの永続化方法を変えてもアプリの変更は不要
    ○格納先のデータストアはミドルウェアで設定
    ● 自分たちで実装する方式
    ○複数のリクエストを跨がって使う情報をセッションと勝手に呼ぶ方式
    ○他のデータアクセスと同様に自ら情報の読み書きを実装
    ■RDBMS、RHDG、Memcached、Redis、ファイル、オブジェクトなど
    ○性能や可用性は実装方法に依存
    APサーバ
    Load Balancer
    Client
    セッション
    情報

    View full-size slide

  5. 認識あわせ:コネクションの負荷分散について
    APサーバ1 APサーバ2
    Load Balancer
    Client
    アルゴリズムに
    よって振り分け
    ● 注:コネクションとリクエストおよび負荷は異なる物です
    ● コネクションの新規確立をアルゴリズムに従って振り分ける
    ● コネクションを再利用したリクエストは振り分けられない
    ○コネクションを再利用するとリクエストは偏る
    ● スティッキーセッションでは前と同じサーバへ接続する
    ○スティッキーセッションを使うとリクエストは偏る
    ● 処理毎に負荷が異なるため負荷を均等にすることは不可能

    View full-size slide

  6. 認識あわせ:Javaのセッションの永続化で気にするべき指標
    ● Javaの標準APIが使えるかどうか
    ● リクエストの負荷分散に対応しているかどうか
    ● どの様な障害に耐えられるか
    ● セッション数の増加がAPサーバに及ぼす影響(GCやIOボトルネックなど)
    ● セッションを用いた処理の速度(ネットワークなどのI/Oを含むか)
    ● 構成の難易度

    View full-size slide

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

    View full-size slide

  8. 何もしない
    APサーバ1 APサーバ2
    Load Balancer
    001の
    セッション
    情報
    jsessionid=001
    Client
    50%の確率
    でこちら
    セッション情
    報がない
    ● 負荷分散がし易い
    ● 複数のAPサーバの構成だとセッション情報が使えない
    ○ただし、1台構成だとセッション情報が使える
    ○初めて複数台構成にすると陥ることが非常に多い
    赤字:メリット、青字:デメリット

    View full-size slide

  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サーバが停止するとセッション情報は消失する
    赤字:メリット、青字:デメリット

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  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サーバ障害時は通信による遅延が生じスループットは低下
    ● セッション情報とそのキャッシュの一貫性を保つのが難しい
    赤字:メリット、青字:デメリット

    View full-size slide

  13. まとめ
    独自実装
    何もしな

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

    View full-size slide

  14. 実装例:Java EE 5以前の Servlet API
    public void doGet(HttpServletRequest request, HttpServletResponse response) throws
    ServletException, IOException {
    // 引数はセッションが無いときにセッションを新規作成するかどうかです。
    HttpSession session = request.getSession(false);
    if(session == null) {
    // セッションが無いときの処理
    } else {
    // セッションがあるときの処理
    }
    }

    View full-size slide

  15. 実装例: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();
    }
    }

    View full-size slide

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

    View full-size slide

  17. 構成方法:JBoss EAPでRHDGへセッション外部化+キャッシュ
    1. リモートキャッシュコンテナの設定
    2. HotRodストアを設定
    参考:JBoss EAP 設定ガイド - HTTP セッションの RED HAT DATA GRID への外部化

    View full-size slide

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

    View full-size slide

  19. その他:セッションでよくある性能トラブル時に必要な情報
    登場人物は例です
    クライアント Load Balancer APサーバ セッション
    格納先
    サービスやRDB
    必要な情報
    処理待ちの時間はキューの長さとス
    レッド使用数から算出
    フレームワークが
    処理中の時間
    HTTPリクエスト
    HTTPリクエスト
    HTTレスポンス
    HTTレスポンス
    アプリケーションが
    処理中の時間
    セッションの読み込み
    セッションの格納
    REST API/SQL など
    REST API/SQL など
    通信などの読み書き時間
    通信などの読み書き時間
    振り分けの記録と
    コネクション数の記録
    クライアントから見た
    処理時間
    MBeanやJFRを用いて上記の処理時間を取ることを推奨します。

    View full-size slide

  20. 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

    View full-size slide