서비스 메시의 구성, 기능, 그리고 이점

서비스 메시는 크게 두 개의 컴포넌트로 구성됩니다.

Data Plane, 그리고 Control Plane입니다.

 

 

Data Plane

데이터 플레인은 proxy 네트워크로 구성됩니다.

위의 구상도를 보면 Instance 아래에 Sidecar Proxy가 존재하는데, 하나의 pod 안에 서비스 컨테이너와 sidecar proxy라는 컨테이너가 생성됩니다.

서비스 컨테이너는 우리가 kubernetes yaml파일에 적은대로 생성되고, 각각의 컨테이너 아래에 Istio라는 서비스가 알아서 sidecar proxy를 생성합니다.

 

지금 저의 서비스에는 Istio를 사용했기 때문에 Istio 기준으로 설명을 드리고 있지만,

굳이 Istio가 아니더라도 다른 서비스 메시 서비스들이 모두 비슷한 동작방식을 가지고 있을 것입니다.

 

하여튼, Data plane은 각각의 pod안에 sidecar proxy라는 프록시를 만들고, 해당 프록시를 활용하여 네트워크를 제어합니다.

Sidecar Proxy를 다른 말로 Envoy라고도 합니다.

출처: linkerd.io

 

Control Plane

프록시를 제어하는 역할을 수행합니다.

프록시가 어떤 동작을 해야하는지 알려주는 역할입니다.

 

즉, 엔지니어들은 Control Plane을 잘 조정하여 설정해놓으면 해당 Control Plane이 Data Plane을 만들게 되겠죠.

 

서비스 메시의 기능

트래픽 관리

A/B 테스트, 카나리 배포 등을 진행하고자 할 때 트래픽을 분산하는 것이 중요합니다.

서비스 메시가 없을 때는 A에 90%의 트래픽을, B에 10%의 트래픽을 구성하고자 할 때 pod를 총 10개 만들어야 했습니다.

 

그러나 서비스 메시가 있다면 그냥 Control Plane을 설정함으로써 파드가 두 개만 있어도 각각 90%, 10%를 할당할 수 있는 것이죠.

 

내가 만든 발표 자료

 

관찰 가능성 (Observability)

서비스의 복잡도가 증가하면서 서비스가 어떻게 굴러가는지 이해하는 과정이 시간이 오래걸리고 어려워지고 있습니다.

서비스 메시는 모든 통신에 대해 텔레메트리(telemetry)를 생성해서 엔지니어가 네트워크에 대한 분석을 용이하게 합니다.

 

보안

마이크로서비스는 하나의 서비스로 묶여있지 않기 때문에 상호간의 통신이 필요합니다.

이 통신 과정에서 메시지 가로채기(man-in-the-middle)공격에 대한 보호, 인증/권한 부여 등 마이크로서비스이기 때문에 요구되는 보안 사항이 존재합니다.

 

서비스 메시 서비스들에는 이런 문제들을 해결할 수 있는 부가기능들이 존재합니다.

모든 서비스에 유효 기간이 존재하는 인증서를 발급하고, 서비스 간 통신을 위한 mTLS를 제공하고, 암호화되지 않은 트래픽을 암호화합니다. 특히 mTLS는 TLS handshake를 양측에서 두 번 진행하기 때문에 양방향으로 암호화가 진행됩니다.

 

서비스 메시의 이점

이점이라기 보다는 위의 저런 특성들로 인해 가능한 기능들인데요,

 

1. Service discovery

같은 서비스 메시 안에 있는 모든 서비스를 추적관리할 수 있습니다.

각각의 서비스들은 서로를 찾아 통신할 수 있습니다.

 

2. Load Balancing

로그밸런싱을 위해 round robin, least connections, weighted load balancing 등의 기능을

 

3. Traffic Management

- Traffic Splitting

- Request Mirroring

- Canary Deployments

- Security (mTLS)

- Monitoring

 

이런 기능들을 구현할 수 있습니다. 각 기능들에 대해서 다룰려면 여기서 한 단계 더 깊게 들어가게 되니 나중에 다뤄보도록 하겠습니다.