本記事は「The Single-Tenant Trap: Why Testing in Production Kills Uptime」を翻訳した記事です。
TL;DR: 開発、ステージング、本番環境のトラフィックを単一のアイデンティティテナント内で実行するのは、アーキテクチャのアンチパターンです。本記事では、マルチテナント構成への移行がアプリケーションの稼働率をどのように保護するか解説します。Auth0 Deploy CLIを使用して真の環境パリティを確立し、きめ細かなダッシュボードアクセス制御を適用し、セキュリティポリシーを分離し、外部ログストリーミングを通じて可観測性を自動化する方法を学びます。
初期段階の企業の多くは、最初に連絡を取った時点で単一のAuth0テナントを運用しています。単一テナントの選択が意図的なアーキテクチャの決定であるケースは稀です。単に認証を最も早くリリースする方法であり、ロードマップ上で見直す余裕がなかったためです。
分離してテストしていると開発者が考えていた機能が本番環境で壊れたときに、問題に気づきます。シングルテナントの罠は、リリースするための手軽なハックとして始まり、最終的には壊滅的な単一障害点となることです。
単一テナント構成の限界
エンジニアがアイデンティティのライフサイクルをコードの変更から分離しようとする際、単一テナント内で複数の環境を管理できるかよく尋ねられます。実現するために、開発者はハードコードされたアプリケーションIDに基づいてAuth0 Actionで条件付きルーティングするなど、カスタムの回避策を構築することがよくあります。しかし、人工的な分割ではテナント全体のインフラストラクチャを分離できません。多要素認証のトリガーやグローバルデータベース接続、セッションCookieなどの重要な機能は、単一テナントの境界内で分割できません。本番テナントへの構造的な調整はすべてのアクティブユーザーに即座に影響します。そのため、本番環境でのテストは依然として重大なリスクとなります。
次の重大インシデントが発生する前に問題を修正するには、真のマルチテナントチームエコシステムへ移行する必要があります。ワークフローを分離し、アクティブユーザーベースを保護するための4ステップのロードマップを本記事で紹介します。
1. 必要になる前に環境を分離する
典型的な障害パターンは、開発者がリダイレクトURLを変更したり、クライアントシークレットをローテーションしたり、新しいActionをデプロイしたりした際に発生します。変更により、本番環境のすべてのアクティブユーザーのログインが即座に停止します。ステージングと本番環境が同一であるため、セーフティネットが存在しません。
開発用と本番用の少なくとも2つのテナントが必要です。単一のアーキテクチャの下で分離された環境テナントをプロビジョニングすることが、アクティブユーザーベースを保護する唯一の方法です。
複数の環境を持つと、手動での同期はリスクになります。Auth0 Deploy CLIを使用すると、テナント構成をコードとして宣言できます。UIで手動更新する代わりに、継続的インテグレーションおよび継続的デプロイメント(CI/CD)パイプラインへ直接統合します。プロモーションを自動化する基本的なGitHub Actionsワークフローは本記事の通りです。
name: Deploy Auth0 Configuration on: push: branches: - main jobs: deploy: runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 - name: Setup Node.js uses: actions/setup-node@v3 - name: Install Auth0 CLI run: npm install -g auth0-deploy-cli - name: Deploy to Production Tenant run: a0deploy import -c config.json -i ./auth0-config/tenant.yaml env: AUTH0_DOMAIN: ${{ secrets.AUTH0_PROD_DOMAIN }} AUTH0_CLIENT_ID: ${{ secrets.AUTH0_PROD_CLIENT_ID }} AUTH0_CLIENT_SECRET: ${{ secrets.AUTH0_PROD_CLIENT_SECRET }}
About the author
Carlos Aguilar
Customer Advocate