Lionel Blog

API 게이트웨이와 서비스 메시의 관계는 제가 최근에 계속 고민해왔던 문제이며, 동료 및 커뮤니티 친구들과도 몇 차례 논의했습니다. 이 짧은 글은 둘 사이의 유사점과 마이크로서비스 아키텍처에서 이 둘의 다른 용도를 명확하게 요약합니다.

아키텍처 패턴으로서 마이크로서비스는 복잡한 시스템을 수십에서 수백 개의 작은 서비스로 분할하며, 각 서비스는 독립적인 비즈니스 로직을 구현합니다. 이러한 작은 서비스는 소규모 소프트웨어 엔지니어링 팀이 이해하고 수정하기 쉽고, 언어 및 프레임워크 선택의 유연성을 제공하며, 애플리케이션 개발 및 출시 시간을 단축하고, 다양한 워크로드 및 리소스 요구 사항에 따라 서비스를 독립적으로 확장/축소할 수 있는 이점을 제공합니다. 반면에 애플리케이션이 여러 마이크로서비스 프로세스로 분할되면 프로세스 내 메서드 호출이 프로세스 간 원격 호출로 변경됩니다. 이는 수많은 서비스의 연결, 관리 및 모니터링의 복잡성을 야기합니다. 이 문서에서는 서비스 메시 패턴이 마이크로서비스 아키텍처의 이러한 과제를 어떻게 해결하는지, 그리고 서비스 메시의 대표적인 오픈 소스 프로젝트인 Istio를 소개합니다.

Nginmesh는 Istio 서비스 메시 플랫폼의 데이터 플레인 프록시로 사용되는 NGINX의 오픈소스 서비스 메시 프로젝트입니다. 이는 7계층 로드 밸런싱 및 서비스 라우팅 기능을 제공하며, Istio와 사이드카로 통합되어 '표준적이고 안정적이며 안전한 방식'으로 서비스 간 통신을 용이하게 하는 것을 목표로 합니다. Nginmesh는 연말에 0.2 및 0.3 버전을 연속으로 출시하여 서비스 디스커버리, 요청 전달, 라우팅 규칙, 성능 지표 수집 등의 기능을 제공합니다. 이 문서에서는 kubeadm을 사용하여 Kubernetes 클러스터를 설치하고 Nginmesh 사이드카를 배포하는 방법을 설명합니다.