Service Mesh
A service mesh is a dedicated infrastructure layer built into applications to handle service-to-service communication, providing reliable, observable, and secur...
Service Mesh는 마이크로서비스 아키텍처 내에서 서비스 간 통신을 처리하기 위한 전용 인프라 계층입니다. 애플리케이션 코드에서 서비스 간 통신의 복잡성을 추상화하여 서비스 네트워크를 관리하고 관찰할 수 있는 투명한 방법을 제공합니다. 일반적으로 각 서비스 인스턴스와 함께 배포되는 경량 네트워크 프록시(sidecar) 세트로 구현되며, Service Mesh는 모든 인바운드 및 아웃바운드 네트워크 트래픽을 가로챕니다. 제어 평면은 이러한 프록시를 관리하고 구성하여 정교한 트래픽 라우팅(예: canary 배포, A/B 테스트), 로드 밸런싱, 서비스 검색 및 보안 정책(예: 상호 TLS 인증, 권한 부여)과 같은 기능을 활성화합니다. Service Mesh는 모든 서비스 상호 작용에 대한 자세한 메트릭, 로그 및 추적을 자동으로 수집하여 애플리케이션 성능 및 동작에 대한 깊은 통찰력을 제공하는 관찰 가능성이 주요 이점입니다. 단점으로는 운영 복잡성 증가, 프록시 계층으로 인한 잠재적 지연, sidecar 프록시 실행으로 인한 리소스 오버헤드가 있습니다. 그러나 개별 마이크로서비스에서 교차 관심사를 외부화함으로써 복원력 있고 안전하며 관찰 가능한 분산 시스템의 개발을 크게 단순화합니다.
graph LR
Center["Service Mesh"]:::main
Rel_advanced_propulsion_systems["advanced-propulsion-systems"]:::related -.-> Center
click Rel_advanced_propulsion_systems "/terms/advanced-propulsion-systems"
Rel_microservices["microservices"]:::related -.-> Center
click Rel_microservices "/terms/microservices"
Rel_observability["observability"]:::related -.-> Center
click Rel_observability "/terms/observability"
classDef main fill:#7c3aed,stroke:#8b5cf6,stroke-width:2px,color:white,font-weight:bold,rx:5,ry:5;
classDef pre fill:#0f172a,stroke:#3b82f6,color:#94a3b8,rx:5,ry:5;
classDef child fill:#0f172a,stroke:#10b981,color:#94a3b8,rx:5,ry:5;
classDef related fill:#0f172a,stroke:#8b5cf6,stroke-dasharray: 5 5,color:#94a3b8,rx:5,ry:5;
linkStyle default stroke:#4b5563,stroke-width:2px;
🧒 5살도 이해할 수 있게 설명
공장 내의 모든 작은 헬퍼 로봇들을 위한 매우 똑똑한 교통 관제사와 같습니다. 로봇들이 스스로 교통을 통제하는 방법을 알 필요 없이, 서로 안전하고 효율적으로 대화할 수 있도록 합니다.
🤓 Expert Deep Dive
A service mesh abstracts the complexities of inter-service communication within a microservices architecture by deploying a network of lightweight proxies, known as sidecars, alongside each service instance. These sidecars intercept all inbound and outbound network traffic for their associated service. The control plane then configures and manages these sidecars, enforcing policies and providing telemetry.
Key components include:
Data Plane: Composed of the sidecar proxies (e.g., Envoy, Nginx). These proxies handle traffic routing, load balancing, TLS termination, authentication, authorization, and metrics collection. They typically operate at Layer 7 (HTTP/gRPC) but can also handle TCP traffic.
Control Plane: Manages and configures the data plane proxies. It exposes APIs for configuration, service discovery, policy enforcement, and telemetry aggregation. Examples include Istio (using Pilot, Citadel, Galley), Linkerd, and Consul Connect.
Architecturally, the sidecar pattern is crucial. A service A intending to communicate with service B doesn't directly connect to B. Instead, A sends its request to its local sidecar proxy. This proxy, configured by the control plane, then handles the network hop to B's sidecar proxy, which forwards it to service B. This allows for features like mutual TLS (mTLS) for secure communication, sophisticated routing rules (e.g., canary deployments, A/B testing), circuit breaking, rate limiting, and distributed tracing without developers needing to implement these concerns in their application logic. Protocols like xDS (Discovery Service) are fundamental for dynamic configuration updates between the control plane and data plane proxies.