[3주차] 복원력(애플리케이션 네트워킹 문제 해결) : 애플리케이션에 복원력 구축

🛡️Istio로 마이크로서비스의
Resilience 강화하기 

---

🚨 마이크로서비스에서 Resilience의 중요성

• 마이크로서비스는 네트워크를 통해 서로 통신하기 때문에 장애 가능성이 높아집니다.
  예를 들어, 서비스 A가 서비스 B를 호출할 때 지연이나 간헐적 오류가 발생하면, 이 문제가 서비스 A와 그 상위 서비스로 퍼져 전체 시스템에 큰 영향을 줄 수 있습니다.
  이런 cascading failures(연쇄 장애)를 막으려면 애플리케이션이 실패를 예상하고 복구할 수 있는 패턴을 적용해야 합니다.

그림 : 서비스 A가 서비스 B를 호출할 때 네트워크 문제 발생 가능성

• 예를 들어:
  • 서비스 B의 특정 엔드포인트에 지연이 생기면, 다른 엔드포인트나 지역으로 요청을 라우팅.
  • 간헐적 오류가 발생하면 요청을 재시도.
  • 서비스 B가 문제를 겪고 있다면, 부하를 줄이기 위해 요청을 일시 중단(백오프).
• 이런 패턴에는 retries, timeouts, circuit breaking 같은 기술이 포함됩니다. Istio는 이런 패턴을 애플리케이션 코드 변경 없이 구현할 수 있게 도와줍니다!

마이크로서비스는 네트워크 장애로 인해 연쇄 장애가 발생할 수 있습니다.
Istio를 활용해 retries, timeouts, circuit breaking 같은 패턴으로 resilience를 강화하세요!

---

📚 애플리케이션 라이브러리로 Resilience 구현하기

• 과거에는 서비스 개발자가 애플리케이션 코드에 직접 resilience 패턴을 구현해야 했어요. 이를 돕기 위해 몇 가지 오픈소스 프레임워크가 등장했습니다:
  • Twitter Finagle (2011): Scala/Java 기반으로 timeouts, retries, circuit breaking 같은 RPC 패턴을 제공. (Finagle)
  • Netflix Hystrix: Java용 circuit breaking 제공. (Hystrix)
  • Netflix Ribbon: 클라이언트 측 로드 밸런싱 제공. (Ribbon)
• 이 라이브러리들은 Spring Cloud 같은 프레임워크에도 통합됐지만, 몇 가지 문제가 있었습니다:
  • 언어 종속성: Java 개발자에게는 유용했지만, Node.js, Go, Python 개발자는 별도의 구현이 필요했어요.
  • 코드 침투성: 네트워킹 코드가 비즈니스 로직과 섞여 코드가 복잡해졌어요.
  • 유지보수 부담: 여러 언어와 프레임워크에 걸쳐 패치와 기능 동기화를 유지하는 게 어려웠어요.
• 이런 문제를 해결하기 위해 Istio가 등장했습니다!

과거에는 Finagle, Hystrix 같은 라이브러리로 resilience를 구현했지만,
언어 종속성과 유지보수 문제가 있었습니다. Istio는 이를 더 쉽게 해결합니다!

---

🛠️ Istio로 Resilience 문제 해결하기

• Istio는 애플리케이션 옆에 배포된 service proxy(Envoy)를 통해 모든 네트워크 트래픽을 관리합니다.
  이 proxy는 HTTP 요청 같은 애플리케이션 수준의 메시지를 이해하므로, resilience 기능을 코드 변경 없이 구현할 수 있어요.

그림 : Istio의 service proxy로 resilience 구현

• 예를 들어, Istio를 설정해 HTTP 503 오류가 발생하면 최대 3번 재시도하도록 구성할 수 있습니다.
  재시도 조건, 횟수, 각 재시도의 타임아웃 등을 세밀하게 조정할 수 있죠.
  Istio는 다음 resilience 패턴을 기본 제공합니다:
  • Client-side load balancing
  • Locality-aware load balancing
  • Timeouts and retries
  • Circuit breaking
• 이 기능들은 서비스별로 배포된 proxy에서 실행되므로, 각 서비스의 필요에 맞게 세밀한 설정이 가능해요.

Istio의 service proxy는 retries, timeouts, circuit breaking 같은 resilience 패턴을 코드 변경 없이 구현합니다.
서비스별로 세밀한 설정이 가능합니다!

---

🌐 분산형 Resilience 구현

• Istio는 애플리케이션 인스턴스와 함께 배포된 data-plane proxy를 통해 요청을 처리하므로, 중앙 집중식 게이트웨이 없이도 resilience를 구현합니다.
  과거에는 하드웨어 로드 밸런서, 메시징 시스템, Enterprise Service Bus 같은 중앙화된 미들웨어를 사용했지만, 이런 방식은 동적이고 탄력적인 클라우드 환경에 적합하지 않습니다.

그림 : 웹 서비스가 백엔드 서비스를 호출하는 예제

• Istio의 분산형 접근 방식은:
  • 애플리케이션 코드에 resilience 로직을 포함시키는 라이브러리와 유사한 구조를 제공.
  • 동적 클라우드 환경에 적합하며, 중앙화된 장비의 병목현상을 피합니다.
• 이 예제에서는 simple-web 서비스가 simple-backend 서비스를 호출하며 resilience 패턴을 테스트합니다.

Istio는 분산형 data-plane proxy로 resilience를 구현해 동적 클라우드 환경에 적합합니다.
Fake Service 예제를 통해 실제 동작을 테스트할 예정입니다!

---

📌핵심 요약

1. Resilience의 중요성: 마이크로서비스는 네트워크 장애로 인해 연쇄 장애가 발생할 수 있으므로, retries, timeouts, circuit breaking 같은 패턴으로 복원력을 강화해야 합니다.
2. 라이브러리 한계: Finagle, Hystrix 같은 라이브러리는 언어 종속성과 유지보수 문제를 가지며, 코드에 침투해 복잡성을 높였습니다.
3. Istio의 해결책: Istio의 service proxy는 코드 변경 없이 client-side load balancing, timeouts, retries, circuit breaking을 제공하며, 서비스별 세밀한 설정이 가능합니다.
4. 분산형 구현: Istio는 중앙화된 미들웨어 대신 분산형 proxy를 사용해 동적 클라우드 환경에 적합하며, Fake Service 예제로 실제 테스트를 진행할 예정입니다.

---