카카오페이 사례
Last updated
Was this helpful?
Last updated
Was this helpful?
Istio는 서비스 메시라는 거대한 기술의 영역을 구현하는 오픈소스 기술로써 envoy proxy를 통해서 다양한 기능들을 제공하고 있다
전체 컨테이너 네트워크를 관리하는 기술이다 보니 실패 사례가 발생하는 경우 서비스 영향도가 매우 크다
그래서 필요한 기능에 한정하여 제한적으로 사용하고 있다
API Gateway라고 해서 거창하게 생각될 수 있지만, 적용한 영역은 몇가지 기능과 패턴을 통한 트래픽 Proxy 기능에 한정되어있다
사용한 istio 객체들을 살펴보자
istio의 모든 객체들은 Kubernetes CRD 를 통해서 구현되는데 먼저 인/아웃바운드의 외부 요청을 k8s 내부 서비스메시 통신을 등록하기 위해서 gateway를 생성해야한다
gateway는 sidecar 패턴으로 구성되는 istio-proxy Envoy pod이 아닌 독립적인 envoy pod에 적용된다
ns 별로 istio가 제공하는 ingressgateway workload resource를 별도로 helm을 통해 배포하고 있고 외부로부터 들어오는 요청을 처리하기 위해서 ingressgateway를 활용하고 있다
두번째로 k8s ingress 객체처럼 라우팅 규칙을 정의하기 위해서 virtualservice를 생성해야한다
port, uri, header 등 다양한 조건으로 라우팅을 처리할 수 있고
subset이라는 설정과 destination 객체를 조합해서 canary 배포와 a/b test등 몇가지 동작을 매우 쉽게 구현할 수 있다
앞서 살펴본 virtualservice 의 라우팅 규칙의 대상을 정의할 수 있는 destination rule
특정 호스트 레이블 정보를 가진 pod들에게 subset 이라는 집합을 통해서 대상을 그룹핑할 수 있다
이외에도 trafficPolicy 라는 설정을 통해서 서비스 메시 로드밸런싱의 동작 방식이나 커넥션 풀 설정을 통해서 tcp, http, keep-alive, time-out 설정등 상세한 옵션을 조정할 수 있다
마지막으로 k8s 외부 대상의 서비스 엔드포인트를 서비스 메시 정보로 등록해야한다
서비스 엔드리라는 객체를 통해서 통신이 필요한 외부의 대상 주소 정보를 서비스 메시에 등록함으로 써 외부로 나가는 트래픽도 서비스 메시 트래픽으로 핸들링 할 수 있다
Retry , Timeout, fault injection 과 같은 다양한 트래픽 매니지먼트 기능들을 사용할 수 있게 된다
서비스에서 발생하는 인바운드 요청을 어떤 컨테이너로 보낼 지 외부 서비스로 트래픽을 전달할 지
지금까지 본 gateway, virtual service, destination rule, service entry 등 4개의 manifast file을 배포함으로써 구현이 가능하다. yaml 형식으로 된 약 100 라인 정도 내외의 코드면 된다
물리적인 서버나 ec2인스턴스 위에 nginx등을 설정하고 관련 설정을 어딘가 현행화하여 배포하는 리소스와 엄청 큰 차이가 발생하게 된다
앞서 설명한 istio 객체를 사용해서 api gateway를 구성
Tip
서비스 성격 별로 NodeGroup 을 충분히 분리