이전 글에서 우리는 Serverless의 내부 작동 방식을 살펴보았습니다. 본질적으로 Serverless는 계층형 스케줄링과 빠른 콜드 스타트를 활용하여 이벤트가 처리되지 않을 때 0으로 스케일 다운할 수 있습니다. 이는 마치 음성 인식 조명과 같아서 사람이 있을 때 켜지고 방이 비면 자동으로 꺼집니다.
기본을 이해했다면, 이 인상적인 기술의 실제 응용 사례가 궁금할 것입니다. 오늘은 Serverless의 사용 사례에 대해 자세히 알아보겠습니다. 그러나 응용 사례를 이해하기 위한 전제 조건은 프로세스 모델을 이해하는 것입니다. 이 개념은 콜드 스타트만큼 중요합니다.
Serverless 프로세스 모델
지난 세션의 Serverless 콜드 스타트 과정을 다시 살펴보겠습니다. 클라우드 제공자가 컨테이너 및 런타임 준비 단계를 관리하므로, 우리는 함수 실행에만 집중하면 됩니다. Serverless 영역에서 함수 실행은 ‘함수 서비스’에 의해 처리됩니다. 함수 트리거가 ‘이벤트’의 도착을 알리면 함수 서비스는 필요에 따라 함수 인스턴스를 생성하고 해당 함수를 실행합니다. 함수 실행이 완료되면 연결된 인스턴스는 종료되어 Serverless 애플리케이션이 0으로 스케일 다운되고 절전 모드로 전환됩니다.
이제 함수 실행 후 인스턴스를 종료하지 않고 계속 유지하여 다음 함수 호출을 기다리게 할 수 있을지 궁금할 것입니다. 이렇게 하면 매번 콜드 스타트 오버헤드가 제거되어 응답 시간이 빨라집니다.
실제로 Serverless는 이러한 시나리오를 예상합니다. 따라서 함수 인스턴스를 실행하는 프로세스 관점에서 두 가지 모델이 있습니다.
- Run-to-Completion: 이 모델에서 함수 인스턴스는 준비되면 함수를 실행하고 즉시 종료됩니다. 이는 가장 순수한 형태의 Serverless 사용입니다.
- 영구 프로세스: 여기서 함수 인스턴스는 준비된 후 함수 완료 시 중단되지 않고 반환되어 다음 함수 호출을 기다립니다. 이 모델에서도 클라우드 제공자는 이벤트가 없을 경우 미리 정해진 시간 후에 함수 인스턴스를 결국 제거합니다.
데이터 오케스트레이션
대부분의 엔지니어는 매우 성공적인 디자인 패러다임인 MVC(Model-View-Controller) 패턴에 익숙합니다. 그러나 프론트엔드 MVVM 프레임워크의 부상으로 View 계층이 앞으로 나아가 SPA(Single Page Applications)로 이어졌습니다. 반대로 백엔드의 Control 및 Model 계층은 하향 이동하여 서비스 지향 백엔드 애플리케이션이 탄생했습니다.
이러한 변화로 인해 프론트엔드와 백엔드가 더욱 철저히 분리되었습니다. 프론트엔드 개발은 모의 데이터 인터페이스에 의존하여 독립적으로 진행될 수 있으며, 백엔드 팀은 데이터 인터페이스 개발에 집중할 수 있습니다. 그러나 이러한 분리로 인해 네트워크 I/O가 높은 데이터 게이트웨이 계층이 도입되었습니다.
Node.js는 비동기, 논블로킹 특성과 프론트엔드 엔지니어에게 친숙한 JavaScript 덕분에 자연스럽게 데이터 게이트웨이 계층의 역할을 맡았습니다. 이로 인해 Node.js BFF(Backend For Frontend) 계층이 등장하여 백엔드 데이터와 인터페이스를 오케스트레이션하고 프론트엔드에 적합한 데이터 구조로 변환합니다.
BFF 계층은 프론트엔드와 백엔드를 연결하는 중간자 역할을 합니다. 가공되지 않은 데이터는 흔히 원시 데이터 또는 메타데이터라고 불리며, 최종 사용자가 사실상 읽을 수 없습니다. 따라서 관련 데이터를 결합하고 처리하여 가치를 더하고 의미 있게 만들어야 합니다. 이 결합 및 처리 과정을 데이터 오케스트레이션이라고 합니다.
전통적으로 BFF 계층을 위한 Node.js 애플리케이션을 관리하는 것은 가상 머신이나 PaaS 플랫폼이 필요하여 리소스가 많이 소모되었습니다. 그러나 BFF 계층은 주로 상태 비저장 데이터 오케스트레이션을 수행하기 때문에, Run-to-Completion 모델을 사용하여 Node.js 애플리케이션을 Serverless로 원활하게 대체할 수 있습니다. 이것이 점점 더 인기 있는 용어인 SFF(Serverless For Frontend)의 핵심입니다.
BFF에서 SFF로의 진화를 이해했으니, 새로운 요청 흐름을 추적해 보겠습니다. 프론트엔드가 데이터 요청을 시작하면 함수 트리거가 함수 서비스를 활성화합니다. 그러면 함수가 시작되어 백엔드의 메타데이터 인터페이스를 호출하고, 반환된 메타데이터를 프론트엔드가 요구하는 형식으로 처리한 후 Serverless 함수는 휴식을 취할 수 있습니다.
서비스 오케스트레이션
서비스 오케스트레이션은 데이터 오케스트레이션과 유사하며, 주요 차이점은 클라우드 제공자가 제공하는 다양한 서비스를 결합하고 처리하는 데 초점을 맞춘다는 점입니다. 이 개념은 Serverless 이전부터 존재했지만, 전통적인 구현은 서비스에서 지원하는 SDK 언어 버전에 의해 제한되었습니다. 일반적으로 YAML 파일이나 명령줄 인터페이스를 사용하여 서비스를 오케스트레이션했습니다. 이러한 서비스나 API를 사용하려면 선호하는 프로그래밍 언어로 해당 SDK를 찾아 코드에 로드하고 비밀 키를 사용하여 SDK 메서드를 호출하여 오케스트레이션해야 했습니다. 데이터 오케스트레이션과 마찬가지로 백엔드 운영 및 배포 비용이 상당했으며, SDK가 없으면 플랫폼의 인터페이스나 프로토콜을 기반으로 수동으로 구현해야 했습니다.
Serverless는 SDK 활용의 경계를 확장합니다. 예를 들어, 이메일을 통해 인증 코드를 전송해야 하는 웹 서비스가 있다고 가정해 보겠습니다. Run-to-Completion Serverless 함수를 사용하여 클라우드 제공자의 SDK를 활용해 이메일을 발송할 수 있습니다. 동시에 영구 Serverless 함수는 무작위 문자열 인증 코드를 생성하고 저장한 후, 이메일 전송 Serverless 함수를 트리거하여 사용자 받은 편지함에 코드를 전달할 수 있습니다. 확인 시에는 영구 Serverless 함수를 다시 호출하여 코드를 검증할 수 있습니다.
Serverless의 주목할 만한 장점은 언어 중립성입니다. 이는 개발 팀이 단일 언어에 국한되지 않고 Java, PHP, Python, Node.js 등의 강점을 활용하여 복잡한 애플리케이션을 공동으로 구축할 수 있게 합니다.
Serverless 서비스 오케스트레이션의 개방성은 클라우드 제공자로부터 큰 주목을 받고 있습니다. 이는 언어에 관계없이 다양하고 복잡한 서비스 오케스트레이션 시나리오를 생성할 수 있게 하여 다양한 클라우드 서비스의 사용 사례를 크게 확장합니다. 그러나 이는 개발자가 선택한 클라우드 제공자가 제공하는 다양한 서비스에 익숙해져야 한다는 요구사항을 동반합니다.
결론
- Serverless의 프로세스 모델에는 상주 프로세스 형과 사용 후 제거 형의 두 가지가 있습니다. 상주 프로세스 형은 기존 MVC 아키텍처에 적응하기 위해 설계된 것으로 자연스럽지 않아 보입니다. 지금부터 Serverless를 시작한다면 사용 후 제거 모델을 적극 추천합니다. 이 모델이 Serverless의 장점을 극대화할 수 있기 때문입니다.
- 역사를 되짚어 보면, 프론트엔드와 백엔드 분리를 통해 발전한 BFF를 정리했으며, 이를 SFF로 대체할 수 있습니다. 내부 인터페이스 오케스트레이션이든 외부 데이터 오케스트레이션이든 Serverless는 큰 장점을 발휘할 수 있습니다.
- 데이터 오케스트레이션에서 더 나아가, Serverless와 클라우드 서비스 제공자의 기능을 활용하여 서비스 오케스트레이션을 실현하고, 더 강력한 복합 서비스 시나리오를 만들어 연구 개발 효율성을 높일 수 있습니다.
Novita AI는 AI 야망을 실현하는 올인원 클라우드 플랫폼입니다. 통합 API, 서버리스, GPU 인스턴스 등 비용 효율적인 도구를 제공합니다. 인프라를 제거하고, 무료로 시작하여 AI 비전을 현실로 만드세요.
추천 자료
