PART 2 — Api-Gateway 소개
NOTICE
해당 블로그 는 PART 2 — Api-Gateway 소개 입니다.
총 3 PART 의 시리즈로 구성했으며 아래와 같습니다.
- PART 1 — 전반적인 소개 및 POD 내 CONTAINER 알아보기
- PART 2 — Api-Gateway 소개
- PART 3 — GitOps 소개
개요
안녕하세요. WATCHA 에서 서버 개발을 하고 있는 Allan 입니다.
이전 포스팅 에서는 WATCHA 에서 Kubernetes 로 인프라를 전환한 전반적인 구조에 대해서 이야기 해보았습니다.
이번 포스팅은 Kubernetes 로 인프라 전환시 구축한 API GATEWAY 에 대해서 이야기 해보고자 합니다.
What’s API GATEWAY?
MSA 구조로 바뀌면서 큰서비스들이 여러 작은 서비스들 분리되었습니다.
하지만 분리된 서비스들이 CLIENT 를 통해서 직접 호출하는 형태라고 한다면, 각 서비스별로 Endpoint 와 인증 및 권한 관리를 해야하는 번거로움이 생깁니다.
게다가 클라이언트와 통신을 위해서 어느 정도 외부로 시스템을 노출시켜서 보안이 취약해 질 수도 있습니다.
API GATEWAY 를 이용하게 된다면 인증 및 권한 관리, 라우팅 및 로드밸런싱, 보안, Rate Limit, Circuit Breaker … 등 다양한 기능을 활용할수 있어서 효율적으로 요청 처리가 가능합니다.
하지만 큰 단점은 API GATEWAY 가 SPOF(Single Point Of Failure) 이라는
점입니다. API GATEWAY 장애시 전체 서비스 장애로 번질수 있어, 적절한 Fallback 또는 장애 대응 프로세스가 필요 할수도 있습니다.
따라서 현 상황에 맞게 잘 활용하는게 중요합니다.
Which API GATEWAY is Selected?
OpenSource 또는 Enterprise 로 제공하는 다양한 API GATEWAY 들이 있습니다.
그 중에서 WATCHA 에서는 Gloo Edge를 이용해서 API GATEWAY 를 구축했습니다.
Gloo Edge 선택했던 이유는 정리해보면 아래와 같습니다.
- CRD 지원 : 대부분 모든 서비스가 K8S 내에서 동작하기 때문에, CRD를 이용하여 쉽게 다양한 기능들을 활용 할 수 있습니다.
- Envoy 기반 : Gloo Edge 는 API GATEWAY 로 Envoy를 이용합니다.
따라서 Envoy 기능을 활용한 적절한 커스텀마이징 이 가능하고, 커뮤니티가 활성화 되어 있어 트러블슈팅에 용이합니다. - Golang 기반: Proxy를 컨트롤 하기 위한 Control Plane 역할을 하는 Controller(App) 들이 Golang 으로 만들어져 있습니다.
회사 내에서 Golang 을 주력으로 이용하는 팀인지라, 적절한 커스텀마이징, 트러블슈팅에 쉽게 접근이 가능한 장점이 있습니다. - 귀여운 ICON: Gloo Edge 를 상징하는 아이콘이 귀엽습니다. 😂 😂 😂
Gloo Edge 를 이용한 인프라 구조
WATCHA 에서 Gloo Edge 를 이용한 인프라 구조는 아래와 같습니다.
1. 프록시
요청된 트래픽은 NLB 를 통해서 Envoy 로 들어오게 됩니다. Envoy는 L7 역할을 담당하며, Envoy 설정을 기반으로 Upstream 으로 트래픽을 전달하게 됩니다.
Envoy 설정은 static(하드코딩) 하게 설정도 할수 있습니다.
하지만 static 한 형태로만 설정을 하게 된다면 설정 변경시 Envoy 를 재시작을 시켜야하는 듯 불편함이 많습니다.
그래서 동적으로 Envoy 설정을 주입할 필요가 있는데, 보통은 xDS 서버를 통해서 Envoy 가 API 통신으로 설정을 주입받게 됩니다.
Gloo Edge는 주기적으로 서비스 상태 와 고유의 CRD 설정을 모니터링 하고, 만약 변경이 발생시 자동으로 Envoy 설정을 생성하고 xDS 서버를 통해서 Envoy에 설정을 주입하게 됩니다.
2. 모니터링
Envoy 자체에도 다양한 매트릭을 지원합니다.
WATCHA 에서는 Proxy 전용 POD 에 DataDog Agent 를 사이드카 컨테이너로 주입해서 IN/OUT 트래픽 및 Envoy 제공하는 매트릭 수집 하고 모니터링을 하고 있습니다.
3. 로깅
Envoy 에서 발생하는 IN/OUT 트래픽 및 다양한 로그들은 gRPC Access Log Service (ALS) 기반으로 개발된 WATCHA 내부 서버를 통하여 WATCHA 로그플랫폼으로 전달되며 빅쿼리에 저장됩니다.
참고로 WATCHA에서는 대부분 로그들은 로그플랫폼을 통해서 수집, 통합 및 분석을 하고 있습니다.
4. 라우팅 및 옵션
Gloo Edge 에서 제공되는 다양한 CRD 를 활용하여서 손쉽게 라우팅룰을 변경하고, 상황에 따라 Retry, Rate Limit, Circuit Breaker …등도 포함시켜서 가급적 장애 전파가 일어나지 않도록 관리하고 있습니다.
미래의 청사진
WATCHA 에서 Gloo Edge 를 API GATEWAY 선택한 가장 큰 이유는
앞으로 가고자 하는 방향에 부합했기 때문입니다.
Envoy 앞단에 다양한 Filter 를 배포하여, 실제 요청이 각 MSA 서비스에 전달되기 전에 전처리 작업을 진행할 계획입니다.
예를 들면 실제 서비스에 전달 되기전에 어뷰징 체크 및 웹 방화벽 같은 역할을 하는 Envoy Filter를 개발하여서 서비스 안정성을 높힐수 있고, 외부에 노출 되는 인증 토큰과 내부에서 사용하는 인증 토큰을 분리하여 보안에 좀더 신경 쓰고, 내부 MSA 기반 서비스들을 내부 인증 토큰 통합하여서 인증에 큰 신경쓰지 않아도 MSA 서비스를 손쉽게 늘려 나갈수 있도록 할수 있습니다.
참고로 Envoy 에서는 기본으로 지원하는 여러 Filter 를 활용 할수 있고, 뿐만아니라 WASM 기반으로 Filter 개발을 지원하기 때문에 사용하는 언어에 제한없이 개발할 수 있는 장점이 있어서 개발자 익숙한 언어로 빠르게 Filter 들을 개발할 수 있습니다.
Conclusion
지금 까지 간략하게 PART 2 — Api-Gateway 소개에 대해서 알아보았습니다.
아직은 고민할 부분이 많이 남아 있지만 지속적으로 개선해볼 생각입니다.
다음 포스팅은 PART 3 — GitOps 소개 에 대해 포스팅 해보도록 하겠습니다.
WATCHA에서는 다양한 기술들을 활용해 서비스를 지속적으로 개선, 발전시켜 갈 실력 있고 뜻있는 개발자들을 모집하고 있습니다. 관심있는 분은 채용공고를 참고해주세요.
