컨테이너 확장의 미래가 서비스 메시인 8가지 이유

마이크로서비스는 개발 속도를 높이는 데 매우 유용하지만, 이러한 아키텍처의 복잡성은 마이크로서비스가 의존하는 서비스 간 통신에 있습니다.

현재 컨테이너화된 마이크로서비스를 확장하기 위한 최소 세 가지의 서로 다른 아키텍처 옵션이 있습니다. 각각은 - 모든 규모와 마찬가지로 - 프록시 기반 로드 밸런서를 기반으로 합니다. 각각 고유한 과제가 있습니다. 그 중 몇몇은 컨테이너 환경 내부의 확장성이 종종 IP 테이블에 의존하고 기존 네트워크 계층(즉, IP와 TCP)을 넘어서는 모든 것에 대한 제한적인 유창성에 의존한다는 간단한 사실에서 비롯됩니다.

이러한 모든 프록시는 컨테이너 환경 전체에 분산된 서비스를 확장하는 동일한 핵심 기능을 제공합니다. 놀라운 점은 서비스가 일시적인 구조물이라는 것입니다. 실제로 이러한 속성은 존재하지 않습니다. 이를 정의하는 리소스(구성) 파일에서만 존재합니다. IP 테이블 기반 확장 솔루션의 문제점은 이러한 서비스가 계층 7(HTTP) 구조로 되어 전체 애플리케이션 대신 단일 API 호출에 대한 "백엔드" 역할을 하는 경우가 많다는 것입니다.

우리가 아는 바와 같이 애플리케이션은 클라이언트 측에서 볼 때 하나의 전체적 구조로 보일 수 있습니다. 실제로 이들은 다양하고 분산된 마이크로서비스로 구성됩니다. 이러한 서비스 중 일부는 순전히 내부적으로만 사용되며, 다른 서비스에서 사용되도록 설계되었습니다. 즉, 컨테이너화된 환경 내에서 많은 서비스 간 통신이 이루어진다는 뜻입니다.

이러한 환경에서는 모든 것이 HTTP/HTTP2를 통한 API이기 때문에 L7(HTTP) 라우팅이 필요합니다. 일관된 보안 태세, 인증 및 정책 시행도 필요합니다. IP 테이블 기반 접근 방식에서는 이런 일이 발생하지 않습니다.

언제나 그렇듯이 오픈 소스가 해결책이 됩니다. 이러한 과제를 해결하기 위해 여러 개의 오픈소스 서비스 메시가 등장했습니다. 많은 오픈 소스 프로젝트의 경우와 마찬가지로 이러한 서비스 메시(예: Istio )는 엔터프라이즈급 솔루션을 제공하는 기능(및 지원)을 갖춘 Aspen Mesh 와 같은 프로젝트로 확장되고 있습니다.

이러한 확장된 노력은 조직이 컨테이너에 마이크로서비스를 배포할 때 직면하는 8가지 과제를 해결하는 데 집중되어 있습니다.

다음은 8가지 과제와 서비스 메시가 이를 극복할 수 있는 방법입니다.

1. 빌드 - 이것은 서비스 메시가 CI/CD 툴체인과 정책을 통합하고 서비스 메시를 코드로서의 인프라로 처리할 수 있도록 선언적 구성 모델을 보장하는 것 외에는 제공할 수 있는 과제 중 하나입니다.
2. 테스트 및 통합 - 서비스 메시는 개발, 테스트, 프로덕션 등 간에 일관된 정책을 보장하여 도움이 될 수 있습니다. 일부 조직에서는 단계적 배포를 완전히 없애는 방안을 고려하고 있습니다. 이러한 접근 방식은 과거에는 잘 작동했지만 배포 프로세스에 지연을 초래하는 장애물 중 하나입니다.  이들은 서비스를 프로덕션에 직접 배포하고 트래픽 조정 및 롤백 메커니즘을 채택하여 장애를 처리하는 방법을 찾고 있습니다.  
3. 버전 관리 - 서비스 메시는 API 버전과 같은 변수에 따라 트래픽을 라우팅하고 API 버전 전환 기간 동안 버전을 변환하는 데 도움이 되는 기본 API 게이트웨이 역할을 할 수 있습니다. 클라이언트 업그레이드(특히 소비자 공간의 앱)는 항상 강제로 진행할 수 있는 것은 아니므로 여러 버전에 대한 요청이 들어오는 경우가 많습니다. 서비스 메시는 이전 API 버전에 대한 요청을 최신 버전으로 변환하여 동일한 API의 여러 버전을 유지 관리하는 데 드는 비용과 부담을 줄이는 데 도움이 됩니다.
4. 배포 – HTTP를 유창하게 처리할 수 있는 서비스 메시는 블루/그린 배포 , 카나리아 테스트 및 트래픽 스티어링을 구현하기에 매우 적합한 곳입니다.
5. 로깅 - 분산 로깅은 항상 문제이며 인스턴스가 매우 다양한 기간 동안 존재하는 환경에서는 더욱 문제가 됩니다. 서비스 메시는 로깅을 구현할 수 있는 공통된 중앙 위치를 제공하고 요청 추적과 같은 기능을 수행할 수 있는 기능을 제공합니다.
6. 모니터링 - 규모의 핵심은 모니터링입니다. 애플리케이션은 서비스의 불가피한 실패를 처리하기 위해 특정 기능(재시도, 회로 차단 등)을 구현할 수 있지만, 이는 애플리케이션에 불필요한 부담을 줍니다. 서비스 메시는 서비스 간 통신의 부담을 덜어주고 모니터링을 위한 장소를 제공합니다. 목표는 프로덕션 환경에서 MTTD와 MTTR에 집중하는 것입니다. 프로덕션 환경에서 실행하는 것은 어렵고 실패는 불가피하기 때문입니다.
7. 디버깅 – 시스템이 복잡할수록 디버깅이 더 어렵습니다. 서비스 메시는 근본 원인 분석을 지원하고, 분석 및 원격 측정을 사용하여 통계와 오류 발생 전 알림을 제공하며, 컨테이너를 종료하는 대신 격리하여 철저히 검사할 수 있습니다. 이 기능은 느린 메모리 누수로 인해 실패하는 경우에 특히 유용합니다.
8. 네트워킹 – 네트워킹은 컨테이너에 여전히 매우 중요한데, 덜 복잡한 환경보다 더욱 그렇습니다. 해당 네트워킹에서 서비스를 추상화하려는 욕구는 모든 서비스에 구현하고 싶지 않은 많은 움직이는 부분이 있다는 것을 의미합니다. 서비스 검색, SSL 및 인증서 관리, 회로 차단기, 재시도, 상태 모니터링 등. 마이크로서비스의 목표는 "로컬에서 코딩하고 소규모로 코딩"하는 것입니다. 네트워킹 관련 기능을 포함해야 할 필요성을 도입하면 마이크로서비스가 부풀어 오르고 추가적인 아키텍처 및 기술적 부채가 발생합니다. 서비스 메시는 이런 기능을 담당하고 개발을 지연시키지 않으면서도 원하는 규모와 보안을 제공합니다.

서비스 메시는 클라우드와 컨테이너의 현대적 원리와 규모의 견고한 기반을 결합한 흥미로운 진화입니다. 2018년에는 컨테이너 도입이 증가하고 엔터프라이즈급 확장성과 지원에 대한 수요가 증가함에 따라 서비스 메시가 더욱 인기를 얻을 것으로 예상됩니다.