쿠버네티스 인그레스 vs 게이트웨이 API: 라우팅 전환
쿠버네티스에서 클러스터 외부 트래픽을 서비스로 흘려보내는 표준은 오랫동안 Ingress였습니다. 그런데 조금만 요구사항이 복잡해져도 Ingress의 한계에 부딪혀 컨트롤러별 애너테이션 지옥에 빠지곤 했습니다. 카나리 배포, 헤더 기반 라우팅,…
쿠버네티스에서 클러스터 외부 트래픽을 서비스로 흘려보내는 표준은 오랫동안 Ingress였습니다. 그런데 조금만 요구사항이 복잡해져도 Ingress의 한계에 부딪혀 컨트롤러별 애너테이션 지옥에 빠지곤 했습니다. 카나리 배포, 헤더 기반 라우팅,…
비동기 메시징을 도입하면 거의 필연적으로 “같은 메시지가 두 번 처리됐다”는 사고를 겪습니다. 결제가 두 번 청구되고 재고가 두 번 차감됩니다. 대부분의 브로커가 기본 보장하는 것이 at-least-once(최소…
단일 리전에서 안정적으로 돌아가던 서비스도 리전 전체 장애 앞에서는 무력합니다. 가용 영역(AZ) 하나가 죽는 상황은 멀티 AZ 배치로 흡수할 수 있지만, 특정 리전 전체가 네트워크·전원·컨트롤 플레인…
사용자가 서울에 있고 오리진 서버가 미국 동부 리전에 있다면, 요청 하나가 왕복하는 데만 물리적으로 200ms 이상이 소요됩니다. 광속은 협상 대상이 아니므로, 지연을 줄이는 유일한 방법은 연산과…
쿠버네티스를 운영하다 보면 “잘 돌던 파드가 갑자기 재시작됐다”는 상황을 반복적으로 만납니다. kubectl get pods를 보면 RESTARTS가 올라가 있고, 상세에는 OOMKilled 또는 Evicted가 찍혀 있습니다. 둘 다…
마이크로서비스가 열 개를 넘어가는 순간, “이 요청이 왜 느린가”라는 질문에 답하기가 급격히 어려워집니다. 게이트웨이에서 결제·재고·알림 서비스를 거쳐 데이터베이스까지 이어지는 호출 경로를 로그만으로 재구성하는 것은 사실상 불가능합니다.…
프로덕션에서 “왜 이 요청이 느린가”를 추적하다 보면 애플리케이션 로그만으로는 부족한 순간이 옵니다. 커넥션이 어디서 끊겼는지, 어떤 시스템콜에서 블로킹됐는지는 커널의 관점에서만 정확히 답할 수 있습니다. 전통적으로 이런…
새 버전을 프로덕션에 올리기 직전, “실제 트래픽에서는 어떻게 동작할까”라는 질문에 명쾌하게 답할 수 있는 팀은 많지 않습니다. 스테이징을 통과한 코드가 실 사용자 요청 패턴, 특정 헤더…
리드 레플리카는 읽기 부하를 분산하는 가장 손쉬운 확장 수단이지만, 동시에 서비스 데이터 정합성을 가장 흔하게 무너뜨리는 원인이기도 합니다. 방금 작성한 글이 목록에서 사라지거나 결제 직후 잔액이…
동시 접속 수만 건을 처리하는 서버를 운영하다 보면, 애플리케이션 코드는 최적화가 끝났는데도 처리량이 어느 지점에서 벽에 부딪히는 경험을 하게 됩니다. CPU도 메모리도 여유가 있는데 새 연결이…