N° 01 — 목록
'분류 전체보기' (197)
-
Software Architecture/FoundationsFoundations - 01. 아키텍처란 무엇인가
코드를 짜는 순간, 아키텍처는 이미 정해져 있다집을 지을 때 거실에서 영화를 보고 주방에서 요리하고 침실에서 잔다는 방의 용도가 같아도, 골조를 목조로 세울지 철골 콘크리트로 세울지는 다른 문제다. 지진이 오거나 3층을 증축하려 할 때 결과를 갈라놓는 건 방의 용도가 아니라 이 골조다. 소프트웨어도 비슷하다. 코드가 "무엇을 하는가"를 정하면, 아키텍처는 그 코드가 "어떤 구조로 세워졌는가"를 결정한다. 그리고 벽돌을 쌓는 순간 골조는 이미 정해진다 — "우린 스타트업이라 아키텍처 같은 건 안 한다"는 말이 성립하지 않는다.아키텍처는 부정할 수 없다소프트웨어 아키텍처 분야의 고전 에서 Bass·Clements·Kazman은 아키텍처를 "시스템에 대해 추론할 때 필요한 구조들의 집합"이라 정의한다. 요소,..
-
DevOps & SRE/Disaster RecoveryKafka + CDC 로 재해복구(DR)를 만들면 생기는 일 — DR 설계 여정 #1
재해복구(DR, Disaster Recovery)는 살아 있는 동안은 쓸 일이 없으면서, 막상 필요한 순간에는 모든 것이 걸려 있는 시스템이다. 평소에는 보이지 않다가, 어느 날 데이터센터가 멈췄을 때 "우리가 준비해 둔 것이 살아 있는가?"라는 질문에 답해야 하는 순간이 온다.이 글에서는 CDC(Change Data Capture)와 Kafka를 활용해 DR을 구축하면서 마주한 질문들과 설계 결정을 공유한다. 연재로 진행될 예정이며, 첫 편에서는 DR 설계의 출발점과 아키텍처 방향을 다룬다.왜 CDC + Kafka인가DR을 구축한다고 했을 때 가장 먼저 떠오르는 질문은 "데이터를 어떻게 복제할 것인가"다. 데이터베이스 자체의 복제 기능(물리 복제, 동기 스트리밍)을 쓸 수도 있고, CDC로 변경 사항을..
-
Cloud & Infrastructure/Kubernetes NetworkingK8s Networking - 14. multi-cluster
클러스터 경계를 넘는 서비스 — 멀티클러스터 네트워킹의 두 접근한 조직이 리전별로 클러스터 3개(서울/도쿄/버지니아)를 운영한다. 각 클러스터는 독립적이다 — 그런데 "서울 클러스터의 서비스가 도쿄 클러스터의 서비스를 불러야 한다"는 요구가 생겼다. 인터넷 경유 공개 API로만 부르자니 지연과 보안이 문제다. 멀티클러스터 네트워킹이 이 문제를 푼다 — 클러스터 경계를 넘어 Pod가 마치 같은 클러스터에 있는 것처럼 통신하게.이 글이 푸는 것은: 클러스터 간 Pod/Service 통신을 어떻게 만드는가, Submariner와 Cilium Cluster Mesh 두 접근이 어떻게 다른가다. 02-k8s-networking 영역의 마지막 주제로, 규모가 커질 때의 네트워크 진화를 다룬다.왜 클러스터를 여러 개..
-
Cloud & Infrastructure/Kubernetes NetworkingK8s Networking - 13. troubleshooting
"네트워크가 안 된다"에서 시작해 범인을 좁히는 법 — 트러블슈팅 결정 트리한 서비스가 "DB에 연결이 안 된다"고 보고됐다. 운영자가 1시간을 헤맸다 — Pod가 살아있는지, Service가 있는지, NetworkPolicy가 막는지, CNI가 꼬였는지, DNS가 풀리는지 전부 의심했다. 결국 원인은 conntrack 테이블 만료. 그런데 그 1시간의 대부분은 틀린 층을 뒤진 데 쓰였다. 이 글은 그 1시간을 5분으로 줄이는 결정 트리를 다룬다.이 글이 푸는 것은: "네트워크가 안 된다"는 모호한 증상에서 시작해, 어느 층(DNS/kube-proxy/CNI/정책/커널)인지를 체계적으로 좁히는 절차다. 핵심은 층별로 나눠 한 층씩 검증하는 것이다.먼저 층을 나눈다 — 어디를 의심할 것인가지금까지 01~1..
-
Cloud & Infrastructure/Kubernetes NetworkingK8s Networking - 12. cilium-service-mesh
사이드카 없는 메시가 가능한 이유 — Cilium이 eBPF로 지운 계층한 클러스터에 Pod가 3000개였다. Istio 사이드카를 넣으려 하니 — Envoy 인스턴스 3000개, 자원 오버헤드가 어마어마했다. 메모리만 수십 기가. 팀은 물었다: "Pod마다 프록시를 넣지 않고 메시를 할 수 없나?" Cilium Service Mesh가 그 질문에 답한다 — eBPF가 커널 단에서 메시 기능을 처리해 사이드카를 없앤다.이 글이 푸는 것은: 왜 사이드카 없는 메시가 가능한가, Cilium이 eBPF로 사이드카의 어떤 역할을 흡수하는가, 그리고 Istio/Linkerd와 어떻게 다른가다.사이드카 메시의 비용 — 왜 "없애고" 싶은가10장에서 사이드카 메시(Istio 등)의 비용을 봤다:Pod마다 Envoy ..
-
Cloud & Infrastructure/Kubernetes NetworkingK8s Networking - 11. istio
Istiod가 수천 개의 Envoy를 어떻게 조율하는가 — 그리고 Ambient가 바꾸는 것한 팀이 Istio를 도입했다. 500개의 Pod에 사이드카(Envoy)가 하나씩 들어갔다. 그 500개의 Envoy에게 "서비스 간 mTLS, 카나리 규칙, 분산 추적"을 어떻게 일관되게 적용할까? 사람이 500대를 돌며 설정할 수는 없다. Istiod가 그 조율을 담당한다 — 컨트롤플레인이 500개의 사이드카를 watch 모델로 지휘한다. 그런데 최근 Istio에 Ambient mesh라는 사이드카 없는 모드가 들어왔다. 이것이 메시의 판도를 어떻게 바꾸나?이 글이 푸는 것은: Istio의 아키텍처(Istiod + Envoy 사이드카), 트래픽 관리 객체(VirtualService/DestinationRule)..