인사이트리포트

들어가며

최근 많은 기업들이 기존 모놀리식 아키텍처(Monolithic Architecture)의 한계를 극복하고 클라우드 환경에서 시스템 운영 이점을 극대화하기 위해 마이크로서비스 아키텍처(Microservices Architecture, 이하 MSA)를 채택하고 있다.

현재 뜨거운 관심을 받고 있는 MSA는 새로운 개념으로 봐야 할까? 그렇지 않다. 15년 전 지금의 MSA와 유사한 SOA(Service Oriented Architecture)라는 개념이 소개되었다. SOA는 애플리케이션을 비즈니스적인 의미를 가지는 기능 단위로 묶어서 표준화된 호출 인터페이스를 통해 서비스라는 소프트웨어 컴포넌트로 재조합 하여 업무를 구현하는 아키텍처로 당시에는 획기적인 사상이었다.

SOA는 실패했을까? 그럼 MSA는?

SOA는 비즈니스 로직에 집중하고 도메인을 중심으로 서비스를 분리하는 등 MSA와 여러 모로 유사하다. 반면 SOA는 분산 처리 환경에서 발생하는 문제를 해결하기 위해 ESB(Enterprise Service Bus)를 사용했다는 점이 MSA와 다르다.

당시로는 장밋빛 미래가 보장될 것만 같았던 SOA는 결국 실패한 것으로 평가 받았다. 그 이유는 다양하게 거론되지만 여기서는 두 가지만 언급하도록 하겠다.

첫째, 조직 변화 수용의 실패

“모든 시스템은 그 조직의 의사소통 구조와 동일하게 만들어진다”는 콘웨이의 법칙(Conway’s law)은 1968년 미국의 컴퓨터 과학자인 멜빈 콘웨이가 주장한 것으로 팀을 구성하는 방법이 업무 수행 방식에 영향을 미친다는 이론이다. SOA는 조직에 엄청난 변화를 가져오기에 제대로 적용하기 위해서는 미지의 두려움에 대한 도전이 필요했다. SOA 자체가 복잡한데다 기능을 전문화하기 위해서는 무엇보다 조직 간 협업이 필수적이었다. 하지만 조직의 인식이 이같은 개념을 수용하지 못했고 조직이 변화해야 한다는 사실도 인지하지 못하였다. 최근 클라우드 컴퓨팅이 부상하면서 대두된 데브옵스(DevOps)와 SRE(Site Reliability Engineering)는 조직의 변화가 수반되어야 함을 강조한다. MSA도 마찬가지다. MSA를 성공적으로 적용하기 위해서는 조직의 구조 역시 이를 수용할 수 있는 형태로 바뀌어야 한다.

둘째, ESB의 부하 중앙 집중 문제

분산 처리 환경의 문제를 애플리케이션 외부에서 해결하려고 한 것이 ESB와 여기서 소개하려는 서비스 메쉬(Service Mesh)의 유사점이라고 할 수 있다. 하지만 ESB는 중앙 집중형으로 공통 기능의 비대화에 따른 문제를 제대로 해소하지 못하였다. SOA라는 개념은 상당히 복잡해서 그 이상에 비해 당시의 기술력이 부족했던 점도 실패 원인 중 하나로 들 수 있다.

SOA가 시들해진 지 수 년이 지났고 다시 MSA라는 개념이 화두가 되고 있다. 그럼 현재의 MSA는 과거의 SOA와 무슨 차이점이 있는 것일까?

MSA와 SOA는 무엇이 다를까?

SOA의 ESB는 중앙에 위치하여 서비스 간 통신을 담당한다. MSA 개념에서 보면 [그림 2]와 같이 하나의 ESB를 다수의 마이크로서비스 컴포넌트로 분리하여 처리하는 것과 다르지 않다.

ESB를 활용하는 SOA와 달리 마이크로서비스 아키텍처는 서비스 간 통신 기능을 구현하는데 많은 시간과 노력을 들여야 한다는 것을 짐작할 수 있을 것이다. 사실 MSA에서 가장 어려운 부분은 서비스 자체를 구축하는 것이 아니라 서비스 간의 통신을 처리하는 것이다. 통신 흐름을 제어하는 것이 대단히 복잡하기 때문이다. 그래서 필요한 것이 바로 서비스 메쉬이다.

본 아티클에서는 서비스 메쉬의 등장 배경과 이를 구현한 오픈소스 솔루션인 이스티오(istio)에 대해 알아보도록 하겠다.

서비스 메쉬

서비스 메쉬와 넷플릭스 OSS

