Grafana Mimir에 Kafka를 도입하기 전 미리 알았다면
Grafana Mimir에 Kafka 기반 ingest-storage architecture를 도입한 경험과 운영상의 함정을 정리했습니다. partition과 ingester ordinal의 1:1 결합, backlog replay, scale-in 절차가 핵심 포인트였습니다.

Grafana Mimir에 Kafka 기반 ingest-storage architecture를 도입한 경험과 운영상의 함정을 정리했습니다. partition과 ingester ordinal의 1:1 결합, backlog replay, scale-in 절차가 핵심 포인트였습니다.
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로 증상을 완화했습니다.
채널톡 메인 백엔드 서버의 CI 병목을 단계적으로 분해해 개선한 과정을 정리했습니다. 공유 상태 제거, prepare 분리, 동적 큐와 캐시로 실행 시간을 크게 줄였습니다.
AI가 코드를 빠르게 만들수록 CI 병목과 피드백 속도가 더 중요해졌습니다. 채널톡은 공유 상태 제거와 캐시, 동적 큐로 메인 백엔드 CI를 36.6분에서 15분대까지 줄였습니다.
Istio Ambient mode의 요청 흐름을 Envoy config와 트래픽 경로로 단계별로 해부했습니다. HBONE, ztunnel, Waypoint가 어떻게 구현되는지 실제 설정 기준으로 설명했습니다.
Istio Ambient mode의 요청 흐름을 Envoy config와 트래픽 경로로 해부했습니다. Gateway, Waypoint, ztunnel이 어떻게 HBONE과 리다이렉션을 구현하는지 정리했습니다.
채널코퍼레이션이 Istio를 프로덕션에 도입하며 Sidecar 대신 Ambient mode를 선택한 배경을 정리했습니다. 또한 ztunnel, waypoint, HBONE 기반의 동작 원리와 장단점을 개괄했습니다.
Istio 서비스 메시 도입 배경과 Ambient mode 선택 이유를 정리했습니다. Sidecar보다 자원 효율과 확장성이 좋지만, 운영 복잡도와 장애 영향 범위 확대라는 단점도 함께 다뤘습니다.
문서 전처리 파이프라인의 리소스 경합과 디버깅 어려움을 해결하기 위해 dagster를 도입했습니다. K8sRunLauncher와 코드 로케이션 분리로 안정성과 운영 효율을 높인 사례를 공유했습니다.
문서 전처리 파이프라인의 리소스 경합과 디버깅 어려움을 해결하기 위해 dagster를 도입했습니다. 파드 격리와 대시보드 관측성으로 안정성과 운영 효율을 높였습니다.