[MSA] Internal LoadBalancer Service Mesh

본 포스팅에서는 마이크로서비스를 관리 및 운영하는 Service Mesh에 대해 알아보자.

마이크로서비스를 정의하는 여러가지 의미 중 "서비스 기능 자체만 독립적이고 간결하게 구현하고 외부에 API만 노출하는 것"
이라고 할때, Service Mesh는 바로 이 마이크로서비스를 외곽에서 관리 및 운영하는 체계이다. Service Mesh를 구성하는 요소를 살펴보면 

Service Discovery, Service Router, Load Balancer, Configuration등이 있다.
즉 Service Mesh는 'API Mediation' 방법 중 하나로서, 컨테이너로 운영되는 마이크로서비스의 API Mediation을 위한 필요한 기술이다.

대표적인 제품으로

	오픈소스 직접 구현	상용 솔루션 활용	Public Cloud 서비스
Service Mesh	Netflix OSS, Istio, Linkerd, Envoy, Consul	Pivotal PAS/PKA 제품에 MSA 관련 오픈소스 패킹하여 제공 (구현은 고객이 직접 해야 할 영역임)	Amazon App Mesh Azure Fabric Isitio

등이 있다.

• Netflix OSS (오픈 소스, Spring Cloud Netflix 및 Steeltoe 프레임 워크 포함), Istio (오픈 소스)
• Buoyant Linkerd (오픈 소스 및 상용 라이센스), HashiCorp Consul (오픈 소스 및 상업 라이센스), Lightbend Lagom (오픈 소스 및 상용 라이센스)
• Aspen Mesh (상업용, Istio 기반), Microsoft Azure 서비스 패브릭 (상업용), AVI 네트워크 (상업용), Red Hat OpenShift Service Mesh (미리보기 : Istio의 상용 배포판)

OSS를 사용할 경우 기술 자유도와 자산화를 할 수 있다는 장점이 있지만, MSA를 구현하기 위한 노력과 투자가 필요하며, CSP의 경우 MSA를 구현하기 쉽고 인프라를 CSP에서 관리 해 줄수 있다는 차이가 있다. 상용 솔루션은 그 중간 정도로 개발 가이드와 컨설팅이 제공되어 MSA를 구현해 나갈 수 있다.

지금부터 살펴 볼 다양한 Service Mesh의 활용 방안에 대해 알아보도록 하겠다.

 

정의

서비스 메시는 다양한 서비스 간의 발견 및 통신과 같은 교차 문제를 처리하기위한 일련의 아키텍처 패턴 및 지원 도구이다. Service Mesh는 Miniservice 및 Microservice 환경 내에서 보안, 확장성 및 가용성을 향상시킨다. 또한, 서비스 메시(Metric)는 디지털 플랫폼을 지원하는 클라우드 기반 인프라의 핵심 요소이다.

• 서비스 메시 기술은 동적 Discovery를 지원하고 트래픽을 가로 채고 정책을 적용함으로써 마이크로 서비스 간의 통신 제어를 제공한다.
• 마이크로 서비스 to 마이크로 서비스 통신의 경우 서비스 메시가 다른 중재 기술 (예 : 기존로드 밸런서 및 API 게이트웨이)보다 선호된다.
• 서비스 메시 기술은 빠르게 발전하고 있으며 상업용 및 오픈 소스 솔루션을 비롯한 여러 가지 옵션을 사용할 수 있다.

 

활용

Service Mesh를 채택하여 안전하고 탄력적인 Miniservice 및 Microservice 구성할 수 있다.

• 사이드카 프록시와 같은 lock-in 요소를 감소시키는 접근방식을 선호하여 특정 서비스 메시 기술에 대한 코드 의존을 제한한다.
• 네트워킹 메시징, 보안 및 개발팀과 협력하고 입력을 요구하는 여러 기능을 갖춘 DevOps 팀에 서비스 메시 관리 역할을 부여하여 논쟁을 줄일 수 있다.

