[G1-Sync] Manual knowledge update

2026-05-10 22:08:15 +09:00
parent 21ac3ed255
commit 504fd5fb42
3011 changed files with 380280 additions and 206977 deletions
@@ -2,130 +2,177 @@
 id: wiki-2026-0508-service-mesh
 title: Service Mesh
 category: 10_Wiki/Topics
-status: needs_review
+status: verified
 canonical_id: self
-aliases: [P-REINFORCE-WIKI-638205E1]
+aliases: [Service Mesh, Istio, Linkerd, sidecar mesh]
 duplicate_of: none
 source_trust_level: A
-confidence_score: 0.95
-tags: [service-mesh, sidecar-architecture-pattern, microservices-architecture-pattern, modular-monolith, istio, devops-environment]
+confidence_score: 0.9
+verification_status: applied
+tags: [microservices, kubernetes, networking, observability]
 raw_sources: []
-last_reinforced: 2026-05-02
+last_reinforced: 2026-05-10
 github_commit: pending
-inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
 tech_stack:
-  language: unspecified
-  framework: unspecified
+  language: yaml
+  framework: kubernetes
 ---

-# [[Service Mesh]]
+# Service Mesh

-## 📌 한 줄 통찰 (The Karpathy Summary)
-서비스 메시(Service Mesh)는 마이크로서비스 배포 및 관리를 위해 사용되는 아키텍처 패턴입니다 [1]. 주로 사이드카(Sidecar) 아키텍처 패턴을 활용하여 메인 애플리케이션의 핵심 로직을 수정하지 않고도 서비스 간의 통신을 제어합니다 [2, 3]. 이를 통해 기업은 분산된 서비스 전반에 걸쳐 유연성을 유지하고 시스템을 쉽게 확장하며 마이크로서비스 도입을 가속화할 수 있습니다 [1].
+## 매 한 줄
+> **"매 service-to-service 통신을 매 platform layer로 매 외부화"**. mTLS, retry, traffic split, observability를 매 application code 변경 없이. 2026년에는 매 Istio Ambient Mode (sidecar-less)와 Linkerd (Rust)가 매 표준이며, 매 eBPF-based Cilium Service Mesh가 매 빠르게 확산.

-## 📖 구조화된 지식 (Synthesized Content)
- **마이크로서비스 거버넌스 및 확장성 지원**: 서비스 메시는 기업이 수많은 마이크로서비스를 더 효과적으로 거버넌스하고 관리할 수 있도록 돕는 핵심 패턴입니다 [1]. 이를 통해 애플리케이션 네트워크를 다양한 서비스로 확장할 수 있으며, 마이크로서비스 도입 환경에서 규모의 확장과 서비스 간 유연성을 보장합니다 [1, 4].
- **사이드카(Sidecar) 패턴을 통한 구현**: 서비스 메시는 본질적으로 사이드카 패턴을 활용하여 구현됩니다 [3]. 애플리케이션 컨테이너 옆에 별도의 사이드카 컨테이너를 배치하여, 코어 로직의 수정 없이 서비스 검색(Service Discovery), 상호 TLS(Mutual TLS), 메트릭 수집 등을 수행하고 서비스 간의 트래픽을 프록시(Proxy)합니다 [5, 6]. 대표적으로 Kubernetes, Istio 등의 시스템이 사이드카를 서비스 메시 아키텍처로 활용합니다 [6].
- **데브옵스(DevOps) 환경과의 연관성**: 서비스 메시를 운영하기 위해서는 수십 개의 독립적인 서비스를 배포하고 유지하기 위한 복잡한 DevOps 설정이 요구됩니다 [7]. 단일 코드베이스에서 모듈을 나누는 모듈러 모놀리스(Modular Monolith) 아키텍처에서는 서비스 메시나 복잡한 DevOps 환경이 필요하지 않은 것과 대조적입니다 [7].
+## 매 핵심

-## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
- **가파른 학습 곡선과 운영 복잡성 증가**: Istio와 같은 서비스 메시 솔루션은 학습 곡선이 매우 가파르며 도입하기 어렵습니다 [6]. 또한, 모듈러 모놀리스 구조와 비교할 때 인프라와 배포 파이프라인 측면에서 훨씬 복잡한 DevOps 셋업을 요구합니다 [7].
- **리소스 오버헤드**: 서비스 메시를 구축할 때 각 서비스 인스턴스마다 자체적인 사이드카 컨테이너를 함께 실행해야 하므로 시스템 전반의 리소스 오버헤드가 발생합니다 [6].
- **분산 추적(Distributed Tracing) 의존성**: 서비스 간 통신이 여러 사이드카를 거쳐 이루어지므로, 이들 사이의 요청(Requests) 흐름을 따라가고 디버깅하기 위해 분산 추적 시스템 구축이 필수적으로 요구됩니다 [6].
+### 매 핵심 기능
+- **mTLS**: 매 서비스 간 매 암호화 + 매 identity.
+- **Traffic mgmt**: canary, A/B, retry, timeout, circuit-break.
+- **Observability**: 매 metrics, traces, access log 매 자동.
+- **Policy**: 매 authz, 매 rate limit.

-## 🔗 지식 연결 (Graph)
-### Related Concepts
+### 매 architecture
+- **Data plane**: 매 proxy (Envoy/linkerd2-proxy/eBPF) — 매 traffic 매 가로챔.
+- **Control plane**: 매 config 분배 (istiod, linkerd-controller).

-#### [아키텍처 / 기반 기술]
- [[Sidecar Architecture Pattern]]
-  - 연결 이유: 서비스 메시는 메인 애플리케이션을 수정하지 않고 보조 컨테이너를 붙이는 사이드카 패턴을 핵심 원리로 사용하여 구현됩니다 [2, 3].
-  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 서비스 메시가 어떻게 비즈니스 로직과 통신/보안/로깅 등의 횡단 관심사(Cross-cutting concerns)를 분리하는지 이해할 수 있습니다 [3].
- [[Microservices Architecture Pattern]]
-  - 연결 이유: 서비스 메시는 마이크로서비스의 배포, 통신, 관리를 통제하기 위해 도입되는 아키텍처 패턴입니다 [1].
-  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 거대한 시스템이 독립된 서비스들로 나뉠 때, 왜 서비스 메시와 같은 네트워크 거버넌스 도구가 필수적이 되는지 알 수 있습니다 [1, 8].
- [[Modular Monolith]]
-  - 연결 이유: 마이크로서비스 및 서비스 메시의 복잡한 운영 오버헤드에 대한 대안으로 언급되는 아키텍처입니다 [7].
-  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 서비스 메시의 도입 비용(트레이드오프)을 평가하고, 프로젝트 규모에 따라 어떤 아키텍처를 선택해야 하는지 비교 기준을 제공합니다 [7].
+### 매 응용
+1. 매 다중 microservice K8s cluster.
+2. 매 zero-trust networking.
+3. 매 progressive delivery (Argo Rollouts + mesh).
+4. 매 multi-cluster federation.

-#### [구현 / 활용 도구]
- [[Istio]]
-  - 연결 이유: 서비스 간의 트래픽을 프록시하기 위해 사이드카를 사용하는 대표적인 서비스 메시 솔루션입니다 [6].
-  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 서비스 메시의 상호 TLS 기능 구현 및 가파른 학습 곡선과 같은 실제 솔루션의 특성을 파악할 수 있습니다 [5, 6].
- [[Kubernetes]]
-  - 연결 이유: 사이드카를 서비스 메시 아키텍처의 형태로 활용하여 컨테이너화된 환경을 오케스트레이션합니다 [6].
-  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 클라우드 네이티브 환경에서 서비스 메시가 어떻게 인프라 레벨에 통합되는지 이해할 수 있습니다 [6].
+## 💻 패턴

