先生と生徒の会話形式で理解しよう

生徒

「Play Frameworkでアプリを複数のサーバーで動かしたいのですが、セッション管理はどうすればいいのでしょうか？サーバーが切り替わるとログアウトされちゃいませんか？」

先生

「その通りですね。複数のサーバーで負荷分散を行う環境では、どのサーバーにアクセスしても同じログイン状態を維持できる仕組みが必要です。これをセッション共有と呼びます。」

生徒

「具体的にはRedisやデータベースを使うと聞いたことがあるのですが、Play Frameworkでも使えるんですか？」

先生

「もちろんです！Playは標準でクッキーベースのセッションを使いますが、外部ストレージと連携させることで、より安全で柔軟な分散環境を構築できます。手順を見ていきましょう！」

1. 分散環境におけるセッション共有の必要性

現代のWebアプリケーションでは、アクセス数が増えると複数のサーバーを並べて処理を分担させる「スケールアウト」が行われます。しかし、通常のログイン情報はサーバーごとのメモリに保存されることが多いため、ユーザーが別のサーバーへ誘導されると「ログインしていない」と判断されてしまいます。

これを解決するために、セッション情報を外部の共通ストレージに保存するのが「セッション共有」の考え方です。 Play Frameworkは元々ステートレスな設計ですが、クッキーのサイズ制限を回避したり、サーバーサイドでセッションを厳密に管理したりするために、Redisやデータベース（DB）を利用することが推奨されます。

2. Play Frameworkのデフォルトセッションの限界

Play Frameworkの標準セッションは、署名付きのクッキーにデータを保存します。この方式は、サーバー間で共有設定をしなくても動くという利点がありますが、一方で「クッキーの最大サイズである4KBを超えられない」という制約があります。

また、クッキーベースではサーバー側でセッションを強制的に無効化（無効セッションの管理）するのが難しいため、セキュリティ要件が厳しいシステムでは不十分な場合があります。大規模な分散システムや、セッションに多くの情報を保持したい場合には、外部の高速なデータストアであるRedisなどの活用が不可欠になります。

3. Redisを利用した高速なセッション管理の実装

Redisはメモリ上で動作するキーバリューストアで、非常に高速な読み書きが可能です。 Play FrameworkでRedisをセッション共有に利用する場合、セッションIDだけをクッキーに保存し、実際のデータはRedis側に格納する構成をとります。

Javaでの実装イメージとして、まずはRedisにセッションデータを保存するシンプルなサービスを作成します。 PlayのCache APIを利用することで、バックエンドがRedisであっても透過的に操作できます。


package services;

import play.cache.SyncCacheApi;
import javax.inject.Inject;
import java.util.Optional;

public class SessionService {
    private final SyncCacheApi cache;

    @Inject
    public SessionService(SyncCacheApi cache) {
        this.cache = cache;
    }

    // Redisにユーザー情報を保存する例
    public void saveUserSession(String sessionId, String userInfo) {
        // 有効期限を1時間に設定して保存
        cache.set(sessionId, userInfo, 3600);
    }
}

4. データベースを利用したセッション共有のメリット

Redisのようなメモリ内DBではなく、PostgreSQLやMySQLなどのリレーショナルデータベース（RDB）にセッションを保存する方法もあります。この最大のメリットは、サーバーが予期せず再起動してもセッション情報が完全に保持される「永続性」にあります。

また、DBを利用することで「現在どのユーザーがログインしているか」をSQLで簡単に集計したり、管理画面から特定のセッションを強制終了させたりといった運用が容易になります。ただし、アクセスのたびにDBへの問い合わせが発生するため、インデックスの適切な設定や、必要に応じてキャッシュ層を挟むなどの工夫が必要です。


package controllers;

import play.mvc.*;
import models.UserSession;
import java.util.UUID;

public class DbSessionController extends Controller {
    public Result login(Http.Request request) {
        String sessionId = UUID.randomUUID().toString();
        
        // データベースにセッション情報を保存する疑似コード
        UserSession session = new UserSession();
        session.id = sessionId;
        session.userId = "user_001";
        session.save();

        // クッキーにはセッションIDだけを持たせる
        return redirect("/dashboard").addingToSession(request, "session_id", sessionId);
    }
}

5. 設定ファイルで外部ストレージ連携を有効にする

外部のRedisやDBを使用する場合、application.confの設定が重要になります。 Playの標準キャッシュモジュールをRedisに切り替える設定を記述することで、ライブラリが自動的に接続を管理してくれます。

ここでは、Redisをキャッシュバックエンドとして使用するための基本的な設定例を示します。接続先のホスト名やポート番号、パスワードなどを指定します。


# Redis接続設定の例
play.cache.redis {
    host = "redis.example.com"
    port = 6379
    password = "your_secure_password"
    database = 0
}

# キャッシュの有効期限などのデフォルト設定
session.maxAge = 1h

6. セッションIDの生成とクッキーのセキュリティ

分散環境で外部ストレージを使う場合でも、クッキーのセキュリティ設定は疎かにできません。セッションIDが第三者に盗まれると、外部ストレージに保存した大事なデータにアクセスされてしまうからです。

application.confで httpOnly を true に設定し、JavaScriptからクッキーを読み取れないようにします。また、通信は必ずHTTPSで行い、secure 属性を付与することが鉄則です。


# クッキーのセキュリティ対策設定
play.http.session.httpOnly = true
play.http.session.secure = true
play.http.session.sameSite = "lax"

7. 分散環境でのセッションの有効期限管理

外部ストレージを利用する場合、ストレージ側の「データの自動削除」機能を利用するのが賢明です。 Redisであれば EXPIRE 命令を使うことで、一定時間操作がないセッションを自動的に消去できます。

DBの場合は、バッチ処理などで一定期間更新がないレコードを定期的に削除する仕組みを導入します。これにより、不要なデータが溜まり続けてデータベースのパフォーマンスが低下するのを防ぐことができます。 Play Frameworkのプログラム側では、アクセスのたびに有効期限を更新する「スライディングセッション」を実装するのが一般的です。

8. Javaコードによるセッション取得の共通化

各コントローラーで毎回外部ストレージに問い合わせるコードを書くと、保守性が下がります。 Action合成（Action Composition）を利用して、リクエストがコントローラーに届く前に自動的にセッションを確認する仕組みを作ると便利です。

以下の例では、リクエストに含まれるセッションIDをキーに、Redisからユーザー情報を取得してリクエスト属性にセットする処理のイメージです。


package actions;

import play.mvc.*;
import java.util.concurrent.CompletionStage;
import javax.inject.Inject;
import services.SessionService;

public class AuthenticatedAction extends Action.Simple {
    @Inject SessionService sessionService;

    public CompletionStage<Result> call(Http.Request req) {
        return req.session().get("session_id")
            .map(id -> {
                // セッションIDに基づいてユーザー情報を取得
                return delegate.call(req);
            })
            .orElseGet(() -> CompletableFuture.completedFuture(redirect("/login")));
    }
}