‘MSA(MicroService Architecture)’는 전체 서비스에 영향을 미치지 않고 서비스들을 독립적으로 개발 및 배포할 수 있고, 서비스별로 리소스를 유연하게 운영할 수 있어 클라우드, 컨테이너 등의 환경에 적합한 아키텍처로 활용이 늘고 있다. MSA는 다양한 장점을 갖추고 있지만 규모가 커지면 커질수록 구성 서비스 수가 증가하고, 복잡도와 부담이 커질 수밖에 없다. 이러한 문제를 해결하기 위해 새롭게 등장한 아키텍처가 ‘서비스 메시(Service Mesh)’다. 성공적인 마이크로서비스 프로젝트를 위한 서비스 메시를 살핀다.

기존의 모놀리식 애플리케이션 시스템에 대해 각각의 기능을 여러 개의 작은 서비스로 쪼개는 것을 의미하는 ‘MSA’는 전체 서비스에 영향을 미치지 않고 서비스들을 독립적으로 개발 및 배포할 수 있다. 또한 서비스별로 리소스를 유연하게 운영할 수 있어 클라우드, 컨테이너 등의 환경에 적합한 아키텍처로 활용이 빠르게 늘고 있다.

MSA 도전 과제
새로운 아키텍처로 부상한 MSA는 다양한 장점을 갖추고 있지만 규모가 커지면 커질수록 구성 서비스 수가 증가하게 되고 서비스 간 호출, 각 서비스 모니터링, 로그 작성, 장애 발생 가능 지점 관리 등에 대한 복잡도와 부담이 커질 수밖에 없다는 문제가 있다. 만약 특정 서비스 A의 장애 발생을 모르고 이 서비스를 필요로 하는 서비스 B, C가 필요한 응답을 받지 못한 채 기약 없이 대기해야 하는 장애전파 현상이 발생하면 어디서부터 어떻게 조치를 취해야 할까? 

이를 용어 측면에서 보면 CCC(Cross Cutting Concern), 즉 횡단 관심사를 어떻게 처리해야하는가에 대한 과제가 생기게 된다. 횡단 관심사는 실제 비즈니스 서비스가 동작하는 것 외에 해야만 하는 혹은 하면 좋은 것들이라 볼 수 있다. 예를 들면 분산 서비스에 대한 로깅이나 장애가 발생했을 때 어떻게 할 것인가 등의 작업이 그것이다.

MSA 환경에서 이 CCC를 구현하는 것이 곧 서비스의 품질이나 장애처리와 직결되는 문제가 됐고, 서비스 수가 많아진다면 반드시 관리돼야 한다. CCC에서 담당해야 하는 역할은 세 가지 측면에서 정의하게 된다.

서비스 간 트래픽은 어떻게 관리할 것인가, 어떤 사용자를, 어떤 형태의 요청을 어떤 서비스로 전달하고 분배할 것인가가 첫 번째다. 그리고 기존의 단일 모놀리식 애플리케이션이 분리되면서 각 서비스 간 통신이 네트워크 레이어를 이용하게 되는데, 이때 어떻게 트래픽에 대한 보안을 적용하고, 의도대로 허용하고 차단할 것인가가 두 번째다. 세 번째는 이러한 모든 활동을 모니터링해 장애를 감지하고 서비스를 개선시키는 것이다.

서비스 메시 아키텍처
기존에는 CCC 기능을 각 서비스마다 모두 비즈니스 로직과 함께 구성했다. 그러다보니 각각을 관리하고 하나의 정책이 바뀌면 관련된 모든 서비스를 재배포해야 하는 방식의 배보다 배꼽이 더 큰 현상이 발생하고는 했다.

복잡한 서비스 간의 상호작용을 관리하는 일은 코드 작성에 상당한 시간을 할애해야 하는 개발자에게는 또 다른 큰 부담으로 작용한다. 또한 모든 서비스에 대해 커뮤니케이션 관리를 작성해야 하며 이 로직을 관리하기 위한 구성 관리 서버 추가도 필요하다. 이러한 과부하 최소화를 위한 아키텍처가 바로 서비스 메시다. 서비스 메시는 서비스 간 통신을 위해 추가로 구성되는 전용 인프라스트럭처 레이어로도 표현할 수 있다.

기존 MSA는 서비스 간 직접 호출을 통해 상호 작용했다면 서비스 메시는 서비스 간 호출을 전담하는 프록시를 구성해 수행하게 된다. 각 서비스의 프록시가 해당 서비스의 설정 정보를 중앙 집중형 컨트롤 플레인에 전달함으로써 서비스 간 통신을 하게 된다. 이러한 프록시는 서비스 내부가 아니라 각 서비스와 함께 실행되기 때문에 이를 ‘사이드카(Sidecar)’라고 칭하기도 한다.

이러한 사이드카 패턴, 즉 비즈니스 로직과 CCC를 분리해 비즈니스 로직이 변경됐을 경우에만 비즈니스 로직을 배포하고, 나머지 CCC의 기능은 별도로 분리해 운영한다는 개념이 나오게 됐다. 이러한 아키텍처가 바로 서비스 메시다.

