🚨 서버가 아픈데 트래픽을 계속 보내시나요? Istio Outlier Detection의 숨겨진 비밀

안녕하세요! MSA(Microservice Architecture) 환경에서 서비스를 운영하다 보면 아찔한 순간들이 있죠. 😵 수많은 서비스 인스턴스 중 하나가 갑자기 응답을 제대로 못 하기 시작합니다. 하지만 로드 밸런서는 이 사실을 모른 채 계속해서 사용자 요청을 아픈 인스턴스로 보내고... 결국 사용자는 5xx 에러 화면만 마주하게 됩니다.

 

이런 상황을 어떻게 막을 수 있을까요? Istio를 사용한다면 아주 우아한 해결책이 있습니다. 바로 이상치 감지(Outlier Detection) 기능입니다! 그런데 이 기능이 어떻게 동작하는지 정확히 알고 계신가요? 혹시 "주기적으로 서버 상태를 콕콕 찔러보는 기능"이라고 생각하셨다면, 오늘 이 글을 꼭 읽어보세요! 핵심적인 오해를 바로잡고 서비스 안정성을 한 단계 끌어올릴 수 있을 겁니다.

---

🤔 Outlier Detection, 넌 정체가 뭐니?

Istio의 Outlier Detection은 서비스 메시 내에서 비정상적으로 동작하는 서비스 인스턴스(Pod)를 자동으로 찾아내어 일시적으로 로드 밸런싱 대상에서 제외하는 기능입니다.

마치 단체 달리기 경기에서 페이스가 처지거나 넘어진 선수를 발견하고 잠시 쉬게 해주는 현명한 감독님 같죠. 🏃‍♂️💨 이 기능 덕분에 특정 인스턴스의 장애가 전체 서비스의 장애로 번지는 것을 막을 수 있습니다.

핵심은 바로 이 '비정상적인 동작을 감지하는 방식'에 있습니다.

🕵️‍♂️ 수동적(Passive) 감시자, Outlier Detection

결론부터 말하자면, Istio의 Outlier Detection은 수동적(Passive) 헬스 체크 방식입니다.

이게 무슨 의미일까요? Active(능동적) 방식과 비교해보면 쉽게 이해할 수 있습니다.

• Passive (수동적) 방식 🕵️‍♂️: 실제 서비스로 들어오는 트래픽의 응답을 가만히 지켜보다가 문제를 파악합니다. 예를 들어, 특정 인스턴스로 가는 요청에서 연속적으로 5xx 에러가 발생하는 것을 감지하면 "아, 이 녀석 지금 상태가 안 좋구나!"라고 판단하고 트래픽 풀에서 잠시 빼버리는 거죠. 별도의 헬스 체크용 요청을 보내지 않습니다. 오직 '실전 트래픽'의 결과만으로 판단합니다.
• Active (능동적) 방식 🩺: 실제 서비스 트래픽과는 상관없이 주기적으로 "잘 있니?" 하고 안부를 묻는 헬스 체크용 요청을 보냅니다. 우리가 흔히 아는 Kubernetes의 Liveness/Readiness Probe가 대표적인 예시죠. /healthz 같은 엔드포인트로 주기적으로 요청을 보내고, 정해진 시간 내에 정상 응답(HTTP 200 OK 등)이 오지 않으면 "얘 아프다!"라고 판단하여 조치를 취합니다.

따라서 Istio의 Outlier Detection은 별도의 요청을 보내지 않고, 실제 트래픽의 흐름 속에서 문제를 감지하기 때문에 수동적(Passive) 방식이 맞습니다.

⚙️ Outlier Detection 설정 살펴보기 (YAML)

말로만 설명하면 감이 잘 안 오죠? 실제 Istio DestinationRule 리소스에서 Outlier Detection이 어떻게 설정되는지 코드로 확인해 보겠습니다.

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: reviews-dr
spec:
  host: reviews.prod.svc.cluster.local
  trafficPolicy:
    outlierDetection:
      # 연속으로 5xx 에러가 몇 번 발생하면 제외할지
      consecutive5xxErrors: 3
      # 감시 주기 (이 주기마다 상태를 스캔)
      interval: 10s
      # 한 번 제외되면 최소 얼마 동안 제외될지
      baseEjectionTime: 1m
      # 로드 밸런싱 풀에서 최대로 제외될 수 있는 인스턴스의 비율
      maxEjectionPercent: 50