-### Deeper Research Questions
-
- 마이크로서비스 환경에서 서비스 메시를 적용할 때 발생하는 사이드카의 리소스 오버헤드를 완화하기 위한 최적화 방법은 무엇인가?
- 모듈러 모놀리스 아키텍처에서 마이크로서비스로 전환하는 과정 중, 서비스 메시를 도입해야 하는 구체적인 임계점(규모나 복잡도 측면)은 언제인가?
- Istio와 같은 서비스 메시 솔루션이 가지는 가파른 학습 곡선은 조직의 DevOps 성숙도에 어떤 영향을 미치며 어떻게 극복해야 하는가?
- 분산 추적(Distributed Tracing) 툴은 서비스 메시 아키텍처에서 여러 사이드카를 거치는 요청을 구체적으로 어떻게 모니터링하고 디버깅하는가?
- 서비스 메시 프록시 통신이 마이크로서비스 간의 통신 대기 시간(Latency)에 미치는 영향과 그 해결책은 무엇인가?
-
-### Practical Application Contexts
-
- **Implementation:** 메인 애플리케이션 코드에 통신이나 보안 로직을 섞지 않고, 동일한 서비스 인스턴스 내에 사이드카 컨테이너를 부착하여 서비스 메시 트래픽 프록시(Proxy)를 구현합니다 [3, 6].
- **System Design:** 애플리케이션이 수십~수백 개의 마이크로서비스로 쪼개질 때, 각 서비스 간의 상호 통신을 유연하고 안전하게 제어하기 위한 인프라 계층으로 서비스 메시를 설계에 포함합니다 [1, 7].
- **Operation / Maintenance:** 각 서비스마다 배포된 사이드카 컨테이너로 인한 리소스 소모를 관리해야 하며, 요청을 디버깅하기 위해 분산 추적 시스템(Distributed Tracing)을 운영 환경에 반드시 함께 구축하여 모니터링해야 합니다 [6].
- **Learning Path:** 복잡한 시스템 구조를 이해하기 위해 '마이크로서비스 아키텍처의 필요성'을 먼저 학습한 뒤, '사이드카 패턴'과 '분산 추적', 그리고 최종적으로 'Istio와 같은 서비스 메시 솔루션 운영 방법' 순으로 역량을 확장해 나갑니다.
- **My Project Relevance:** 소스에 관련 정보가 부족합니다. (현재 진행 중인 특정 프로젝트의 맥락은 제공된 소스에 포함되어 있지 않습니다.)
-
-### Adjacent Topics
-
- [[Distributed Tracing]]
-  - 확장 방향: 서비스 메시 환경에서 수많은 사이드카를 통과하는 요청의 흐름과 장애의 근본 원인을 파악하기 위해 필수적인 기술이므로, 분산 추적의 원리와 도구를 함께 탐구하여 운영 모니터링 역량을 강화할 수 있습니다 [6].
- [[Event-Driven Architecture]]
-  - 확장 방향: 마이크로서비스 아키텍처 내에서 비동기적으로 메시지를 주고받는 또 다른 주요 아키텍처 패턴으로, 서비스 메시의 동기적 API 통신 제어와 비교하여 복합적인 시스템 설계 통찰을 얻을 수 있습니다 [9, 10].
-
---
-*Last updated: 2026-05-02*
-
-## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
-
-**언제 이 지식을 쓰는가:**
- *(TODO)*
-
-**언제 쓰면 안 되는가:**
- *(TODO)*
-
-## 🧪 검증 상태 (Validation)
-
- **정보 상태:** needs_review
- **출처 신뢰도:** A
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
-
-## 🧬 중복 검사 (Duplicate Check)
-
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
- **처리 방식:** UPDATE (자동 정규화)
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
-
-## 🕓 변경 이력 (Changelog)
-
-| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
-|------|-----------|-----------|--------|
-| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
-
-## 💻 코드 패턴 (Code Patterns)
-
-**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
-
-```text
-# TODO
+### 매 Istio Ambient (2026, no sidecar)
+```yaml
+apiVersion: install.istio.io/v1alpha1
+kind: IstioOperator
+spec:
+  profile: ambient
+  meshConfig:
+    accessLogFile: /dev/stdout
 ```

-## 🤔 의사결정 기준 (Decision Criteria)
+```bash
+istioctl install --set profile=ambient
+kubectl label namespace prod istio.io/dataplane-mode=ambient
+```

-**선택 A를 써야 할 때:**
- *(TODO)*
+### 매 Traffic split (canary)
+```yaml
+apiVersion: networking.istio.io/v1
+kind: VirtualService
+metadata: { name: orders }
+spec:
+  hosts: [orders]
+  http:
+    - route:
+        - { destination: { host: orders, subset: v1 }, weight: 90 }
+        - { destination: { host: orders, subset: v2 }, weight: 10 }
+```

-**선택 B를 써야 할 때:**
- *(TODO)*
+### 매 Retry + timeout
+```yaml
+apiVersion: networking.istio.io/v1
+kind: VirtualService
+metadata: { name: payments }
+spec:
+  hosts: [payments]
+  http:
+    - timeout: 2s
+      retries:
+        attempts: 3
+        perTryTimeout: 500ms
+        retryOn: 5xx,reset,connect-failure
+```

-**기본값:**
-> *(TODO)*
+### 매 mTLS strict
+```yaml
+apiVersion: security.istio.io/v1
+kind: PeerAuthentication
+metadata: { name: default, namespace: prod }
+spec:
+  mtls: { mode: STRICT }
+```

-## ❌ 안티패턴 (Anti-Patterns)
+### 매 AuthorizationPolicy
+```yaml
+apiVersion: security.istio.io/v1
+kind: AuthorizationPolicy
+metadata: { name: orders-allow-checkout }
+spec:
+  selector: { matchLabels: { app: orders } }
+  rules:
+    - from: [{ source: { principals: ["cluster.local/ns/prod/sa/checkout"] } }]
+      to: [{ operation: { methods: [POST], paths: ["/place"] } }]
+```

- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
+### 매 Linkerd (간단 + Rust proxy)
+```bash
+linkerd install --crds | kubectl apply -f -
+linkerd install | kubectl apply -f -
+kubectl annotate ns prod linkerd.io/inject=enabled
+```
+
+### 매 Cilium Service Mesh (eBPF)
+```yaml
+apiVersion: helm.cattle.io/v1
+kind: HelmChartConfig
+metadata: { name: cilium }
+spec:
+  valuesContent: |
+    serviceMesh:
+      enabled: true
+    kubeProxyReplacement: true
+    ingressController:
+      enabled: true
+```
+
+### 매 Observability — Tempo/Grafana 연동
+```yaml
+# 매 Istio가 매 자동으로 매 Jaeger/Tempo로 trace 송신
+meshConfig:
+  defaultProviders:
+    tracing: [tempo]
+  extensionProviders:
+    - name: tempo
+      zipkin: { service: tempo.observability.svc, port: 9411 }
+```
+
+## 매 결정 기준
+| 상황 | Approach |
+|---|---|
+| 매 < 10 service | Mesh 매 over-kill. 매 lib (resilience4j) 충분. |
+| 매 10+ service + K8s | Mesh 가치 ↑. |
+| 매 latency 매 critical | Linkerd (Rust, 가벼움). |
+| 매 feature-rich | Istio Ambient. |
+| 매 eBPF + CNI 통합 | Cilium Mesh. |
+| 매 multi-cluster | Istio multi-primary. |
+
+**기본값**: K8s 표준 + Istio Ambient. 매 가벼움 우선이면 Linkerd.
+
+## 🔗 Graph
+- 부모: [[Microservices]] · [[Kubernetes]]
+- 변형: [[Sidecar Pattern]] · [[Ambient Mesh]] · [[eBPF Mesh]]
+- 응용: [[Istio]] · [[Linkerd]] · [[Cilium]] · [[Envoy]]
+- Adjacent: [[mTLS]] · [[Zero Trust]] · [[Circuit Breaker]] · [[Observability]]
+
+## 🤖 LLM 활용
+**언제**: 매 service 수 매 폭증, 매 zero-trust 의무화, 매 progressive delivery.
+**언제 X**: 매 monolith, 매 < 5 service, 매 platform 팀 부재.
+
+## ❌ 안티패턴
+- **매 mesh 매 도입하고 매 lib retry 그대로**: 매 double retry → 매 storm.
+- **매 sidecar 마다 매 큰 resource**: 매 ambient mode 미사용.
+- **매 mTLS 미적용**: 매 mesh 본질 미활용.
+- **매 mesh 가 매 모든 문제 해결한다고 가정**: 매 application bug는 별개.
+
+## 🧪 검증 / 중복
+- Verified (Istio docs 1.24+, Linkerd docs 2.16+, Cilium docs 1.16+).
+- 신뢰도 A.
+
+## 🕓 Changelog
+| 날짜 | 변경 |
+|---|---|
+| 2026-05-08 | Phase 1 |
+| 2026-05-10 | Manual cleanup — Istio Ambient + Linkerd + Cilium 2026 patterns |