はじめに

本記事は any Advent Calendar #2 「マルチテナントSaaSにおけるエンジニアリング大全」 Day16 の記事です。弊社anyのアドベントカレンダーをひとつ丸ごと占有して、ひとりアドベントカレンダーとして、筆者の「マルチテナントSaaSのエンジニアリング」への経験をすべてアウトプットしていくカレンダーです。

今日はマルチテナントにおけるログ管理について紹介していきます。ログについてはアプリケーションごとに求められる要件が大きく異なります。そこで今回は弊社プロダクトQastの事例を紹介しながら、マルチテナントSaaSにおけるログの種類、形式、プラクティスについて紹介していきます🏄‍♂️

マルチテナントにおけるログ戦略

前提: 構造化ログにする

大前提として、出力するログについては「構造化ログにすること」が重要です。テナントの識別にとどまらず、クエリを用いてフィルタリングできることが大きな一歩となります。構造化ログによって、CloudWatch Logs Insightなどで強力な検索をサポートできます。

そのうえで、これまでの記事で述べてきたような「データ分離戦略」「テナント解決の方法」にもログ設計が左右されます。例えばプールモデルにおいては明示的に区別できるプロパティをつける必要があります。これらを踏まえたうえで、各種ログごとの性質を見ていきましょう。

アクセスログ / セキュリティログ

アクセスログは、インフラレイヤのネットワーク層におけるアクセスログ、また認証の成否などのログのことを指します。AWSであれば、ALBやWAFなどのクラウドサービスが出力するログが事実上のアクセスログになります。前述したようにテナント分離戦略にも左右されます。Qastにおいては、URLのサブドメインが顧客ごとに変化する関係上、サブドメインでテナントを識別できます。

アプリケーションログ / エラーログ

マルチテナントにおいては、サイロモデルでない限りリソースを共有することになりますが、アプリケーションログやエラーログについては明示的に「どのテナント」の「どのユーザー」かを識別するプロパティを付与することをおすすめます。

Qastにおいては、バックエンドはNestJSを中心に構築しているため、Interceptor層でロガーに強制的にテナントIDに相当する値を注入しています。各種アプリケーションレイヤでは意識する必要がないように設計することで漏れなく値が設定されるようにしています。

@Injectable()
export class LoggerInterceptor<T> implements NestInterceptor<T, Response<T>> {
    constructor(
        @Inject(QAST_LOGGER_KEY) private readonly logger: QastStructuredLogger,
    ) {
    }

    public async intercept(executionContext: ExecutionContext, next: CallHandler): Promise<Observable<Response<T>>> {
        if (executionContext.getType() !== 'rpc') {
            return next.handle();
        }

        const { tenantId } = executionContext.switchToRpc().getData();

        this.logger.setExtra({
            tenantId
        });

        return next.handle();
    }
}

QastではStructured Loggerという構造化ロガーも共通に提供して、NestJSで構築されたマイクロサービスから利用できるようにしています。

監査ログ（Audit Log）

監査ログは非常に概念が広いですが、主に顧客向けと社内向けの二種類の監査ログが存在します。

顧客向けにおいては、エンタープライズ向けの機能として監査ログの提供を必須とするケースもあります。これはSaaS内の操作を記録しておき、それを管理者に提供する仕組みを用意するように設計しなければなりません。SOC2やISMAPなどのセキュリティ認証取得には必須であることもあります。

また社内向けの監査ログといえば、社内のデータベースクエリに対するログや、社内開発者の不正利用を防止する、また不正なアクセスがないかを確認するセキュリティ観点で保存するものもあります。ほぼ黒塗りで申し訳ないですが、弊社ではGitHubなどの監査ログもDatadogに流すことで、統一した監査ログの集約を推し進めています。

さいごに

マルチテナントに限った話ではないものの、ログ設計は一度正しく設計しておくと複利的に効果が発揮されていきます。テナントごとに詳細に調査ができることは、ノイジーネイバー問題等への検知も容易になります。ぜひ参考になさってください🍵