🚀 [Istio] 서킷 브레이커 vs K8s Readiness Probe: 완벽한 MSA를 위한 이중 방어막

안녕하세요! 오늘은 마이크로서비스 아키텍처(MSA)를 운영하면서 많은 분들이 한 번쯤 고개를 갸웃하게 되는 주제를 가지고 왔습니다.

"Istio의 서킷 브레이커(Circuit Breaker)는 쿠버네티스의 Readiness Probe랑 똑같은 거 아닌가요? 둘 다 문제 있는 파드에 트래픽 안 보내는 거잖아요?"

 

결론부터 말씀드리면, "결과는 비슷하지만, 과정과 목적은 완전히 다릅니다!" 🙅‍♂️

이 두 가지 기술이 어떻게 다르고, 왜 실무에서는 두 가지를 모두 사용해야 '무중단 서비스'라는 유니콘🦄을 잡을 수 있는지 아주 상세하게 파헤쳐 보겠습니다.

 

 

---

1. 직관적인 이해: 결과는 같지만 방식이 다르다 🎯

맞습니다. 질문하신 대로 "문제가 있는 녀석에게 일을 시키지 않는다(트래픽 차단)"는 결과론적인 관점에서는 두 기능이 동일합니다.

하지만 '누가', '언제', '어떻게' 문제를 판단하느냐에서 결정적인 차이가 발생합니다.

• K8s Readiness Probe: "나 아직 준비 안 됐어..." (스스로 혹은 외부의 주기적 검사)
• Istio Circuit Breaker: "너 지금 실수했어! 잠깐 나가 있어!" (실시간 감시자에 의한 퇴장 조치)

---

2. K8s Readiness Probe: "주기적인 건강 검진" 👨‍⚕️

쿠버네티스의 **Readiness Probe(준비성 프로브)**는 능동적(Active)인 헬스 체크 방식입니다.

• 작동 원리: 노드의 에이전트인 kubelet이 정해진 시간마다 파드에게 묻습니다. "살아있니? 요청 받을 수 있어?" (/healthz 호출)
• 특징: 트래픽이 오든 안 오든, 끊임없이 검사합니다.
• 주요 목적: 애플리케이션이 구동 중(Startup)이거나, 설정 파일 로딩 등으로 인해 아직 트래픽을 받을 준비가 안 된 상태를 걸러내기 위함입니다.

비유하자면? 의사 선생님이 주기적으로 회진을 돌며 환자의 체온과 혈압을 재는 것과 같습니다. "열이 나네? 오늘은 쉬세요." 하고 진단을 내리는 것이죠.

---

3. Istio 서킷 브레이커: "엄격한 경기 심판" 👮‍♂️

Istio의 서킷 브레이커(정확히는 Outlier Detection)는 수동적(Passive)인 감지 방식입니다.

• 작동 원리: 사이드카 프록시인 Envoy가 실제 사용자의 트래픽이 지나가는 길목을 지키고 서 있습니다. 평소엔 가만히 있다가, 실제 에러(5xx)가 발생하거나 응답이 느려지면 그때 개입합니다.
• 특징: 트래픽이 없으면 파드가 고장 났는지 알 수 없습니다. 대신, 실제 운영 중 발생하는 '진짜 문제'를 실시간으로 잡아냅니다.
• 주요 목적: 갑작스런 부하로 인한 응답 지연, DB 커넥션 풀 고갈 등 실제 서비스 품질 저하를 막고 장애 전파를 차단하기 위함입니다.

비유하자면? 축구 경기 심판과 같습니다. 선수가 가만히 서 있을 땐 아무 말 안 하지만, 경기 중에 반칙(에러)을 하거나 헛발질을 하면 즉시 호루라기를 불어 "너 퇴장(Ejection)!" 시키는 것과 같습니다.

---

4. 한눈에 보는 비교 분석표 📊

이 표 하나면 면접 질문도 완벽 대비 가능합니다! 😉

비교 항목	K8s Readiness Probe	Istio Circuit Breaker
감지 방식	Active (능동적) 주기적으로 찔러봄	Passive (수동적) 실제 에러 발생 시 감지
감지 주체	kubelet (인프라 레벨)	Envoy Proxy (네트워크/앱 레벨)
판단 기준	개발자가 만든 API 응답 (OK/Fail)	실제 트래픽의 HTTP 5xx, Latency
조치 방법	Service 엔드포인트 목록에서 제거	Envoy 로드밸런싱 풀에서 제외 (Ejection)
사각지대	앱은 켜져 있는데 기능이 고장 난 경우 감지 어려움	트래픽이 없으면 고장 난 줄 모름

 

---

5. 왜 둘 다 써야 할까? (시너지 효과) 🤝

"하나만 잘 쓰면 되는 거 아니냐?" 하실 수 있지만, 실무에서는 상호 보완적인 관계 때문에 둘 다 필수입니다.

😱 시나리오: 좀비 서버의 탄생

어떤 파드가 Tomcat은 쌩쌩하게 돌아가는데, 내부의 DB Connection Pool이 꽉 차서 DB 쿼리만 날리면 에러가 나는 상황이라고 가정해 봅시다.

1. Readiness Probe만 있다면?
   • kubelet: "헬스 체크 API 응답해?"
   • 파드: "응! (톰캣은 살아있으니까 200 OK)"
   • kubelet: "오케이, 트래픽 계속 받아!"
   • 결과: 사용자는 계속 500 에러를 보게 됩니다. (장애 감지 실패) ❌
2. Istio Circuit Breaker가 추가된다면?
   • Envoy: "어? 방금 들어온 사용자 요청에 500 에러 뱉었네? 또 500이네?"
   • Envoy: "너 상태 이상하다. 아웃라이어 감지! 3분간 격리!"
   • 결과: 해당 파드로 가는 트래픽이 즉시 차단되고, 정상적인 다른 파드로 요청이 넘어가 사용자는 에러를 보지 않게 됩니다. (장애 방어 성공) ✅

---

6. 결론 및 요약 📝

• Readiness Probe는 "준비 운동" 단계입니다. 아예 뛸 수 없는 선수를 경기장에 들이지 않는 역할입니다.
• Istio Circuit Breaker는 "경기 중 퇴장" 조치입니다. 경기 중에 다치거나 실력이 떨어진 선수를 벤치로 불러들이는 역할입니다.

이 두 가지가 합쳐져야 비로소 "준비된 파드만 투입하고, 문제 생기면 바로 빼버리는" 철벽같은 무중단 시스템이 완성됩니다.

여러분의 쿠버네티스 클러스터에는 이 두 가지 안전장치가 모두 잘 설정되어 있나요? 지금 바로 YAML 파일을 확인해 보세요! 🧐

---