Service Mesh는 마이크로서비스 인프라의 중요한 부분으로, 응용 프로그램의 복원력과 보안을 향상시킬 수 있다. 이는 서비스간의 통신과 관련된 기능을 자동화함으로써 개발자의 부담을 줄인다.

또한, Service Mesh는 응용 프로그램 서비스 간의 통신을 최적화하는 분산 컴퓨팅 미들웨어이다. 서비스 간 통신을 위한 프록시 역할 또는 로드밸런서 역할을 제공하고 인증, 권한 부여, 암호화, 서비스 검색, 요청 라우팅, 로드 밸런싱, 자가 치유/복구 및 서비스 계측과 같은 기능을 지원한다. 

마이크로서비스 환경에서 모놀리식이었던 응용 프로그램은 독립적인 구성요소로 분리되어 분산형 서비스로 배포된다. 일반적으로 임시적이고 동적으로 확장 가능한 관리 컨테이너 시스템으로 배포된다. 서비스 인스턴스는 필요에 따라 시작, 중지, 삭제, 재구성 또는 대체 될 수 있다. 결과적으로 이러한 서비스에는 동적 발견 및 자가 치유 연결을 동적이며 안정적인 방식으로 서로 통신 할 수 있는 통신 미들웨어가 필요하다. 이것이 바로 서비스메시이다.

 

[그림 1] 서비스메시 기능 @ 2018 Gartner, Inc.

서로 통신하기 위한 서비스 요구사항은 새로운 것이 아니다. 그러나 마이크로서비스의 크기, 규모 및 일시적인 성격으로 인해 기존 방식에서 벗어난 가볍고 빠른 기술이라 할 수 있다.

 

기능

서비스 메시는 컨트롤 플레인과 데이터 플레인으로 구성되어있어 서비스 간 통신을 느슨하게 결합하고, 안정적이며, 안전하고 유연하게 유지하는 핵심 기능을 제공한다.

컨트롤 플레인은 서비스 메시를 관리하는 역할을 담당한다. 컨트롤 플레인의 목적은 데이터 플레인에서 구현할 정책을 설정하는 것이다.

데이터 플레인은 컨트롤 플레인에서 설정한 정책을 적용하고 서비스 간 데이터 흐름 및 통신을 관리한다.

라이브러리 기반 접근 방식과 같은 서비스 메시는 응용 프로그램 코드를 수정해야했으며 컨트롤 플레인을 사용하지 않았다. 컨트롤 플레인없이 서비스 메시를 실행할 수는 있지만 이러한 경우 정책이 코드에서 분리되지 않기 때문에 권장되지 않는다.

[그림 2] 서비스메시 기능 @ 2018 Gartner, Inc.

컨트롤 플레인은 다음과 같은 관리 기능을 제공한다.

