스타트업 환경에서 Google Cloud 서버리스 기술을 사용하여 빠르게 변경하고 개선하기

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

스타트업은 MVP(최소 기능 제품)에 빠르게 도달하고 얼리 어답터의 의견을 수집하며 짧은 주기로 제품을 변경하고 개선해야 합니다. 기능을 개발하고 변경 및 개선하는 것과 관계없는 모든 활동이 출시를 지연시키는 요인이 되며, TTM(time to market)이 중요한 상황에서 이는 심각한 문제를 불러 일으킵니다. 

Google Cloud는 완전 관리형 서버리스 플랫폼에서 백엔드 서비스를 빌드하고 실행하도록 지원하는 제품을 제공하여 시간을 절약하고 서비스 실행에 필요한 인프라의 프로비저닝 및 관리 부담을 덜도록 도와줍니다. 덕분에 인프라에 쓰는 시간이 줄어 서비스 구현과 변경 및 개선에 더 많은 시간을 투자할 수 있습니다. 또한 대부분의 서버리스 제품은 처음에 초기 비용이 거의 들지 않는 '사용한 만큼만 지불' 가격 책정 모델을 지원합니다. 서비스와 스타트업의 규모에 따라 가격이 증가하므로 원할 때 필요한 만큼만 지불하면 됩니다.

이러한 제품 중 몇 가지를 살펴보고 빠르게 변경 및 개선하는 데 어떤 도움을 주는지 알아보겠습니다. 

코드를 실행하는 위치

먼저 코드를 배포하고 실행할 위치를 결정해야 합니다. Cloud Functions는 Google Cloud에서 코드를 실행하는 가장 쉬운 방법입니다. Cloud Functions를 사용할 경우 지원되는 언어로 간단한 함수를 작성하고 이 함수를 트리거하는 방법(HTTP 또는 이벤트를 통해)을 결정하면 Cloud Functions가 해당 함수를 실행, 트리거, 자동 확장하는 방식과 관련된 모든 세부적인 작업을 처리해 줍니다. 

Cloud Functions는 기본적으로 전체 앱이 아닌 단일 용도의 사용 사례를 위해 설계되었기 때문에 제한사항을 숙지하고 있어야 합니다. 예를 들어 사용할 수 있는 언어의 종류에 제한이 있으며 정해진 시간 내에 함수가 응답해야 합니다. 

Cloud Functions의 제한사항으로 인해 한계에 부딪힌 경우 더 유연한 Cloud Run을 사용할 수 있습니다. Cloud Run 서비스에서는 함수 대신 서버리스 HTTP 컨테이너를 실행합니다. 자체 런타임의 정의가 가능해 원하는 언어를 사용할 수 있고 컨테이너에서 모두 실행할 수 있는 한 간단한 함수가 아닌 더 정교한 로직을 구현할 수 있습니다. 

요청을 지속적으로 처리하는 서비스가 아니라 완료될 때까지 실행되는 코드만 필요한 경우 Cloud Run 작업을 사용하면 됩니다. 완전 관리형 서버리스 환경에서 장기 실행되는 여러 컨테이너를 동시에 실행할 수 있습니다. 

Cloud Functions와 Cloud Run을 사용하는 경우 모두 사용자는 함수나 컨테이너를 작성하는 데 집중하면 됩니다. 이를 실행하고 확장하는 데 필요한 인프라는 Google Cloud가 관리해 줍니다. 덕분에 서비스의 기능을 빠르게 변경하고 개선할 수 있습니다.

서버리스 개발을 위한 Cloud Code

서비스 실행을 위해 Cloud Functions 또는 Cloud Run 중 무엇을 사용하든 Cloud Code를 사용해 원하는 IDE에서 빠르게 서비스를 만들어 Google Cloud에 배포할 수 있습니다. 

Cloud Code에는 Cloud Functions 또는 Cloud Run 애플리케이션을 신속하게 만들 수 있는 템플릿이 있습니다.

이후 IDE에서 이러한 서비스를 배포하고 배포된 Cloud Functions 및 Cloud Run 서비스 목록을 볼 수 있습니다.

서비스 조정 방법

서비스를 실행한 후에는 단순한 HTTP 이상의 트리거 방법을 결정해야 합니다. Cloud Scheduler를 사용하면 시간에 따라 실행할 수 있습니다. 보다 세밀한 제어를 원하는 경우 Cloud Tasks 큐로 HTTP 서비스를 앞에 배치하면 재시도, 비율 제한, 중복 제거 등 정교한 기능을 즉시 사용할 수 있습니다.

여러 개의 서비스를 사용할 때는 각 서비스의 통신 및 조정 방법도 결정해야 합니다. 다음과 같은 옵션이 있습니다.

• 직접적인 서비스 간 통신
• 간접적인 이벤트 기반 통신(코레오그래피라고도 함)
• 통신을 지시하는 중앙 조정자

직접적인 서비스 간 통신은 구현하기 쉽습니다. 하지만 서비스 간에 긴밀한 결합이 형성되므로 피하는 것이 좋습니다.

이벤트 기반 통신을 위해 Google Cloud에서는 Pub/Sub 및 Eventarc를 지원합니다. Pub/Sub는 이벤트 전송 관련 고도의 맞춤설정을 지원하는 낮은 수준의 서비스인 반면, Eventarc는 서비스를 연결하는 더 쉬운 시맨틱스를 갖춘 높은 수준의 서비스입니다. 중요한 점은 두 서비스 모두 완전 관리형 글로벌 서비스로서 기본 인프라에 대한 걱정 없이 이벤트 소스를 이벤트 소비자와 연결하도록 도와준다는 것입니다.

서비스 조정을 원한다면 Workflows를 사용하면 됩니다. 서비스 조정 정의에서 서비스를 호출할 순서와 방법을 정의하면 Workflows에서 사용자가 정의한 방식대로 호출을 수행하고 이와 더불어 출력을 캡처하고 오류를 처리해 줍니다.

이러한 모든 조정 서비스가 서버리스 방식으로 실행되어 기본 인프라에 대해 걱정할 필요 없이 실질적인 서비스에 더 많은 시간을 쓸 수 있습니다. 

서버가 필요한 경우

서버리스 플랫폼의 제한사항으로 인해 서버가 필요할 때도 있습니다. 예를 들어 모든 서버리스 플랫폼에는 워크로드를 실행할 수 있는 시간과 워크로드에 포함할 수 있는 CPU 및 메모리 리소스에 대한 제한이 있습니다. Cloud Functions 또는 Cloud Run과 같은 서버리스 서비스에서 코드를 실행할 수 없더라도 Batch를 사용하면 Compute Engine의 가상 머신(VM)에서 일괄 작업을 실행하고 관리할 수 있습니다. 마찬가지로 Workflows와 해당 Compute Engine 커넥터를 사용하면 Workflows를 통해 VM에서 코드를 실행하고 VM 수명 주기를 관리할 수 있습니다. 두 경우 모두 실제 워크로드가 서버에서 실행되어 그에 따른 전체적인 유연성을 누릴 수 있지만 서버 관리는 Batch 및 Workflows와 같은 서비스에서 서버리스 방식으로 처리됩니다. 

결론

코드를 실행해야 할 때마다 이 코드를 서버리스 플랫폼에서 실행할 수 있는지 자문해 보세요. 실행할 수 없더라도 서버리스 플랫폼에서 수명 주기를 관리할 수 있습니다. 클라우드에 인프라 관리를 많이 위임할수록 실질적인 서비스를 개발하고 변경 및 개선하는 데 소중한 시간을 더 많이 할애할 수 있습니다.