왜 Service Mesh는 절대 성공하지 못했는가 (엄청나게 강력함에도 불구하고)

Source: Dev.to

위의 소스 링크 아래에 번역하고자 하는 텍스트를 제공해 주시면, 해당 내용을 한국어로 번역해 드리겠습니다. (코드 블록, URL 및 마크다운 형식은 그대로 유지됩니다.)

약속은 실제였다

Years ago, when AWS announced App Mesh at re:Invent, I tested it with a few microservices to see the interconnections between them. The benefits were genuinely impressive:

서비스 메시가 해결하는 문제

• Instant visibility – 모든 서비스 간 트래픽 흐름을 실시간으로 확인합니다.
• Performance insights – 50–200개의 마이크로서비스 전반에 걸친 병목 현상을 한눈에 파악합니다.
• Automatic troubleshooting – 고위 SRE만이 아니라 누구나 장애를 정확히 찾아낼 수 있습니다.
• Zero‑trust security – 모든 서비스 간 mTLS 암호화를 자동으로 적용합니다.

Before service mesh, only the most experienced engineers could diagnose issues across complex microservice architectures. Service mesh democratized observability.

Source: …

인프라 수준 회로 차단기

Kubernetes 생태계를 검토하면서 Istio가 다시 눈에 들어왔습니다. 이전에 놓쳤던 기능을 발견했는데, 바로 인프라 수준 회로 차단기입니다.

집의 전기 회로 차단기를 생각해 보세요. 과부하가 걸리면 즉시 차단되어 손상을 방지합니다. 서비스 메시는 여러분의 서비스에 대해 동일한 역할을 수행합니다.

회로 차단기 없이

1. 결제 서비스 데이터베이스가 다운됩니다.
2. 체크아웃 서비스가 요청을 계속 보냅니다(각 5초 타임아웃).
3. 체크아웃 스레드가 대기하면서 쌓입니다.
4. 체크아웃 서비스가 자원을 고갈시킵니다.
5. 전체 시스템이 연쇄적으로 실패합니다.

회로 차단기와 함께 (Istio 사용)

1. 결제 서비스 데이터베이스가 다운됩니다.
2. 회로 차단기가 5번 시도 후 실패를 감지합니다.
3. 회로가 “열림” 상태가 되어 즉시 요청을 중단합니다.
4. 체크아웃 서비스가 대기 대신 빠른 오류를 반환합니다.
5. 시스템이 점진적으로 감소하며, 충돌하지 않습니다.
6. 30초 후 회로가 다시 시도합니다(반열림 상태).
7. 성공하면 회로가 닫히고 정상 운영이 재개됩니다.

핵심 포인트? Istio는 애플리케이션 코드를 건드리지 않고 인프라 수준에서 이를 처리합니다. 개발자는 각 서비스마다 복잡한 재시도 로직, 타임아웃 처리, 실패 감지를 구현할 필요가 없습니다.

왜 서비스 메시는 보편적이지 않은가

사이드카 프록시 오버헤드

• 서비스 메시는 사이드카 프록시를 모든 파드에 추가합니다. 쿠버네티스에서는 파드당 추가 컨테이너가 하나 더 생겨 이를 설정·관리·문제 해결해야 합니다.
• Helm 차트나 Terraform 모듈이 일부 복잡성을 가릴 수는 있지만, 문제가 발생했을 때는 애플리케이션 로직 및 메시 설정을 모두 디버깅해야 하므로 인지 부하가 사실상 두 배가 됩니다.

비용 고려 사항

인프라 오버헤드

• 각 파드는 추가 사이드카 프록시를 실행하므로 CPU와 메모리를 추가로 소비합니다.
• 트래픽 패턴에 따라 30–90 % 정도의 컴퓨팅 비용 증가가 예상됩니다.
• 100노드 클러스터는 동일한 워크로드를 처리하기 위해 130–190 노드가 필요할 수 있습니다.

가시성 비용

• Prometheus/Grafana 로 전송되는 방대한 텔레메트리 데이터 양.
• AWS X‑Ray(분산 추적)는 수신된 트레이스당 요금을 부과하며, 트래픽에 비례해 비용이 증가합니다.
• 높은 트래픽(1 000+ req/s)에서는 AWS X‑Ray 비용이 $1 400+/월에 달할 수 있습니다.

실제 사례

AWS X‑Ray의 요청당 요금 모델과 비교했을 때, 비용 충격은 많은 팀이 대규모로 서비스 메시를 포기하는 이유를 설명합니다.

서비스 메시가 의미가 있을 때

• 대규모 조직(20 + 마이크로서비스, 여러 팀)
• 엄격한 보안/컴플라이언스 요구사항(필수 mTLS)
• 문제 해결 시간 절감이 비용을 정당화하는 복잡한 아키텍처

의미가 없는 경우

• 소규모 팀 (< 10 서비스)
• 비용에 민감한 환경
• 단순한 아키텍처

Takeaway

서비스 메시는 강력하지만 비용이 많이 듭니다. 많은 사용 사례에서 대부분의 이점은 애플리케이션 수준 계측을 통해 비용의 일부만으로도 달성할 수 있습니다. 운영 및 재정적 오버헤드보다 고급 기능이 진정으로 더 큰 가치를 제공하는 시나리오에만 서비스 메시를 사용하십시오.