마이크로서비스 아키텍처를 기반으로 하는 웹 애플리케이션을 설계할 때 애플리케이션 기능을 마이크로서비스로 분할하는 방법과 이 마이크로서비스를 애플리케이션의 일부로 호출하는 방법을 결정해야 합니다. 장기 실행 서비스의 경우 비동기 서비스 호출을 사용해야 할 수 있습니다. 이 참조 아키텍처는 장기 실행 프로세스를 비동기적으로 호출하는 컨테이너화된 애플리케이션을 배포하는 방법을 설명합니다.
이 참조 아키텍처 문서는 Google Kubernetes Engine(GKE) 및 Pub/Sub을 포함하는 현대적인 테크놀러지를 사용하여 마이크로서비스를 구현하고자 하는 개발자 및 설계자를 대상으로 작성되었습니다. 이 문서에서는 사용자가 마이크로서비스와 일반적으로 Google Cloud의 Pub/Sub 및 GKE에 익숙하다고 가정합니다.
아키텍처
다음은 애플리케이션이 미리보기 이미지를 생성하는 시나리오 예시를 보여주는 다이어그램입니다. 미리보기 이미지를 생성하는 것은 리소스를 많이 사용하는 작업이므로 다소 시간이 걸릴 수 있습니다.
그림 1. VM 사용을 기반으로 하는 이미지 처리의 원래 아키텍처
앞의 다이어그램에서 애플리케이션은 클라이언트로부터 이미지 파일을 수신한 후 미리보기 이미지를 생성합니다. 이 아키텍처에서 애플리케이션은 Compute Engine의 가상 머신(VM) 인스턴스를 사용하고 Cloud Storage의 백엔드 파일 스토리지를 사용하여 구현됩니다. 이 애플리케이션은 Cloud Storage를 사용하여 메타데이터를 저장합니다. Cloud Load Balancing은 요청을 여러 VM에 분산합니다.
VM 유지 관리를 위해 운영 오버헤드를 줄이기 위해서는 VM을 사용하지 않는 새 아키텍처로 이 시스템을 마이그레이션할 수 있습니다.
다음 다이어그램에서는 시스템 구성요소 간의 비동기 호출을 구현하기 위해 마이크로서비스와 알림을 이용하는 관리형 서비스를 통해 이 흐름을 구현하는 방법을 보여줍니다.
그림 2. 컨테이너 및 비동기 메시징 사용을 기반으로 하는 이미지 처리를 위한 새로운 아키텍처
새 아키텍처에서는 클라이언트가 애플리케이션에 이미지를 제출하고 애플리케이션이 Cloud Storage에 이미지를 업로드합니다. 그런 후 Pub/Sub 알림이 Pub/Sub 메시지 큐에 메시지를 넣습니다. 이 메시지는 GKE에서 실행되는 마이크로서비스를 호출합니다. 마이크로서비스는 Cloud Storage로부터 이미지를 수신하여 미리보기 이미지를 생성하고 이를 Cloud Storage에 업로드합니다.
설계 고려사항
다음 가이드라인은 운영 효율성 및 성능에 대한 조직의 요구사항을 충족하는 아키텍처를 개발하는 데 도움이 될 수 있습니다.
운영 효율성
새로운 아키텍처에는 다음과 같은 장점이 있습니다.
독립적인 확장성: 원래 아키텍처에서는 Compute Engine에서 실행되는 애플리케이션이 두 가지 핵심 태스크를 처리합니다. 한 태스크는 파일을 수신하는 것이고 다른 태스크는 원본 이미지에서 미리보기 이미지를 생성하는 것입니다. 업로드된 파일 수신에는 네트워크 대역폭이 소비되고, 미리보기 이미지 생성에는 CPU가 집중적으로 사용됩니다. Compute Engine 인스턴스에서는 이미지 생성을 위한 CPU 리소스가 부족할 수 있지만, 파일 수신을 위한 네트워크 대역폭은 그래도 충분할 수 있습니다. 새로운 아키텍처에서는 이러한 태스크가 Cloud Storage 및 GKE에서 공유되기 때문에 태스크가 독립적으로 확장될 수 있습니다.
간편한 새 기능 추가: 원래 아키텍처에서는 기능을 추가하고 싶으면 동일한 Compute Engine 인스턴스에서 배포해야 합니다. 새 아키텍처에서는 애플리케이션을 개발하고 독립적으로 추가할 수 있습니다. 예를 들어 새 미리보기 이미지가 생성되었을 때 이를 알리기 위한 메일 발신자 애플리케이션을 추가할 수 있습니다. Pub/Sub는 GKE에서 실행되는 원래 코드를 수정하지 않고 비동기 방식으로 미리보기 이미지 생성 애플리케이션과 메일 발송기 애플리케이션에 연결할 수 있습니다.
결합 감소: 원래 아키텍처의 일반적인 문제 중 하나는 일시적인 결합입니다. 메일 릴레이 서버를 사용할 수 없는 경우 애플리케이션이 알림을 전송하려고 시도하면 알림이 실패합니다. 이러한 프로세스가 밀접하게 결합되어 있어서 클라이언트가 애플리케이션에서 성공적으로 응답을 받지 못할 수 있습니다. 새 아키텍처에서는 미리보기 이미지 생성과 알림 전송이 느슨하게 결합되어 있기 때문에 클라이언트가 성공적으로 응답을 얻습니다.
이 새로운 아키텍처에는 다음과 같은 단점이 있습니다.
애플리케이션 현대화를 위한 추가 노력 요구: 애플리케이션을 컨테이너화하려면 시간과 노력이 필요합니다. 새 아키텍처에는 서비스가 더 많이 사용되며, 애플리케이션 모니터링, 배포 프로세스, 리소스 관리에 대한 변경사항을 포함하여 관측 가능성에 대해 다른 접근 방법이 필요합니다.
애플리케이션 측의 중복 처리 필요: Pub/Sub는 최소 1회 메시지 전송을 보장하며, 따라서 중복 메시지가 전송될 수 있다는 의미입니다. 애플리케이션은 이 가능성을 처리해야 합니다.
성능
새로운 아키텍처는 리소스 사용량을 효율적으로 제공할 수 있습니다. 원래 아키텍처에서는 Compute Engine 인스턴스를 확장할 때 운영체제 실행을 위해 더 많은 리소스가 사용됩니다. GKE를 사용하면 더 적은 서버에서 여러 컨테이너를 실행하는 서버 리소스를 효율적으로 사용할 수 있습니다(적재 방법). 컨테이너를 빠르게 확장하고 축소할 수 있으므로, 새 아키텍처가 짧은 시간의 갑작스러운 부하 증가를 처리하고 태스크가 완료되면 빠르게 수평 축소할 수 있습니다.
배포
이 아키텍처를 구현하는 예시 애플리케이션을 배포하려면 Pub/Sub 및 GKE를 사용하는 마이크로서비스 배포를 참조하세요.
다음 단계
- DevOps에 대한 설명을 읽고 이 참조 아키텍처와 관련된 아키텍처 기능에 대해 자세히 알아보세요.
- DevOps 빠른 점검을 사용하여 업계와 비교되는 자신의 현재 상태를 파악하세요.
- 그 밖의 참조 아키텍처, 다이어그램, 튜토리얼, 권장사항을 알아보려면 클라우드 아키텍처 센터를 확인하세요.