위 YAML 파일의 outlierDetection 설정을 하나씩 뜯어볼까요?

• consecutive5xxErrors: 3: reviews 서비스의 특정 인스턴스가 연속으로 3번 502, 503, 504 같은 5xx 에러를 반환하면...
• interval: 10s: Istio는 10초마다 이런 상황이 발생했는지 스캔하고...
• baseEjectionTime: 1m: 문제가 감지된 인스턴스를 최소 1분 동안 트래픽 분배 대상에서 제외합니다. (실제 제외 시간은 baseEjectionTime * 제외된 횟수로 계산되어 점점 늘어납니다.)
• maxEjectionPercent: 50: 아무리 많은 인스턴스에 문제가 생겨도, 전체 인스턴스의 **50%**까지만 제외하여 서비스 전체가 마비되는 것을 방지합니다.

이 설정 어디에도 "/health 경로로 요청을 보내라"와 같은 Active 방식의 설정은 찾아볼 수 없죠? 오직 실제 트래픽의 응답 결과를 기반으로 동작함을 명확히 알 수 있습니다.

💡 그래서 뭐가 더 좋은 건가요?

"그럼 Active 방식은 틀렸고, Passive 방식만 써야 하나요?" 라고 생각하실 수도 있습니다.

정답은 "아니요, 둘 다 필요하고 상호 보완적입니다!" 입니다.

구분	Istio Outlier Detection (Passive)	Kubernetes Probes (Active)
감지 방식	실제 트래픽 응답 모니터링 📊	주기적인 헬스 체크 요청 발송 핑퐁 핑퐁
장점	실제 사용자에게 영향을 주는 문제를 즉각적으로 파악 가능. 부하가 없음.	트래픽이 없는 상태에서도 인스턴스의 문제를 미리 파악 가능.
단점	트래픽이 없으면 문제를 감지할 수 없음.	헬스 체크 요청 자체가 서비스에 약간의 부하를 줄 수 있음.
주요 역할	일시적인 과부하나 간헐적 오류로부터 서비스 보호 (트래픽 격리)	애플리케이션 자체가 다운되거나 먹통이 된 상태 감지 (컨테이너 재시작)

보시는 것처럼 두 방식은 서로 다른 종류의 문제를 해결합니다.

• K8s Probe (Active): 컨테이너가 아예 죽었거나, DB 커넥션 풀이 꽉 차서 더 이상 요청을 처리할 수 없는 등 근본적인 문제를 감지하여 컨테이너를 재시작시키는 역할을 합니다.
• Istio Outlier Detection (Passive): 컨테이너는 살아있지만, 일시적인 CPU 스파이크나 네트워크 지연 등으로 잠깐 응답이 불안정해진 인스턴스를 감지하여 사용자 트래픽으로부터 잠시 격리하는 역할을 합니다.

✨ 결론: 함께 사용해서 더 강력하게!

결론적으로 Istio의 Outlier Detection은 실제 트래픽을 감시하는 수동적(Passive) 헬스 체크 방식입니다. 이는 주기적으로 헬스 체크 요청을 보내는 Kubernetes의 Liveness/Readiness Probe와 같은 능동적(Active) 방식과는 명확히 구분됩니다.

가장 이상적인 구성은 이 두 가지를 함께 사용하는 것입니다. 🤝

1. Readiness Probe로 아직 준비되지 않은 Pod에 트래픽이 가는 것을 막고,
2. Liveness Probe로 완전히 죽어버린 Pod를 재시작시키며,
3. Outlier Detection으로 잠깐 상태가 메롱인 Pod를 트래픽 풀에서 잠시 격리하여 서비스 안정성을 극대화하는 것이죠.

이제 Istio의 Outlier Detection이 어떻게 동작하는지, 그리고 왜 '수동적' 방식인지 명확히 이해되셨나요? 이 개념을 정확히 이해하고 적용하여 더욱 견고하고 탄력적인 마이크로서비스를 만들어보세요!

---