하나의 애플리케이션에서 동작하는 모놀리식 아키텍처와 달리 MSA는 나뉘어진 서비스와 인스턴스 수만큼 관리 대상이 급격히 증가한다. 또한 서비스간 복잡한 연결 구조 때문에 장애 추적이 어렵고, 장애가 발생한 서비스로 인해 타 서비스를 호출하는 로직이 수행되지 않으면서 다른 서비스까지 동작하지 않는 장애 전파 현상이 나타난다. 서비스 메쉬 아키텍처는 MSA의 트래픽 문제를 보완하는 마이크로서비스 간 커뮤니케이션 인프라이다. 서비스 메쉬를 사용하면 마이크로서비스 간에는 직접 통신을 하지 않게 된다. 대신 모든 통신은 애플리케이션 네트워크 기능을 제공하는 서비스 메쉬를 통해 이루어진다.

클라우드에 적극적이었던 넷플릭스(Netflix)는 이런 탄력적인 서비스의 필요성을 가장 먼저 깨닫고 서킷 브레이커 패턴의 Hystrix, 서비스 디스커버리 패턴의 Eureka, 모니터링 서비스인 Turbine 등의 컴포넌트를 개발하여 넷플릭스 OSS(Open Source Software)로 공개하였다. 아울러 오픈소스 애플리케이션 개발 프레임워크인 스프링 프레임워크(Spring Framework)에 넷플릭스 OSS를 통합한 Spring Cloud Netflix를 제공하여 손쉽게 마이크로서비스를 구현할 수 있도록 하였다.

하지만 넷플릭스 OSS는 Java로 개발된 관계로 이를 사용하기 위해서는 라이브러리를 포함하고 코드에 관련된 컴포넌트를 추가해야 하는 등의 제약이 있다. 또한 당시에는 가상머신이 클라우드에서 애플리케이션을 실행하는 유일한 방법이었고 넷플릭스 OSS도 이에 최적화되어 있다 보니 최신의 운영 환경을 모두 수용하지 못하는 단점이 있다.

클라우드 네이티브(Cloud Native)와 쿠버네티스(Kubernetes)의 등장

현재 많은 기업이 기존의 레거시 시스템을 클라우드 환경으로 이전하고 있다. 이와 같이 클라우드 컴퓨팅의 이점을 활용하는 애플리케이션 구축 및 실행 컨셉을 클라우드 네이티브(Cloud Native)라고 하며, 이는 클라우드를 기반으로 개발 생산성과 IT 속도를 극대화하기 위해 탄생하였다.

퍼블릭 클라우드 벤더(AWS, Microsoft, Google 등)의 성장과 함께 컨테이너 기술 개발도 활발해졌는데 가장 빠르게 발전한 것이 오픈소스 컨테이너 오케스트레이션 플랫폼인 쿠버네티스(Kubernetes)이다. 현재 쿠버네티스와 컨테이너는 마이크로서비스 애플리케이션을 실행하는데 사실상 표준이 되었다.

다수의 컨테이너에 애플리케이션 서비스를 올리게 되면서 수많은 애플리케이션을 운영하는 환경으로 변화되었다. 컨테이너 관리와 더불어 마이크로서비스로 불리는 서비스 간의 통신 역시 증가할 수 밖에 없게 되었고, 이로 인해 네트워크와 밀접한 애플리케이션 기능인 서비스 메쉬에 대한 관심도 높아지는 형국이다.

서비스 메쉬의 핵심, 사이드카(Sidecar) 패턴

사이드카(Sidecar) 패턴은 모든 응용 프로그램 컨테이너에 사이드카 컨테이너를 추가하여 배포한다. 사이드카는 서비스에 들어오거나 나가는 모든 네트워크 트래픽을 처리한다. 가장 큰 특징은 비즈니스 로직이 포함된 실제 서비스와 사이드카가 병렬로 배치되기 때문에 서비스가 타 서비스를 직접 호출하는 것이 아니라 프록시(proxy)를 통해서 호출한다는 점이다. 따라서 대규모의 마이크로서비스 환경이더라도 별도 작업 없이 서비스 연결뿐만 아니라 로깅, 모니터링, 보안, 트래픽 제어가 가능하다는 장점이 있다.

이스티오(Istio)

쿠버네티스 기반의 서비스 메쉬, 이스티오

서비스 메쉬의 기본 아키텍처는 서비스간 직접 호출 대신 앞에서 언급한 경량화된 사이드카 패턴의 프록시를 배치하여 통신한다. 이 같은 서비스 메쉬 기술의 대표적인 구현체가 이스티오이다.

Google, IBM, Lyft 등이 참여하는 오픈소스 프로젝트로 2018년 일반에 공개된 이스티오는 Spring Cloud Netflix와 많은 유사점이 있다. 하지만 Java에 국한된 Spring Cloud Netflix와 달리 플랫폼 영역에서 동작하기 때문에 개발 언어와 무관하게 사용할 수 있다.

무엇보다 쿠버네티스와 클라우드 기반에 적합하여 이미 RedHat의 Openshift, Vmware Tanzu 등 PaaS 플랫폼의 서비스 메쉬로 선택되기도 하였다. 컨테이너 환경에서 MSA 상의 분산 아키텍처를 수용하기 위한 노력들이 더해지면서 이스티오에 대한 세간의 관심이 높아지는 추세다.

