이 문서에서는 Google Cloud에서 마이크로서비스를 사용하여 확장 가능한 상거래 플랫폼을 빌드하는 데 사용할 수 있는 일련의 아키텍처 접근 방식을 설명합니다.
소매 상거래 요구사항 및 마이크로서비스
지속적으로 증가하는 소비자 기기 및 플랫폼의 수요를 감당하려면 소매 상거래 작업 부하에 여러 클라우드 네이티브 기능이 필요합니다.
- 전 세계 고객층에 서비스를 제공하기 위해 일반적으로 이러한 배포는 여러 지역에서 이루어져야 합니다.
- 어느 정도의 자동 확장 또는 예정된 확장을 지원해야 하며, 성수기의 최대 수요에 맞게 확장하고, 수요가 낮을 때에는 축소해 인프라 비용을 줄여야 합니다.
- 소매 상거래 배포는 변화하는 시장의 수요를 충족하기 위해 고객에게 특성과 기능을 신속하고 효율적으로 제공할 수 있어야 합니다.
- 또한 소매 상거래 배포는 관리형 인프라를 사용하여 개발자가 고객용 기능에 집중할 수 있도록 해야 합니다.
- 마지막으로 이러한 배포는 중앙에서 보호하고 관리해야 합니다.
마이크로 서비스는 이러한 모든 요구사항에 적합합니다. 개별 마이크로 서비스는 서로 독립적으로 배포 및 확장될 수 있어 새로운 특성과 기능을 신속하게 제공할 수 있습니다. 서비스는 소규모의 모듈형이고 느슨하게 연결되며 특정 비즈니스 기능 및 요구사항을 중심으로 구성됩니다. 마이크로 서비스는 서비스 검색을 활용하며 다양한 장치에서 쉽게 연결할 수 있는 간단한 메커니즘(예: HTTP)을 사용할 수 있습니다.
백엔드 아키텍처
소매 상거래 작업 부하의 경우 마이크로 서비스를 고객용 사용자 환경을 구축하는 데 필요한 개별 기능으로 구성합니다. 예를 들어 특정 제품에 대한 메타데이터를 검색 및 캐시(선택 사항)하는 제품 메타데이터 서비스가 있을 수 있습니다. 또는 특정 고객에 대한 제품 가격을 검색하는 제품 가격 책정 서비스가 있을 수 있습니다.
마이크로 서비스는 REST API를 통해 클라이언트에 노출되며, 클라이언트 애플리케이션은 API 게이트웨이를 통해 REST API와 통신합니다.
다음 다이어그램은 상거래 중심 백엔드 마이크로 서비스 아키텍처의 예입니다.
프런트엔드 아키텍처
소매 상거래 워크로드의 고객 관련 사용자 환경에는 일반적으로 응답성이 우수한 웹 애플리케이션(종종 프로그레시브 웹 애플리케이션의 형태로 제공)과 선택적으로 기본 모바일 애플리케이션이 포함됩니다. 이전에 설명한 백엔드 아키텍처와 함께 백엔드 API 및 서비스와 반응하고 통신하는 여러 프런트엔드 구성요소를 조합하여 애플리케이션을 구축할 수 있습니다.
다음 다이어그램은 상거래 중심 웹 애플리케이션 프런트엔드의 예시입니다.
데이터 스토리지
소매 상거래 작업 부하는 여러 카테고리의 데이터를 유지해야 합니다. 카테고리는 다음과 같습니다.
- 제품 카탈로그—이름, 설명, 색상, 크기 등의 제품 속성
- 쇼핑객 프로필—이름, 나이, 선호 사항, 청구, 배송지 주소 등의 고객 데이터
- 쇼핑객 트랜잭션—구매한 상품, 구매 날짜 등의 고객 구매 정보
- 클릭 스트림 데이터—웹사이트를 통해 쇼핑객의 경로를 추적하는 정보
- 제품 이미지 및 동영상—자사 제공 콘텐츠 및 고객 제공 콘텐츠를 포함한 특정 제품과 관련된 미디어
- 평가 및 리뷰—제품에 대한 고객의 의견과 피드백
- 제품 인벤토리—상품 재고 여부 및 신규 입고 예상 시간 데이터
다음 테이블과 같이 각 데이터 카테고리는 Google Cloud Storage 메커니즘에 매핑될 수 있습니다.
| 객체 | 비관계형 | 관계형 | 웨어하우스 | ||
|---|---|---|---|---|---|
| Cloud Storage | Cloud Datastore | Cloud Bigtable | Cloud SQL | Cloud Spanner | BigQuery |
|
이미지 동영상 |
카탈로그 프로필 인보이스 |
클릭 스트림 가격 |
트랜잭션 인벤토리 평가 |
트랜잭션 인벤토리 평가 |
애널리틱스 웨어하우징 |
제품 카탈로그
제품 카탈로그에서 제품은 이름, 설명 등의 속성을 가집니다. 제품 카탈로그가 다양해질수록 제품의 고유한 속성의 수도 증가하게 됩니다. 각각의 새로운 제품 카테고리는 상품 크기 및 색상, 상품 유형 및 모델 등 검색하거나 필터링에 사용할 수 있는 고유한 속성 집합을 가집니다.
따라서 제품 카탈로그에 대한 가장 적합한 저장소 옵션은 NoSQL 문서 중심의 데이터베이스입니다. 이 데이터베이스는 유연한 스키마를 가지며 카테고리별 또는 객체별 속성을 저장할 수 있습니다. Datastore는 완전 관리형 NoSQL 문서 중심의 데이터베이스이며 이러한 사용 사례를 지원합니다. Datastore에서는 객체를 항목으로 저장하고 각 항목은 JSON 구조와 비슷한 중첩된 키-값 쌍을 지원합니다. Datastore는 여러 Google Cloud 리전에서 사용 가능한 상시 사용 설정된 서비스입니다.
제품 미디어
제품 카탈로그의 모든 제품에는 자사 이미지 또는 동영상이 있을 수 있으며 고객이 제공한 이미지 또는 동영상도 있을 수 있습니다. 이러한 자료는 확장 가능한 객체 저장소에 저장할 수 있으며 웹 애플리케이션 또는 모바일 애플리케이션에 직접 제공할 수 있습니다. Cloud Storage는 여러 지역에서 데이터를 제공할 수 있는 관리형 객체 저장소 서비스입니다. Cloud Storage는 니즈에 따라 다양한 등급의 데이터 액세스와 가용성을 제공합니다. Cloud CDN은 고성능을 위해 Google이 보유한 세계 각지에 분산된 에지 위치를 활용하여 Cloud Storage에서 제공하는 콘텐츠를 더욱 빠르게 전달합니다. 이렇게 하면 다운로드 지연 시간을 최소화할 수 있도록 정적 애셋을 최종 사용자와 최대한 가깝게 배치할 수 있습니다.
쇼핑객 프로필
쇼핑객 프로필은 일관된 속성 집합을 가지며 종종 다차원으로 구성되어있습니다. 예를 들어 일부 고객은 여러 개의 배송지 주소 또는 여러 가지 결제 수단을 사용할 수 있으며 결제 수단마다 자체 청구서 수신 주소가 있습니다.
여러 개의 표를 사용하여 관계형 데이터베이스에 쇼핑객 프로필을 저장할 수 있습니다. 하지만 NoSQL 문서 중심의 데이터베이스를 사용하여 고객 프로필을 저장할 수도 있습니다. 이렇게 하면 쇼핑객 프로필은 특정 고객에 대한 모든 데이터를 보유하는 단일의 풍부한 객체로 저장됩니다. Datastore는 완전 관리형 NoSQL 문서 중심의 데이터베이스이며 이러한 사용 사례를 지원합니다.
평가 및 리뷰
고객이 남긴 제품 평가 및 리뷰는 상대적으로 단순한 데이터세트로 구성되며 여러 가지 저장 메커니즘을 사용하여 이러한 정보를 유지할 수 있습니다. 제품 ID, 고객 ID, 평가 값, 리뷰 텍스트와 같은 필드가 포함된 관계형 스키마를 사용하는 것이 일반적입니다. Cloud SQL 또는 Spanner를 사용하여 이 데이터를 저장할 수 있습니다. 대부분의 사용 사례에서 Cloud SQL이 평가와 리뷰 데이터를 저장하는 데 가장 적합한 시스템입니다. 애플리케이션에 트랜잭션 처리량 증가 및 수평 확장이 필요한 경우에는 Spanner를 선택하는 것이 좋습니다. 데이터베이스 서비스 선택에 대한 자세한 내용은 스토리지 옵션 선택을 참조하세요.
트랜잭션 및 인보이스
평가 및 리뷰와 마찬가지로 여러 저장소 메커니즘을 사용하여 트랜잭션 및 인보이스 또는 주문 세부정보를 유지할 수 있습니다. 트랜잭션은 ACID 시맨틱스, 특히 원자적으로 쓰기를 수행하는 기능을 지원하는 데이터베이스 시스템에 저장해야 합니다. Datastore, Cloud SQL, Spanner 모두 원자적 작업을 지원합니다. 대부분의 사용 사례에서 관계형 시스템이 트랜잭션에 적합합니다. 데이터가 하나의 쓰기에서 다음 쓰기로 일관되게 구조화되어 있기 때문입니다. 스토리지 시스템 선택은 SQL 또는 NoSQL 시스템을 사용하는 사용자의 편의성과 선택한 데이터베이스에 애플리케이션을 맞춤설정하는 기능에 크게 좌우됩니다.
인보이스 또한 NoSQL 또는 관계형 데이터베이스를 사용하여 저장할 수 있습니다. 다운스트림 사용 사례에 따라 시스템을 선택해야 합니다. 현대 상거래 워크로드에서 Datastore와 같은 NoSQL 문서 중심 데이터베이스는 인보이스의 전체 상태를 하나의 풍부한 객체로 저장할 수 있으므로 인보이스 또는 주문 세부정보를 유지하는 데 자주 사용됩니다. 보다 전통적인 상거래 워크로드에서는 Cloud SQL 또는 Spanner가 적합할 수도 있습니다.
트랜잭션과 인보이스에 사용되는 데이터베이스 서비스에 대한 자세한 내용은 스토리지 옵션 선택을 참조하세요.
환경이 전적으로 클라우드 네이티브인 경우 모든 트랜잭션 및 인보이스 데이터는 클라우드 인프라에 상주하게 됩니다. 반면 하이브리드 환경에서 작업하는 경우, 클라우드 환경과 온프레미스 환경 간 데이터를 동기화해야 합니다. 하이브리드 시나리오에서 트랜잭션 및 인보이스 데이터는 일반적으로 온프레미스 인프라에 상주합니다. 이 경우 커스텀 애플리케이션 조합, Pub/Sub 또는 데이터베이스 복제를 사용하여 백엔드 시스템을 클라우드 데이터 인프라와 동기화할 수 있습니다.
클릭 스트림 데이터
고객 트래픽에 대한 데이터는 Google 애널리틱스와 같은 애널리틱스 패키지를 통해 수집되는 경우가 많습니다. 그러나 이러한 탐색 데이터(클릭 스트림 데이터)는 실시간으로 수집할 수도 있습니다.
클릭 스트림 데이터를 캡처하는 방법에는 여러 가지가 있습니다. 그 중 하나는 Google Cloud를 통해 서버리스 픽셀 추적을 사용하는 것입니다. 클릭 스트림 추적을 위해 생성된 데이터세트는 크기가 매우 큰 편이며 종종 머신러닝 또는 예측 분석의 소스로 사용됩니다. 이러한 유형의 데이터는 일반적으로 Bigtable과 같은 NoSQL 와이드 칼럼 시스템에 저장됩니다. Bigtable은 대규모 데이터세트(최대 수백 페타바이트)를 지원하며 짧은 지연 시간과 높은 처리량을 제공하므로 이러한 사용 사례에 유용합니다.
제품 인벤토리
제품 사용 가능 여부에 대한 데이터는 전반적인 고객 경험에 매우 중요합니다. 인벤토리 데이터는 제품 SKU, 현재 인벤토리, 추가 인벤토리 예상 날짜가 포함된 데이터세트로 구성되는 경우가 많습니다. 그러나 이 데이터가 애플리케이션에서 자주 사용되는 방식을 고려할 때, 저장소 메커니즘은 인벤토리 수준을 정확하게 반영하기 위해 트랜잭션 및 원자적 작업을 지원해야 합니다. Datastore, Cloud SQL, Spanner 모두 원자적 작업을 지원합니다. 대부분의 사용 사례에서 관계형 시스템이 인벤토리 데이터에 적합합니다. 데이터가 일관되게 구조화되어 있기 때문입니다. 데이터베이스 서비스 선택에 대한 자세한 내용은 스토리지 옵션 선택을 참조하세요.
트랜잭션 데이터와 마찬가지로 환경이 전적으로 클라우드 기반인 경우 인벤토리 데이터는 클라우드 데이터 인프라에 상주하게 됩니다. 하이브리드 환경에서 작업하는 경우, 클라우드 환경과 온프레미스 환경 간 데이터를 동기화해야 합니다. 하이브리드 시나리오에서 인벤토리 데이터는 일반적으로 온프레미스 인프라에 상주합니다. 이 경우 커스텀 애플리케이션 조합, Pub/Sub 또는 데이터베이스 복제를 사용하여 백엔드 시스템을 클라우드 데이터 인프라와 동기화할 수 있습니다.
배포 아키텍처
Google Cloud를 사용할 경우 일반적으로 Cloud Run 또는 Google Kubernetes Engine을 사용하여 마이크로서비스를 배포합니다. Cloud Run은 웹 요청 또는 Pub/Sub 이벤트를 통해 호출 가능한 스테이트리스(Stateless) 컨테이너를 실행할 수 있게 해주는 관리형 컴퓨팅 플랫폼입니다. GKE는 오픈소스 컨테이너 조정 및 클러스터 관리 메커니즘인 Kubernetes에서 빌드되었습니다. 배포를 위한 플랫폼 선택은 필요한 유연성 수준과 애플리케이션 인프라의 복잡도에 따라 다릅니다.
자세한 내용은 컴퓨팅 옵션 선택을 참조하세요. 이 가이드에서는 두 가지 배포 옵션을 모두 설명합니다.
Cloud Run 사용
다음 다이어그램은 Cloud Run을 사용하는 마이크로서비스 배포 예시를 보여줍니다.
Cloud Run은 수신 트래픽을 기준으로 애플리케이션을 실행하는 인스턴스 수를 자동으로 확장 및 축소합니다. Cloud Run을 사용하여 마이크로서비스 아키텍처에서 애플리케이션을 배포할 때 애플리케이션은 컨테이너로 패키징되고 서비스로 배포됩니다. 서비스는 여러 컨테이너 인스턴스 간에 실행될 수 있고 서로 독립적으로 확장될 수 있습니다. Cloud Run은 부하 분산 리소스를 자동으로 프로비저닝하고 개별 마이크로서비스의 버전 관리 및 버전 간 트래픽 분할 기능을 제공합니다.
Cloud Run은 Knative에서 빌드되며, Cloud Run, Google Kubernetes Engine 클러스터, Cloud Run for Anthos 포함 온프레미스에서 완전 관리형 컨테이너를 실행하도록 선택할 수 있게 해줍니다. Cloud Run 서비스는 단일 리전 또는 GKE 클러스터 네임스페이스 내에서 배포되며, 중복성 및 장애 조치를 위해 리전의 여러 영역 간에 자동으로 복제됩니다. 단일 Google Cloud 프로젝트는 여러 리전 또는 GKE 클러스터에서 여러 서비스를 실행할 수 있습니다.
Cloud Run에서 개별적으로 데이터 스토리지 인프라를 프로비저닝하고 조작합니다. 예를 들어 Cloud Run의 애플리케이션은 관계형 데이터 스토리지를 위해 Cloud SQL 관리 PostgreSQL 데이터베이스에 연결할 수 있습니다.
다음 다이어그램은 멀티 리전 Cloud Run 배포에 대한 예시 아키텍처를 보여줍니다.
GKE 사용
다음 다이어그램은 GKE를 사용하여 마이크로 서비스를 배포하는 예를 보여줍니다.
GKE를 사용할 때 각각의 마이크로 서비스는 별도의 개발 및 배포 수명 주기를 가집니다. 각 마이크로 서비스는 Docker 컨테이너로 패키지화됩니다. 다음 방법 중 하나를 사용하여 이러한 컨테이너를 Kubernetes 포드 또는 서비스로 배포합니다.
GKE는 CPU 사용량에 따라 수평형 pod 자동 확장 처리를 사용하여 자동 확장 pod를 지원합니다. 또한 GKE 클러스터는 포화되거나 사용량이 적은 리소스를 기준으로 클러스터 크기를 자동으로 조절하는 GKE 클러스터 자동 확장 처리를 사용하여 자동 확장을 지원합니다.
GKE 클러스터는 지역별 리소스이므로 고가용성이 필요한 배포의 경우 여러 영역에 걸쳐 배포를 만들어야 합니다. 자세한 내용은 멀티 영역 GKE 클러스터 개요를 참조하세요.
전 세계 고객층에 제공해야 하는 배포의 경우 단일 프로젝트 내에 여러 GKE 클러스터를 지역마다 하나씩 배포하세요. 각 마이크로 서비스에 대한 데이터 저장소는 GKE 클러스터와 동일한 프로젝트에서 프로비저닝되고 운영됩니다.
다음 단계
- Cloud Run 안내 가이드
- 멀티 영역 GKE 클러스터
- Google Cloud에 대한 참조 아키텍처, 다이어그램, 가이드, 권장사항 살펴보기. Cloud 아키텍처 센터 살펴보세요.