ASP.NET CoreとRLSで安全に開発できるマルチテナント共通基盤を実装する

こんにちは7110です。
現在マルチテナンシーのSaaSアプリケーションを開発しています。

今回はその開発中に出会った以下の課題とアプローチに関して社内勉強会で登壇した内容を記事にしました。

• マルチテナント構成にRLSを活用しているためDBにアクセスする際にテナントの識別情報が必須となる
• アプリケーション層とドメイン層はテナントに依存しないため、テナントの識別情報を渡したくない
• 可能なら開発メンバ―全員が意識せずとも開発できるようにインフラ層にRLSの処理をカプセル化したい

環境

• API
  • ASP.NET Core
  • EntityFramework
• DB
  • Postgresql

『採用理由』
【ASP.NET Core】
最初はGolangやNode.jsの採用も検討しましたが、弊社の技術スタックとして私の入社以前から採用されていましたので、習得コストを考慮しそのまま採用しました。

【EntityFramework】
C#のORMと言えばEntityFrameworkと言えるくらい有名なライブラリです。
EntityFrameworkは弊社で何度か採用経験がありますが、SqlCommandを活用し生SQLを書く方が一般的でした。私も当初はSqlCommandで実装していましたが、ソースコードとDBの状態を同期的に管理したかったことと、ValueObject等の型制約をアプリケーション全体で認知させたかったことから気合で乗り換えました。結果的に管理対象が大幅に減ったので運用面では正解だったと感じています。(クエリの実行速度が新たな課題になってしまいましたが。。。)

【Postgresql】
多機能かつライセンス料が無償のRDBです。
当社でSaaSを開発/運用するうえで現行の体制でシングルテナントで運用することは現実的でないと考えました。そこでマルチテナンシーで運用している他社さんの事例を調べRLSを利用できることなどの機能面や料金を考慮し採用に至りました。

アーキテクチャ

アーキテクチャは以下の4層のレイヤードアーキテクチャとなっており、API層以外のレイヤーはclasslibでライブラリとして実装しています。

レイヤー	責務
API	HTTP Serverの実行モジュール 依存性注入やHTTPリクエスト/レスポンスをさばく
Application	アプリケーションのビジネスロジックを担う
Domain	業務知識の集約
Infrastructure	外部サービス(DB/Cloud等)との接続をカプセル化

依存の向きはこちらです。

アプリケーションの実行プロセスはAPI -> Application -> Domain or Infrastructureとなります。

本題

さて、4層のレイヤーをそれぞれカプセル化していることで困ったことが出てきました。
PostgresqlではRLSを利用しているので、DB問い合わせ時にテナントの識別情報を渡す必要があります。
テナントの認証情報はAPI層でリクエスト時にMiddlewareを使って抜き出しているので、Application層、Domain層、Infrastructure層とバケツリレーで渡すこともできますが、Application層とDomain層はテナントに依存しないため、可能なら存在を知らせたくありませんし、Infrastructure層でのRLS割り当てが実装者に依存してしまうかもしれないと考えました。
そこでRLS適応を共通基盤化し、テナントの存在をアプリケーションのコアロジック及び、開発者が意識しなくても実装できる形を目指しました。
共通基盤実装にはASP.NET CoreのDIの仕組みとDbConnectionクラスのEventHandlerを活用しました。

『ASP.NET CoreのDIの仕組み』
ASP.NET CoreはDIのアプローチを3種類提供しています。
ASP.NET Core での依存関係の挿入

メソッド	詳細
Transient	インスタンスを要求されるたびに新しいインスタンスが生成されます。
Scoped	HTTPリクエストの期間中に同じインスタンスを再利用します。リクエスト内での一貫した状態を保ちつつ、リクエストが終了するとインスタンスが破棄されます。
Singleton	アプリケーションのライフタイム全体にわたって同じインスタンスを使用します。

Scopedが要件に適していたので、今回はScopedを用いて実装しました。

1. テナントの識別情報をAPI層からInfrastructure層にダイレクトに伝える

Infrastructure層はQueryServiceとRepositoryの実装クラスとDbContextの基盤クラスがあります。
QueryServiceとRepositoryはコンストラクタでDbContextのサブクラスのインスタンスを受け取るように実装します。

PostRepository.cs

public class PostRepository : IPostRepository
{
    private readonly BaseDBContext _context;

    public PostRepository(
        BaseDBContext context
    )
    {
        this._context = context;
    }
}

PostQueryService.cs

public class PostQueryService : IPostQueryService
{
    private readonly BaseDBContext _context;

    public PostQueryService(
        /* ※QueryServiceはReadDBへの接続を渡すことでマスタ/リードDBへ操作対象を分けることができます。 */
        BaseDBContext context
    )
    {
        this._context = context;
    }
}

DbContextのサブクラスは以下のようにしておきます。

BaseDBContext.cs

public class BaseDBContext : DbContext
{
    private readonly Guid _tenantId;

    public BaseDBContext(
        Guid tenantId
    )
    {
        this._tenantId = tenantId;
    }
}

API層のProgram.csは以下のようにしておきます。

Program.cs

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddScoped<BaseDBContext>(provider => {
    // 1. HttpContextを取得
    var httpContext = provider.GetRequiredService<IHttpContextAccessor>().HttpContext;

    // 2. 認証されていなかった場合例外を発生
    if(!(httpContext?.User.Identity?.IsAuthenticated ?? false)) throw new Exception("認証エラー");

    var tenantId = /* httpContextからテナントの情報を取得 */

    return new BaseDBContext(
        tenantId: tenantId
    );
})

