Istio Hands-on Study [1기]

1주차 : Istio 이해하기 (1)

구구달스 2025. 4. 8. 21:06 
CloudNet@ 가시다님이 진행하는 Istio Hands-on Study [1기]

✅ 서비스 지향 아키텍처 전환 시 겪는 속도와 신뢰성의 딜레마  

💠마이크 서비스 아키텍처에서 겪은 주요 문제들

  1. 성능 불안정:
    일부 서비스가 요청을 처리하는 데 걸리는 시간이 들쭉날쭉했고, 특히 사용자 접속이 많은 시간에는 서비스가 제대로 작동하지 않는 경우가 있었음.
    예: 서비스 B에 문제가 생기면, 서비스 A도 특정 요청에서 영향을 받음.
  2. 배포 문제:
    블루-그린 배포 방식(새 버전과 기존 버전을 병행 운영 후 전환)을 사용했지만, 실제로는 문제가 한꺼번에 발생. 자동화된 테스트로도 버그를 걸러내지 못하는 경우가 있었음.
  3. 보안 방식의 불일치:
    • 서비스 A: 인증서와 개인 키를 사용한 보안 통신 선호
    • 서비스 B: 자체 제작한 토큰 기반 보안 프레임워크 사용
    • 서비스 C: 내부망이라는 이유로 별도 보안 조치 없음
서비스 간 일관되지 않은 성능, 문제 많은 배포 전략, 서로 다른 보안 접근 방식으로 인해 어려움을 겪었으며, 이는 서비스 지향 아키텍처(SOA) 전환 시 흔히 발생할 수 있는 문제들입니다.

💠 클라우드 환경에서는 다음과 같은 점들을 고려

  1. 클라우드도 결국 하드웨어와 소프트웨어로 이루어져 있음:
    사용자는 실제 하드웨어를 보지 못하지만, 클라우드는 수많은 컴퓨터, 저장장치, 네트워크 장비로 구성되어 있음. 이 모든 구성 요소는 언제든지 고장날 수 있음.
  2. 이전과 달라진 가정:
    과거에는 인프라가 항상 잘 작동한다는 가정 아래 앱을 만들었지만,
    클라우드에서는 인프라가 언제든 사라지거나 장애가 날 수 있다는 걸 전제로 앱을 설계해야 함.
클라우드에서는 인프라가 언제든지 불안정해질 수 있다는 점을 전제로, 앱을 더 견고하게 설계해야 하며, 하나의 서비스가 느려져도 전체 시스템이 영향을 받지 않도록 대비해야 합니다.

💠 서비스 간에 문제가 생겼을 때 할 수 있는 대처 방법들

Preference 서비스와 Customer 서비스:
Preference 서비스가 Customer 서비스를 호출했는데, 그 응답이 느릴 경우 Preference 서비스 전체가 영향을 받을 수 있음.
심하면 다른 서비스들까지 연쇄적으로 고장나는 캐스케이딩 실패가 발생할 수 있음.

  1. 이런 문제가 생기는 이유는 다양함:
    • Customer 서비스 자체가 느림
    • 버그가 있음
    • 네트워크 장비나 설정 문제
    • 하드웨어 고장으로 인한 우회 경로 발생 등

대처 방법들:

  1. 요청을 다시 시도(재시도)
    시스템이 이미 느린 상황에서는 더 큰 부담 또, 전에 보낸 요청이 성공했는지 확실하지 않기 때문에 주의가 필요
  2. 일정 시간 안에 응답이 없으면 요청을 중단하고 에러 발생. (타임아웃)
  3. 다른 인스턴스(서버)로 요청. (예: 다른 지역에 있는 서버로 요청하기)
  4. 계속 문제가 생기면 잠깐 아예 요청을 멈추는 방법. 서킷 브레이킹(circuit breaking)

이런 문제들을 막기 위한 주요 설계 방법들(패턴들):

  • 클라이언트 쪽 로드 밸런싱:
    여러 서버 중에서 클라이언트가 스스로 고를 수 있게 해줌.
  • 서비스 디스커버리:
    작동 중인 건강한 서버 목록을 찾아주는 기능.
  • 서킷 브레이킹:
    문제가 생긴 서비스에 잠시 요청을 멈추고, 나중에 다시 시도함.
  • 벌크헤딩(Bulkheading):
    서비스가 너무 많은 요청을 받지 않도록 제한을 둠 (예: 연결 수, 스레드 수 제한).
  • 타임아웃:
    일정 시간 안에 응답이 없으면 중단.
  • 재시도(Retry):
    실패한 요청을 다시 보내기.
  • 재시도 예산(Retry Budget):
    너무 많이 재시도하지 않도록 제한함. 예: 10초 동안 최대 50%만 재시도.
  • 데드라인:
    요청에 “언제까지 응답이 필요하다”는 시간을 정해두는 것.

💠 안정적인 서비스 유지를 위한 변화 전 모니터링의 중요성  

빠르게 개발하고 배포하는 것도 중요하지만, 그 전에 제대로 가고 있는지 확인하는 것이 더 중요

아래와 같은 정보를 항상 알고 있어야 합니다:

  • 어떤 서비스가 서로 통신하는지
  • 평소에 얼마나 많은 요청이 있는지
  • 얼마나 자주 실패가 일어나는지
  • 실패하면 어떤 일이 일어나는지
  • 서비스가 건강한지 (잘 작동하는지)
