이 문서는 소프트웨어 개발자와 데이터베이스 관리자가 Bigtable을 데이터베이스로 사용하여 기존 Aerospike 애플리케이션을 마이그레이션하는 데 도움이 됩니다. Aerospike에 대한 지식을 사용하여 Bigtable로 마이그레이션하기 전에 이해해야 하는 개념을 설명합니다.
Bigtable 및 Aerospike 작업을 시작하는 데 도움이 되도록 이 문서에서는 다음을 수행합니다.
- Aerospike와 Bigtable 간의 용어를 비교합니다.
- Bigtable 작업에 대한 개요를 제공하고 Bigtable 내의 데이터 레이아웃을 설명합니다.
- 데이터 모델링 및 주요 설계 고려사항을 설명합니다.
- 복제가 어떻게 이루어지고 그 영향이 무엇인지 명확히 설명합니다.
마이그레이션 프로세스 및 마이그레이션을 완료하는 데 사용할 수 있는 오픈소스 도구에 대한 자세한 내용은 Aerospike에서 Bigtable로 마이그레이션을 참고하세요.
용어 비교
Aerospike와 Bigtable은 모두 분산 NoSQL 데이터베이스이지만 설계, 작업, 용어에서 큰 차이가 있습니다.
Aerospike에서 데이터는 레코드에 저장됩니다. 각 레코드에는 하나 이상의 명명된 bin과 레코드 크기 (바이트), 수명 (TTL), 마지막 업데이트 시간 (LUT)과 같은 메타데이터가 포함됩니다.
Bigtable은 각각 정렬된 키-값 매핑으로 구성되어 있고 확장 가능한 테이블에 데이터를 저장합니다. 테이블은 행 키로 색인이 생성된 행과 열 한정자로 식별되는 열로 구성됩니다. 서로 관련된 열은 column family를 형성할 수 있습니다. 이 구조를 사용하면 동일한 키 아래에 값의 여러 버전을 저장할 수 있습니다. 각 버전은 고유한 타임스탬프로 식별됩니다. 이전 버전은 읽기 작업 중에 필터링하거나 구성된 정책에 따라 가비지 컬렉션을 통해 삭제할 수 있습니다.
자세한 내용은 Bigtable 스토리지 모델을 참고하세요.
다음 표에서는 공유 개념과 각 제품에서 사용하는 용어를 간략하게 설명합니다.
| Aerospike | Bigtable |
|---|---|
| 직접적으로 상응하는 항목이 없습니다. | 인스턴스: 복제 및 연결 라우팅이 발생하는 여러 Google Cloud 영역 또는 리전의 관리형 클러스터 그룹입니다. |
| 클러스터: 노드 모음으로 구성된 Aerospike 배포입니다. | 클러스터: 동일한 지리적 Google Cloud 영역에 있는 노드 그룹입니다. |
| 노드: 컴퓨팅을 제공하고 스토리지를 소유하는 서버입니다. | node: 컴퓨팅만 제공하는 서버입니다. 스토리지는 별도의 분산 파일 시스템인 Colossus에 의해 처리됩니다. |
| namespace: TTL 또는 스토리지 유형과 같은 매개변수를 저장합니다. 네임스페이스 내에서 데이터는 세트와 레코드로 세분화됩니다. | table: Aerospike 네임스페이스와 가장 유사한 항목입니다. 일부 매개변수는 클러스터 수준에서 모든 테이블에 대해 설정됩니다. 테이블 또는 column family 수준에서 더 세밀하게 제어할 수 있습니다. |
| set: 레코드 및 TTL, 한도 크기와 같은 매개변수의 논리적 분할에 사용됩니다. 키는 세트 내에서 고유해야 합니다. | 직접적으로 상응하는 항목이 없습니다. |
| 직접적으로 상응하는 항목이 없습니다. | table: 모든 클러스터에 자동으로 복제되는 인스턴스 수준 리소스입니다. 테이블에는 고유한 행 키로 식별되는 값 집합이 포함됩니다. 테이블은 희소하므로 값이 포함되지 않은 열을 저장하는 데 추가 공간을 사용하지 않습니다. |
| 직접적으로 상응하는 항목이 없습니다. | 태블릿: 함께 저장된 연속된 행 범위입니다. Bigtable은 노드에 태블릿을 할당하여 부하 분산에 사용합니다. 태블릿 경계는 동적이므로 시간이 지남에 따라 분할되거나 병합될 수 있습니다. |
| record: 데이터를 저장하는 데 사용되는 명명된 bin의 집합입니다. 크기는 최대 8MB입니다. | row: column family, column qualifier, 타임스탬프로 식별되는 값의 집합입니다. 모든 작업은 행 수준에서 원자적으로 이루어집니다. |
| 직접적으로 상응하는 항목이 없습니다. | column family: 사전순으로 정렬된 열 그룹입니다. 가비지 컬렉션은 이 수준에서 설정됩니다. |
| bin: 레코드 내 값의 식별자가 bin 이름인 키-값 쌍입니다. | column qualifier: 테이블에 저장된 값의 라벨입니다. |
| 직접적으로 상응하는 항목이 없습니다. | 셀: 테이블에 저장된 타임스탬프 값의 라벨입니다. |
| (레코드) 다이제스트: 레코드를 식별하는 3개 튜플(네임스페이스, 세트, 키)의 해시입니다. | 직접적으로 상응하는 항목이 없습니다. |
| key: 세트 내에서 고유한 레코드 식별자입니다. | row key: 테이블 내에서 고유한 행 식별자입니다. |
| AQL:Aerospike 데이터베이스의 데이터를 탐색하고 사용자 정의 함수를 개발하는 명령줄 도구입니다. | GoogleSQL: Spanner, BigQuery, Bigtable을 비롯한 여러 Google Cloud 서비스에서 사용되는 쿼리 언어입니다. |
데이터 유형 제한
다음 표에서는 Aerospike와 Bigtable에서 사용하는 데이터 유형의 한도를 비교합니다.
| Aerospike | Bigtable |
|---|---|
| namespace: Enterprise Edition의 최대 네임스페이스 수는 32개입니다. | table: 인스턴스에는 최대 1,000개의 테이블이 있을 수 있습니다. 표 이름은 50자(영문 기준)를 넘을 수 없습니다. |
| 세트: 클러스터에는 최대 4,095개의 세트가 있을 수 있습니다. 세트 이름은 63바이트를 초과할 수 없습니다. | 직접적으로 상응하는 항목이 없습니다. |
| record: 최대 레코드 크기는 8MB입니다. | row: 최대 행 크기는 256MB입니다. |
| 직접적으로 상응하는 항목이 없습니다. | column family: column family 수는 무제한이지만 100개를 초과하면 성능이 저하될 수 있습니다. |
| bin: bin 수는 무제한이지만 각 bin은 1MB 이하의 데이터를 보유할 수 있습니다. 빈 이름은 15바이트를 초과할 수 없습니다. | 열 한정자: 제한은 100MB이지만 10MB를 초과하지 않는 것이 좋습니다. 열 수는 무제한입니다. |
| key: 최대 키 크기는 8KB입니다. | row key: 최대 행 키 크기는 4KB입니다. |
Bigtable 및 Aerospike 한도에 대한 자세한 내용은 할당량 및 한도 및 Aerospike 시스템 한도 및 기준점을 각각 참고하세요.
아키텍처
다음 섹션에서는 Bigtable 및 Aerospike의 아키텍처 개요를 제공합니다.
Bigtable
Bigtable 노드는 스토리지 레이어와 분리되어 있으므로 노드는 데이터 내구성에 영향을 주지 않습니다. Bigtable 테이블 클라이언트는 기본 데이터 분포를 알지 못합니다. 추가 라우팅 레이어가 요청을 올바른 노드로 분산합니다. 각 노드는 클러스터에 대한 요청 중 일부를 처리합니다. Bigtable 테이블은 태블릿이라고 하는 연속된 행의 블록으로 분할되어 Colossus에 저장됩니다. Colossus는 높은 내구성을 제공하는 분산 파일 시스템입니다. 각 태블릿은 특정 Bigtable 노드와 연결됩니다.
Bigtable 아키텍처는 다음과 같은 이점을 제공합니다.
- Bigtable 클라이언트는 데이터 분산 및 부하 분산을 인식할 필요가 없습니다. 이러한 복잡성은 라우팅 계층에서 처리합니다.
- 실제 데이터가 노드 간에 복사되지 않으므로 재균형화가 매우 빠르게 이루어지고 오류로부터의 복구도 빠릅니다.
- Bigtable 노드가 실패해도 데이터는 손실되지 않습니다.
Aerospike
Bigtable과 달리 Aerospike의 스토리지는 서비스를 제공하는 노드에 있습니다. Aerospike 클러스터의 모든 노드 (서버)는 동일합니다. 각 네임스페이스의 데이터는 레코드 이름을 해싱하여 정확히 4,096개의 파티션으로 나뉩니다. 이러한 파티션은 노드 간에 균등하게 분산됩니다.
노드는 서로를 인식하고 클러스터가 변경되면 저장된 파티션을 리밸런싱합니다. 클러스터가 변경될 때마다 복제본은 리밸런싱을 조정하는 기본 복제본을 선택합니다. 클라이언트 라이브러리는 기본 파티션을 저장하는 복제본을 추적하고 올바른 복제본에 쓰기 요청을 전송해야 합니다. 클라이언트가 잘못된 노드에 요청을 보내면 (리밸런싱 중에 발생할 수 있음) 노드에서 요청을 리라우팅합니다.
복제
이 섹션에서는 Aerospike와 Bigtable의 복제 프로세스를 비교합니다.
Bigtable
Bigtable 인스턴스는 단일 클러스터 또는 여러 복제된 클러스터로 구성될 수 있습니다. 테이블은 항상 인스턴스 내의 모든 클러스터에 복제됩니다. 다른 클러스터에 미치는 영향을 최소화하면서 인스턴스에서 클러스터를 추가하거나 삭제할 수 있습니다.
Bigtable은 단일 클러스터 내에서 작성한 항목을 읽을 수 있는 일관성을 제공합니다. 쓰기는 단일 클러스터에서 수행되며 인스턴스의 다른 클러스터에서 eventual consistency를 갖게 됩니다. Aerospike와 달리 Bigtable은 개별 셀이 내부적으로 버전이 지정되어 쓰기가 손실되지 않으므로 중간 업데이트가 손실되지 않습니다. 각 클러스터는 현재 타임스탬프가 최신인 셀을 처리합니다.
Bigtable API는 토큰 생성 전에 적용된 모든 변경사항이 완전히 복제되었는지 확인하는 데 사용할 수 있는 테이블 수준 일관성 토큰을 제공합니다.
Aerospike
Aerospike는 파티션 수준에서 클러스터 내 복제를 처리합니다. 네임스페이스는 노드 간에 균등하게 분산된 파티션으로 분할됩니다. 클러스터 내에서 강력한 일관성이 보장됩니다. 쓰기 작업은 클러스터 내의 모든 복제본이 이를 승인한 후에만 확인됩니다.
데이터 센터 간 복제 (XDR)는 서로 다른 클러스터 간의 데이터 동기화를 위해 구성할 수 있습니다. Aerospike의 bin 수렴은 복제 종료 시 모든 데이터 센터의 데이터가 결국 동일하도록 보장하지만 중간 업데이트가 손실될 수 있습니다.
내구성을 위해 Aerospike의 명단 기반 일관성 알고리즘에는 N개의 장애를 처리하기 위해 N+1개의 복사본이 필요합니다.
데이터 모델
이 섹션에서는 Bigtable과 Aerospike에서 사용되는 데이터 모델을 비교합니다.
유연한 스키마
Aerospike는 스키마 제약 조건을 적용하지 않으므로 각 레코드에 다양한 값 유형의 서로 다른 구간이 있을 수 있습니다. 마찬가지로 Bigtable은 희소 열을 지원하므로 값이 없는 열에는 스토리지가 사용되지 않습니다. 열 또는 column family 수에는 엄격한 제한이 없지만 성능상의 이유로 column family 수를 100개 미만으로 유지하는 것이 좋습니다.
row key 설계
Bigtable은 테이블 내에서 고유해야 하는 행 키로 행을 식별합니다. 이러한 항목은 사전순으로 정렬되고 태블릿에 함께 보관됩니다. 레코드가 해시에 따라 노드에 분산되는 Aerospike와는 다릅니다. 자주 함께 액세스하는 행도 함께 저장되도록 행 키를 설계해야 합니다.
데이터 유형
Aerospike는 스칼라, GeoJSON, HyperLogLog, 목록, 중첩 객체 등 고급 데이터 유형을 지원합니다. 이러한 유형은 보조 색인을 지원하여 색인을 생성하고 쿼리할 수 있습니다. 또한 Aerospike는 지리적 위치별 필터링이나 목록 콘텐츠 조작과 같은 이러한 데이터 유형에 대한 복잡한 작업을 허용하는 서버 측 API를 제공합니다.
Bigtable API는 몇 가지 예외를 제외하고 주로 원시 바이트 처리에 중점을 둡니다. 또한 타임스탬프와 카운터에 INT64를 기본적으로 사용하며, 이는 원자적 작업으로 증가할 수 있습니다. 쿼리 언어는 스칼라, JSON 객체, HLL bin과 같은 복잡한 유형도 많이 지원합니다. 고급 유형은 향후 점점 더 많이 지원될 수 있지만 이 문서를 작성하는 시점에는 이러한 유형을 Bigtable에 넣을 방법이 없으며 모든 것이 클라이언트 측에서 직렬화됩니다. aerospike-migration-tools의 어댑터 라이브러리를 사용하여 데이터 유형을 직렬화할 수 있습니다.
Column family
Bigtable에서 column family는 테이블에서 함께 저장 및 검색되는 열을 정의하며 각 테이블에 하나 이상의 column family가 있어야 합니다. 관련 열은 동일한 가족으로 그룹화해야 합니다. 가비지 컬렉션 정책은 column family 수준에서 적용되므로 보관 요구사항이 다른 데이터는 별도의 column family로 분리해야 합니다.
Column Qualifier
Bigtable에서는 column family 내에서 column qualifier를 사용하여 개별 열을 정의합니다. 테이블은 수백만 개의 열을 지원할 수 있지만, 단일 행의 열 수를 제한하는 것이 좋습니다. 선택적으로 column qualifier를 데이터로 취급하여 공간을 절약하기 위해 값을 열 이름에 직접 삽입할 수 있습니다.
셀
Bigtable에서 셀은 행 키와 열 이름 (column qualifier와 결합된 column family)의 교집합입니다. 각 셀에는 클라이언트가 제공하거나 서비스에서 자동으로 적용하는 타임스탬프 값이 한 개 이상 포함됩니다.
보조 색인
연속 구체화된 뷰는 비동기 보조 색인 역할을 하여 테이블을 다양한 조회 패턴이나 속성을 사용하여 쿼리할 수 있습니다. 자세한 내용은 비동기 보조 색인 만들기를 참고하세요.
거래
Bigtable과 Aerospike는 모두 다중 행 트랜잭션을 지원하지 않지만 단일 행 기능은 다릅니다. Bigtable은 클러스터 내에서 완전히 일관된 단일 행 쓰기를 제공하며 mutate-row 요청을 통해 단일 행 트랜잭션을 지원합니다. 단일 행에 대한 여러 작업을 허용하며, 모든 작업은 원자적으로 실행되고 모두 성공하거나 모두 실패합니다. 또한 읽기-수정-쓰기 및 검사 및 변형 작업이 있지만 멀티 클러스터 라우팅 프로필에서는 사용할 수 없습니다. 반대로 Aerospike는 서버 측 데이터 조작 및 클라이언트 정의 함수 실행을 통해 단일 행 트랜잭션을 확장합니다.
부하 분산 및 장애 조치
Aerospike는 Smart Client를 사용하여 클라이언트 측에서 부하 분산을 처리합니다. 클러스터 상태와 데이터 분산을 인식하는 클라이언트 측에서 실행되는 프로세스입니다. 이 클라이언트는 요청 라우팅을 담당합니다.
노드에 장애가 발생하거나 새 노드가 추가되면 클러스터의 균형을 다시 조정해야 합니다. 노드 간에 파티션의 재분산 및 재조정을 조정하기 위해 임시 기본 노드가 선택됩니다. 이러한 상황이 발생하는 동안 클러스터는 작동 상태를 유지하지만 클라이언트는 요청 라우팅을 위해 변경사항을 추적해야 합니다. 요청이 잘못된 노드에 도달하면 올바른 노드로 내부적으로 라우팅됩니다.
Bigtable 클라이언트는 씬 클라이언트로, 클러스터 상태 및 데이터 분산과 같은 모든 복잡성을 사용자에게 숨깁니다. 요청 라우팅은 Google CloudBigtable 인프라 내의 다음 레이어인 두꺼운 클라이언트에서 처리합니다.
또 다른 차이점은 Aerospike에서는 사용할 수 없는 라우팅 정책입니다. Bigtable은 애플리케이션 프로필을 사용하여 요청 라우팅을 관리하며, 구성 가능한 우선순위를 통해 요청이 처리되는 순서를 제어합니다. 라우팅 정책에는 단일 클러스터와 멀티 클러스터의 두 가지 유형이 있습니다. 멀티 클러스터 프로필은 사용 가능한 가장 가까운 클러스터로 작업을 라우팅합니다. 동일한 리전의 클러스터는 작업 라우터의 관점에서는 등거리로 간주됩니다. 요청된 키 범위를 담당하는 노드가 오버로드되거나 클러스터에서 일시적으로 사용할 수 없는 경우 이 프로필이 자동 장애 조치를 제공합니다. 반면 Aerospike는 전체 클러스터 장애 발생 시 자동 장애 조치를 제공하지 않습니다.
백업 및 복원
Aerospike는 클라이언트 측에서 논리적 백업을 생성하고 스캔을 실행하는 것과 유사한 asbackup 및 asrestore이라는 외부 백업 및 복원 도구를 제공합니다. 백업 관리는 Aerospike 백업 서비스 또는 Aerospike Kubernetes 연산자를 통해서도 처리할 수 있으며, 둘 다 내부적으로 asbackup 및 asrestore를 사용하고 예약 및 다중 프로세스 조정을 제공합니다. 백업은 원자적이지 않습니다. 즉, 백업 중에 발생하는 쓰기 작업이 캡처되지 않을 수 있습니다.
Bigtable은 일반적인 백업 요구사항을 처리하기 위해 Bigtable 백업과 관리형 데이터 내보내기라는 두 가지 방법을 제공합니다. 백업은 클러스터의 구성원 객체로 저장되는 테이블의 복원 가능한 사본을 만듭니다. 백업을 시작한 클러스터의 새 테이블로 백업을 복원할 수 있습니다. 백업은 애플리케이션 수준의 손상이 발생할 경우 복원 지점을 만들도록 설계되었습니다. Bigtable 백업은 원자성도 아닙니다. 백업이 이미 복사한 테이블의 섹션이 변경될 수 있습니다.
백업 처리의 주요 차이점
- Aerospike 백업은 클라이언트 측에서 생성됩니다. 서버 측에 추가 공간이 필요하지 않지만 속도가 느립니다. Bigtable에서 백업은 물리적 스토리지를 소스 테이블 및 테이블의 다른 백업과 공유합니다.
- Aerospike 사용자는 오래된 백업을 내보내고 저장하고 삭제해야 합니다. Bigtable의 백업은 완전히 통합되어 있으므로 이러한 모든 작업은 Bigtable 서비스에서 자동으로 처리합니다.
성능에 대한 고려사항
Aerospike와 Bigtable은 읽기 및 쓰기 작업을 다르게 처리하므로 고려해야 할 성능 차이가 있습니다. 다음 표에는 두 데이터베이스 간의 성능 차이의 몇 가지 예가 나와 있습니다. 자세한 내용은 Bigtable 성능 가이드라인을 참고하세요.
| 고려사항 | Bigtable | Aerospike |
|---|---|---|
| 핫 행 | 리소스 사용량을 균등하게 하기 위해 태블릿과 작업을 분산합니다. 자주 액세스하는 행을 한 노드의 단일 행 태블릿으로 격리하여 다른 행에 미치는 영향을 제한할 수 있습니다. | 트래픽과 관계없이 모든 노드에 해시를 기반으로 행을 분산합니다. 핫 행은 전체 파티션의 성능에 영향을 미칠 수 있습니다. |
| 정렬된 키를 통해 스캔 | 데이터를 사전순으로 저장하므로 정렬된 데이터를 스트리밍하는 데 매우 효과적입니다. | 해시를 기반으로 레코드를 분산하므로 연속된 키를 많이 스캔하려면 여러 노드를 쿼리하고 결과를 집계해야 하므로 속도가 느릴 수 있습니다. 고급 유형을 포함한 보조 색인을 지원하므로 스캔의 필요성이 줄어들 수 있습니다. |
| 연속된 키를 많이 삽입 | 데이터를 사전순으로 저장합니다. 즉, 단일 노드가 연속된 키 쓰기 작업을 많이 처리합니다. 결과적으로 읽기 또는 쓰기 패턴이 행 키 공간의 끝을 담당하는 태블릿을 보유한 노드에서 발생하여 효과적으로 오버로드될 수 있습니다. | 해시에 따라 키를 분산하여 연속 키를 쓸 때 여러 노드 간에 부하를 분산합니다. |
| 열 수가 매우 많은 행 | Bigtable은 최대 256MB의 행을 지원할 수 있지만 큰 행을 처리하면 성능에 영향을 줄 수 있습니다. Bigtable은 작은 행에 최적화되어 있으므로 불필요한 경우 여러 셀에 데이터가 분산되지 않도록 스키마 설계 시 셀 구성 및 데이터 액세스를 고려해야 합니다. | 열이나 구간이 매우 많은 행 또는 레코드를 만나면 최적의 성능을 발휘하지 못합니다. |
| 콜드 스타트 | 자주 액세스되는 큰 테이블에서 가장 효과적입니다. 일정 기간 사용하지 않은 후 (콜드 스타트) 요청을 보내기 시작하면 지연 시간이 길어질 수 있습니다. 이는 태블릿으로 분할하고 노드 간에 분산하는 것이 최적화되지 않았기 때문이며 캐시가 콜드 상태이기 때문입니다. 콜드 스타트 및 리밸런싱 중에는 몇 분이 지나야 노드 간 배포가 완전히 최적화될 수 있습니다. | 데이터 분포가 로드 기반이 아니므로 시간이 지나도 성능이 변하지 않습니다. 캐시는 워밍이 필요하지만 색인은 메모리에 유지되므로 디스크 검색 시간이 최소화되고 캐싱의 중요성이 줄어듭니다. |
| 작은 테이블이 많음 | 작은 테이블을 많이 만들지 마세요. 별도의 테이블은 다른 사용 사례나 스키마에는 적합하지만 유사한 데이터에는 적합하지 않습니다. 로드 균형 조정이 개선되지 않고 관리 오버헤드가 증가하기 때문입니다. | 대부분의 레코드는 하나의 네임스페이스에 있으며 세트로 그룹화됩니다. 세트에는 특정 스키마가 없지만 보조 색인이나 스캔 작업은 세트별로 설정할 수 있습니다. 데이터를 세트로 분할해도 성능에는 영향을 미치지 않습니다. |
| 대규모 데이터 세트 | 엑사바이트 규모의 데이터 세트를 저장할 수 있습니다. 아키텍처와 동적 태블릿 분할로 인해 전체 데이터 세트 크기가 성능에 영향을 미치지 않습니다. | 기술적으로 Aerospike 데이터베이스에는 크기 제한이 없지만 Aerospike는 색인과 레코드를 별도로 저장합니다. 성능을 높이기 위해 두 종류의 데이터를 모두 다양한 유형의 저장 장치에 저장할 수 있습니다. 지연 시간을 줄이려면 RAM에 색인을 저장해야 하지만 매우 큰 데이터 세트에는 적합하지 않을 수 있습니다. 예를 들어 객체가 40억 개이고 복제 요소가 2 (RF2)인 경우, 올플래시에서 클러스터 전체의 기본 색인과 연결되어 사용되는 메모리는 2.5GiB입니다. 기본 색인이 메모리에 있는 하이브리드 메모리 구성에서 동일한 예를 사용하면 476.8GiB의 메모리가 사용됩니다. |
| 확장 | 처리 및 스토리지는 분리되어 있으며 독립적으로 확장할 수 있습니다. 단일 노드는 수백 테라바이트 또는 페타바이트의 데이터 청크를 처리할 수 있습니다. | 지연 시간을 줄이려면 RAM에 색인을 저장해야 합니다. 이 경우 기본 색인을 고려하여 스토리지 용량과 함께 머신을 수직으로 확장해야 합니다. |
다음 단계
- Bigtable 스키마 디자인 읽어보기
- Aerospike에 대해 자세히 알아보세요.
- Bigtable 에뮬레이터 알아보기
- Google Cloud에 대한 참조 아키텍처, 다이어그램, 권장사항을 살펴보세요. Cloud 아키텍처 센터 살펴보기