지금은 마이크로서비스의 시대라고 해도 과언이 아닙니다.
컨테이너와 클라우드 기술이 발전하면서 안정적인 서비스 제공을 위해 서비스를 기능 단위로 쪼개서 배포하게 된 것인데요. Kubernetes와 같은 컨테이너 오케스트레이션 툴이 이런 마이크로서비스 아키텍처 구현에 자주 쓰이고 있죠.
마이크로서비스 아키텍처는 각 기능이 독립된 서비스로 분리되어 개발 및 배포의 유연성을 높여주기도 하지만, 동시에 서비스 간의 네트워크 통신이 기하급수적으로 증가하게 됩니다. 이렇게 서비스가 분산된 환경에서는 전체 시스템의 복잡성을 높이고, 개별 서비스 호출을 관리하고 추적하는 것을 어렵게 만들죠.
이런 문제를 해결하기 위해 등장한 것이 바로, Service Mesh(서비스 메시)라는 개념입니다.
🛜마이크로서비스 시대에 Service Mesh가 필요한 이유?
마이크로서비스 간 통신과 관련해서 우리가 주목해야 할 주요 과제를 정리하면 아래와 같습니다.
- 보안성
- 마이크로서비스 환경에서는 수많은 서비스들이 내부 네트워크를 통해 서로 통신하므로 통신 구간의 보안이 매우 중요
- 트래픽 관리
- 특정 서비스의 장애가 다른 서비스로 전파되지 않도록 신뢰성을 높이는 패턴(재시도, 타임아웃 등)이 필요
- 관찰 가능성(Observability)
- 전체 시스템의 동작 상태와 성능을 파악하고 문제를 신속하게 진단하기 위해 필요
그렇다면 Service Mesh가 이 과제들을 모두 해결할 수 있을까요? 물론입니다!
Service Mesh는 애플리케이션 코드 변경 없이 서비스 간 통신을 안정적이고 안전하게 관리하기 위한 전용 인프라 계층입니다.
일반적으로 각 서비스의 인스턴스(Pod)에 사이드카 프록시 형태로 배포되며, 서비스 간의 모든 네트워크 트래픽을 중간에서 가져와 제어하는데요.
이를 통해 개발자는 비즈니스 로직 개발에 집중할 수 있고, 서비스 간의 통신 관련 작업은 Service Mesh에 맡길 수 있습니다.
Service Mesh가 플랫폼 수준에서 제공하는 주요 기능을 아까 살펴봤던 주요과제와 연결지어보면 아래와 같은데요.
- mTLS 암호화, 인증/인가 ← 보안성
- 라우팅, 로드밸런싱 ← 트래픽 관리
- 메트릭, 트레이스, 로그 기록 ← 관찰 가능성
이런 기능들을 통해 서비스 간 보안 정책을 일관되게 적용하고, 통신의 신뢰성을 향상시키며, 시스템 전체의 동작을 쉽게 파악할 수 있게 됩니다.
그래서 Service Mesh를 도입하면 마이크로서비스 운영의 복잡성을 줄이면서 관리 효율성을 크게 높일 수 있습니다.
✨Linkerd가 Service Mesh 도입에 유리한 이유는?
(출처: https://linkerd.io/2-edge/features/dashboard/)
Service Mesh라는 개념이 등장하면서 다양한 관련 툴들이 세상에 나왔습니다. 대표적인 것이 Istio, Linkerd 등인데요.
그 중에서도 우리가 이번에 Linkerd를 살펴보는 이유는, 아래와 같은 특장점이 있기 때문입니다.
- 도입 용이성
- Linkerd는 기능이 풍부한 Istio와 달리 핵심 기능에 집중하여 설계됨 (‘Just work’ 원칙)
- 복잡한 CRD(Custom Resource Definition)나 설정 파일 없이도 Service Mesh를 빠르게 바로 사용 가능함
- 리소스 효율성
- Linkerd의 프록시는 메모리 사용량이 적으면서 높은 성능을 자랑하는 Rust 언어로 구현됨
- 프록시가 본 애플리케이션의 성능에 미치는 영향을 최소화하고, 적은 리소스로 안정적인 동작이 가능함
- 운영 편의성
- 직관적인 CLI 명령어와 가독성 좋은 대시보드가 제공되어 사용자가 주요 기능을 쉽게 이해하고 활용 가능함
이러한 특징 덕분에, Linkerd는 Kubernetes를 사용하지만 규모가 크지 않은 팀에게 부담이 적은 선택지가 되어줍니다.
게다가 Linkerd도 Istio와 마찬가지로 CNCF의 Graduated(졸업) 프로젝트로서 안정성과 지속 가능성을 인정받았습니다.
🔎Linkerd의 핵심 아키텍처 훑어보기
(Linkerd의 Data Plane은 각 Pod에 사이드카 컨테이너로 배포된 프록시들로 구성됩니다.)
Linkerd의 구성요소는 아래와 같이 크게 Control Plane과 Data Plane으로 나뉘는데요.
- Control Plane:
- Service Mesh 전체의 정책 관리
- 설정 정보 제공
- 집계된 원격 측정(Telemetry) 데이터 수집
- Data Plane:
- 실제 애플리케이션 트래픽을 처리하는 사이드카 프록시로 구성
- Control Plane으로부터 지시를 받아 동작
Control Plane은 Data Plane의 프록시들이 올바르게 동작하는 데에 필요한 모든 정보를 제공합니다. 여기엔 서비스 디스커버리 정보부터 라우팅 정책, 보안 정책(예: mTLS 인증서) 등이 포함되죠.
또한 각 프록시로부터 수집된 성공률, 지연 시간 등의 원격 측정 데이터를 집계하는 역할도 Control Plane이 수행합니다.
사용자는 CLI나 대시보드를 통해 Control Plane과 상호작용하며 Mesh를 관리합니다.
Linkerd의 Data Plane은 각 애플리케이션의 Pod와 함께 배포되는 초경량 사이드카 프록시인 linkerd-proxy로 이루어집니다.
이 프록시가 해당 Pod로 들어오고 나가는 모든 TCP 트래픽(HTTP, gRPC 등)을 가져온 다음, mTLS 암호화, 로드 밸런싱, 재시도, 타임아웃, 메트릭 수집 등 수행하는 것입니다.
이런 다양한 기능들을 애플리케이션 코드를 전혀 수정하지 않고도 사용 가능하다면 믿어지시나요?
Linkerd는 자동 프록시 주입(Automatic Proxy Injection)이라는 기능을 제공하기 때문에, Kubernetes의 특정 Namespace에 어노테이션(linkerd.io/inject: enabled)을 설정하거나, Deployment와 같은 Workload 매니페스트에 직접 어노테이션을 추가하기만 하면 된답니다.
그러면 어노테이션을 추가한 Namespace나 Workload에서 새로운 Pod가 생성될 때 Linkerd의 사이드카 프록시가 자동으로 함께 생성되는 것이죠.
지금까지 Linkerd의 구조와 동작 방식에 대해 알아봤으니, 다음은 Linkerd의 핵심 기능을 살펴볼 차례입니다.
🛠️Linkerd가 제공하는 핵심 기능 미리보기
1. 보안성 측면
Linkerd는 Control Plane의 인증서 관리 기능을 통해, Service Mesh 내부에 있는 모든 서비스 간의 통신에 대해 상호 TLS(mTLS) 암호화를 기본적으로 활성화할 수 있습니다.
그래서 별도의 설정 없이도 데이터의 기밀성과 무결성을 보장하며, 중간자 공격과 같은 위협으로부터 서비스를 보호할 수 있게 됩니다. 즉, 제로 트러스트(Zero-Trust) 네트워크 보안 원칙을 쉽게 구현할 수 있는 것입니다.
제로 트러스트 보안 원칙이란?
제로 트러스트 보안 원칙은 ‘아무것도 신뢰하지 않는다’는 철학을 바탕으로 설계된 것입니다.
모든 사용자, 디바이스, 컴포넌트를 잠재적 위협 요소로 간주하는 원칙인데요.
기존의 ‘경계 기반 보안’과는 달리, 네트워크 내/외부와 상관없이 모든 접속에 대해 엄격한 인증과 승인을 적용하여 보안을 강화하고자 하는 것입니다.
2. 트래픽 관리 측면
일시적인 네트워크 문제나 서비스 과부하로 인해 발생하는 간헐적인 요청 실패는 시스템 전체의 안전성을 저해할 수 있습니다.
그래서 Linkerd는 HTTPRoute(Gateway API)이라는 리소스를 통해, 특정 서비스나 경로에 대해 자동으로 요청을 재시도하거나 응답 대기 시간(타임아웃)을 설정하는 기능을 제공합니다.
그 외에도 Linkerd는 트래픽 분할과 같은 고급 라우팅 규칙 설정이나, 다양한 배포 전략(카나리 배포, Blue/Green 배포 등)도 구현 가능합니다.
3. 관찰 가능성 측면
Linkerd의 Data Plane 프록시는 모든 요청과 응답에 대한 성공률(Success Rate, SR), 요청량(Requests Per Second, RPS), 지연 시간(지연 시간 분포 백분위수)과 같은 주요 성능 지표(Golden Metrics)를 자동으로 수집합니다.
지연 시간 분포 백분위수란?
특정 시간 동안 요청 처리 지연 시간을 측정하여 해당 시간 내에서 특정 백분위수에 해당하는 지연 시간을 나타내는 지표입니다.
예를 들어, 99번째 백분위수(P99)는 전체 지연 시간 데이터 중 하위 99%에 해당하는 지연 시간 값으로, 상위 1%의 지연 시간 값을 의미합니다.
이런 메트릭은 Control Plane을 통해 집계되어 대시보드나 CLI로 쉽게 확인 가능한데요. 이를 통해 개발자와 운영자는 애플리케이션의 상태를 실시간으로 파악하고 문제를 신속하게 진단 가능합니다.
(출처: https://linkerd.io/2-edge/features/dashboard/)
💪Linkerd를 도입하면 우리 팀이 어떻게 달라질까?
Linkerd를 도입하면 팀에 어떤 변화가 있을지 지금까지의 내용을 토대로 전체적으로 정리했습니다. 이번 주제에 대해 복습하는 차원에서 확인해보시면 좋을 것 같습니다.
- Linkerd 도입은 개발자가 비즈니스 로직에 더 집중하도록 도와준다.
- Linkerd가 서비스 간 통신, 보안, 관찰 가능성과 같은 복잡한 인프라 문제를 처리해주므로, 개발자는 애플리케이션의 핵심 비즈니스 로직 개발에 더 집중할 수 있고 개발 생산성이 향상된다.
- Linkerd는 점진적인 도입과 확장이 가능하여 Service Mesh를 효과적으로 활용할 수 있다.
- 특정 Namespace나 서비스로부터 시작해서 점진적으로 Service Mesh를 도입할 수 있도록 설계되었기 때문에, 기존에 운영 중인 시스템에도 안정적으로 도입하고 확장할 수 있다.
- Linkerd는 운영팀의 서비스 가시성을 향상시켜 장애 진단 소요 시간을 단축시킨다.
- 풍부한 원격 측정 데이터와 직관적인 대시보드 덕분에 운영팀이 문제의 원인을 신속하게 파악하고 문제를 해결할 수 있다.
- Linkerd는 클러스터 전체의 보안 수준을 강화한다.
- Linkerd의 mTLS 기능 등으로 Service Mesh 내 모든 통신을 암호화하여 데이터 유출 및 변조 위험을 최소화할 수 있다.
- Linkerd를 통해 더 안정적이고 탄력적인 마이크로서비스 운영 환경을 구축할 수 있다.
- Linkerd의 자동 재시도 및 타임아웃과 같은 기능으로 일시적인 장애로부터 시스템을 보호하고 서비스의 안정성도 높일 수 있다.
🔭마무리
이렇게 Linkerd의 구조와 주요 기능까지 살펴봤는데요. 어떠신가요? Linkerd에 대해 흥미가 좀 더 생기셨나요?
Linkerd의 핵심 구성요소와 기능을 최대한 알기 쉽게 풀어서 정리했으니 Service Mesh와 Linkerd에 대해 궁금하셨던 분들에게 도움이 되었길 바랍니다.
이번 글에선 Linkerd의 개념을 말로 풀어서 설명했지만, 이론만 짚고 넘어가기엔 너무 중요한 주제여서 다음 글에서 Linkerd의 핵심 기능을 직접 사용해보는 실습을 진행해보려 합니다.
실습 가이드 역시 핵심 기능만 컴팩트하게 다뤄볼 예정이니 부담 없이 함께 진행하실 수 있을 겁니다.
그럼 다음 글에서 뵙겠습니다.
감사합니다.