시스템에 문제가 생기거나, 버그 있는 코드를 배포했을 때, 전체 시스템이 망가지지 않으려면 지속적으로 모니터링(메트릭, 로그, 트레이싱) 해야 합니다.

💠 클라우드 시대를 이끈 대기업들의 마이크로서비스 도구들

처음 클라우드 환경에서 서비스를 잘 운영한 기업들은 구글, 트위터, 넷플릭스 같은 대형 인터넷 기업들이었습니다.
이들은 특정 언어(주로 Java)를 위한 프레임워크와 라이브러리를 만들어, 클라우드 환경에서의 문제를 해결했습니다.

예를 들어, Netflix는 아래와 같은 도구들을 만들었습니다:

  • Hystrix – 장애 격리 (서킷 브레이커 역할)
  • Ribbon – 클라이언트 측 로드 밸런싱
  • Eureka – 서비스 등록 및 검색
  • Zuul – 동적 프록시 (API Gateway 역할)

이런 도구들은 Java 프로젝트 전용이며, 사용하려면 코드에 직접 추가해야 합니다.

💠 분산된 복원력 구현의 복잡함과 한계

애플리케이션에 장애 복원 기능(서킷 브레이커 , 로드 밸런싱 등)을 각자 구현하면 클라우드 환경에 유리하지만, 다음과 같은 새로운 문제점들이 생깁니다:

  1. 기술 제약과 의존성
    • 특정 라이브러리(예: Netflix Hystrix, Ribbon)를 사용하려면 특정 언어(Java) 를 써야 합니다.
    • 여러 라이브러리를 함께 사용해야 하므로 복잡성이 증가합니다.
  2. 언어와 프레임워크 다양성의 어려움
    • 예: NodeJS로 API를 만들고 싶어도 Java용 라이브러리와 호환되지 않아 대체 라이브러리를 찾아야 합니다.
    • 언어마다 구현 방식이 달라져 기능 불일치와 디버깅 어려움이 생깁니다.
    • 완전한 복원 기능을 구현하기 어려운 언어도 있습니다.
  3. 운영 및 유지보수의 어려움
    • 여러 언어/프레임워크에서 동일한 기능을 일관되게 유지하기 매우 어렵습니다.
    • 작은 차이도 시스템의 예측 불가능성을 높입니다.
    • 모든 서비스에 동시에 업데이트를 적용하는 것도 매우 까다롭습니다.
각 애플리케이션에 복원 기능을 직접 넣는 방식은 처음엔 좋아 보여도, 실제로는 많은 운영 부담과 복잡성을 초래합니다.
그래서 이득은 유지하면서도, 운영 부담을 줄이는 방법이 필요합니다

💠 공통 네트워크 기능은 언어와 무관하게 처리되어야 한다

  • 재시도, 타임아웃, 회로 차단기, 로드 밸런싱 같은 기능은 모든 서비스에 꼭 필요하지만, 언어마다 따로 구현하는 것은 비효율적
애플리케이션이 직접 처리하지 않고, 언어나 기술에 관계없이 공통적으로 처리할 수 있는 방식이 필요합니다.

 

✅ 애플리케이션 대신 인프라가 네트워크 기능을 처리

  • 재시도, 타임아웃, 로드 밸런싱, 회로 차단 같은 기능은 모든 서비스에 필요한 공통 기능이지만, 각 언어마다 따로 구현하면 비용도 많이 들고 비효율적입니다.

➡️ 그래서 이런 기능은 애플리케이션이 아닌 인프라(프록시) 에서 처리하는 게 더 좋습니다.

  • 우리가 원하는 것은 단순한 프록시가 아닌, 애플리케이션의 요청과 메시지를 이해할 수 있는 "애플리케이션 인식 프록시"(Layer 7 프록시) 입니다. 이런 프록시는 서비스 대신 네트워크 기능을 처리해줍니다.

✅ Envoy: 애플리케이션 네트워크 기능을 대신해주는 스마트 Proxy

💠 Envoy: 애플리케이션 네트워크 기능을 대신해주는 스마트 Proxy

Envoy는 Lyft에서 개발된 오픈소스 서비스 프록시로, 재시도, 타임아웃, 회로 차단, 로드 밸런싱, 서비스 검색, 보안, 모니터링 등
복잡한 네트워크 기능을 애플리케이션 밖에서 처리해줍니다.

  • 언어나 프레임워크에 상관없이 사용 가능
  • 애플리케이션의 요청을 대신 처리하고, 네트워크 상태를 자동으로 관찰
  • 애플리케이션 코드를 변경하지 않아도 복원력과 가시성을 확보할 수 있음
  • Envoy는 각 애플리케이션과 함께 사이드카(sidecar) 방식으로 배포됨 (예: Kubernetes Pod 안에서 같이 배포)
Envoy를 사용하면, 복잡한 네트워크 처리를 인프라에서 자동으로 하게 되어 운영은 쉬워지고, 시스템 전체를 더 잘 관찰하고 관리할 수 있게 됩니다.

💠 애플리케이션과 주고받는 모든 네트워크 트래픽은 Proxy 를 통과합니다.

💠 사이드카 배포는 메인 애플리케이션 프로세스와 협력하여 일부 기능을 제공하는 추가 프로세스입니다.

저작자표시 (새창열림)