APISIX로 11번가 Open API 모놀리식 시스템 개선하기 [리뷰]

‍정진철·2023년 12월 23일
1

APISIX로 11번가 Open API 모놀리식 시스템 개선하기

ref: https://techtalk.11stcorp.com/2023/session/session04.html

목차
1. 11번가 Opan API 시스템 소개
2. 역사
3. 문제점
4. API Gateway 패턴
5. Apache APISIX 소개
6. 개선점

11번가 Open API 시스템 - 소개

  • 현재 11번가에서는 셀러와 일반 고객들을 대상으로 OPEN API 제공 (총 662개)
  • 평시 2,000 RPS 트래픽 처리

11번가 Open API 시스템 - 역사

  • 거대한 모놀리틱 구조
  • 모든 요청이 모놀리틱 서버에서 처리
  • 상품,리뷰 등 모든 도메인 처리 -> 서버 사이즈 및 유지보수 비용 증대

  • 따라서, 도메인 별 코드베이스 및 서버 분리

  • 기존 코드베이스를 fork하고, 해당 도메인 별 필요한 코드만 잔재하도록함.

  • 각 도메인 서버로 요청을 처리하기 위해 WAS에서 URI 기반 라우팅 수행

  • 따라서 각 팀에서는 소스코드와 해당 도메인 서버만 관리하면 됐었다.

  • scale out도 도메인 별로 가능해졌으며, 한 도메인에서의 장애가 다른 도메인으로의 장애로 이어지지 않음 ( Single Point Of Failure - 단일 장애점 방지)

11번가 Open API 시스템 - 문제점

그럼에도 불구하고, 개선점이 요구되는 부분이 있었음

1. 노후화된 기술 스택

  • 기존 코드베이스(Java 7)에서 포크를 수행해 새로운 도메인 서버를 구성했기에 기존 기술스택을 사용할 수 밖에 없었다.
  • 기존 코드베이스를 포그한 이유는 빠른 도메인에 대한 분리의 측면도 있었지만 인증/인가와의 강한 결합성도 한 몫 함.

2. 인증/인가 로직 중복

  • OPEN API 특성 상 API키를 검증하고, 유효한 키 일 때만 OPEN API를 사용하도록 허용해야함
  • 그 외에도 허용된 프로토콜 및 IP 검증에 대한 과정이 필요함
  • 이런식으로 총10단계의 복잡한 인증/인가 로직을 거침
  • 이러한 인증/인가 로직이 "모든 도메인" 서버에 공통적으로 적용됨.
  • 따라서 특정 인증/인가 로직이 변경되면 해당 변경된 부분을 코드베이스에 반영해야함.
  • 또한 도메인 서버를 분리할 때 마다 해당 인증/인가 로직을 넣어줘야 하기 때문에 기존의 관습을 계속해서 따라가야만 했음

=> 인증/인가 로직에 대한 관리로 인해 비지니스 로직에 대한 집중 어려움

3. 일관되지 않은 로깅과 모니터링

  • 웹 서버에서 Access Log를 수집하고는 있지만, 인증에 대한 처리는 각 도메인 별 뒷단에서 처리되고 있기에 해당 로그는 수집 X

  • 따라서, Access Log는 '각 도메인 서버'에서 관리
    => 하지만, 각 도메인 별로 Access Log를 수집하고 관리하는 방식이 일관되지 않은 상태

  • 또한 Accesss Log를 DB에서 관리하다 보니, 로그 검색이 번거로운 단점 존재

  • 모니터링도 각 도메인 별로 관리되고 한눈에 볼 수 있는 대시보드 역시 부재.

11번가 Open API 시스템 - 개선목표

해결책 : API Gateway 도입

API GateWay 패턴

  • API GateWay는 소프트웨어 아키텍쳐 패턴 중 하나
  • API GateWay는 마이크로서비스 혹은 백엔드 서비스의 진입점 역할을 하는 컴포넌트
  • API GateWay는 기본적으로 유저 요청을 Upstream 서버로 라우팅 하는 역할 수행
  • 뿐만 아니라, 인증에 대한 인증/인가 처리도 수행
  • 요청에 대한 모니터링/로깅 수행

=> 이처럼 API GateWay는 마이크로 서비스에서 중요한 역할 수행

Apache API (APISIX) 도입

특징

    1. Cloud Native
    1. 고성능
    1. Full Dynamic (재가동 없이 동적으로 변경사항 반영)
    1. 다양한 플러그인 제공
    1. Multi-Language 제공 (Custom Plugin 개발 가능)

11번가 Open API 시스템 - 개선점

  • 클라우드 쿠버네티스 환경에서 운영
  • 인증을 처리하는 별도 서버를 두어 APISIX와 연동
  • APISIX 플러그인을 사용해 유레카,로키,프로메테우스 서비스와 연동

구체적 개선 POINT 1 - 인증/인가 처리 개선

Before

  • 인증 서버가 각 도메인 별로 구현되어있었음
  • 인증/비지니스 로직의 결합도가 큼