• Configuration Store : 모든 서비스에서 일관된 방식으로 공유 구성을 사용할 수 있다. 서비스는 이 정보를 사용하여 서비스 간 통신을 구성한다.
• Service Registry : 서비스가 느슨하게 결합된 방식으로 서로를 발견 할 수 있도록 한다. 이것은 서비스 레지스트리로 구현되어 서비스 인스턴스가 시스템에 들어갈 때 자체적으로 등록하고 시스템을 떠날 때 등록을 취소 할 수 있도록 한다. 서비스 소비자는 서비스 레지스트리를 쿼리하여 서비스 제공자의 위치를 ​​확인한 후 통신 할 수 있다. 서비스 메시를 사용할 때 서비스 메시에 대한 쿼리는 데이터 플레인을 통해 발생한다.
• Traffic Routing : 정책 또는 구성을 기반으로 요청을 올바른 서비스 인스턴스로 라우팅하기위한 정책을 설정한다. 클라이언트 응용 프로그램의 트래픽이 우선 순위를 정하거나 카나리아 배포 전략, AB 테스트 또는 Circuit Braeker를 지원하기 위해 다른 버전의 서비스로 트래픽이 선택적으로 라우팅 될 수 있다.
• Load Balancing : 확장성을 지원하기 위해 서비스 로드밸런싱 정책을 설정한다. 이러한 정책의 예로는 RR 및 LC가 있습니다. RR에서는 요청이 기본 설정에 따라 각 서비스 인스턴스에 차례로 또는 무작위로 분배된다. LC는 처리되지 않은 요청 수가 가장 적은 서비스 인스턴스로 라우팅된다.
• Observability (관찰성) : 서비스 코드를 최소한으로 수정하거나 수정하지 않고 서비스 메시를 통해 서비스 간 트래픽을 로깅 및 디버깅 목적으로 관측 할 수 있다. 서비스 간 실제 호출을 볼 수 있기 때문에 마이크로서비스의 흐름을 파악하고 추적할 수 있다.
• Resiliency (복원력) : RR 또는 LC와 같은 기본로드 밸런싱 정책 외에도 Latency 및 Cascading Failure(계단식 실패 또는 실패가 또 다른 실패를 야기하여 장애가 전파되는 현상)를 위한 정책을 구성한다. 예를 들자면, Latency를 해결하기 위해 이동평균법(EMA. WMA)을 계산하는 것이다. 이 경우 RTT는 미해결 요청 수에 따라 계산되고 가중치가 적용된다. 이후 예상 응답 시간이 가장 낮은 트래픽이 서비스 인스턴스로 라우팅된다. 요청이 서비스에서 실패로 표시되고 제거되기 전에 설정된 횟수만큼 반복 될 수 있는 Circuit Breaker 및 Retry와 같은 패턴은 Cascading Failure를 줄이기 위해 정책으로 설정할 수 있다. Timeout, ConnectionPool Hangup, 연결 실패 등의 지정한 정책에 해당하는 문제가 발생했을 때, 특정 응답을 반환한다.
• Identity : 서비스 아이덴티티에 액세스 할 수 있는 서비스에 대한 매핑을 유지 관리하고 누가 어떤 서비스에 언제 액세스했는지 기록한다. 또한 JSON (JavaScript Object Notation) 웹 토큰 (JWT) 생성, 전파 및 유효성 검증을 통해 ID의 유효성을 검증 할 수 있다. 이를 통해 최종 사용자 및 호출 서비스를 기반으로 권한 부여 할 수 있다.
• Security and Encryption : 서비스 간 통신을 암호화 할 수 있다. 컨트롤 플레인은 인증 기관에서 인증서 생성 및 인증서 교환과 같은 기능을 제공하고 이러한 인증서 및 관련 구성 데이터를 컨트롤 플레인으로 전송한다.

데이터 플레인은 컨트롤 플레인에서 설정 한 정책을 구현한다. Lyft의 오픈 소스 프로젝트 인 Envoy는 가장 널리 사용되는 데이터 플레인 중 하나이다. Envoy는 Istio의 기본 데이터 플레인이고 HashiCorp Consul의 권장 및 지원 데이터 플레인이다. Envoy는 또한 AWS (Amazon Web Services) App Mesh 오퍼링의 기초로 사용되고 있다. 다른 데이터 플레인에는 Buoyant의 Linkerd가 있으며 컨트롤 플레인으로도 사용된다. NGINX, Traefik 및 HAProxy와 같은 에지 /로드 밸런서도 데이터 플레인으로 사용 가능하다.

