청사진에는 Cymbal Bank라는 샘플 애플리케이션이 포함되어 있습니다. Cymbal Bank는 컨테이너화된 애플리케이션에 장려되는 권장사항을 보여줍니다. 사용자는 Cymbal Bank 애플리케이션을 이용하여 로그인 계정을 만들고, 자신의 계정에 로그인하고, 거래 내역을 확인하고, 입금하고, 다른 사용자의 계정으로 송금할 수 있습니다. Cymbal Bank 서비스는 REST API 및 gRPC API를 통해 서로 연결되는 컨테이너로 실행됩니다.
다음은 청사진 개발자 플랫폼에 배포된 Cymbal Bank 애플리케이션을 도식화한 다이어그램입니다.
테넌트 간의 구분을 제공하기 위해 개발자 플랫폼의 각 테넌트에는 한 개의 팀 범위와 한 개 이상의 Fleet 네임스페이스가 있습니다.
테넌트는 네임스페이스를 공유하지 않습니다. Cymbal Bank를 배포하려면 각 테넌트에 하나의 네임스페이스만 있으면 됩니다. 더 복잡한 시나리오에서는 테넌트에 여러 네임스페이스가 있을 수 있습니다.
Cymbal Bank가 개발자 플랫폼에 배포되는 방식을 설명하기 위해 이 예에서는 중점 분야가 서로 다른 세 개의 개별 애플리케이션 개발팀이 있다고 가정합니다. Terraform은 각 팀별로 다음과 같은 개발자 플랫폼 테넌트를 만듭니다.
frontend 테넌트: 웹사이트 및 모바일 애플리케이션 백엔드에 중점을 둔 개발팀입니다.
accounts 테넌트: 고객 데이터에 중점을 둔 개발팀입니다.
ledger 테넌트: 원장 서비스를 관리하는 팀입니다.
Cymbal Bank 앱
Cymbal Bank 애플리케이션은 frontend,
ledgerwriter, balancereader, transactionhistory, userservice, contacts의 6개 마이크로서비스로 구성됩니다.
각 마이크로서비스는 이를 소유한 테넌트 내 애플리케이션에 매핑됩니다.
다음 표에서는 Cymbal Bank의 팀, 팀 범위, Fleet 네임스페이스, 마이크로서비스 매핑을 설명합니다. 이 매핑에는 Cymbal Bank가 세 개의 개별 애플리케이션 운영자 팀에서 개발되었다고 가정합니다. 팀들은 다양한 서비스를 관리합니다. 각 팀에는 팀 범위가 할당됩니다.
Cymbal Bank 데이터베이스는 PostgreSQL용 AlloyDB를 사용하여 배포됩니다. 데이터베이스는 한 리전의 고가용성 기본 인스턴스와 여러 영역의 중복 노드로 구성되며, 재해 복구를 위해 리전 간 복제본이 사용됩니다. Cymbal Bank는 IAM 데이터베이스 인증을 사용하여 서비스가 데이터베이스에 액세스하도록 허용합니다. 데이터베이스는 CMEK를 사용하여 암호화됩니다. 원장용 ledger-db 및 사용자 계정용 accounts-db라는 두 가지 PostgreSQL 데이터베이스가 사용됩니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2024-12-13(UTC)"],[],[],null,["# Cymbal Bank application architecture\n\nThe blueprint includes a sample application that is named *Cymbal Bank* . Cymbal\nBank demonstrates the best practices that are recommended for containerized\napplications. The Cymbal Bank application lets users create login accounts, sign\nin to their account, see their transaction history, make deposits, and transfer\nmoney to other users' accounts. Cymbal Bank services run as containers that\nconnect to each other over [REST APIs](https://en.wikipedia.org/wiki/Representational_state_transfer) and [gRPC APIs](https://grpc.io/).\n\nThe following diagram shows the Cymbal Bank application that is deployed on the\nblueprint developer platform.\n\nEach application is also a network service. Only the frontend application is\nexposed externally to the cluster through the [GKE Gateway controller](/kubernetes-engine/docs/concepts/gateway-api).\nAll applications run as distributed services through the use of\n[Cloud Service Mesh](/anthos/service-mesh).\n\nFor more information about the services that are included in the Cymbal Bank\napplication, see the [Cymbal Bank repository on GitHub](https://github.com/GoogleCloudPlatform/terraform-google-enterprise-application/tree/main/examples/cymbal-bank).\n\nCymbal Bank tenants\n-------------------\n\nTo provide separation between tenants, each tenant in the developer platform has\none [team scope](/anthos/fleet-management/docs/team-management)\nand at least one fleet namespace.\nTenants never share a namespace. To deploy Cymbal Bank, each tenant only needs\none namespace. In more complex scenarios, a tenant can have several namespaces.\n\nTo illustrate how Cymbal Bank is deployed on the developer platform, this example assumes\nthat there were three separate application development teams with different\nfocus areas. The Terraform creates the following developer platform tenant for each of those\nteams:\n\n- **`frontend` tenant**: A development team that focuses on the website and mobile application backends.\n- **`accounts` tenant**: A development team that focuses on customer data.\n- **`ledger` tenant**: A team that manages the ledger services.\n\nCymbal Bank apps\n----------------\n\nThe Cymbal Bank application consists of six microservices: `frontend,\nledgerwriter, balancereader, transactionhistory, userservice`, and `contacts`.\nEach microservice is mapped to an application within the tenant that owns it.\n\nThe following table describes the mapping of the teams, team scope, fleet\nnamespace, and microservices for Cymbal Bank. For the purpose of this mapping,\nthis example assumes that Cymbal Bank is developed by three separate application operator\nteams. Teams manage a varying number of services. Each team is assigned a team\nscope.\n\nCymbal Bank database structure\n------------------------------\n\nCymbal Bank databases are deployed using\n[AlloyDB for PostgreSQL](/alloydb/docs/overview). The\ndatabases are configured with a [highly available primary instance](/alloydb/docs/overview#ha)\nin one [region](/docs/geography-and-regions#regions_and_zones) with\nredundant nodes in different zones, and [cross-region replicas](/alloydb/docs/cross-region-replication/about-cross-region-replication)\nare used for disaster recovery. Cymbal Bank uses [IAM database authentication](/alloydb/docs/manage-iam-authn#enable)\nto allow services access to the databases. The databases are encrypted using\n[CMEK](/sql/docs/postgres/configure-cmek). Two\nPostgreSQL databases are used: `ledger-db` for the ledger, and `accounts-db`\nfor user accounts.\n\nWhat's next\n-----------\n\n- Read about [mapping BeyondProd security principles to the blueprint](/architecture/enterprise-application-blueprint/mapping-beyondprod-security-principles) (next document in this series)."]]