그래서 MSA 어떻게 개발해야되는데? #1 API GATEWAY

InnomDB·2022년 5월 27일
3
post-thumbnail

api gateway가 뭔가요?

MSA를 구성하는 가장 큰 기술 중에 하나는 api gateway이다. 왜 api gateway가 중요할까?
우리는 어딘가로 들어가려면 항상 문을 거쳐야 한다. gateway는 바로 문이다. 우리가 만들 서비스의 입구역할을 담당하기 때문에 처음 주제로 적당하다고 판단했다.

게이트웨이는 무슨일을 하는데?

게이트웨이는 다양한 일을 할 수 있다. 예를 들면 우리가 집에 있을 때 누군가 벨을 누르면 누구세요? 라는 말부터 하지 않는가 이 처럼 게이트웨이는 상대방이 누구인지 신원을 확인해 줄 수 있다. 이 말을 한 가지 단어로 나타내면 바로 인증이다. 또한, 우리가 모르는 건물을 들어간다면 바로 앞에 데스크센터에 가서 목적지로 가려면 몇층으로 가야되나요? 하고 물으면 몇 층 몇 호로 가시면 되요~ 라는 대답을 듣곤 한다. 게이트웨이는 위처럼 경로를 알려주는 라우팅역할도 맡을 수 있다. 겨우 이정도 기능만 있다면 이번 포스팅을 다루지도 않았다. 우리는 보안이 심한 건물을 들어가게 된다면 방명록을 적어야 한다. 게이트웨이는 누가 왔다 갔다 했는지 알 수 있게 로그기능도 제공한다. 사실 이것 말고도 엄청 많지만 이런 것들은 다 우리 입맛에 맞게 적용하는 것이다.

사실 위에 적은 기능들은 내가 사용할 기능들 중에 추려서 적어놓은 것이다. 이외에도 CORS, 캐싱, 트래픽 관리, 원격 측정 및 분석, API 문서화 총 8가지의 기능을 담은 게이트웨이를 만들 예정이다.

상용화 게이트웨이

시중에는 지금 gateway들이 엄청 많다. KONG / Spring cloud gateway / tyk / krakend 등 오픈 소스 api gateway부터 AWS-API GATEWAY같은 cloud회사에서 제공하는 api-gateway들 까지 많은 api-gateway들이 있다.

어떤 게이트웨이를 써야하나요?

정답은 없다. 사용자가 상황에 맞게 각 기술 문서들을 보고 결정해야한다. 입맛에 맞는 게이트웨이가 없다면 직접 커스텀 게이트웨이를 만들면 된다. 우리 팀 또한 아직 어떤 게이트웨이를 쓸지 결정하지 못했지만 왜 몇가지 게이트웨이들에서 고민하는지에 대해서 적어보겠다.

  1. KrakenD(크라켄)
    공식 문서가 상당히 정리가 잘되있다.
    의존성이 없고 JSON 파일로 세팅이 끝난다.
    zero trust 정책 - 각 API마다 header 정보를 일일히 넣어줘야 한다.
    플러그인 적용 가능
    header에 크라켄이 추가되서 날아온다.
    로그 기본 세팅이 너무 빈약하다.

  2. kong(콩)
    많은 레퍼런스들이 있다.
    리소스를 많이 잡아먹는다. ex) 1개만 띄워도 1GB를 잡아먹는다.
    RDB는 오직 PostgreSQL과 호환된다.
    엄청나게 많은 플러그인이 지원된다.

  3. Spring Cloud Gateway
    자바를 썻다면 바로 채택했을 예정이지만 우리 팀 스택은 자바가 아니라 노드라 인프라 세팅에 어려움을 겪을거 같아 바로 탈락시켰다.

  4. Tyk(틱? 타이크?)
    공식 문서가 너무 조잡하다.
    국내 사용풀이 너무 적어 관련 자료들을 얻기 쉽지 않다.
    Tyk만의 특별한 장점이 보이지가 않는다.

    여러가지 이유로 아직도 고민중이다. 팀내 의견은 차라리 직접 구축하자는 의견이 나오고 있다.
    구축하는 방법도 여러가지이다. 오픈 소스를 다운받아서 입맛에 맛게 커스텀하거나 아니면 처음부터 끝까지 구축하거나 우리는 후자쪽에 의견이 더 실리고 있는 편이다.

    API GATEWAY를 어디에 위치 시켜야 하나요?

    이것은 나의 상황을 예시로 들겠다.

위의 사진은 배달의 민족 Legacy 였던 모놀리식 구조에서의 배달의 민족 아키텍처였다.
우리도 똑같다.. 대부분 모놀리식으로 구성하면 위처럼 구성이 된다.

우리의 목적은 ELB 앞단에 API GATEWAY를 놓는 것이다. 여기서 내가 겪었던 멍청한 고민을 말해보겠다.

우리 서비는 AWS를 이용하는데 AWS CLOUD안에 ALB(L7 LoadBalancer)가 있는데 어떻게 코드레벨로 API GATEWAY를 달 수 있는거지라는 멍청한 생각을 한적이 있었다. 대충 서비스를 그려보자면 아래와 같다.


전형적인 AWS ECS fragate구조이다. 이것을 혼자 손으로 테라폼보면서 그렸는데 아니 대체 어떻게 CLOUD 앞단에 코드 레벨로 게이트 웨이를 관리하겠다는 거지? 무조건 AWS API GATEWAY를 써야하는거 아닌가? 라는 생각을 잠깐 했었다. 그 생각은 바로 우아한형제들 기술블로그를 보고 사라졌다. 배달의 민족은 아래 사진과 같이 API GATEWAY를 구성하였다.

이 사진을 보자마자 나는 그냥 유레카~

이것을 보자마자 아닛!! ELB가 무려 3개!? 컨테이너를 띄워서 컨테이너 안에다가 API GATEWAY를 구성하면 코드 레벨로 관리가 가능하겠구나라는 생각이 들었다. 게다가 ELB는 1개만 가능한줄 알았었던 나는 반성의 시간을 가져 AWS에 깊숙히 들어가보도록 했다.

그래서 다음 포스팅은 AWS관련 포스팅이 될거 같다ㅋㅋㅋ.. MSA는 API 게이트 웨이를 정하고 다시 돌아오겠다!! 그럼 20000~

배달의민족 API GATEWAY 구성기
AWS 구성도 사진 출저 블로그인데 겁나 정리 잘해놨다. AWS를 포스팅할때 소개할 예정이다.

profile
이노오오옴

1개의 댓글

comment-user-thumbnail
2022년 5월 27일

다음 글이 기대되네요 뭐로 될까..두큰

답글 달기