• Service Discovery : 서비스 인스턴스가 사용 가능한 다른 서비스를 검색하고 시작 또는 종료시 자신을 등록 또는 등록 취소 할 수 있다. 이는 컨트롤 플레인에서 관리하는 서비스 레지스트리에 대한 요청으로 구현한다.
• Health Checking : Service Discovery에서 반환 된 서비스가 정상이며 요청을 수락 할 준비가 되었는지 확인한다. 서비스 인스턴스가 Active 상태이며 REST 기반 서비스에 대해 HTTP 요청에 대한 응답을 검증한다.
• Traffic Routing : REST 요청을 통해 현재 서비스 인스턴스의 특정 엔드 포인트로 특정 리소스에 대한 요청이 이루어질 때 데이터 플레인은 요청을 적절한 서비스로 라우팅 할 수 있다. 데이터 플레인은 자동 확장 가능한 컨테이너기반 플랫폼에 자동으로 대처한다.
• Load Balancing : 요청 된 서비스 엔드 포인트가 트래픽 라우팅 정책에서 설정되면 관련 로드밸런싱 정책에 따라 요청을 올바른 서비스 인스턴스로 전송한다.
• Authentication and Autorization : 컨트롤 플레인에서 설정 한 ID 및 암호화 정책을 따르고 서비스 호출자가 요청 된 엔드 포인트를 호출 할 수 있는 올바른 권한을 부여한다.
• Observability : 각 요청에 대한 분산 추적 데이터와 같은 자세한 성능 및 사용 통계, 로그 및 기타 관련 데이터를 수집한다. 이 데이터를 로깅 서비스로 전달할 수 있다.

㉠ 관리 컨테이너 시스템 (예 : Kubernetes, Mesos 및 Docker Swarm)

㉡ 컨테이너 (Amazon Web Services [AWS] Fargate 및 Google Kubernetes Engine과 같은 서비스 환경)

㉢ 공용 및 개인 PaaS 환경 (예 : OpenShift Online, Heroku 및 Pivotal Cloud Foundry)

㉣ 비교 가능한 관리 컴퓨팅 환경 (예 : Azure Service Fabric 및 Lightbend Reactive Platform)

 

성장

서비스메시 기술의 성장은 마이크로서비스 및 컨테이너의 성장과 관련되어 있다. 현대 응용프로그램은 갈수록 분산되고 컨테이너화 되어 서비스메시 기술의 관심과 채택을 촉진한다.

서비스메시 기술은 초기에 마이크로 서비스를 채택한 사람들이 위와 같은 새로운 기능을 필요로하여 탄생하였다. 클라이언트와 서비스간의 통신을 제공하는 전통적인 API 게이트웨이 기술은 마이크로 서비스간 통신에 비해 너무 무겁고 마이크로서비스 팀은 더 가벼운 솔루션이 필요했다.

이로 인해 개발된 최초의 서비스메시 기술 중 하나는 Netflix OSS 공통 런타임 서비스 및 라이브러리 (Ribbon, Hystrix, Eureka 및 Zuul과 같은 구성 요소 포함)이다. 다른 초기 얼리 어댑터들은 Twitter, Airbnb, Lyft 등에 서비스메시 기술을 구축했다. Microsoft는 Azure Service Fabric 프레임 워크의 일부인 서비스 메시를 구축 한 최초의 공급 업체 중 하나였다. Buoyant는 트위터 초기 작업을 기반으로 Linkerd를 개발 한 다른 초기 벤더였다.

서비스메시 기술에 대한 고객의 관심은 2017 년 초 Google, IBM, Lyft가 Kubernetes에서 실행되는 마이크로서비스를 위한 서비스 메시 프레임 워크를 제공하기 위해 Istio 오픈 소스 프로젝트를 시작하면서 가속화되었다. Istio v1.0은 2018년 7월에 출시되었으며, Kubernetes 기반 플랫폼의 수많은 공급 업체는 상용 Istio 기반 제품을 출시 할 계획이다. Cloud Foundry 기반 플랫폼 공급 업체 중 다수가 Istio를 Cloud Foundry에 이식하기 위해 노력하고 있다.

• 라이브러리 방식 : 개발 언어별 라이브러리 기반의 API를 소스코드에 반영하여 서비스를 찾아가는 방식. 개발 언어의 종속성과 개발 복잡도가 높으며, 인프라 호환성과 관련없이 적용 가능
• 노드 에이전트 방식 : 노드에서 실행되는 에이전트 기반으로 처리. 언어는 상관없으며, 인프라와의 호환성이 중요. 마이크로서비스에 비적합
• 사이드카 방식 : 개발된 서비스와 독립적으로 별도의 프록시를 구성하여 프록시 간 연계를 통해 서비스를 호출하는 방식. 개발과 독립적으로 컴포넌트를 배치할 수 있음

