소개
서버리스(Serverless)에 대해 이야기할 때 Kubernetes는 피할 수 없는 주제입니다.
오늘 수업에서는 프라이빗(private) 서버리스 환경을 설정하는 방법을 계속 배워보겠습니다. 구체적으로는 지난 수업에서 구축한 로컬 K8s 배포를 기반으로 서버리스 인프라를 구축할 것입니다. 그런 다음, 추가 구성 요소를 설치하여 K8s 클러스터의 기능을 확장하고, 최종적으로 로컬 K8s 클러스터가 서버리스를 지원할 수 있도록 만들 것입니다.
서버리스 구축을 위한 사전 요구 사항
시작하기 전에, 서버리스 컴퓨팅(FaaS) 기초 과정에서 제기된 질문을 명확히 해보겠습니다. 어떤 학생들은 “마이크로서비스, Service Mesh, 서버리스는 어떤 관계인가요?”라고 물었습니다.
이러한 개념들은 논의에서 자주 등장하지만, 부담스러워할 필요는 없습니다. 저도 서버리스에 대해 처음 배울 때는 이러한 개념들이 혼란스러웠습니다. 먼저 마이크로서비스를 다시 살펴보겠습니다. BaaS를 만들기 위해 마이크로서비스를 사용할 때, 마이크로서비스의 많은 개념이 서버리스의 개념과 상당히 유사하다는 것을 알 수 있습니다.
간단히 말해, Service Mesh는 마이크로서비스 자체가 인식하지 못하는 상태에서 작동하는 마이크로서비스 네트워크 통신 솔루션입니다. 또한 서버리스 아키텍처의 네트워크 통신을 Service Mesh에 위임할 수 있습니다. Service Mesh를 통해 서버리스 구성 요소는 K8s 클러스터와 긴밀하게 협력하여 궁극적으로 배포된 애플리케이션을 서버리스 방식으로 지원할 수 있습니다. 다음 아키텍처 다이어그램을 살펴보겠습니다.
다이어그램에서 서버리스의 기본 인프라는 Service Mesh 위에 구축될 수 있음을 명확히 알 수 있습니다. 그러나 Service Mesh는 서버리스 네트워크 통신을 구현하는 솔루션 중 하나일 뿐입니다. RSocket, gRPC, Dubbo와 같은 다른 옵션도 있습니다. 제가 Service Mesh를 선택한 이유는 이 솔루션이 K8s 구성 요소를 기반으로 할 수 있고, 시각화 도구를 제공하여 서버리스 작동 메커니즘(예: 제로 시작 시간 달성, 점진적 릴리스를 위한 트래픽 제어)을 이해하는 데 도움이 되기 때문입니다. 실습을 원한다면 Service Mesh가 의심할 여지 없이 첫 번째 선택입니다.
서버리스 인프라: Service Mesh
어떤 사람들은 Kubernetes, Service Mesh, 서버리스 기술을 클라우드 네이티브 애플리케이션 개발의 “세 가지 기둥”이라고 부릅니다. 이제 그 이유를 이해하셨으리라 생각합니다. 그러나 분명히 말씀드리자면, 다음 수업에서는 많은 새로운 용어를 소개할 것입니다. 이러한 용어에 대해 개괄적으로 설명해 드렸으니, 넓은 이해를 가지셨을 것입니다. 시간이 된다면 더 깊이 공부해보시기 바랍니다.
이제 본론으로 돌아와서 Service Mesh의 원리를 자세히 살펴보겠습니다.
마이크로서비스를 논의할 때는 분해와 통합에 대한 이론적 지침만 다루었고, 구체적인 구현은 다루지 않았습니다. 구현으로 전환하면, 업계에는 실제로 많은 마이크로서비스 프레임워크가 있지만 대부분 특정 언어의 SDK로 제한되어 있으며, 특히 Java 마이크로서비스 프레임워크가 그렇습니다.
SDK 형태의 마이크로서비스 프레임워크는 일반적으로 마이크로서비스 간 네트워크 통신 구현에 중점을 둡니다. 예를 들어, 실패한 서비스 요청 재시도, 여러 서비스 인스턴스 간의 로드 밸런싱, 높은 서비스 요청 볼륨 시 트래픽 제한 등이 있습니다. 이러한 로직은 종종 마이크로서비스 개발자의 관심을 필요로 하며, 각 SDK 언어에서 반복적으로 구현되어야 합니다. 그렇다면 마이크로서비스 네트워크 통신 로직을 SDK에서 추출하여 마이크로서비스를 더 가볍게 만들고, 심지어 네트워크 통신에 대해 걱정할 필요가 없게 할 수 있을까요?
정답은 Service Mesh입니다.
분해된 애플리케이션을 K8s 클러스터 Pod에 배포하면, 아래 다이어그램에 표시된 프로세스가 진행됩니다. 여기서 MyApp 애플리케이션은 클러스터 내에서 HTTP를 통해 사용자 마이크로서비스 및 할 일(todo) 마이크로서비스를 직접 호출합니다.
그러나 직접 HTTP 액세스로 인한 보안 문제는 어떻게 될까요? 누군가 우리 클러스터에서 BusyBox 컨테이너를 시작하면, 사용자 마이크로서비스와 할 일 마이크로서비스를 직접 공격할 수 있지 않을까요? 또한 사용자 마이크로서비스의 여러 인스턴스가 있을 때, 트래픽을 어떻게 할당할까요?
전통적으로는 마이크로서비스 아키텍처 SDK를 사용했으며, 이 SDK에는 이러한 로직과 SDK를 호출할 때 언제 활성화할지 결정해야 하는 많은 전략이 포함되어 있습니다. 우리의 코드도 마이크로서비스 아키텍처 SDK와 강하게 결합됩니다.
반면 Service Mesh는 다른 접근 방식을 취합니다. 마이크로서비스에서 네트워크 통신 로직을 추출하고, 비침투적(non-intrusive) 방식으로 네트워크 트래픽을 관리하여 더 이상 무거운 마이크로서비스 SDK에 대해 걱정할 필요가 없게 합니다. Service Mesh가 이 문제를 어떻게 해결하는지 살펴보겠습니다.
Service Mesh는 데이터 플레인(data plane)과 컨트롤 플레인(control plane)으로 나눌 수 있습니다. 데이터 플레인은 네트워크 통신을 관리하는 역할을 하고, 컨트롤 플레인은 네트워크 통신 상태를 제어하고 모니터링합니다. Service Mesh는 사이드카(Sidecar)를 주입하여 모든 네트워크 트래픽을 가로챕니다.
데이터 플레인에서, 애플리케이션과 마이크로서비스는 사이드카와 직접 통신하는 것처럼 보이지만, 실제로 사이드카는 트래픽 하이재킹을 통해 이를 달성할 수 있습니다. 따라서 애플리케이션과 마이크로서비스는 일반적으로 이를 인식하지 못하며, 수정이 필요 없고 HTTP 요청을 사용하여 데이터를 전송하기만 하면 됩니다.
컨트롤 플레인은 더 복잡하며 Service Mesh 운영의 핵심입니다. Pilot(파일럿)은 전체 컨트롤 플레인의 드라이버로, 서비스 디스커버리, 트래픽 관리, 스케일링을 담당합니다. Citadel(시타델)은 컨트롤 플레인의 수호 요새로, 보안 인증서와 인증을 담당합니다. Mixer(믹서)는 통신 장교로, 컨트롤 플레인의 정책을 배포하고 각 서비스의 운영 상태를 수집합니다.
이제 Service Mesh가 무엇인지, 어떻게 마이크로서비스 네트워크 통신 로직을 SDK에서 추출하는지, 그리고 왜 Service Mesh가 서버리스의 네트워크 통신 기반이라고 말하는지 명확히 이해하셨을 것입니다.
서버리스와 컨테이너 엔진의 관계
서버리스의 핵심 가치는 서버를 관리할 필요 없이 비즈니스 로직에 집중할 수 있다는 데 있습니다. 컨테이너 기술은 서버리스에 필요한 강력한 인프라와 유연한 스케줄링 기능을 제공하며, 특히 Kubernetes와 같은 오케스트레이션 도구와 결합될 때 더욱 그렇습니다.
컨테이너는 경량 패키징, 리소스 격리, 빠른 시작과 같은 장점을 제공합니다. 컨테이너는 애플리케이션과 그 종속성을 패키징하여 런타임 환경의 일관성을 보장함으로써 서버리스 플랫폼에서 애플리케이션 인스턴스의 빠른 배포와 시작을 용이하게 합니다. 또한 컨테이너는 격리된 런타임 환경을 제공하여 서로 다른 애플리케이션이 서로 간섭하지 않도록 하여 플랫폼의 전반적인 안정성을 향상시킵니다. 게다가 컨테이너 시작은 가상 머신보다 빠르기 때문에 서버리스 애플리케이션의 탄력적 스케일링에 대한 높은 요구 사항을 충족시킵니다.
서버리스 스케줄링의 핵심인 Kubernetes는 자동화된 배포, 탄력적 스케일링, 서비스 디스커버리와 같은 기능을 가지고 있습니다. 사전 설정된 규칙에 따라 컨테이너화된 애플리케이션을 자동으로 배포할 수 있으며, 수동 개입이 필요 없습니다. 실시간 로드에 따라 애플리케이션 인스턴스 수를 조정하여 성능을 보장하면서 리소스 사용률을 최적화하고, 서비스 디스커버리 메커니즘을 제공하여 서버리스 플랫폼 내 구성 요소 간의 통신을 용이하게 합니다.
컨테이너 기반 서버리스 플랫폼을 구축하려면 먼저 애플리케이션과 그 종속성을 컨테이너 이미지로 패키징하여 플랫폼에서 빠르게 배포 및 실행될 수 있도록 해야 합니다. 그런 다음 적절한 클라우드 플랫폼을 선택하거나 자체 호스팅 Kubernetes 클러스터를 서버리스 플랫폼의 인프라로 설정합니다. 다음으로 서버리스 플랫폼 구성 요소를 개발합니다. 여기에는 외부 요청을 수신하고 라우팅하는 API 게이트웨이, 함수 코드를 로드 및 실행하고 함수 수명 주기를 관리하는 함수 런타임, 다양한 이벤트 소스를 수신하고 이벤트를 함수 호출로 변환하는 이벤트 트리거가 포함됩니다. 마지막으로 Kubernetes의 Deployment를 사용하여 애플리케이션 인스턴스의 배포와 업데이트를 관리하고, Service를 사용하여 서비스 디스커버리와 로드 밸런싱을 수행하며, HPA를 사용하여 자동 탄력적 스케일링을 구현합니다.
컨테이너 기반 서버리스 플랫폼은 높은 유연성, 강력한 사용자 지정 가능성, 비용 효율성을 제공합니다. 개발자는 기본 컨테이너 기술과 Kubernetes 플랫폼을 자유롭게 선택하고, 필요에 따라 서버리스 플랫폼의 기능과 특징을 사용자 지정할 수 있으며, Kubernetes의 리소스 스케줄링 기능을 활용하여 리소스 사용률을 최적화하고 비용을 절감할 수 있습니다.
컨테이너 기술과 Kubernetes의 조합은 효율적이고 유연하며 확장 가능한 서버리스 플랫폼을 구축하기 위한 강력한 도구와 방법을 제공하여 개발자가 자신만의 서버리스 플랫폼을 쉽게 구축하고 비즈니스 로직 개발에 집중하며 개발 효율성을 향상시킬 수 있게 합니다.
Novita AI 서버리스
Novita AI에서는 자체 컨테이너 엔진인 Nexus를 개발했습니다. Nexus의 강력한 분산 컴퓨팅 및 리소스 스케줄링 기능을 활용하여 Novita AI는 차세대 생성형 AI를 겨냥한 서버리스 서비스를 구축했습니다. 사용자는 기본 컴퓨팅 리소스에 대해 걱정할 필요 없이 비즈니스 혁신에만 집중하면 됩니다. 현재 사전 예약이 진행 중입니다. 대기자 명단에 등록하여 Novita AI 서버리스를 가장 먼저 경험해보세요.
Novita AI는 AI 야망을 실현하는 올인원 클라우드 플랫폼입니다. 통합 API, 서버리스, GPU 인스턴스 — 비용 효율적인 도구를 제공합니다. 인프라에 대한 고민을 없애고, 무료로 시작하여 AI 비전을 현실로 만드세요.
추천 자료