builder.Services.AddScoped<IPostRepository, PostRepository>();
builder.Services.AddScoped<IPostQueryService, PostQueryService>();

上記のように依存性を注入することで、同一リクエストのスコープ内でtenantIdをフィールドに保持しているBaseDBContextのインスタンス生成され、それが各Repository、QueryServiceで使いまわされます。

『AddDbContext』
DbContextの生成にはAddDbContextのアプローチもありますが、現行の構成で利用するとビルド時に例外を吐いてしましました。

どうやらAddDbContextでサービスコンテナに登録するDbContextはHttpContextAccessorがインスタンス化される前にインスタンス化の処理が実行される可能性があるらしいです。
その結果HttpContextがnullとなり、テナントの識別情報を取得できない旨のエラーが発生しました。
AddScopedであれば、Httpリクエストのスコープ内でインスタンス化されるためHttpContextがnullにならずにテナントの識別情報をHttpContextから取得することができました。

『Infrastructure層でDbContextのインスタンスを共有することの注意点』
DbContextはスレッドセーフではありません。
なので、複数のRepositoryまたはQueryServiceを利用して、並列処理を実行するとエラーが出ます。
例えば以下のような処理はできません。

SampleApplicationService.cs

// _userRepositoryと_postRepositoryはDbContextを共有している
Task<UserEntity> findUserTask = _userRepository.FindUserByIdAsync(userId);
Task<PostEntity> findPostTask = _postRepository.FindPostByIdAsync(postId);

// 複数タスクを並列で実行
await Task.WhenAll(
    findUserTask,
    findPostTask
);

これを解決し、尚且つテナント識別情報をカプセル化するためにはInfrastructure層でDbContextのFactoryクラスを作り、それをDIで渡すのがよさそうかなとか考えてます。

2. DBのセッションにRLSを適応させる

まずはテーブルのRLSポリシーを有効化し、制約を割り当てます。
テーブルへのRLSを適応は少し手間ですが、MigrationBuilderを拡張し、Migrationファイルでテーブルを作成時に対応するモデルをgenericsで渡しています。

internal static void AddRLSPolicy<M>(this MigrationBuilder migrationBuilder) where M : BaseModel
{
    // テーブル名を取得する処理(※内部的にはアトリビュートで取得している)
    var tableName = ModelHandler.GetTableName<M>();

    var rlsPolicyName = $"{tableName}_access_policy";

    // RLSの有効化
    migrationBuilder.Sql($"ALTER TABLE {APPLICATION_SCHEMA}.{tableName} ENABLE ROW LEVEL SECURITY;");

    // RLSポリシーの割り当て
    migrationBuilder.Sql($@"
        CREATE POLICY {rlsPolicyName}
        ON {APPLICATION_SCHEMA}.{tableName}
        TO {_role}
        USING (tenant_id = current_setting('app.current_tenant_id')::UUID)
    ");
}

migrationファイル

migrationBuilder.AddRLSPolicy<SampleModel>();

次に、DB接続時のセッションにRLSを適応します。
DBセッションへのRLS適応は以下の関数で実現できます。

this.Database.ExecuteSql($"select set_config('app.current_tenant_id', {this._tenantId}::TEXT, false);");

DBセッションへのRLS適応方法はいくつか考えました。

1. 全てのクエリの前段で関数を呼ぶ処理を書く。
2. クエリの実行時に呼ばれる共通関数を実装する。

1は分かりやすいですが、実装者に依存してしまい共通基盤実装に至った目的に反してしまいます。
2はEntityFrameworkで実行時に呼ばれる共通関数を特定する必要があり、EntityFramework依存の実装になってしまいます。実装が複雑化する可能性があったので、あまりやりたくありませんでした。

いろいろ調べた結果C#のDbConnectionクラスは接続状態の変化時にEventHandlerを仕込むことができると知りました。
DbConnection.StateChange イベント
EntityFrameworkに依存せず、実装者にも依存しないことから、EventHandlerを活用することにしました。

先ほど実装したBaseDBContext.csに手を加えていきます。

BaseDBContext.cs

public class BaseDBContext : DbContext
{
    private readonly Guid _tenantId;

    public BaseDBContext(
        Guid tenantId
    )
    {
        this._tenantId = tenantId;
        this.Database.GetDbConnection().StateChange += SetRLSPolicy;
    }

    /// <summary>
    /// DbConnectionのステート変更イベント発生時にコネクションがOpenになったらDBセッションににRLSを適応する
    /// </summary>
    /// <param name="sender"></param>
    /// <param name="args"></param>
    private void SetRLSPolicy(
        object sender,
        StateChangeEventArgs args
    )
    {
        if (args.CurrentState is ConnectionState.Open)
        {
            // 現在のセッションにテナントIdを強制
            this.Database.ExecuteSql($"select set_config('app.current_tenant_id', {this._tenantId}::TEXT, false);");
        }
    }
}

this.Database.GetDbConnection().StateChange += SetRLSPolicy;

コンストラクタ内のこの1行により、DbConnectionがOpenした際にRLSをセッションに適応してくれます。
ビジネスロジックを達成する際に複数回呼ばれる可能性があることが気になりますが、許容できる範囲だと思います。

まとめ

今回の実装はC#とASP.NET Coreの機能に助けられたという印象が強かったです。
ASP.NET Coreが非常に成熟した開発環境を提供していることを再認識しました。
Webアプリケーション開発もやりやすい環境を提供してくれているので、新たな技術スタックを検討する際にC# x ASP.NET Coreはいかがでしょうか？

参照

• ASP.NET Core での依存関係の挿入
• DbConnection.StateChange イベント
• DbContext のスレッド処理の問題を回避する