유의점

미성숙, lock-in 및 스킬요구를 포함하여 서비스메시 기술을 사용하는데는 여러 가지 위험이 있다.

㉠ 미비 : 서비스메시 기술은 비교적 새롭고 미성숙하다. 예를 들어, Istio와 Linkerd는 빠르게 발전하고 있으며 얼리 어답터는 안정성, 성능 및 확장성에 대한 우려를 보고하고 있다. 또한 서비스메시를 지원하는데 필요한 문서화 및 관리를 비롯하여 적합한 운영 방식이 확립되지 않았다.

㉡ Lock-in : 서비스메시는 특히 프레임 워크 또는 라이브러리 기반 솔루션을 사용할 때 lock-in이 발생한다. Linkerd 또는 Istio와 같은 사이드 카 패턴을 사용하여 배치되는 서비스메시는 lock-in을 감소시키기 좋다.

㉢ 기술력 보유 : 대부분의 기업은 서비스메시 기술에 대한 경험이 없다.

 

비교

서비스메시의 선택은 서비스 코드가 메시와 얼마나 밀접하게 결합되어 있는지 검토해야 한다. Microsoft Azure Service Fabric 및 Lightbend Lagom과 같은 일부 메시기술은 개발 프레임워크의 일부이며 메시는 서비스코드에 포함된다. Netflix OSS와 같은 일부 메시기술은 라이브러리로 구현되며 서비스는 API 호출을 통해 메시에 결합된다. Istio 및 Linkerd와 같은 일부 메시기술은 사이드카 프록시를 사용하여 서비스 코드를 메시와 독립적으로 사용할 수 있게 한다.

[그림 3] 코드 결합에 기반한 서비스메시 기술의 스펙트럼 @ 2018 Gartner, Inc.

위 이미지는 서비스 메시의 lock-in 정도 및 Service Code와의 종속성을 보여주는 스펙트럼이다. 프레임워크기반 메시는 개발자가 잘 설계된 서비스를 구축하는데 도움이되지만 프레임 워크와 런타임 환경과의 긴밀한 결합을 유발한다. 사이드카 기반 메쉬는 관리 및 유지보수가 쉬우며 런타임 정책을 구성할 수 있는 보다 융통성있는 방법을 제공한다.

지금부터 대표 Service Mesh 제품 중 CSP 사의 AWS App Mesh와 OSS Istio를 비교해 보도록 하자.

① AWS App Mesh

https://aws.amazon.com/ko/app-mesh/features/

AWS Fargate, Amazon ECS, Amazon EKS, Kubernetes on EC2와 함께 App Mesh를 사용하면 규모에 맞춰 컨테이너화 된 마이크로서비스를 효과적으로 사용할 수 있다.

㉠ 일관된 마이크로서비스 통신 : App Mesh는 통신 모니터링과 제어에 필요한 논리를 각각의 마이크로서비스 대한 모든 네트워크 트래픽을 관리하는 프록시로 나눈다.

㉡ 오픈소스 프록시 : App Mesh는 마이크로서비스 컨테이너로 오가는 모든 트래픽을 관리하기 위해 오픈소스인 Envoy 프록시를 설정한다.

㉢ 가시성 : App Mesh는 마이크로서비스 간 모든 통신에 대한 수치, 로그, 트레이스를 모으기 때문에 에러 발생 부분을 빠르게 처리할 수 있다. 이 기능은 AWS 서비스와 오픈 소스를 이용해 수행할 수 있다.

㉣ 트래픽 제어 : App Mesh는 어플리케이션 내부 코드 수정이나 로드밸런서를 사용하는 일 없이 마이크로서비스들을 바로 연결할 수 있도록 한다. 각 아미크로서비스가 시작할 때, 마이크로서비스의 프록시가 App Mesh에 연결하고 어플리케이션 내 다른 마이크로서비스들의 위치를 담고 있는 데이터를 받아 연결한다.

② Istio

