CloudNet@에서 진행하는 Istio Study 1주차 1장 내용입니다.
"Istio IN ACTION"
1부 Istio 이해하기 일부입니다.
클라우드 플랫폼이나 컨테이너 같은 신기술을 더 빠르게 활용하기 위한 방법을 모색하다 보면 과거의 문제가 증폭되는 상황을 마주하게 된다.
- 더 크고 더 분산된 시스템을 구축할 때에는 네트워크가 애플리케이션 설계 고려사항 의 중심이 되어야 한다.
- Application에서 Networking, Security, Metric은 꼭 필요하지만, 특별한 요소는 아니다.
- 언어, 프레임워크에 종속되지 않는 방식과 구현을 정책으로 만드는 것이다.
Istio 이전 문제점들
1. 클라우드 인프라는 신뢰할 수 없다.
- 일시적이고 간혹 사용할 수 없다는 것이다.
- 이러한 시나리오를 미리 대비해야 한다.
2. 서비스 상호작용을 복원력 있게 만들기
여러 시나리오에 대비해 몇 가지 패턴이 있다.
-
Client-site load balancing
특정 논리적 서비스의 주기적으로 갱신되는 정상 엔드포인트 목록을 찾는 매커니즘이다. -
Service discovery
특정 논리적 서비스의 주기적으로 갱신되는 정상 엔드포인트 목록을 찾는 매커니즘이다. -
Circuit Breaking
오동작하는 것으로 보이는 서비스에 일정 시간 부하를 차단한다. -
Bulkheading
서비스 호출 시 클라이언트 리소스 사용량을 명시적 임계값으로 제한한다 (커넥션, 스레드, 세션 등). -
Retries
실패한 요청을 재시도한다. -
Retry Budgets
재시도에 제한을 적용. 즉, 일정 기간의 재시도 횟수를 제한하는 것 (예. 10초 동안 호출의 50%까지만 재시도 가능 -
Deadlines
요청에 응답 유효 기간을 지정한다. 데드라인을 벗어나면 요청 처리를 무시한다.
종합하면 Application Networking으로 볼 수 있다.
3. 실시간으로 이해하기
- 통신, 서비스 부하 형태, 오작동, 상태 등의 아키텍처를 아는 것
- Metric, Log, Trace로 시스템을 관찰하는 것
위의 사항들은 매우 중요한 부분입니다.
Service Mesh란?
- 애플리케이션 대신 프로세스 외부에서 투명하게 네트워크 트래픽을 처리하는 분산형 애플리케이션 인프라
Data Plane은 메시를 거쳐가는 트래픽을 설정하고 보호하고 제어하는 책임을 맡는다.
Control Plane은 메시의 두뇌로, 운영자가 네트워크 동작을 조작할 수 있도록 API를 노출한다.
Istio란?
서비스 메시의 오픈소스 구현체이며 구글, IBM, 리프트가 주도했다.
Istio >> Service Mesh 오픈소스 구현체
- 코드 수정 불필요
- 보안, 정책, 관찰 가능성 해결
- 클라우드 Native 시스템
- Data Plane은 Envoy Proxy기반의 Service Proxy
- Service Proxy는 중개자 역할
- 각 애플리케이션 인스턴스 옆에 서비스 프록시가 있으면 애플리케이션은 더 이상 서킷 브레이커, 시간 초과, 재시도, 서비스 디스커버리, 로드 밸런싱 등을 위해 언어별 복원력 라이브러리가 필요하지 않다.
- 또한 서비스 프록시는 메트릭 수집, 분산 트레이싱, 접근 제어도 처리한다.
- 컨트롤 플레인 istiod는 라우팅, 보안, 텔레메트릭 수집, 복원력을 처리하는 Istio Proxy를 설정하는 데 사용한다.
- 서비스가 mTLS를 바로 사용할 수 있도록 키 및 인증서 발급, 설치, 로테이션을 관리할 수 있다.
- 워크로드에 ID를 부여하고 이를 인증서에 포함시킬 수 있다. 또한 ID를 사용해 강력한 접근 제어 정책을 구현할 수 있다.
- 할당량, 속도 제한, 조직 정책을 구현할 수 있다.
Istio 구성 요소
출처 - https://lcc3108.github.io/articles/2020-12/istio
- 파일럿(Pilot): 모든 Envoy 사이드카에서 프록시 라우팅 규칙을 관리하며, 서비스 디스커버리와 로드 밸런싱 설정을 제공합니다.
- 갤리(Galley): Istio와 쿠버네티스(TLS 연결 및 파일럿에 필요한 설정)를 연결해 주는 역할을 합니다. 서비스 메시 구성 데이터를 검증하고 변환합니다.
- 시타델(Citadel): 보안 기능을 담당하며, TLS 인증서 발급 및 관리를 통해 서비스 간 통신의 암호화를 수행합니다.
Istio 구성요소와 envoy : 컨트롤 플레인(istiod) , 데이터 플레인(istio-proxy > envoy)
- istiod : Pilot(데이터 플레인과 통신하면서 라우팅 규칙을 동기화, ADS), Gally(Istio 와 K8S 연동, Endpoint 갱신 등), Citadel(연결 암호화, 인증서 관리 등)
Service Mesh의 단점?
1. 요청 경로에 미들웨어, 특히 프록시가 추가
- 프록시에 익숙하지 않은 이들에게는 블랙박스가 돼 애플리케이션의 동작을 디버깅하기 어렵게 만들 수 있다.
- Envoy Proxy는 디버깅이 쉽도록 설계되었지만, 익숙치 않은 사람들에게는 복잡할 수 있습니다.
2. 테넌시 측면
- 물리적 메시 배포의 테넌트 및 격리 모델에 적절한 정책, 자동화, 그리고 사전 고려 없이는 메시를 잘못 구성하면 많은 서비스에 영향을 미칠 수 있는 상황에 처할 수 있으므로, 학습과 설정이 매우 중요하다.
3. 요청 경로에 위치하기 때문에 서비스 및 애플리케이션 아키텍처의 매우 중요한 요소
- 보안, 관찰 가능성 및 라우팅 제어 자세를 개선할 수 있는 많은 기회를 제공하지만, 단점은 메쉬가 또 다른 레이어와 또 다른 복잡성의 기회를 제공한다는 점입니다.
# 결론
- 서비스 메시가 가져다주는 이점이 크지만, 그에 따른 트레이드오프가 없지 않으므로, 적합한 판단과 계획을 세워야합니다.
다음 2장은 이스티오 첫 걸음으로 첫 실습을 시작합니다.
