

당근이 AWS CloudHSM으로 대규모 서명키 관리 시스템을 구축한 방법– 2부: CloudHSM 아키텍처와 다계층 접근 제어
AWS CloudHSM 기반 서명 시스템을 네트워크·애플리케이션·HSM 내부의 3계층으로 보호하는 구조를 소개했습니다. Istio, Kyverno, mTLS, 키 속성 설정으로 허용된 경로에서만 서명되도록 설계했습니다.


AWS CloudHSM 기반 서명 시스템을 네트워크·애플리케이션·HSM 내부의 3계층으로 보호하는 구조를 소개했습니다. Istio, Kyverno, mTLS, 키 속성 설정으로 허용된 경로에서만 서명되도록 설계했습니다.

Istio Ambient mode 운영 중 만난 507 응답과 istiod disconnected 탐지 사례를 정리했습니다. Envoy buffer limit과 xDS 연결 상태를 어떻게 바라볼지 설명했습니다.

Istio Ambient mode 업그레이드를 istiod, istio-cni, ztunnel로 나눠 안전하게 진행하는 순서를 정리했습니다. 특히 ztunnel은 rolling update보다 node pool blue-green 방식이 더 안전하다고 설명했습니다.

Ambient mode에서 Pod은 Ready인데 mesh 트래픽이 실패하는 partially enrolled 문제를 다뤘습니다. istio-cni 준비 전에는 일반 Pod이 스케줄되지 않도록 startup taint와 untaint-controller를 활용했습니다.

Istio Ambient mode에서 워크로드 재시작 시 간헐적 503이 발생한 원인을 추적했습니다. 오래된 HBONE connection 재사용과 ztunnel의 graceful close 부재가 핵심이었고, reset retry로 증상을 완화했습니다.

Istio Ambient mode에서 Pod IP 재사용과 stale connection 재사용이 겹쳐 간헐적 503이 발생했습니다. 로그와 pcap, socket을 교차 검증하고 reset retry로 증상을 완화했습니다.

Kubernetes 환경에 LLM 서빙 최적화 기술을 도입하며 발생한 충돌과 해결 과정을 공유했습니다. Istio, 스케줄러, Pod 보호 정책과의 실전 문제를 진단한 사례입니다.

Istio Ambient mode의 요청 흐름을 Envoy config와 트래픽 경로로 단계별로 해부했습니다.\nHBONE, ztunnel, Waypoint가 어떻게 구현되는지 실제 설정 기준으로 설명했습니다.
쿠팡 파트너스
이 게시물은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다.

Istio Ambient mode의 요청 흐름을 Envoy config와 트래픽 경로로 해부했습니다. Gateway, Waypoint, ztunnel이 어떻게 HBONE과 리다이렉션을 구현하는지 정리했습니다.

채널코퍼레이션이 Istio를 프로덕션에 도입하며 Sidecar 대신 Ambient mode를 선택한 배경을 정리했습니다. 또한 ztunnel, waypoint, HBONE 기반의 동작 원리와 장단점을 개괄했습니다.

Istio 서비스 메시 도입 배경과 Ambient mode 선택 이유를 정리했습니다. Sidecar보다 자원 효율과 확장성이 좋지만, 운영 복잡도와 장애 영향 범위 확대라는 단점도 함께 다뤘습니다.
Stage 환경에서 Locust 트래픽을 기반으로 카오스 실험 결과를 정리했습니다. Pod 지연과 외부 API 차단이 서비스와 사용자 경험에 미치는 영향을 확인하고 개선 포인트를 도출했습니다.