이 문서에서는 모놀리식 플랫폼의 웹사이트를 Google Cloud에 있는 리팩토링된 컨테이너 기반 마이크로서비스 플랫폼으로 마이그레이션하는 과정의 개념을 간략히 설명합니다. 대규모 마이그레이션 이벤트 및 관련 위험을 피하기 위해 기능별로 마이그레이션이 수행됩니다. 이 문서는 모놀리식 플랫폼에서 호스팅되는 복잡한 웹사이트 현대화를 담당하는 IT 전문가를 대상으로 합니다. 이 문서는 Google Cloud 또는 Kubernetes에 대한 심층적인 지식이 없어도 이해할 수 있습니다.
이와 같은 마이그레이션의 목표는 사이트의 개별 기능을 모놀리식 플랫폼보다 더 쉽게 관리하고 업데이트할 수 있는, 더 민첩하고 확장 가능한 환경을 제공하는 것입니다. 이러한 환경에서 이전된 각 기능을 실행하면 기능이 더 빠르게 개선되고 사용자에게 계속 가치를 제공할 수 있습니다.
이 문서에서는 전자상거래 웹사이트를 작업 부하 예로 사용합니다. 많은 전자상거래 웹사이트는 모놀로식 독점 플랫폼으로 구축되어 있으므로 이 문서에 설명된 이전 대상으로 적절합니다. 하지만 이 문서에 설명된 원칙은 다양한 작업 부하에 적용할 수 있습니다. 사용 중인 시스템과 해당 제약조건이 이 문서에 설명된 내용과 매우 유사하다면 여기에 설명된 원칙을 적용하면 유용합니다. 예를 들어 호텔 또는 렌터카를 예약하는 웹사이트도 이러한 이전 대상으로 적절합니다.
Google Cloud로 마이그레이션: 시작하기 문서에 설명된 것처럼 클라우드로 마이그레이션하는 패턴에는 크게 리프트 앤 시프트, 개선 및 이동, 전면 교체와 같은 세 가지 패턴이 있습니다. 이 문서에서는 애플리케이션 전체가 아닌 애플리케이션의 각 기능에 패턴이 점진적으로 적용되는 전면 교체 패턴이라는 특정 패턴을 설명합니다.
또한 이 문서에서는 이러한 이전 패턴 외에 두 가지 하이브리드 패턴도 살펴봅니다. 실제 이전 과정에서는 클라우드에 일부 기능이 있고 일부 기능은 여전히 온프레미스에 있는 하이브리드 아키텍처가 애플리케이션에 적용됩니다. 이전이 완료되면 전체 애플리케이션이 클라우드에서 호스팅되지만 온프레미스에 남아 있는 백엔드 서비스와 여전히 상호작용합니다.
용어
- 애플리케이션
- 이 문서에서 애플리케이션은 최종 사용자가 단일 단위로 인식하고 여러 기능이 있는 완전한 소프트웨어 시스템을 말합니다. 애플리케이션의 예로 전자상거래 웹사이트가 있습니다. 애플리케이션으로 수행할 수 있는 모든 작업은 해당 애플리케이션의 특정 기능으로 수행할 수 있습니다.
- 기능
- 애플리케이션의 기능 단위입니다. 애플리케이션에 핵심적인 사용자용 기능(예: 전자상거래 웹사이트의 장바구니), 애플리케이션에 필요한 사용자용 기능(예: 로그인) 또는 애플리케이션 내부 기능(예: 전자상거래 웹사이트의 재고 관리) 등이 있습니다.
- 서비스
- 애플리케이션의 독립형 구성요소입니다. 이 문서에서 애플리케이션은 최종 사용자에게 보이지 않는 여러 서비스로 구성되어 있습니다. 예를 들어 웹사이트에서 사용하는 데이터베이스는 서비스입니다.
- 모놀리식 애플리케이션
- 단일 배포 가능 단위로 빌드된 애플리케이션입니다. 간단히 모놀리식이라고도 합니다. 예를 들어 단일 자바 EE 애플리케이션 또는 단일 .NET 웹 애플리케이션이 있습니다. 모놀리식 애플리케이션은 데이터베이스 및 클라이언트 측 사용자 인터페이스와 연결된 경우가 많습니다.
- 마이크로서비스
- 애플리케이션 기능을 수용하도록 빌드된 단일 서비스입니다. 마이크로서비스 패턴에서 애플리케이션은 각각 특정 목표를 가진 여러 서비스의 집합체입니다. 예를 들어 고객의 장바구니를 처리하는 서비스, 결제 서비스를 처리하는 데 사용되는 서비스, 백엔드 애플리케이션과 상호작용하여 재고를 확인하는 서비스가 있을 수 있습니다. 이러한 마이크로서비스는 느슨하게 결합되어야 하며 잘 정의된 API를 통해 상호작용해야 합니다. 서로 다른 언어와 프레임워크로 작성될 수 있으며 수명 주기도 서로 다를 수 있습니다.
- 하이브리드 아키텍처
- 자체 데이터 센터에서 호스팅되는 비공개 리소스와 함께 퍼블릭 클라우드 제공업체(예: Google Cloud)를 사용하는 아키텍처입니다. 하이브리드 아키텍처를 구현하는 이유와 방법은 다양합니다. 자세한 내용은 하이브리드 및 멀티 클라우드 패턴과 관행 문서를 참조하세요.
- 스테이트리스(Stateless) 및 스테이트풀(Stateful) 서비스
- 서비스가 직접 데이터 스토리지를 관리하는지 여부를 알려줍니다. 이 문서에서는 Twelve-Factor App 방법론과 동일한 스테이트리스(Stateless) 및 스테이트풀(Stateful) 정의를 사용합니다. 어떠한 데이터에도 의존하지 않고 작동하는 서비스를 스테이트리스(Stateless) 서비스라고 합니다. 스테이트풀(Stateful) 서비스는 그 반대입니다. 예를 들어 고객의 장바구니를 처리하는 서비스는 장바구니를 저장하고 검색해야 하기 때문에 스테이트풀(Stateful) 서비스입니다. 백엔드 시스템에 있는 항목의 가용성을 확인하는 서비스는 스테이트리스(Stateless) 서비스입니다. 데이터(상태)를 저장하는 것이 서비스가 아닌 백엔드 시스템이기 때문입니다.
마이크로서비스로 전환해야 하는 이유
애플리케이션을 마이크로서비스로 분할하면 다음과 같은 이점이 있습니다. 마이크로서비스가 느슨하게 결합된 점과 관련된 이점이 대부분입니다.
- 마이크로서비스는 독립적으로 테스트하고 배포할 수 있습니다. 배포 단위가 작을수록 배포가 쉬워집니다.
- 다양한 언어와 프레임워크로 구현할 수 있습니다. 각 마이크로서비스마다 특정 사용 사례에 가장 적합한 기술을 자유롭게 선택할 수 있습니다.
- 여러 팀이 관리할 수 있습니다. 마이크로서비스 간에 경계가 있어 하나 또는 여러 개의 마이크로서비스에 전담 팀 하나를 배정하기가 더 쉽습니다.
- 마이크로서비스로 전환하면 팀 간 종속성이 느슨해집니다. 각 팀은 사용 중인 마이크로서비스의 API만 신경 쓰면 됩니다. 마이크로서비스의 구현 방식, 출시 주기 등에 대해 생각할 필요가 없습니다.
- 오류에 대비한 설계를 더 쉽게 수행할 수 있습니다. 서비스 간에 명확한 경계를 두면 서비스가 중지된 경우에 해야 할 일을 더 쉽게 판단할 수 있습니다.
마이크로서비스를 모놀리식과 비교하면 몇 가지 단점이 있습니다.
- 마이크로서비스 기반 앱에는 상호작용 방식이 대체로 불분명한 여러 서비스가 얽혀 있기 때문에 시스템의 전반적인 복잡성이 증가하는 경향이 있습니다.
- 모놀리식의 내부 기능과 달리 마이크로서비스는 네트워크를 통해 통신합니다. 경우에 따라 이는 보안 문제로 볼 수 있습니다. Istio는 마이크로서비스 간의 트래픽을 자동으로 암호화하여 이 문제를 해결합니다.
- 서비스 간 지연 시간 때문에 모놀리식 접근법과 동일한 수준의 성능을 달성하기가 어려울 수 있습니다.
- 시스템의 동작은 단일 서비스로 인해 발생하는 것이 아니라 많은 서비스와 상호작용으로 인해 발생합니다. 따라서 시스템이 프로덕션 환경에서 어떻게 작동하는지(관찰 기능) 이해하는 것이 더 어렵습니다. 이 문제도 Istio로 해결할 수 있습니다.
Google처럼 이미 수년간 마이크로서비스를 사용해온 회사도 있지만 마이크로서비스의 공식적인 개념(및 서비스 지향 아키텍처(SOA)와의 관계)은 제임스 루이스, 마틴 파울러, 샘 뉴먼이 공동 집필한 마이크로서비스 문서에 나와 있습니다.
이전 프로세스 개요
이 문서에서 설명하는 마이그레이션 프로세스는 대규모 프로젝트이기 때문에 완료하는 데 몇 달이 걸릴 수 있습니다. 이 섹션에서는 모놀리식 온프레미스 애플리케이션을 Google Cloud에서 완벽하게 호스팅되고 마이크로서비스로 빌드된 애플리케이션으로 마이그레이션하는 경로를 설명합니다.
출발점: 모놀리식 온프레미스 앱
이 문서에서는 사용자가 현재 온프레미스에서 모놀리식 애플리케이션을 실행 중이라고 가정합니다. 다음은 사용자의 현재 아키텍처와 유사한 아키텍처의 대략적인 다이어그램입니다.
이 다이어그램은 현재 시스템을 완전히 보여주는 것은 아닙니다. 이와 같은 아키텍처에서 일반적으로 사용되는 기술 중 일부는 다음과 같습니다.
- 관계형 데이터베이스(예: Oracle® 데이터베이스 또는 SAP HANA)
- 전자상거래 플랫폼(예: Oracle ATG 또는 SAP Hybris)
- Apache Solr 또는 기타 검색엔진
종료점: Google Cloud의 마이크로서비스 기반 앱
여기에 설명된 마이그레이션 프로세스는 온프레미스 모놀리식 아키텍처를 Google Cloud에서 실행되는 마이크로서비스 기반 아키텍처로 전환하는 데 사용됩니다. 대상 아키텍처는 다음과 같습니다.
대상 아키텍처는 Google Kubernetes Engine(GKE)에서 마이크로서비스를 실행합니다. Kubernetes는 컨테이너를 관리, 호스팅, 확장, 배포하는 플랫폼입니다. 컨테이너는 이식 가능한 방식으로 코드를 패키징하고 실행하는 데 사용됩니다. 이는 각 마이크로서비스가 자체 컨테이너에서 실행될 수 있는 마이크로서비스 패턴에 매우 적합합니다. 마이크로서비스는 Cloud Interconnect 또는 Cloud VPN으로 만든 비공개 네트워크 연결을 통해 백엔드 시스템을 호출할 수 있습니다. 또는 Apigee를 사용하여 백엔드 서비스를 노출하고 이에 대한 액세스를 보호할 수 있습니다. 이러한 제품과 적합한 제품을 선택하는 방법에 대한 자세한 내용은 이 문서의 뒷부분에 나오는 Apigee, Cloud VPN, Cloud Interconnect에 설명되어 있습니다.
또한 마이크로서비스는 필요에 따라 다른 여러 Google Cloud 제품과 상호작용할 수 있습니다. Cloud Storage 및 Cloud SQL은 전자상거래 애플리케이션에 가장 일반적인 Google Cloud 제품입니다. Pub/Sub는 비동기 작업에서 서로 다른 마이크로서비스 간의 메시지 버스로 사용할 수 있습니다.
애플리케이션을 인터넷에 노출하는 방법은 두 가지가 있습니다. 이미지와 같은 애셋의 경우 Google Cloud 부하 분산기를 통해 직접 노출하고, 공개 API의 경우 필요에 따라 Apigee를 통해 노출할 수 있습니다.
다음은 대상 아키텍처에서 사용할 수 있는 제품이 나와 있는 표입니다. 모든 제품이 필수는 아니며 정확한 사용 사례에 따라 용도가 달라집니다.
네트워킹
| Google Cloud 제품 | 용도 | 참고 |
|---|---|---|
| Virtual Private Cloud | VPC는 리소스(예: GKE 클러스터)가 있는 소프트웨어 정의 비공개 네트워크입니다. VPC에는 방화벽 및 라우팅과 같은 기능이 포함되어 있습니다. VPC는 전역적으로 사용 가능하며 Google 소유의 광섬유 네트워크를 기반으로 전 세계에 비공개 연결을 허용합니다. | Cloud VPC는 이 아키텍처에서 필수입니다. |
| Cloud Interconnect | Cloud Interconnect를 활용하면 가용성이 높고 지연 시간이 짧은 연결을 통해 온프레미스 네트워크를 Google 네트워크로 확장할 수 있습니다. Dedicated Interconnect를 사용하여 Google에 직접 연결하거나 Partner Interconnect를 사용하여 지원되는 서비스 제공업체를 통해 Google에 연결할 수 있습니다. | 전자상거래 웹사이트는 창고 관리 시스템이나 청구 시스템과 같은 온프레미스의 백엔드 서비스를 호출해야 할 수 있습니다. Cloud Interconnect는 이를 위한 솔루션 중 하나입니다. |
| Cloud VPN | Cloud VPN은 IPsec VPN 터널을 통해 온프레미스 네트워크를 Google 네트워크로 안전하게 확장합니다. 트래픽은 암호화되어 공개 인터넷을 통해 두 네트워크를 오갑니다. Cloud VPN은 소규모 데이터 연결에 유용합니다. | 전자상거래 웹사이트는 창고 관리 시스템이나 청구 시스템과 같은 온프레미스의 백엔드 서비스를 호출해야 할 수 있습니다. Cloud VPN은 이를 위한 솔루션 중 하나입니다. |
| Cloud Load Balancing | Cloud Load Balancing은 Google의 관리형 부하 분산 솔루션입니다. L4(TCP/UDP) 및 L7(HTTP) 부하 분산을 모두 지원합니다. 또한 SSL(HTTPS) 종료 엔드포인트 역할을 할 수 있습니다. Google Cloud 부하 분산기를 만들면 단일 anycast IP가 제공됩니다. 네트워크 지연 시간 단축을 위해 이 IP에 액세스하려는 모든 사용자는 Google의 프리미엄 등급 네트워크를 통해 가장 가까운 Google 지점으로 자동 라우팅됩니다. | Cloud Load Balancing은 이 아키텍처에서 필수입니다. |
| Cloud CDN | Cloud CDN(Content Delivery Network)은 Google의 전 세계에 분산된 에지 접속 지점을 사용하여 사용자와 가까운 위치에 HTTP(S) 부하 분산 콘텐츠를 캐시합니다. Google 네트워크 에지에서 콘텐츠를 캐시하면 콘텐츠가 사용자에게 더 빨리 전송되며 서버 사용 비용이 감소됩니다. | Cloud CDN은 이 시나리오에서 필수는 아니지만 정적 콘텐츠에 특히 권장됩니다. |
플랫폼
| Google Cloud 제품 | 용도 | 참고 |
|---|---|---|
| Google Kubernetes Engine(GKE) | GKE는 컨테이너 애플리케이션을 배포하기 위해 Google이 관리하는 Kubernetes 제품입니다. GKE는 오픈소스 Kubernetes와 완벽하게 호환되며 고가용성을 위한 리전 클러스터, 비공개 클러스터, 수직형 pod 자동 확장, 클러스터 자동 확장, GPU, 선점형 노드와 같은 여러 고급 기능을 제공합니다. | GKE는 이 아키텍처에서 필수입니다. |
| Istio | Istio는 마이크로서비스를 보호, 연결, 모니터링하는 일관된 방법을 제공하여 마이크로서비스 배포 관리의 복잡성을 줄입니다. | Istio는 이 아키텍처에서 필수는 아니지만 향상된 모니터링, 트래픽 암호화, 라우팅과 같은 유용한 기능은 물론 애플리케이션의 탄력성 테스트를 위한 결함 주입 기능을 제공합니다. |
| Apigee | Apigee는 관리형 API 게이트웨이입니다. Apigee를 사용하면 API를 안전하게 설계, 게시, 모니터링, 수익화할 수 있습니다. 공개 API와 비공개 API를 모두 노출할 때 Apigee를 사용할 수 있습니다. 마이크로서비스 아키텍처에서 공개 API는 Google Cloud에서 호스팅되는 반면 백엔드 온프레미스 시스템은 Google Cloud의 마이크로서비스에서만 사용되는 비공개 API로 노출될 수 있습니다. |
Apigee는 이 아키텍처에서 필수는 아니지만 사이트의 모든 콘텐츠가 공개 API를 통해 제공되는 것이 좋습니다. Apigee와 같은 API 게이트웨이는 할당량, 버전 관리, 인증과 같은 여러 API 관리 기능을 제공합니다. |
| Pub/Sub | Pub/Sub는 메시징 및 스트리밍 시스템입니다. 이 아키텍처에서 사용할 경우 마이크로서비스 간 메시지 버스 역할을 하며 마이크로서비스 간의 비동기 워크플로를 허용합니다. | Pub/Sub는 필수는 아니지만 게시자/구독자 패턴으로 확장 문제를 완화할 수 있습니다. |
스토리지
| Google Cloud 제품 | 용도 | 참고 |
|---|---|---|
| Cloud Storage | Cloud Storage는 통합 객체 스토리지 API를 제공합니다. 웹사이트 콘텐츠 제공, 데이터 백업 및 보관처리, 큰 객체 배포와 같은 여러 사용 사례에 적합합니다. 전자상거래 웹사이트의 경우 Cloud Storage의 주 용도는 제품 이미지 및 동영상과 같은 정적 애셋을 저장하고 제공하는 것입니다. | 완벽한 확장성을 제공하는 Cloud Storage와 Cloud CDN은 이 문서에서 설명하는 마이크로서비스 아키텍처에 함께 사용하기 적합하므로 권장됩니다. |
| Firestore | Firestore는 빠른 완전 관리형 NoSQL 문서 데이터베이스입니다. | Firestore는 이 아키텍처에서 필수는 아니지만 전자상거래 웹사이트의 여러 일반적인 사용 사례에 매우 적합합니다. 예를 들어 사용자 장바구니와 사용자 메타데이터를 저장하는 데 사용할 수 있습니다. |
| Cloud SQL | Cloud SQL은 MySQL 및 PostgreSQL용 제품으로, Google에서 관리합니다. 이러한 관계형 데이터베이스는 다양한 용도로 사용됩니다. | Cloud SQL은 이 시나리오에서 필수는 아니지만 전자상거래 웹사이트의 여러 일반적인 사용 사례에 매우 적합합니다. 예를 들어 Cloud SQL을 사용하여 주문을 저장하면 집계 및 계산이 쉬워집니다. |
| Cloud Spanner | Spanner는 전역적으로 사용 가능하고 수평적으로 확장 가능하며 strong consistency를 가지는 관계형 데이터베이스입니다. 99.999%의 업타임(멀티 리전 인스턴스의 경우)에 대한 SLA를 체결하면 비즈니스에 중요한 데이터의 매우 높은 가용성이 보장됩니다. | Spanner는 이 시나리오에서 필수는 아닙니다. Spanner는 전역적으로 트랜잭션 일관성을 제공하는 관계형 데이터베이스이기 때문에 전 세계 고객을 대상으로 하는 전자상거래 웹사이트에 매우 적합합니다. |
| Memorystore | Memorystore for Redis는 인메모리 키-값 데이터베이스인 Redis의 관리형 버전입니다. 지연 시간이 짧은 데이터베이스인 Redis는 자주 액세스되는 데이터에 적합합니다. | Memorystore는 이 시나리오에서 필수는 아니지만 사용자 세션 정보 저장 및 애플리케이션 캐시 제공과 같은 웹사이트의 여러 일반적인 사용 사례에 매우 적합합니다. |
이 목록은 전자상거래 아키텍처에서 가장 많이 사용되는 제품을 나타냅니다. 물론 다른 Google Cloud 제품도 사용할 수 있습니다. 또한 Cloud Bigtable, BigQuery, Vertex A와 같은 제품을 활용하여 데이터에서 인텔리전스를 수집하는 구성요소를 추가하면 이 아키텍처가 자연스럽게 진화한다는 사실도 고려해야 합니다.
현재 기술 중 여전히 관련성이 있거나 이동 비용이 너무 높은 일부 기술은 이 대상 아키텍처에서 계속 사용할 수도 있습니다. 다음은 Google Cloud에서 일반적인 전자상거래 기술을 실행하는 방법에 대한 몇 가지 예시입니다.
- Google Cloud 파트너는 Oracle 워크로드를 관리하여 해당 워크로드와 Google Cloud 인프라 사이의 지연 시간을 밀리초 미만으로 유지할 수 있습니다. 또한 기존 라이선스를 재사용할 수 있습니다.
- SAP와 Google Cloud 간의 파트너십 덕분에 Google Cloud에서 HANA 및 Hybris를 비롯한 다양한 SAP 워크로드를 실행할 수 있습니다.
- GKE에서 Apache Solr를 실행하거나 Google Cloud Marketplace에서 제공되는 일부 Solr 솔루션을 사용할 수 있습니다.
- Cloud Marketplace 솔루션 사용과 같이 GKE에서 Elasticsearch를 실행하거나 Google Cloud에 빌드된 Elastic을 통해 관리형 서비스를 사용할 수 있습니다.
Apigee, Cloud VPN, Cloud Interconnect
이 프로젝트 초기의 가장 중요한 결정 사항 중 하나는 GKE에서 호스팅되는 새로운 마이크로서비스와 온프레미스에 있는 기존 시스템 간의 통신을 처리하는 방법입니다. API 기반 통신과 비공개 연결을 기반으로 한 통신이라는 두 가지 주요 솔루션이 있으며, 이 둘은 공존할 수 있습니다.
API 기반 솔루션에서는 Apigee와 같은 API 관리 솔루션을 두 환경 간의 프록시로 사용합니다. 따라서 기존 시스템에서 노출시킬 부분과 노출 방법을 정밀하게 제어할 수 있습니다. 또한 API 사용자에게 영향을 주지 않으면서 API 구현(즉, 기존 서비스에서 마이크로서비스로 이동)을 원활하게 리팩토링할 수 있습니다. 다음 다이어그램은 Apigee, 온프레미스 시스템, Google Cloud 시스템 간의 상호작용을 보여줍니다.
Apigee를 사용한 Kubernetes API의 대규모 배포 패턴과 Apigee eBook API로 ESB 아키텍처 능가하기를 참조하면 이 설계를 이해할 수 있습니다.
비공개 연결을 기반으로 하는 솔루션에서 비공개 네트워크 연결을 사용하여 Google Cloud 환경과 온프레미스 환경을 연결합니다. 마이크로서비스는 이 연결을 통해 기존 시스템과 통신합니다. Cloud VPN을 사용하는 IPSec 기반 VPN 터널을 설정할 수 있습니다. 더 많은 대역폭이 필요한 경우 가용성이 높고 지연 시간이 짧은 연결을 제공하는 Cloud Interconnect가 적합합니다. 다양한 옵션에 대한 개요는 상호 연결 유형 선택을 참조하세요.
다음 다이어그램은 Cloud VPN 또는 Cloud Interconnect를 통한 온프레미스 시스템과 Google Cloud 시스템 간의 상호작용을 보여줍니다.
API 기반 솔루션은 애플리케이션 팀이 구현합니다. 이 솔루션은 비공개 연결을 기반으로 하는 솔루션보다 기존 애플리케이션과의 통합이 프로젝트 초기부터 더 많이 필요합니다. 그러나 API 기반 솔루션은 장기적으로 더 많은 관리 옵션을 제공합니다. Cloud VPN 또는 Cloud Interconnect를 기반으로 하는 솔루션은 네트워킹 팀이 구현하며 초기에 기존 애플리케이션과의 통합이 덜 필요합니다. 그러나 장기적으로 부가 가치를 제공하지는 않습니다.
마이그레이션 프로세스
이 섹션에서는 새로운 아키텍처로 이전할 때 따라야 할 대략적인 단계를 간략히 설명합니다.
기본 요건
첫 번째 마이크로서비스를 GKE로 이동하기 전에 작업을 수행할 Google Cloud 환경을 준비해야 합니다. GKE에서 첫 번째 마이크로서비스를 프로덕션 단계로 이동하기 전에 다음을 해결하세요.
- Google Cloud 리소스를 호스팅할 글로벌 환경인 Google Cloud 조직을 설정합니다. 이 단계를 수행하는 동안 조직의 직원이 Google 제품을 사용하는 데 필요한 계정인 Google ID도 구성합니다. 자세한 내용은 Google Cloud에 대한 ID 온보딩 방법 결정을 참조하세요.
- Google Cloud 리소스를 제어할 수 있도록 Google Cloud 정책을 설계합니다. 엔터프라이즈 고객을 위한 정책 설계 문서를 참고하면 도움이 될 것입니다.
- 코드형 인프라(IaC)를 사용하여 GKE 클러스터를 포함한 Google Cloud 리소스를 배포하는 계획을 세웁니다. 이렇게 하면 표준화되고 재현 가능하며 감사 가능한 환경을 구현할 수 있습니다. 이때 Cloud Deployment Manager 또는 Terraform을 사용하는 것이 좋습니다.
- 다양한 GKE 기능을 연구하고 필요에 따라 조정합니다. 비즈니스에 중요한 애플리케이션의 경우 일부 기본값을 변경하고 클러스터를 강화하는 것이 좋습니다. 클러스터 보안 강화에는 이를 수행하는 방법에 대한 정보가 포함되어 있습니다.
- Kubernetes용 지속적 통합/지속적 배포(CI/CD) 도구를 제작합니다. Cloud Build를 사용하여 컨테이너 이미지를 빌드하고, Container Registry를 사용하여 컨테이너 이미지를 저장하고 취약점을 감지할 수 있습니다. 이러한 제품을 기존 CI/CD 도구와 결합할 수도 있습니다. 이 작업을 활용하여 컨테이너 빌드 및 작동 권장사항을 구현하세요. 프로젝트 초기에 이 작업을 수행하면 프로덕션 단계에서 문제가 발생하지 않습니다.
- 선택한 옵션에 따라 Apigee 계정을 설정하거나 Google Cloud와 Cloud VPN 또는 Cloud Interconnect를 사용하는 온프레미스 데이터 센터 간에 비공개 연결을 설정합니다.
단계별로 마이그레이션
전자상거래 웹사이트의 기능을 하나씩 새로운 환경으로 이전하고, 필요한 경우 마이크로서비스를 만들어야 합니다. 이러한 마이크로서비스는 필요 시 이전 시스템으로 콜백할 수 있습니다.
이 접근법은 주요 이전 및 리팩토링 프로젝트를 여러 개의 작은 프로젝트로 변환하는 것과 같습니다. 이렇게 진행하면 두 가지 이점이 있습니다.
- 소규모의 각 프로젝트는 전체 이전 프로젝트보다 쉽게 제한되고 추론하기 쉽습니다. 전체 웹사이트를 한 번에 이전하려면 여러 팀이 시스템, 제약조건, 사용 가능한 웹사이트에 의존하는 서드 파티 시스템 등의 상호작용에 대해 더 많이 이해해야 합니다. 따라서 오류 위험이 증가합니다.
- 소규모 프로젝트가 많이 있으면 유연성이 있습니다. 소규모 팀이 하나 있다면 해당 팀이 과도한 부담 없이 이러한 프로젝트를 하나씩 처리할 수 있습니다. 여러 팀이 있다면 일부 작업을 동시에 처리하고 한 번에 여러 이전 작업을 진행할 수 있습니다.
이 프로젝트 단계에서 가장 중요한 결정 사항 중 하나는 바로 이전할 기능과 이전 시기입니다. 이 결정을 내릴 때는 기능 간의 종속 관계를 고려해야 합니다. 제대로 작동하기 위해 다른 기능에 크게 의존하는 기능도 있고, 상당히 독립적인 기능도 있습니다. 기능의 종속성이 낮을수록 이전이 쉬워집니다. 이전할 기능을 결정할 때 고려해야 할 다른 요소와 종속성 문제는 먼저 이전해야 할 기능 섹션에서 자세히 설명합니다.
예: 장바구니 이전
이 섹션에서는 이전 프로세스를 설명하기 위해 전자상거래 웹사이트의 장바구니라는 단일 기능의 이전을 수행합니다.
이 기능의 종속성을 이해하려면 일반적인 사용 경로와 모놀리식 애플리케이션에서 이 기능을 구현하는 방법을 고려하세요.
- 사용자가 웹사이트를 둘러보면서 관심 있는 항목을 찾습니다.
- 사용자가 내 장바구니에 추가를 클릭합니다. 이 작업은 사용자 브라우저에서 장바구니 기능에 대한 API 호출을 트리거할 수 있습니다. 프런트엔드가 장바구니에서 작동하는 것이 첫 번째 종속성입니다.
- 장바구니 기능은 호출 수신 시 항목의 재고가 있는지 여부를 확인합니다. 이 이벤트는 장바구니 기능에서 재고를 처리하는 시스템에 대한 API 호출을 트리거합니다. 장바구니가 재고 하위 시스템에 의존한다는 것이 두 번째 종속성입니다.
- 항목의 재고가 있으면 장바구니 기능은 '사용자 A가 항목 X의 인스턴스 1개를 장바구니에 담음'과 같은 정보를 저장합니다. 장바구니에서 이 정보를 저장하려면 데이터베이스가 필요하다는 것이 세 번째 종속성입니다.
- 사용자가 체크아웃하고 결제 프로세스를 진행하면 결제 하위 시스템이 합계를 계산하기 위해 장바구니를 쿼리합니다. 결제가 완료되면 결제 하위 시스템이 장바구니 기능에 장바구니를 비우라고 알려줍니다. 결제 하위 시스템에서 장바구니를 쿼리한다는 것이 네 번째 종속성입니다.
요약하면, 장바구니 기능은 프런트엔드 및 결제 하위 시스템에 의해 호출되며 데이터베이스 및 재고 하위 시스템을 쿼리합니다.
문서 데이터베이스는 장바구니를 저장하는 데 매우 적합합니다. 장바구니 데이터를 저장할 때는 강력한 관계형 데이터베이스가 필요하지 않으며, 장바구니는 사용자 ID로 손쉽게 색인화할 수 있습니다. Firestore는 관리형 서버리스 NoSQL 문서 데이터베이스이며, 특히 이러한 사용 사례에 매우 적합하므로 대상 아키텍처에 권장되는 데이터 저장소입니다.
장바구니 데이터는 여러 가지 방법으로 이전할 수 있습니다. (이 내용은 뒷부분에 나오는 데이터 이전 전략 섹션에서 자세히 설명합니다.) 이 문서에서는 예약된 유지보수 방법(뒷부분에서 설명)이 적절하다고 간주합니다. 이러한 조건에서 다음과 같은 대략적인 단계를 수행하여 장바구니 기능을 마이그레이션할 수 있습니다.
- 장바구니 API를 구현하는 새로운 마이크로서비스를 만듭니다. 장바구니를 저장하려면 Firestore를 사용합니다. 이 새로운 마이크로서비스가 재고 하위 시스템을 호출할 수 있는지 확인하세요.
- 기존의 장바구니 하위 시스템에서 장바구니를 추출하고 Firestore에 기록하는 스크립트를 만듭니다. 필요한 만큼 여러 번 재실행 가능하고 마지막 실행 이후 변경된 장바구니만 복사하도록 스크립트를 작성합니다.
- 동일한 작업을 수행하지만 반대로 Firestore에서 기존 시스템으로 장바구니를 복사하는 스크립트를 만듭니다. 마이그레이션을 롤백해야 하는 경우에만 이 스크립트를 사용합니다.
- Apigee를 사용하여 장바구니 API를 노출합니다.
- 프런트엔드 및 결제 하위 시스템에 대한 수정사항을 준비하고 테스트하여 새 장바구니 마이크로서비스를 호출할 수 있도록 합니다.
- 2단계에서 작성한 데이터 이전 스크립트를 실행합니다.
- 웹사이트를 유지보수 모드로 설정합니다.
- 데이터 마이그레이션 스크립트를 재실행합니다.
- 5단계의 수정사항을 기존 프로덕션 시스템에 배포합니다.
- 웹사이트의 유지보수 모드를 중지합니다.
이제 웹사이트의 장바구니 기능이 Google Cloud에서 호스팅되는 마이크로서비스가 되었습니다. 이 프로세스에서 가장 힘든 단계는 아마 5단계일 것입니다. 기존 시스템을 수정해야 하기 때문입니다. 하지만 더 많은 기능을 마이크로서비스로 마이그레이션할수록 점점 더 많은 종속 항목이 마이크로서비스가 되므로 이 단계가 더 수월해집니다. 따라서 이러한 기능은 모놀리식 애플리케이션에 있을 때보다 느슨하게 결합되어 있으며 수정 및 배포가 더 쉽습니다.
다른 마이그레이션 방법으로는 새로운 마이크로서비스가 원래 장바구니 데이터베이스로 콜백한 후 데이터를 Firestore로 마이그레이션하도록 할 수 있습니다. 이러한 두 마이그레이션 모델 중에 선택할 때는 마이크로서비스와 원래 데이터베이스 간의 지연 시간, 스키마 리팩토링의 복잡성, 채택하려는 데이터 마이그레이션 전략을 고려해야 합니다.
먼저 이전해야 하는 기능
이 섹션에서는 먼저 이전해야 하는 기능을 파악하도록 도와줍니다(초기 이전 작업). 복잡한 이전 과정의 내재된 위험을 줄이려면 항상 분할 이전 방법을 사용하는 것이 좋습니다.
이전을 계획할 때는 누구나 쉽게 이전할 수 있는 기능부터 시작하려고 합니다. 이렇게 하면 빠르게 실행할 수 있지만 팀에게 가장 적절한 학습 경험은 아닐 수도 있습니다. 이전을 바로 진행하는 대신 모든 기능을 평가하고 이전 계획을 세우는 데 시간을 할애해야 합니다.
다음과 같은 평가 영역 목록을 기능별 분석을 위한 프레임워크로 사용할 수 있습니다.
- 비즈니스 프로세스
- 설계 및 개발
- 운영
- 인력과 팀
비즈니스 프로세스 평가
이전 팀은 초기 이전 작업 중에 프로세스를 학습하고 개발하며 이 과정에서 실수가 있을 수도 있습니다. 그렇기 때문에 초기 이전 작업은 주요 비즈니스에 영향을 주지 않도록 비즈니스에 중요한 시스템을 포함해서는 안 되지만 팀에게 학습 기회를 부여할 수 있도록 중요한 사용 사례를 대표해야 합니다. 비즈니스 프로세스를 평가할 때는 개발 프로세스뿐만 아니라 규정 준수 및 라이선스와 관련된 프로세스도 고려합니다.
설계 및 개발 평가
설계 및 개발의 관점에서 이상적인 초기 이전 작업은 다른 기능 및 데이터에 대한 종속성이 가장 적고, 필요한 경우 가장 쉽게 리팩토링할 수 있는 작업입니다.
종속성과 리팩토링에 필요한 작업을 고려하여 각 기능을 분석해야 합니다. 각 기능의 종속성 분석은 다음을 참조하세요.
- 종속성 유형 - 데이터 또는 다른 기능의 종속성
- 종속성 규모 - 이 기능의 종속성 변경에 영향을 받을 수 있는 기능 수
데이터 종속성이 큰 기능을 이전하는 작업은 일반적으로 다음과 같은 이유로 인해 중대한 작업으로 간주됩니다.
- 기능을 먼저 이전하고 관련 데이터를 나중에 이전하기로 결정한 경우 초기 이전 작업 후에 제작자, 소비자, Datastore 간의 증가한 네트워크 지연 시간을 고려해야 합니다.
- 일시적으로 여러 위치에서 데이터를 읽고 쓸 수도 있기 때문에 이전 단계에서 데이터 무결성 및 동기화 문제가 발생합니다.
또한 각 기능에 필요한 리팩토링의 양도 평가해야 합니다. 잠재적 리팩토링은 현재 기능 설계와 향후 방향에 따라 달라집니다. 해당 작업이 관련 비즈니스 프로세스에 미치는 영향을 추측해 보세요.
이 평가 과정에서 생각해 보아야 할 가장 중요한 질문은 다음과 같습니다.
- 이 기능은 어떤 데이터를 사용하나요?
- 이 기능은 데이터를 얼마나 사용하나요?
- 이 기능이 제대로 작동하려면 다른 기능이 필요한가요?
- 이 기능을 변경할 경우 영향을 받는 다른 기능은 얼마나 되나요?
- 이 기능에 대한 네트워킹 또는 연결 요구 사항이 있나요?
- 이 기능의 현재 설계는 리팩토링에 어떤 영향을 주나요?
운영 평가
운영 관점에서 단순 이전 기간 동안 발생하는 다운타임을 감당할 수 있는 기능도 고려해야 합니다. 다운타임을 최소화해야 하는 경우 고가용성이 필요한 기능을 이전할 때 추가 작업이 필요할 수 있습니다.
인력과 팀 평가
초기 이전 작업을 진행하는 프로세스가 잘 정립되어 있는 팀을 선택하는 것이 좋습니다. 또한 팀은 이전 여정의 첫 단추를 잘 끼우겠다는 의지가 있어야 하고, 새로운 과제가 생길 경우 해결책을 찾아야 한다는 사실도 이해해야 합니다.
초기 이전 작업 선택
이 평가 프레임워크에 따르면 초기 이전 작업으로 이상적인 작업은 의미가 있을 만큼 적당히 어려우면서도 실패 위험은 최소화할 수 있는 정도로 간단한 작업입니다. 또한 초기 이전 프로세스는 다음과 같아야 합니다.
- 기능 자체와 관련 비즈니스 프로세스를 모두 고려할 때 리팩토링이 거의 필요하지 않아야 합니다.
- 스테이트리스(Stateless), 즉 외부 데이터 요구 사항이 없어야 합니다.
- 종속 항목이 아예 없거나 거의 없어야 합니다.
마이그레이션 계획의 예
다음 목록은 마이그레이션 순서의 예를 보여줍니다.
- 플랫폼 프런트엔드(즉, 사용자 인터페이스)
- 통화 변환 서비스와 같은 스테이트리스(Stateless) 기능
- 오프라인 매장을 나열하는 서비스처럼 독립적인 데이터세트가 있는 기능(다른 데이터세트에 대한 종속성이 없는 데이터세트)
- 공유 데이터세트가 있는 기능(전자상거래 플랫폼의 비즈니스 로직)
플랫폼 프런트엔드 및 스테이트리스(Stateless) 기능
플랫폼 프런트엔드와 스테이트리스(Stateless) 기능은 보통 종속성이 거의 없습니다. 둘 다 아키텍처의 중요한 구성요소이므로 초기 이전 대상으로 이상적입니다. 초기 이전 단계에서는 백엔드 API가 여전히 기존 데이터 센터나 다른 클라우드 공급자가 호스팅하는 런타임 환경에서 제공되므로 필요한 리팩토링이 한정적입니다.
플랫폼 프런트엔드 기능과 스테이트리스(Stateless) 기능의 경우 모두 통합 및 배포 파이프라인에 중점을 두어야 합니다. GKE 작업 부하는 컨테이너화되어야 하므로 더 많은 운영 작업을 수행해야 할 수 있습니다.
독립적인 데이터세트가 있는 기능
다음으로 이전할 구성요소는 데이터세트가 다른 데이터세트와 독립적인 기능입니다. 이러한 독립적인 데이터세트는 종속성이 있는 데이터세트보다 이전 시스템에서 추출하기가 더 쉽습니다. 물론 독립적인 데이터세트가 있는 기능을 이전하는 경우 실제로 데이터를 이전할 때 Stateless(스테이트리스) 기능을 이전하는 경우와 달리 새로운 Datastore를 만들고 관리하는 등의 추가 작업이 필요합니다.
데이터 이전을 계획 중인 경우 스토리지 시스템을 선택할 수 있습니다. 애플리케이션을 현대화하려면 다음을 사용하면 됩니다.
- 파일을 저장하는 데 사용되는 관리형 데이터 스토리지 서비스(예: Cloud Storage 또는 Filestore)
- RDBMS에서 데이터를 마이그레이션하는 데 사용되는 Cloud SQL
- NoSQL 데이터베이스에서 데이터를 마이그레이션하는 데 사용되는 Firestore
공유 데이터세트가 있는 기능
공유 데이터세트가 있는 기능은 이전하기가 가장 어렵습니다. 나중에 자세히 설명하겠지만 일관성, 배포, 액세스, 지연 시간 요구 사항으로 인해 데이터 이전 작업이 까다롭기 때문입니다.
데이터 마이그레이션 전략
데이터 마이그레이션 접근 방식에 대한 자세한 내용은 데이터 마이그레이션 접근 방법을 참조하세요.
마이크로서비스 관련 권장사항
다음 섹션에는 마이크로서비스 설계, 작성, 배포 시 따라야 하는 일련의 권장사항이 나와 있습니다.
마이크로서비스 설계
마이크로서비스를 설계할 때는 각 마이크로서비스의 컨텍스트 및 경계를 올바르게 정할 수 있게 해주는 설계 패턴을 따르세요. 그러면 마이크로서비스 작업 부하의 불필요한 파편화가 방지됩니다. 또한 마이크로서비스가 유효한, 정확한 컨텍스트(또는 도메인)를 정의할 수 있습니다. 이러한 설계 패턴의 예로 도메인 중심 설계(DDD)가 있습니다.
API 계약
각 마이크로서비스는 일련의 인터페이스에서만 호출되어야 합니다. 그리고 각 인터페이스는 OpenAPI Initiative 사양(이전 명칭 Swagger) 또는 RAML과 같은 API 정의 언어를 사용하여 구현할 수 있는 계약을 통해 명시적으로 정의됩니다. API 계약 및 인터페이스가 잘 정의되어 있으면 이러한 API 인터페이스에 대한 테스트를 솔루션의 기본 구성요소로 개발할 수 있습니다(예: 테스트 기반 개발 적용).
변경사항 관리
API 계약에 브레이킹 체인지를 도입해야 하는 경우 클라이언트가 변경사항을 처리하는 데 필요한 리팩토링 작업을 최소화하기 위해 미리 준비해야 합니다. 이 문제를 처리하는 두 가지 방법은 다음과 같습니다.
- 버전 관리
- 새 마이크로서비스 구현
버전 관리
기존 클라이언트를 손상시킬 수 있는 업데이트를 유연하게 관리할 수 있도록 마이크로서비스용 버전 관리 스키마를 구현해야 합니다. 버전 관리를 사용하면 기존 버전을 사용하는 클라이언트에 영향을 주지 않고 업데이트된 버전의 마이크로서비스를 배포할 수 있습니다. 버전 관리를 사용하는 경우 기존 계약의 일부 내용에 위배되는 변경사항을 도입할 때마다(최소한의 변경사항이라도) 새 버전을 만들어야 합니다.
다음 스키마를 사용하여 버전 관리 스키마를 구현할 수 있습니다.
- 글로벌 버전 관리
- 리소스 버전 관리
글로벌 버전 관리 스키마를 구현한다는 것은 전체 API의 버전을 관리한다는 의미입니다. 한 가지 구현 방법으로 다음과 같이 리소스 URI에 버전 정보를 빌드하는 방법이 있습니다.
/api/v1/entities or api.v3.domain.tld/entities
이러한 유형의 버전 관리 스키마는 한 곳에서 버전 관리가 이루어지므로 쉽게 배포할 수 있습니다. 하지만 리소스 버전 관리 스키마만큼 유연하지는 않습니다. 글로벌 버전 관리 스키마의 예는 Kubernetes API 버전 관리 스키마를 참조하세요.
리소스 버전 관리 스키마를 사용하여 마이크로서비스가 제공하는 모든 리소스의 버전을 개별적으로 관리할 수 있습니다. 특정 리소스에 대한 작업(예: HTTP 동사)에 따라 해당 리소스의 버전을 관리하여 유연성을 극대화할 수도 있습니다. 이러한 버전 관리 스키마는 다양한 방법으로 구현할 수 있습니다. URI를 사용하거나 다음 예처럼 커스텀 또는 표준 HTTP 요청 헤더를 사용할 수 있습니다.
Accept: application/tld.domain.entities.v2+json
리소스 버전 관리 스키마의 경우 모든 개체에 맞게 일반화된 접근법이 필요하므로 글로벌 버전 관리 스키마보다 설계하기 어려울 수 있습니다. 그러나 리소스에 여러 가지 독립적인 업그레이드 정책을 구현할 수 있으므로 더욱 유연합니다.
새 마이크로서비스 구현
브레이킹 체인지를 처리하는 또 다른 방법으로, 완전히 새로운 마이크로서비스를 구현하고 새 계약을 맺는 방법이 있습니다. 새 버전의 마이크로서비스에 변경사항이 너무 많아서 기존 버전을 업데이트하는 것보다 새 버전을 작성하는 것이 더 바람직할 경우 이 작업을 수행할 수 있습니다. 이 방식은 최대한의 유연성을 제공하지만 기능과 계약이 겹치는 마이크로서비스를 제공할 가능성이 있습니다. 새로운 마이크로서비스를 구현한 후 해당 마이크로서비스를 사용하도록 클라이언트를 점진적으로 리팩토링하고 이전 버전에서 마이그레이션할 수 있습니다.
다음 단계
- GKE Enterprise 알아보기
- GKE 시작하기
- Apigee를 사용한 Kubernetes API의 대규모 배포 패턴
- 블랙 프라이데이 프로덕션 준비
- Cloud SQL 및 외부 서버 간 데이터 이전
- 소매 작업 부하용 솔루션 보기
- Google Cloud에 대한 참조 아키텍처, 다이어그램, 권장사항 살펴보기. Cloud 아키텍처 센터 살펴보기