N° 01 — 목록
'service-mesh' (3)
-
Infra Architecture/Datacenter & CloudDatacenter & Cloud - 08. Cloud Native 플랫폼
클라우드 네이티브란 무엇인가 — Cloud Native 플랫폼 개관2013년, Netflix는 자체 데이터센터를 AWS로 완전히 이전했다. 당시에는 "미친 짓"으로 불렸다 — 자기 핵심 인프라를 남에게 맡긴다는 비판이었다. 하지만 Netflix는 — 이전 과정에서 마이크로서비스·Chaos Engineering·자동 배포 같은 기법을 개발했고, 이 기법들이 모여 "클라우드 네이티브(Cloud Native)"라는 패러다임이 됐다. 2026년 — 클라우드 네이티브는 더 이상 선구자의 선택이 아니라 업계의 기본이다. 이 글은 클라우드 네이티브가 무엇인지, CNCF가 왜 만들어졌는지, GitOps와 Service Mesh가 "운영"에 어떤 의미를 갖는지를 다룬다.이 글은 foundations 06의 IaC 철학과..
-
Software Architecture/Distributed SystemsDistributed Systems - 11. 서비스 디스커버리·게이트웨이
서비스 디스커버리와 API 게이트웨이 — 클라이언트가 어디로 보낼까2016년 한 회사가 30개의 마이크로서비스를 운영했다. 각 서비스의 URL이 설정 파일에 적혀 있었다. 어느 날 인프라팀이 로드 밸런서를 교체하면서 모든 서비스의 IP가 바뀌었다. 설정 파일을 모두 수정하고 재배포하는 데 하루가 걸렸다. 그 사이 프로덕션은 중단됐다. 서비스가 어디 있는지 알아내는 것조차 복잡한 작업이 된 것이다. 또 다른 문제 — 30개 서비스마다 각자 인증, 속도 제한, 로깅을 구현했는데, 코드가 중복되고 정책이 어긋났다. 이 두 문제를 다루는 패턴이 서비스 디스커버리와 API 게이트웨이다. 이 글은 두 패턴과 그 현대적 변형인 서비스 메시까지 다룬다.비유로 감 잡기 — 호텔 프론트 데스크큰 호텔에 왔다고 상상하자. ..
-
Cloud & Infrastructure/Kubernetes NetworkingK8s Networking - 10. service-mesh concepts
왜 모든 앱에 "트래픽 관리 코드"를 중복해서 짜야 할까 — 서비스 메시가 푸는 문제마이크로서비스가 30개로 늘었다. 각 서비스마다 같은 코드가 반복됐다: 재시도, 타임아웃, 서킷 브레이커, 메트릭, 분산 추적, mTLS 인증. 개발자는 비즈니스 로직보다 이 인프라 코드*를 더 짜고 있었다. 그리고 언어마다(Java/Go/Node) 각자 다시 구현했다. 한 팀이 물었다: "이걸 *앱 밖으로 뺄 수 없나?" 서비스 메시(service mesh)가 바로 그 답이다.이 글이 푸는 것은: 서비스 메시가 어떤 문제를 풀고, 사이드카 패턴으로 어떻게 앱 코드에서 인프라 로직을 빼내는가다. 이해하면 11장(Istio)/12장(Cilium 메시)의 설계가 보인다.서비스 간 통신에 필요한 것 — 그리고 그것이 앱마다 중..