부하 분산과 트래픽 관리

이스티오는 파일럿과 사이드카 프록시인 Envoy를 통해 트래픽을 제어하고 관리한다.

믹서는 파일럿을 이용하여 서비스 버전별 트래픽 양을 분산하거나 요청 콘텐츠에 따라 특정 버전별로 트래픽을 분할하여 전송할 수 있다. 또한, 파일럿을 통해 서비스를 디스커버리하고 로드밸런싱한다. 서비스 상태를 주기적으로 체크하여 비정상적인 인스턴스는 자동으로 제거한다. 서비스간 호출 안전성을 위해 호출 재시도 횟수를 통제하거나 응답 시간에 따른 에러 처리 등 통신 상태도 관리할 수 있다.

보안

이스티오는 모든 서비스의 트래픽이 Envoy를 통해 이뤄지며 TLS(Transport Layer Security)를 이용하여 서비스간 통신이 암호화 된다. TLS 통신을 위한 인증서와 키는 시타델에서 관리한다.

이스티오는 여러 가지 인증 방식을 제공하고 있다. 서비스간 인증, 서비스와 엔드 유저(클라이언트)간 인증이 가능하고 역할 기반 접근 제어(RBAC, Role Based Authentication Control) 기능으로 서비스 접근 권한을 통제한다. 인증된 서비스나 엔드 유저에게는 특정 역할을 부여하고 이에 기반하여 서비스 접근이 가능하도록 한다.

모니터링

이스티오는 믹서를 통해 서비스간 호출 관계, 서비스 응답 시간, 처리량 등의 네트워크 트래픽 지표를 수집하고 모니터링 한다.

모든 서비스는 호출될 때 앞 단의 Envoy를 거치기 때문에 각 서비스의 호출 시 또는 주기적으로 믹서에 정보를 전달하고 이를 로깅할 수 있다. 믹서는 손쉽게 플러그인(Plugin)이 가능한 어댑터(Adapter) 구조로 여러 모니터링 시스템에 연결된다. 예를 들면 쿠버네티스에서 많이 사용하는 Heapster, Prometheus, StackDriver, Datadog 등의 모니터링 도구들과 연계하여 시각화 할 수 있으며 Grafana를 통해 각 서비스들의 응답 시간, 처리량 등을 확인할 수 있다. 또한 Jaeger를 이용하면 분산 트랜잭션 구간별로 응답 시간을 모니터링 할 수도 있다.

서비스 메쉬 적용 시 고려 사항

앞서 언급했듯이 MSA의 가장 큰 화두는 마이크로서비스 간의 통신 흐름으로 볼 수 있다. 이 관점에서 서비스 메쉬도 적용 시 고민해야 할 부분이 존재한다.

– 복잡성: 서비스 메쉬를 사용하면 런타임 인스턴스 수가 증가한다.

– 사이드카 컨테이너 수 증가: 각 서비스는 서비스 메쉬의 사이드카 프록시를 통해 호출되므로 개별 프록시 수가 증가하게 된다. 이에 따른 부하로 서비스 운영에 문제가 발생할 가능성이 있는지에 대해 아키텍처 구조 측면에서 사전에 검토해야 한다.

– 기술력의 미성숙: 이스티오는 빠르게 발전하고 있으나 아직은 새롭고 미성숙한 기술에 속한다. 또한 많은 기업이 서비스 메쉬에 대한 경험이 없는 실정이다.

마치며

디지털 트랜스포메이션이 가져온 IT 환경 변화의 중요한 이니셔티브 중 하나는 과거에 구축한 대규모 모놀리식 애플리케이션을 보다 작은 사이즈의 마이크로서비스로 바꾸는 것이다.

서비스 메쉬 아키텍처는 분산 아키텍처 환경에서 마이크로서비스가 동반하는 문제점을 보완하고 효과적으로 운영할 수 있도록 한다. 서비스 메쉬 솔루션인 이스티오는 MSA가 적용된 시스템의 안정성, 가시성, 신뢰성 및 표준화 목표를 달성하도록 돕는다. 무엇보다 오픈소스 기반으로 표준화하면 더 큰 커뮤니티에 의해 생성된 기능, 지식, 사례를 이용할 수 있고, 보다 탄력적인 애플리케이션 서비스를 구성할 수 있으며, 구축 시간을 단축해 비용을 절감할 수 있다. 또한 오픈소스 전문 기업의 기술서비스를 통해 안정적인 운영과 유지보수도 가능하다.

마이크로서비스가 각광받는 시대, 오픈소스 기반의 서비스 메쉬 솔루션인 이스티오는 개발자가 서비스의 연결 및 관리를 구현하는 복잡한 작업에서 벗어나 비즈니스 로직에 집중할 수 있도록 함으로써 개발 생산성을 높이는데 일조할 것이다.