개요
서비스 기업 채용 공고에서 쉽게 보이는 우대사항들이 있다.
대용량 트래픽 처리 경험, 서비스 메시, 무중단 배포 등등
실제 서비스를 다루면서 배우면 좋겠지만, 그 경험도 쉽게 얻을 수 있는 경험은 아니다.
하지만 나에겐 인터넷과 책이라는 세상의 선배가 있으니 간접 경험을 해보고자 (+ 약점 극복)
이 시리즈를 작성하게 되었다.
목표
서비스 메시(Service Mesh)는 분산 시스템에서 서비스 간 통신과 관리를 효과적으로 처리하기 위한 도구이다.
서비스 메시가 무엇이고 어떨 때 사용하면 좋은 지 살펴보자.
(이 글은 도서 이스티오 첫걸음을 참고하여 작성하였습니다.)
여정
Application과 Infra가 분리되어야 하는 이유
현대 Application은 Micro Service Architecture가 등장함에 따라 많은 변화가 생기기 시작했다.
그 중 하나는 Infra 관심사를 다루는 복잡한 작업을 어떻게 처리할 것인가? 이다.
이를 처리하기 위해 Application 단에서는 라이브러리를 추가하기 시작했다.
대표적으로 Spring 진영에서 다루는 Sping Cloud 프로젝트를 들 수 있다.
이에 대해 자세한 설명을 하지는 않겠지만
서비스 규모가 커져감에 따라서, Infra 측면의 기능들을 Application 단에서도 신경써야 하기 시작했다.
그 기능들 중 일부를 나열하면 이렇다.
- 네트워크 기능
- Load Balancing : 서비스 간의 부하 분산 및 효율적인 리소스 활용을 위해 요청을 여러 인스턴스로 분배
- Circuit Breaker : 서비스 간의 통신에서 장애가 발생할 경우 전체 시스템의 안정성을 유지하기 위해 특정 서비스의 요청을 차단
- Service Discovery : 분산 시스템에서 서비스 간의 위치 및 접속 정보를 동적으로 관리하고 제공
- 재시도 및 타임아웃 : 네트워크 문제 또는 서비스 지연에 대응하여 요청을 다시 시도하거나 타임아웃을 설정
- 보안 기능
- 인증 및 권한 부여 : 서비스 간의 통신을 안전하게 보호하기 위해 각 서비스의 인증 및 권한 부여를 관리
- 암호화 : 데이터의 기밀성과 무결성을 보장하기 위해 통신 데이터를 암호화
- 관측 기능
- 로그 및 지표 수집 : 서비스의 상태 및 성능을 모니터링하기 위해 로그 및 지표를 수집
- 요청 추적 : 서비스 간의 요청 및 응답을 추적하여 전체 시스템의 동작을 이해하고 문제를 해결
다만, 점차 늘어나는 Infra 설정과 라이브러리 버전 문제, 서로 다른 Framework 호환성 문제 등이 생겨났다.
또한, Log 관측, 보안 제어와 같은 기능을 Application Level에 추가하기에는 큰 시간과 노력이 예상되었다.
그렇다. 즉, Infra 문제를 Application에서 처리하기에는 비용이 많이 들었다.
따라서, Infra 관심사는 Application과 점차 분리되기 시작했다.
이를 해결하기 위해 생겨난 개념이 Service Mesh이다.
Service Mesh는 Application Instance와 병렬로 Service Proxy를 사용하여 다양한 역할을 수행할 수 있다.
특히 위에서 나열한 네크워크 기능, 보안 기능, 관측 기능 등을 담당할 수 있다.
Service Mesh가 성능과 비용 면에서 Overhead가 있는 것은 분명하다.
따라서, 무조건 Service Mesh를 채택해야 하는 것은 아니다!
왜 Service Mesh인가?
사실 Service Mesh가 담당하는 기능은 다른 대체제로 충분히 대체할 수 있다.
Kubernetes의 경우가 그렇다.
- CoreDNS로 Service Discovery를 수행할 수 있다.
- Sidecar 패턴을 이용하여 Log 수집 기능을 수행할 수 있다.
- Ambassador 패턴으로 Service Proxy를 삽입할 수도 있다.
- Ingress로 LoadBalancer 기능과 SSL 인증 기능도 수행할 수 있다.
그렇다면 왜 굳이 Service Mesh를 사용하는 걸까?
바로 Service Mesh가 Micro Service를 연결하는 네트워크를 가장 지능적이고 균일하게 관리할 수 있기 떄문이다
Kubernetes와 같은 Container Orchestrator는 지속적으로 복원력을 가지고 인스턴스를 관리한다.
하지만 Service Mesh만큼 지능적으로 네트워크를 관리해주진 않는다.
여기서 지능적이라는 표현은 다음과 같은 상황들을 의미한다.
- 장애가 발생한 Pod를 피해 트래픽을 라우팅한다.
- 대기 시간이 긴 요청이 발생하지 않도록 트래픽을 라우팅한다.
- 서비스 간 트래픽을 안전하게 보호한다.
- 서비스 통신 실패의 원인을 알 수 있게 관측 가능성을 제공한다.
- 단순 연결 외에 세분화된 서비스 동작으로 일관된 정책을 적용할 수 있다.
즉, Service Mesh는 이와 같은 지능적인 네트워크 동작을 Application에 작성하지 않아도 이용할 수 있게 해준다.
Service Mesh의 구성요소가 Interface로 이루어져 있기 때문에 가질 수 있는 이점이다.
Interface로 이루어져 있다는 것은 올바르게 동작하는 구현체만 있으면 된다는 의미이다.
따라서, Service Mesh의 종류도 여러가지이다. (Istio, Linkerd, Consul 등)
그렇기 때문에 Service Mesh는 꼭 Kubernetes가 필요한 것은 아니다.
Service Mesh는 Control Plane과 Data Plane이 동작할 수 있는 환경이면 어디든 구성될 수 있다.
즉, Container Ochestrator와 Service Discovery 시스템이 있으면 동작할 수 있다.
Q & A
- 좋은 건 알겠는데, Service Mesh는 성능과 비용 면에서 별로 아닌가요?
다시 한번 말하지만,
Service Mesh가 성능과 비용 면에서 Overhead가 있는 것은 분명하다.
따라서, 무조건 Service Mesh를 채택해야 하는 것은 아니다!
인프라 구성, 컴퓨팅 자원, 사용하는 기능 수와 요청 등에 따라 필요한 양이 다르지만, 대략적으로 아래와 같은 수치의 자원을 요구한다.
- 사이드카 프록시 : 최대 1,000회 요청 당 0.5 vCPU (+ 로깅 사용 시 0.5 vCPU)
- 믹서 : 최대 1,000회 요청 당 0.5 vCPU (캐시 적중률 80%로 가정)
- mTLS : CPU 및 대기 시간 측면에서 무시 가능한 수준
이에 따라서, 필요한 기능과 비용을 Trade-off한다고 생각하면 좋다.
더 자세한 벤치마크가 필요하다면 Meshery와 같은 Service Mesh 벤치마크 도구를 이용하자.
마무리
이번 시간에는 Service Mesh가 등장한 이유와 그 필요성에 대해 알아보았다.
다음 시간에는 본격적으로 Service Mesh의 구성 요소, 동작 프로세스 등 기본에 대해서 배워보도록 하자.
참고자료
이스티오 첫걸음 | 리 칼코트 - 교보문고 (kyobobook.co.kr)
[Istio] Service mesh에 적합한 Ingress Gateway는 무엇일까 ? (tistory.com)
'DevOps' 카테고리의 다른 글
| [다.인.서] Dive into Service Mesh | Service Mesh의 구성 요소와 동작 과정 (0) | 2024.05.25 |
|---|---|
| [쿠.짤] 쿠버네티스 짤팁 | 컨테이너는 결합할 수 있다(Init, Sidecar, Ambassador) (0) | 2024.01.23 |
| [쿠.짤] 쿠버네티스 짤팁 | Pod 배치는 신중하게! (Schedule Process와 Affinity) (0) | 2024.01.14 |
| [쿠.짤] 쿠버네티스 짤팁 | 정상 상태와 수명 주기를 이해하자! (Probe와 SIGKILL) (0) | 2024.01.06 |
| [쿠.짤] 쿠버네티스 짤팁 | KinD로 Local Kubernetes 구축하기 (0) | 2024.01.03 |