서비스 메시 위한 컨트롤 플레인 ‘컨설’
규모가 커지면 커질수록 연동이 필요한 CCC 수가 늘어나 이들을 관리하기 위한 컨트롤러(컨트롤 플레인)가 필요로 하게 된다. 사용자는 각 서비스에 대한 정보나 서비스 간 라우팅 정보 등 시스템 운영에 필요한 정책을 수립하게 된다.

수립된 정책들은 컨트롤 플레인을 통해 등록 및 관리하며 각 서비스의 데이터 플레인에 전달해 각 서비스에서 해당 정책이 반영되도록 한다. 대표적인 컨트롤 플레인이자 서비스 메시 솔루션으로 하시코프(Hashicorp)의 ‘컨설(Consul)’을 꼽을 수 있다.

컨설은 서비스 커뮤니케이션과 트래픽을 통합하는 단일 구성 환경을 제공하고 공통의 안전한 애플리케이션 간 서비스 메시를 구성하게 지원한다. 또한 다양한 인프라 전반에 걸쳐 일관된 프레임워크를 제공해 서비스를 관리하고 안전하게 보호하고 연결한다.

개발자는 원하는 런타임 환경에서 코드와 설정 변경을 최소화해 서비스를 위한 연결과 트래픽 관리 기능을 지원하는 컨트롤 플레인과 인프라를 구현할 수 있다. 모든 플랫폼에서 사용 언어와 상관없이 서비스 연결과 트래픽 관리 정책을 적용할 수 있으므로 모놀리스, 미니, 마이크로서비스 등 분산 아키텍처를 개발하고 운영하기가 더욱 쉬워진다.

조직 관점에서는 컨설을 각기 관리하고자 하는 요건이 발생할 수 있으므로 관리되는 데이터 플레인은 하나지만 내부 인프라 구성별 관리를 위한 파티션 기능을 제공한다. 그리고 인프라는 다중 데이터센터, 멀티 및 하이브리드 클라우드 구성을 위한 페더레이션 구성으로 모든 컨트롤 플레인을 중앙에서 통제한다.

벤츠 사례로 보는 컨설과 서비스 메시
글로벌 완성차 기업인 메르세데스 벤츠는 차세대 커넥티드카, 자율주행, 전기자동차와 이를 개발하기 위한 에코시스템을 구축하는데 컨설을 적극 활용했다.

기존의 벤츠 연구개발센터에서는 클라우드 플랫폼을 비롯 개발을 컨테이너화하고 새로운 기능을 보다 빨리 제공하는데 필요한 속도와 민첩성을 제공하기 위해 쿠버네티스를 적극 도입하고자 했다. 각 서비스 개발팀 별로 자체 개별 클러스터를 운영하며 서비스를 개발 및 테스트 중이었는데, 다른 클러스터에서 실행되는 서비스나 종속 서비스를 확인할 방법이 없었으며 컨테이너 특성상 서비스에 할당된 주소 또는 포트 정보가 시시때때로 추가 및 변경됐다.

그러나 이를 대응하기 위한 적합한 서비스 검색과 서비스 간 연결 및 제어 기능을 수행할 체계를 구축하지 못한 상황이었다. 각 클러스터 내에서 실행되는 서비스가 늘어날수록 이를 찾아내고 연결하는 것에 대한 어려움은 가중될 수밖에 없었다.

벤츠 연구개발센터는 동적 애플리케이션 및 인프라 서비스 검색 기능 제공은 물론 모든 런타임 플랫폼을 비롯한 전반적인 클라우드 환경에서 손쉽게 사용할 수 있다고 판단하고, 컨설을 도입하게 됐다. 벤츠는 컨설을 통해 실현한 가시성, 투명성, 제어 기능은 신속하고 효율적인 작업 수행을 가로막았던 서비스 검색과 서비스 간 연결 관련 장애 요인 중 상당수를 해소할 수 있었다고 평가했다. 

특히 200개 이상의 마이크로서비스를 실행하고 관리하는 쿠버네티스 클러스터를 컨설 클라이언트에 연결하고 이를 대규모 서비스 검색 구조와 서비스 메시를 형성하는 컨설 서버 클러스터에 연동함으로써 수 분 이내에 서비스를 검색하고 서비스 간 연결을 가능케 했다. 더불어 개발 및 스테이징 환경, 운영 환경 구분을 위해 동일한 조건의 여러 환경을 구성하는 것이 아니라 컨설 기반 태깅을 활용해 유지 관리 비용 또한 크게 줄일 수 있었다.

메르세데스 벤츠와 같이 대다수의 기업들은 마이크로서비스의 확산으로 인해 복잡한 서비스 연결이 수없이 늘어나는 것을 경험하고 있다. 폭발적으로 늘어나는 애플리케이션 간의 통신은 복잡해질 뿐 아니라 관리 및 추적이 어려운 상황이 많이 발생하기 때문에 서비스 메시를 고려하게 된다. 

결국 내부 네트워크의 복잡성을 단순화하고 배포 및 운영을 보다 쉽게 도와줄 수 있는 환경이 마련돼야 비즈니스에 필요한 유연성, 속도, 그리고 확장성을 확보할 수 있다.