> ## Documentation Index
> Fetch the complete documentation index at: https://docs.iru.com/llms.txt
> Use this file to discover all available pages before exploring further.
# プラットフォームアーキテクチャ
> Iru Identity の構築方法: データレジデンシー、信頼性、可観測性のために設計された、分離されたリージョンにまたがる 2 プレーンのサービスアーキテクチャ。
Iru Identity は、アクセスの信頼できる中心となるように構築されたクラウドサービスです。以下では、サービスの構築方法と、それが信頼性と分離にとって何を意味するかを説明します。
## 役割によって分離された 2 つのプレーン
プラットフォームは、共通の階層化されたコアを共有する、独立してデプロイされる 2 つのサービスに分割されています。特権的なプロビジョニングをテナントごとのリクエストトラフィックから分離することで、それぞれの影響範囲を縮小します。
```mermaid theme={null}
flowchart TB
subgraph cp["コントロールプレーン"]
tprov["テナントライフサイクル
(作成 / 削除)"]
jwks["公開鍵の公開 (JWKS)"]
tmpl["アプリテンプレートの同期"]
end
subgraph tp["テナント API"]
iam["テナントごとの IAM API"]
work["バックグラウンドのプロビジョニングワーカー"]
end
cp -->|"プロビジョニング"| tp
people["管理者とユーザー"] --> tp
apps["アプリ"] --> tp
```
| プレーン | 責任 | 分離されている理由 |
| - | - | - |
| **コントロールプレーン** | テナントの作成と削除、署名キーの公開、アプリケーションテンプレートカタログの同期。 | 顧客のリクエストトラフィックから離して保持される、小さな特権サーフェス。テナント操作には定数時間で比較されるトークンが必要です。テンプレート同期の資格情報はリクエストごとにマネージドシークレットストアから取得されるため、ローテーションはすぐに有効になります。 |
| **テナント API** | 顧客向けの ID およびアクセス API と、アプリにアカウントをプロビジョニングするバックグラウンドワーカー。 | ユーザーとアプリが実際に使用する高トラフィックのサーフェス。プロビジョニングは帯域外で処理されるため、低速なダウンストリームアプリがサインインをブロックすることはありません。 |
## 規律ある階層化されたコア
両方のサービスは、一方向の依存関係ルールを持つ階層化アーキテクチャで Go で構築されています。個別に強制される**プラットフォーム**層が製品レイヤーの下にあり、テナント分離と ID プリミティブを所有します。**ファウンデーション**は、テナントコンテキストを持たない共有インフラストラクチャユーティリティのために依存関係のない状態を維持します。
テナント分離と ID の中核: データベースアクセス、セッション、テナントとリージョンの解決、アクター、ロギング、パブリック URL の処理。この層は個別にレビューおよび強制されるため、分離は通常の製品コードから切り離されます。
上位のものに依存しない共有インフラストラクチャユーティリティ (暗号化やトレースなど)。テナントスコープの関心事はここではなくプラットフォームにあります。
エンティティ (ユーザー、アプリケーション、ポリシーなど) ごとのビジネスロジック。プラットフォームとファウンデーションに依存し、ユースケースや REST には依存しません。
複雑なフローのために複数のドメインサービスを調整します。
HTTP ハンドラーとミドルウェア。通信プロトコルを扱う唯一のレイヤーです。
この階層化は、コンパイラーによって保証される不変条件ではなく、文書化された**レビューで強制される**規約です (リンティングとディレクトリ構造によって裏付けられています)。誇張せずに正直にそのことを明記しています。
テストも同じ規律に従います。純粋なビジネスロジックはモックなしで単体テストされ、動作は**実際の PostgreSQL データベースに対して実行される統合テスト**によって検証されるため、テストではスタブによる近似ではなく、本番環境で実行されるのと同じ行レベルセキュリティと監査の動作が実行されます。
## ホスティングと強化
Iru Identity は、セキュリティが強化されたデプロイメントで **AWS** 上で実行されます。
サービスは AWS Fargate 上で非 root として、**読み取り専用のルートファイルシステム**、**no-new-privileges**、およびすべての Linux ケーパビリティを削除した状態で実行されます。
アプリケーションは、短命の **IAM 認証トークン**を使用してマネージド **PostgreSQL (Amazon RDS)** に接続します。漏洩する静的な DB パスワードはありません。
資格情報と署名キーは実行時にマネージドシークレットストアから挿入され、リポジトリにコミットされたり、データベースにプレーンテキストで保存されたりすることはありません。
コンテナイメージは、出荷前に CI パイプラインで脆弱性がスキャンされます。
静的アセットは CDN (Fastly) を通じて提供され、テスト用の短命なプレビュー環境は Google Cloud Run で実行されます。
## 2 つのリージョン、実際のデータレジデンシー
Iru Identity は **2 つの分離されたリージョン (米国 `us-east-2` と欧州連合 `eu-central-1`)** で運用されており、レジデンシーは慣例ではなくコードで強制されます。
```mermaid theme={null}
flowchart LR
req["リクエスト"] --> mw["サブドメインから
テナントを解決"]
mw --> reg{"テナントの
リージョン?"}
reg -->|"US"| usdb[("US データベース")]
reg -->|"EU"| eudb[("EU データベース")]
reg -->|"不明"| rej["拒否"]
```
* すべてのテナントは**リージョンに固定**され、テナントレコードに保存されます。
* データベースレイヤーは**リージョンごとに個別の接続プール**を保持し、すべてのトランザクションをテナントのリージョンによってルーティングします。リージョンを解決できないリクエストは**拒否**されます。黙って別のリージョンにフォールバックすることはありません。
* リージョン固有のデータ操作 (シードデータなど) は、間違ったリージョンに対して実行できないよう制御されています。
結果として、EU テナントのデータは EU のインフラストラクチャに対してのみ読み書きされます。各リージョンのデータベース*内*で分離がどのように継続されるかについては、[マルチテナント分離](/ja/identity/security/multi-tenant-isolation)を参照してください。
## 稼働し続け、可観測性を備えるよう構築
依存関係のないライブネスエンドポイントにより、オーケストレーターはデータベースや認証に触れることなくプローブできます。シャットダウン時、サービスはトラフィックの受け入れを停止し、トレース、エラーレポート、データベース接続を順番にフラッシュします。
接続プールは調整および制限されており、起動時にデータベースに ping を送信し、到達できない場合は壊れたリクエストを処理するのではなく**フェイルファスト**します。
アプリへのアカウントのプロビジョニングは、キャンセルを認識するバックグラウンドワーカーの**アウトボックスと調整**ループを通じて実行されるため、ダウンストリームの変更は失われることなく成功するまで再試行されます。
リクエストは **OpenTelemetry** で HTTP からアプリケーションコードを経て SQL クエリまでトレースされ、構造化ログはテナントとトレース ID によって相関付けられます。エラーは、忠実度とコストのバランスを取るためにサンプリングを使用して一元的に取得されます。
スキーマの変更は埋め込まれ、バージョン順に並べられ、**チェックサムで検証**されます (すでに適用されたマイグレーションが変更された場合はハードエラーになります)。常設のチェッカーが、すべてのテーブルの監査ジャーナルがライブスキーマと同期していることを証明します。
## 次のステップ
行レベルセキュリティと追記専用の監査によって、すべてのテナントのデータを分離し、改ざん検知可能に保つ方法。
フィッシング耐性のあるサインイン、署名付きリクエスト、および SSO の信頼の確立方法。
これらのメカニズムがもたらす保証。
ID とサインインがどのように流れるかについての顧客向けの説明。