After

  • APISIX에서는 'forward-auth-plugin' 제공
  • 해당 플러그인을 통해 인증 시스템을 외부 서비스로 위임 가능
  • 이러한 인증 로직 분리를 통해 개발자들은 오로지 '비지니스 로직'에만 집중 가능

  • 인증 서버에서 인증 로직을 거치면, API키에 해당하는 회원 정보를 조회
  • 해당 정보를 헤더에 심어 Upstream 서버로 전송하도록 구현
  • 이러한 구조로 인해 각 도메인 서버에서 인증 처리를 하지 않아도 단순 헤더에서 인장/인가 처리 즉, 회원정보를 알 수 있게됨
  • 불필요한 DB조회 하지 않아도됨.

구체적 개선 POINT 2 - Service Discovery 연동

  • 11번가에서는 유레카라는 Service Discovery를 MSA환경에서 사용해왔기에 이와 연동하기로 결정

  • 예를들어, 클레임 서버를 기존 모놀로틱 구조에서 분리 시, 서비스 디스커버리인 유레카에 서버 인스턴스를 등록하고 주기적으로 heartbeat를 전송
  • APISIX는 유레카에서 클레임 서버의 정보를 주기적으로 가져와 최신 상태 유지
  • APISIX에 라우트 설정까지 마치면 유저의 트래픽을 받을 수 있음.

=> 즉, APISIX는 서비스 디스커버리와 연동해 쉽게 upstream을 등록할 수 있음

구체적 개선 POINT 3 - 일관된 로깅 및 모니터링

  • APISIX는 로깅과 모니터링을 제공하기 위한 다양한 플러그인 제공
  • 프로메테우스 플러그인 사용 시, Metric 정보 수집 가능
  • 로키 로거 플러그인 사용 시 Access Log 정보 수집 가능
  • 그라파나로 시각화 수행

구체적 개선 POINT 4 - GitOps와 Hot-reload

  • GitOps는 어플리케이션 운영에 관한 요소를 코드화해서 깃에 관리하고 깃에 저장된 설정이 운영환경에 자동으로 Sync되도록함.
  • APISIX도 upstream과 라우터 정보를 깃에 저장 후 깃에 저장된 정보를 APISIX 운영환경에 자동으로 Sync 하도록 할 수 있음.
  • APISIX는 쿠버네티스 환경에서의 운영을 지원하기 위해 Ingress Controller 제공
  • Ingress Controller에서 APISIX 업스트림, 라우터와 같은 CRD (Custom Resource Definition) 지원

깃 Repo에 저장된 설정 파일이 APISIX에 동적으로 반영되는 과정

  1. 유저가 깃 설정 파일 수정
  2. Argo CD를 통해 변경사항 쿠버네티스에 반영
  3. APISIX Ingress Controller에서 변경사하 감지 후 APISIX에 반영

=> Hot-Reload의 과정

구체적 개선 POINT 5 - Custom Plugin 구현 (written in Java)

  • APISIX는 다양한 언어로 Custom Plugin을 구현할 수 있도록 SDK 지원
  • APISIX는 서브 프로세스로 Plugin Runner 실행
  • APISIX와 Plugin Runner는 Unix Domain Socket으로 로컬 통신 수행
  • 이러한 외부 플러그인을 통해 요청에 대한 검증 및 변환 로직 수행 가능

커스텀 플러그인 활용법

  • 사용자의 요청의 Accept 헤더에 따라 응답 형태 변환
  • 예를들어, 사용자가 XML,EUC-KR에 대한 포맷 요청을 했으나 upstream 서버는 JSON, UTF-8에 대한 응답 포맷만을 지원할 시
    커스텀 플러그인은 사용자의 요청을 upstream 서버에 전송하기 전에 사용자의 요청에 맞춰 포맷 변환 수행
  • 이러한 플러그인 사용하면 upstrem의 개입없이도 사용자의 요청에 맞는 반환 가능

개선점 정리

느낀점

우선은 모놀리틱 아키텍쳐 특성 상 모듈간의 결합도가 높아 모듈의 재사용성 및 모듈성의 장점을 발휘 할 수 없다는 것이 가장 큰 단점으로 느껴졌다.

해당 세션에서도 각각의 도메인에 대한 결합도 즉, 코드 베이스를 기준으로 굴비처럼 서로간에 엮여있다 보니 독립적인 로직 수행이 불가했다.

따라서 소프트웨어 아키텍쳐 중 API GateWay 아키텍쳐를 도입해 해당 게이트웨이가 일종의 중간다리 역할을 맡고 해당 중간다리에서 인증/인가 로직처리, 요청에 대한 변환, 도메인 서버와의 연동 등 다양한 로직을 한곳에서 처리할 수 있는 간편한 아키텍쳐 구성이 가능해지는 것이 특장점으로 다가왔다.

해당 세션에서 가장 크게 다가온 점은 인증/인가에 대한 처리를 기존에는 각각의 도메인 별로 가지고 있기에 upstream 서버에서 해당 로직을 처리했다면 해당 로직을 게이트웨이에서 맡아주니 한결 가벼워지고 나는 나만의 최신화된 언어 및 문법으로 비지니스 로직을 구현할 수 있다라는 점이 가장 인상깊게 다가왔다.

profile
‍정진철
WILL is ALL
이전 포스트

리눅스 기본 명령어

다음 포스트

aws-cli 사용하기

0개의 댓글

관련 채용 정보