Workflows로 빌드할 수 있는 3가지 범용 서버리스 패턴

* 본 아티클의 원문은 2021년 2월 24일 Google Cloud 블로그(영문)에 게재되었습니다.

2021년 1월부터 Google Cloud의 Workflows 조정 및 자동화 서비스가 정식 버전으로 제공되고 있습니다. 또한 다른 Google Cloud 제품과의 원활한 통합 기능을 제공하는 커넥터의 미리보기 버전을 사용할 수 있도록 Workflows를 업데이트했습니다. Workflows와 커넥터를 함께 사용하면 고급 서버리스 애플리케이션을 빌드하는 데 도움이 되는 범용 아키텍처 패턴을 효과적으로 설계할 수 있습니다.

Workflows는 모든 Google Cloud API와 인터넷에서 사용할 수 있는 HTTP 기반 API에서 작업을 조정할 수 있도록 설계된 서버리스 제품입니다. 인프라 관리가 필요하지 않으며 워크플로가 작업 완료를 기다리는 시간에 대해서 비용이 발생하지 않습니다. Workflows의 핵심 기능을 자세히 알아보려면 Google Cloud의 이전 블로그 게시물을 참고하세요.

이 블로그 게시물에서는 반복 워크플로 실행 예약, 결과 폴링을 통한 장기 실행 API 요청의 처리, 데이터베이스 항목 배열을 통한 반복 등 몇 가지 유용한 아키텍처 패턴을 살펴보겠습니다.

예약 워크플로

사용자 트래픽이 예상된 정상 범위를 벗어날 때마다 지원팀의 개입이 필요한 전자상거래 웹사이트나 게임 애플리케이션에 대해 생각해 보겠습니다. 예를 들어 사용자 수가 예외적으로 적으면 서비스 중단이 발생한 것으로 보일 수 있고, 동시 실행 사용자 수가 예상보다 많으면 확장성 문제가 발생할 수도 있습니다.

동시 실행 온라인 사용자 수는 Firestore 데이터베이스에 분산 카운터로 저장되며 로그인/로그아웃 트랜잭션에 따라 업데이트됩니다. 워크플로는 이 카운터 값을 주기적으로 확인하고 값에 따라 다른 조치를 취해야 합니다.

다음 워크플로를 살펴보세요.

이 워크플로는 5분마다 트리거되며 Firestore Connector를 사용해 현재 사용자 카운터 값을 Firestore 데이터베이스에서 가져옵니다. 또한 카운터 값 외에도 이전 워크플로 실행 시 저장된 마지막 트래픽 상태(예: '낮음', '정상', '높음')를 가져옵니다.

Workflows에 기본 제공되는 스위치 단계는 커스텀 수식을 결합해 현재 카운터 값이 워크플로의 이전 실행에 저장된 상태와 다른 상태에 해당하는지를 판단하는 데 사용됩니다. 상태가 달라진 경우 Firestore 데이터베이스에 새로운 상태가 저장되고 Pub/Sub 커넥터가 지원팀에 푸시 메시지를 전송해 상태 변화를 알려줍니다. 워크플로는 현재 카운터 값뿐 아니라 마지막으로 저장된 상태도 확인하기 때문에 상태가 변경된 경우에만 알림이 전송됩니다.

몇 단계만 거치면 위의 워크플로는 완전한 실행 내역 추적이 가능한 안정적인 서버리스 애플리케이션이 될 수 있습니다. 기본 제공되는 Identity and Access Management(IAM) 통합 기능은 Firestore, Pub/Sub 등 다른 Google Cloud 제품과의 상호작용에 따른 복잡성을 줄여줍니다.

Cloud Scheduler를 사용해 위 예시와 같이 워크플로 실행을 예약하는 방법을 알아보려면 이 가이드를 참고하세요.

API 폴링이 포함된 워크플로

이번에는 외부 API를 사용하는 장기 실행 작업의 실행을 요청하는 워크플로를 살펴보겠습니다. 외부 API는 작업 실행 요청을 수락하고 이 작업의 실행 상태를 폴링하는 데 사용되는 고유의 JobID를 반환합니다. 이러한 작업에는 몇 시간이 걸릴 수 있으며 워크플로는 작업이 완료된 후에만 다음 단계를 진행할 수 있습니다. 이 API에는 워크플로에 작업 완료를 알려주는 기능이 없기 때문에 워크플로가 작업 상태를 주기적으로 폴링해야 합니다.

아래 제시된 워크플로는 이 패턴을 수행하면서 2분마다 작업 상태를 확인합니다. Workflows의 가격 책정 모델은 실행된 단계의 수를 기준으로 하며 대기 작업 시간에 대한 비용은 청구되지 않습니다. 워크플로는 최대 1년 동안 실행 가능하기 때문에 가장 긴 장기 실행 작업도 계속 처리할 수 있습니다.

실제 상황에서는 이 워크플로를 시작하기에 앞서 안전한 저장 시스템에서 외부 API에 대한 인증 키를 가져오는 단계를 추가해야 할 수 있습니다. Secret Manager를 키 또는 비밀번호 저장 시스템으로 사용하고 Secret Manager Connector 기능을 사용해 키 값을 가져오는 것이 좋습니다.

데이터베이스 레코드 배열을 통한 반복

이번 예시는 애플리케이션이 고객 레코드를 매일 한 번씩 확인하고 기한이 지난 인보이스에 대한 이메일 알림을 고객에게 전송해야 하는 경우입니다.

아래 워크플로는 Firestore Connector를 사용해 연체 대금이 있는 모든 고객의 항목을 가져오는 쿼리를 수행합니다. 워크플로는 이 세트를 반복하면서 SendGrid와 같은 외부 Email API를 사용해 각 고객에게 연체 대금에 대한 이메일 알림을 전송합니다.

위 예시는 이 샘플 워크플로에서 볼 수 있듯이 배열을 처리하고 각 배열의 모든 요소에 대한 작업을 수행할 수 있는 Workflows의 기능을 활용합니다. 워크플로에서 오류 처리와 재시도를 지정하면 간헐적인 장애나 특정 항목의 오류 때문에 나머지 고객에게도 메시지를 성공적으로 전송하지 못하는 경우를 예방할 수 있습니다.

이전 예시와 유사하게 이 워크플로는 이메일 서비스에 대한 액세스 키를 가져오기 위해 Secret Manager에 대한 커넥터 호출로 확장해야 할 수 있습니다.

Workflow 준비하기

실제 상황에서 비즈니스 계열 애플리케이션은 여러 아키텍처 패턴을 조합하여 사용해야 하는 경우가 많습니다. 고객의 실제 사용 사례는 위 예시와 다를 수 있지만 주기적 예약, 폴링, 배열 반복은 범용적으로 사용되며 수많은 구현을 구성하는 요소입니다. 서버리스 및 API 기반 아키텍처에 대한 Workflows의 지원 덕분에 지속적인 운영 오버헤드를 최소화하면서도 비즈니스 로직을 완전히 제어할 수 있습니다. 또한 커넥터를 통해 Pub/Sub, Firestore, Compute Engine, Secret Manager, Cloud Tasks 등 Google Cloud 제품을 사용 환경에 간편하게 통합할 수 있습니다.

이제 Workflows가 정식 버전으로 제공되므로 비즈니스 계열 애플리케이션 제작을 위해 Workflows를 안심하고 사용할 수 있으며 기본 제공되는 API 호출 오류 처리 기능을 통해 애플리케이션의 안정성을 더욱 향상할 수 있습니다. 자세히 알아보려면 지금 Workflows 방문 페이지로 이동하거나 바로 Cloud Console로 이동해 사용해 보세요.