このブループリントには、Cymbal Bank という名前のサンプル アプリケーションが含まれています。Cymbal Bank は、コンテナ化されたアプリケーションに推奨されるベスト プラクティスを示しています。Cymbal Bank アプリケーションを使用すると、ログイン アカウントの作成、アカウントへのログイン、取引履歴の確認、入金、他のユーザーの口座への送金を行えます。Cymbal Bank サービスは、REST API と gRPC API を介して相互に接続するコンテナとして動作します。
次の図は、ブループリントのデベロッパー プラットフォームにデプロイされる Cymbal Bank アプリケーションを示しています。
各アプリケーションはネットワーク サービスでもあります。フロントエンド アプリケーションのみが、GKE Gateway Controller を介してクラスタ向けに外部に公開されます。すべてのアプリケーションは、Cloud Service Mesh を使用して分散サービスとして動作します。
Cymbal Bank アプリケーションに含まれるサービスの詳細については、GitHub の Cymbal Bank リポジトリをご覧ください。
Cymbal Bank のテナント
テナントを分離するために、デベロッパー プラットフォームの各テナントには 1 つのチームスコープと 1 つ以上のフリート名前空間があります。テナントが名前空間を共有することはありません。Cymbal Bank をデプロイするうえで各テナントに必要な名前空間は 1 つだけです。より複雑なシナリオでは、テナントが複数の名前空間を持つ場合があります。
この例では、Cymbal Bank がデベロッパー プラットフォームにどのようにデプロイされているかを説明するため、重点分野が異なる 3 つのアプリケーション開発チームが存在することを想定しています。Terraform は、チームごとに次のデベロッパー プラットフォーム テナントを作成します。
frontendテナント: ウェブサイトやモバイルアプリのバックエンドを担当する開発チーム。accountsテナント: 顧客データを担当する開発チーム。ledgerテナント: 台帳サービスを管理するチーム。
Cymbal Bank のアプリ
Cymbal Bank のアプリケーションは、frontend,
ledgerwriter, balancereader, transactionhistory, userservice と contacts の 6 つのマイクロサービスで構成されています。各マイクロサービスは、その所有元のテナント内のアプリケーションにマッピングされます。
次の表に、Cymbal Bank のチーム、チームスコープ、フリートの名前空間、マイクロサービスの対応関係を示します。この対応関係の例では、Cymbal Bank が 3 つの別々のアプリケーション オペレータ チームによって開発されていることを想定しています。チームはさまざまな数のサービスを管理します。各チームにはチームスコープが割り当てられます。
| チーム | チームスコープ | フリートの名前空間 | アプリケーション - マイクロサービス | Kubernetes サービス アカウント |
|---|---|---|---|---|
フロントエンド チーム |
|
|
|
|
台帳チーム |
|
|
|
|
|
||||
|
||||
アカウント チーム |
|
|
|
|
|
Cymbal Bank のデータベース構造
Cymbal Bank データベースは、AlloyDB for PostgreSQL を使用してデプロイされます。データベースは、異なるゾーンに冗長ノードがある 1 つのリージョン内の高可用性プライマリ インスタンスを使用して構成され、障害復旧のためクロスリージョン レプリカが使用されています。Cymbal Bank は、IAM データベース認証を使用して、サービスがデータベースにアクセスできるようにしています。データベースは CMEK を使用して暗号化されます。2 つの PostgreSQL データベース（台帳用の ledger-db とユーザー アカウント用の accounts-db）が使用されます。
次のステップ
- BeyondProd のセキュリティ原則のブループリントへのマッピング（このシリーズの次のドキュメント）を読む。