이전 챕터에서 마이크로서비스에서의 복원력에 대해 간략히 소개했어요. 이번 챕터에서는 마이크로서비스에서 흔히 겪을 수 있는 시나리오를 통해 장애 허용(fault tolerance)이 왜 중요한지, 그리고 우리의 마이크로서비스가 일상적으로 직면할 수 있는 문제들에 대해 어떻게 복원력을 가져야 하는지에 대해 설명드릴게요.
시나리오 개요
여기 API 게이트웨이 또는 엣지 서버가 있다고 가정해볼게요. 이 서버는 외부 클라이언트로부터 들어오는 트래픽을 처리해요. 우리의 마이크로서비스 네트워크에는 Accounts 마이크로서비스에 fetchCustomerDetails라는 REST API가 있어요. 이 API를 호출하면, 고객의 전체 정보, 즉 계좌 정보, 대출 정보, 카드 정보를 받아야 해요.
이 과정은 다음과 같아요:
- 엣지 서버가 클라이언트의 요청을 Accounts 마이크로서비스로 전달해요.
- Accounts 마이크로서비스는 계좌 및 고객 정보만 제공할 수 있고, 나머지 정보는 Loans 및 Cards 마이크로서비스에서 가져와야 해요.
- Accounts 마이크로서비스는 Loans와 Cards 마이크로서비스에서 받은 응답을 모아 데이터를 결합한 후, 이를 엣지 서버에 다시 전달해요.
- 마지막으로 엣지 서버는 전체 응답을 클라이언트에게 반환해요.
문제 시나리오
이제 이 과정 중에 하나의 마이크로서비스, 예를 들어 Cards 마이크로서비스가 문제를 겪고 있다고 가정해볼게요. 이 마이크로서비스가 너무 많은 요청을 처리하느라 지연되거나, 아예 응답을 하지 못할 수도 있어요.
보통, Accounts 마이크로서비스는 Cards 마이크로서비스로부터 1초 이내에 응답을 기대해요. 하지만 문제가 발생하면, Cards 마이크로서비스가 10초 이상 걸리거나 아예 응답하지 않을 수도 있어요.
연쇄 효과
Accounts 마이크로서비스가 Cards 마이크로서비스의 응답을 제때 받지 못하면, 다음과 같은 일이 발생해요:
- Accounts 마이크로서비스는 Cards 마이크로서비스의 응답을 기다리면서 스레드와 CPU, 메모리와 같은 자원을 소비해요.
- Accounts 마이크로서비스가 너무 오래 기다리면, 자신의 응답 시간도 지연돼요.
- 이 지연은 엣지 서버에도 영향을 미쳐, 엣지 서버 역시 Accounts 마이크로서비스의 응답을 기다리게 돼요.
- 결과적으로, 엣지 서버의 성능이 저하되며, 들어오는 모든 클라이언트 요청(고객 세부 정보 요청뿐만 아니라 다른 요청들도 포함)이 지연되거나 실패할 수 있어요.
이것이 바로 하나의 마이크로서비스의 문제가 어떻게 전체 마이크로서비스 네트워크에 연쇄적인 영향을 미칠 수 있는지 보여주는 전형적인 시나리오에요.
해결책: 서킷 브레이커 패턴
이런 상황을 방지하기 위해 서킷 브레이커 패턴과 같은 복원력 패턴을 사용할 수 있어요. 이 패턴은 문제가 있는 서비스를 전체 시스템에 영향을 주지 않도록 격리시키는 데 도움을 줘요.
서킷 브레이커 패턴 소개
서킷 브레이커 패턴은 마이크로서비스 네트워크에서 발생할 수 있는 연쇄적인 실패(cascading failure)를 방지하기 위한 패턴입니다. 이 패턴은 전기 시스템에서 사용하는 서킷 브레이커(회로 차단기)의 원리에서 영감을 받아 소프트웨어 개발에 적용된 것입니다.
서킷 브레이커의 전기 시스템에서의 역할
전기 회로 차단기는 과도한 전류나 잠재적인 화재 위험으로부터 전기 회로를 보호하기 위해 설계된 안전 장치입니다. 회로 차단기는 단락(short circuit)이나 전기 과부하가 발생했을 때 이를 감지하고 자동으로 회로를 차단하여, 전기 기기들이 손상되지 않도록 보호합니다. 만약 회로 차단기가 없다면, 과부하된 전류가 전기 기기로 흘러들어가 결국 기기가 손상될 수 있습니다.
서킷 브레이커 패턴의 소프트웨어에서의 역할
전기 시스템에서 전류가 네트워크를 통해 흐르는 것처럼, 분산 환경에서 원격 리소스나 서비스에 대한 호출이 발생합니다. 이 원격 호출은 여러 가지 이유로 실패할 수 있습니다. 예를 들어, 일시적인 오류(transient faults), 느린 네트워크, 타임아웃, 리소스 과부하, 일시적인 서비스 비가용 등이 있습니다. 대부분의 경우 이러한 오류는 짧은 시간 후에 자동으로 해결되지만, 이러한 잠재적인 문제에 대해 마이크로서비스가 복원력을 갖추도록 준비해야 합니다.
서킷 브레이커 패턴의 작동 원리
서킷 브레이커 패턴은 전기 회로 차단기와 마찬가지로 특정 서비스로의 원격 호출을 모니터링합니다. 만약 서비스가 너무 오래 응답하지 않거나, 응답 속도가 느려지거나, 네트워크 문제가 발생하면, 서킷 브레이커는 해당 호출을 중단시킵니다. 그리고 다수의 호출이 실패하거나 문제가 발생하는 경우, 서킷 브레이커는 해당 서비스로의 모든 추가적인 요청을 즉시 실패로 처리합니다. 이를 통해 다른 서비스들이 오랜 시간 동안 응답을 기다리며 리소스를 낭비하는 상황을 방지할 수 있습니다.
이 과정에서 서킷 브레이커는 서비스가 복구될 시간을 주며, 일정 시간 후에 일부 트래픽을 서비스로 보내서 서비스가 정상적으로 복구되었는지 확인합니다. 만약 이 테스트 트래픽이 성공하면, 서킷 브레이커는 다시 모든 요청을 허용하지만, 여전히 문제가 있다면 일정 시간 동안 다시 요청을 차단합니다.
서킷 브레이커 패턴의 주요 장점
-
빠른 실패 처리: 서비스가 응답하지 않거나 문제가 있을 때, 요청을 빠르게 실패 처리하여 다른 서비스가 오랜 시간 대기하지 않도록 합니다.
-
우아한 실패 처리: 서킷 브레이커를 사용하면 요청이 실패할 때 우아하게 실패 처리(fallback)를 구현할 수 있습니다. 예를 들어, 기본 값을 반환하거나 캐시된 데이터를 사용할 수 있습니다.
-
서비스의 원활한 복구 지원: 서킷 브레이커는 문제가 있는 서비스에 일정 시간 동안 휴식 시간을 주어 서비스를 원활하게 복구할 수 있도록 돕습니다.
물론입니다! 이제 강의를 요약해드릴게요.
서킷 브레이커 패턴의 트래픽 제어 방법
서킷 브레이커 패턴은 특정 마이크로서비스에 대한 트래픽을 제어하기 위해 설계된 패턴입니다. 기본적으로 서킷 브레이커는 모든 마이크로서비스를 모니터링하지 않으며, 필요한 마이크로서비스에만 이 패턴을 구성해야 합니다. 서킷 브레이커 패턴이 활성화되면, 트래픽의 흐름을 제어하기 위해 세 가지 상태를 사용합니다.
1. Closed 상태 (닫힌 상태)
- 초기 상태: 애플리케이션이 시작될 때 서킷 브레이커는 기본적으로 Closed 상태에 있습니다.
- 트래픽 허용: Closed 상태에서는 모든 요청이 해당 마이크로서비스로 전달됩니다. 전기 시스템에서 회로가 닫혀 있을 때 모든 전류가 통과하는 것과 유사합니다.
- 모니터링: 서킷 브레이커는 모든 요청을 모니터링하고, 마이크로서비스의 응답이 정상인지, 네트워크 문제나 응답 지연이 있는지 분석합니다.
- 상태 전환: 만약 서킷 브레이커가 다수의 요청이 실패하고 있음을 감지하면, 설정된 실패율 임계값에 따라 Closed 상태에서 Open 상태로 전환됩니다. 예를 들어, 실패율 임계값이 50%로 설정되어 있다면, 50% 이상의 트래픽이 실패할 경우 서킷 브레이커는 Open 상태로 전환됩니다.
2. Open 상태 (열린 상태)
- 트래픽 차단: Open 상태에서는 해당 마이크로서비스로의 요청을 차단하고, 요청이 들어오면 즉시 실패 응답을 반환합니다.
- 릴레이션 방지: Open 상태를 통해 특정 마이크로서비스의 문제로 인해 다른 마이크로서비스에 연쇄적인 영향을 주는 것을 방지합니다.
- 지속 시간: Open 상태는 영구적이지 않으며, 설정된 시간(예: 90초) 동안 유지됩니다. 이 시간 동안 마이크로서비스가 복구될 수 있는 시간을 제공합니다.
- 상태 전환: 설정된 시간이 지나면 서킷 브레이커는 Half Open 상태로 전환됩니다.
3. Half Open 상태 (반열림 상태)
- 일부 요청 허용: Half Open 상태에서는 일부 요청만 허용됩니다. 예를 들어, 10개 또는 20개의 요청을 허용할 수 있습니다.
- 재분석: 이 요청들 중 다수가 성공하면, 서킷 브레이커는 Closed 상태로 전환되어 정상적인 작동을 재개합니다. 하지만 요청이 여전히 실패하면 다시 Open 상태로 전환됩니다.
- 상태 반복: 이 과정은 마이크로서비스가 완전히 복구될 때까지 주기적으로 반복됩니다.
서킷 브레이커의 구성
서킷 브레이커 패턴의 구현은 복잡하게 들릴 수 있지만, Resiliency4j와 Spring Boot Framework와 같은 라이브러리와 프레임워크를 사용하면 쉽게 구성할 수 있습니다.
다음 강의에서 서킷 브레이커 패턴을 실제로 구현할 예정이니, 이 세 가지 상태(Closed, Open, Half Open)에 대해 명확히 이해하고 넘어가는 것이 중요합니다.