https://istio.io/docs/concepts/what-is-istio/

㉠ 트래픽 관리 : Istio의 간단한 룰 설정과 트래픽 라우팅은 사용자로 하여금 서비스 간 트래픽과 API 요청의 흐름을 조절할 수 있게 한다. Istio는 circuit breakers, timeouts, retries 같은 서비스 레벨의 속성들의 설정을 단순화 하고, A/B Testing, Canary Rollouts과 같은 동작을 손쉽게 적용할 수 있다.

㉡ 보안 : Istio의 보안 기능을 통해 개발자들은 응용프로그램 단계의 보안에 집중할 수 있다. Istio는 기본 보안 통신채널을 제공하고, 규모에 따른 서비스 통신의 인증, 권한부여, 암호화를 관리한다.

㉢ 관측 : Istio의 강력한 tracing, monitoring 그리고 logging은 service mesh 배포에 대한 깊은 통찰력을 제공한다. 서비스 성능이 업스트림과 다운스트림에 어떤 영향을 끼치는지를 Istio의 모니터링 기능을 통해서 확인 할 수 있다.

㉣ 플랫폼 지원 : Istio는 플랫폼에 독립적이고, 다양한 클라우드, On-premise, Kubernetes, Mesos 같은 다양한 환경에서 돌아가도록 설계 되었다.

㉤ 통합 및 사용자 정의 : Istio의 정책 실행 구성요소는 ACLs, Logging, Monitoring, Quotas, Auditing 그 외의 기존의 솔루션들과 통합되도록 확장 및 사용자 정의할 수 있다.

Service Mesh vs API Management

	Service Mesh	API Management
라우팅	서비스를 호출한 또 다른 서비스에서 직접 라우팅을 결정하며, Local Network 스택의 일부가 되는 클라이언트의 Sidecar를 통해 통신 함	서버측에서 직접 서비스 라우팅을 담당한다. 이로 인해 모든 서비스는 APIM을 거쳐 요청이 전달된다. 이로 인한 네트워크 hop이 증가할 수 있다.
로드밸런싱	서비스 레지스트리에서 서비스 가능한 서비스 목록을 수신하고, 이를 기반으로 클라이언트 sidecar에서 로드밸런싱 알고리즘을 통해 수행	서비스 별 자체 API를 통해 서비스를 탐색하며, API Gateway에 연결된 서비스로 로드밸런싱을 직접 수행
배치	애플리케이션의 네트워크 경계에서 통신	외부 네트워크와 내부 애플리케이션 사이에 위치
범위	애플리케이션 내부에서 교차되는 서비스 간 추적, 로깅, 메트릭 수집	API Gateway를 거치는 모든 요청에 대한 추적, 로깅, 메트릭 수집
보안	HTTP, OAuth, Key Pair 방식	TLS 방식

결론적으로 Service Mesh는 클러스터 내부 서비스 간의 연결을 추적하고 관리하는 것에 초점이 맞추어져 있다면, API Management는 클러스터 외부와 내부간의 연결을 추적하고 관리하는데 초점이 맞추어져 있다고 볼 수 있다.

결론

마이크로서비스를 배치 할 때 서비스메시는 반드시 필요하며 실행 가능한 대안이 없다고 할 수 있다. 기술적으로 서비스메시를 배치 할 수는 있지만 서비스 수가 늘어남에 따라 운영상의 지원 및 확장이 극히 어렵기 때문이다.

다른 비슷한 제품 (API 게이트웨이 및 애플리케이션 딜리버리 컨트롤러)도 충분하지 않다. 이러한 제품은 종종 서비스메시와 함께 사용해야 하지만 서비스 메시를 대체할 수는 없다.

대체로 ADC, 로드밸런서, API 게이트웨이는 응용 프로그램 앞에 클라이언트와 통신방식을 제공하고, 서비스메시는 내부 서비스 간 통신을 지원는 방식으로 구성는 것이 적합한 방식이라 할 수 있으며, 이는 하나의 솔루션으로 대체될 수도 있다.