GraphQL 기반 애플리케이션 MSA 여정기 pt.1

안녕하세요. 백엔드 엔지니어 잭슨입니다.

작년 한해 태스크 중에 가장 많은 시간을 할애했던 Micro Service Architecture 도입기를 다른 분들에게 도움이 됐으면 하는 마음에 기록으로 남겨봅니다.

Why MSA?

저희 회사는 연초 대규모 투자를 받으며 회사의 규모를 확장하였습니다. 그로 인해 스쿼드(목적조직) 단위 조직구조로 개편이 되며 예상치 못한 문제에 봉착하게 되었습니다.

기존에 Mono Repo 구조에서 프론트엔드별 엔드포인트를 두어 사용하고 있었기 때문인데요. 이런 구조로 인해 5개의 스쿼드가 같은 개발주기를 가져가야 했고 또한 한 스쿼드가 준비가 되지 않았을 경우 다른 스쿼드의 블로커가 되는 비효율적인 구조가 되었습니다. 또한 스프린트 막바지에 항상 스쿼드 리드가 모여 배포에 대해 논의해야 하는 커뮤니케이션 비용도 치루고 있었습니다.

이를 해결하고자 플랫폼 엔지니어링팀에서는 스쿼드 단위별 배포를 위해 Micro Service Architecture를 도입하자는 논의가 이뤄지게 되었고 백엔드 개발자 분들의 동의를 얻어 프로젝트를 시작할 수 있게 되었습니다.

요구사항

Micro Service Architecture을 도입함에 있어 크게 세가지의 요구사항이 존재했습니다.

첫번째, 5개의 스쿼드별 배포가 가능할 것. 위에서도 말씀드렸다시피 가장 큰 Pain Point였기 때문에 최우선적으로 처리되어야 하는 사항입니다.

두번째, Backward Compatibility(하위 호환성)을 지키기 위해 프론트에선 최대한 변경이 일어나지 않을 것. 백엔드 API를 사용하는 가장 큰 두개의 클라이언트가 모바일과 태블릿이었기 때문에 API 스펙이 크게 바뀌어 하위호환성을 지키지 못하는 경우 장애로 이뤄질 가능성이 높았습니다. 그렇기 때문에 프론트와 소통하는 GraphQL Schema는 최대한 변경하지 않도록하는 것도 중요한 부분이었습니다.

세번째, 스쿼드에 계신 백엔드 엔지니어분들이 기능개발에 집중할 수 있도록 플랫폼에서 최대한 집중할 것. 여느 스타트업이 그러하듯, 저희 회사의 제품 또한 속도가 정말 중요한 상황이었습니다. 그렇기 때문에 MSA 도입은 플랫폼팀에서 전담하기로 하였습니다.

기존 아키텍처 (AS-IS)

전통적인 3계층을 기준으로 그림을 보며 설명해보도록 하겠습니다.

(이 외에도 Scheduler, Elastic Search, Redis, Redis Subscriber Application 등등 다른 인프라 요소들이 있지만 생략합니다)

다이어그램에서 보여지듯 Client와 GraphQL로 통신하고 있습니다. 그렇기 때문에 자연스럽게 BFF(Backend For Frontend) 아키텍처로 최초에 설계되지 않았나 생각이 됩니다.

기본적으로 코드 베이스는 Mono Repo로 이뤄져 있고 각 API는 코드 상으로 Service를 공유하고 있습니다. 때문에 배포시 모든 컴포넌트가 배포되는 플로우입니다.

CI/CD Process

1. Github Repo에 코드를 푸시합니다.
2. 코드를 푸시할 경우 Jenkins에서 AWS CodeBuild를 트리거합니다.
3. AWS CodeBuild에서 Build 및 Test를 진행합니다.
4. Build가 완료된 이미지를 AWS ECR에 푸시합니다.
5. CodeBuild에서 EKS Control Plane에 각 k8s Pods가 새로운 ECR 이미지를 통해 배포되도록 커맨드를 날립니다.

바뀔 아키텍처 (TO-BE)

다이어그램에서 보여지듯 변경될 아키텍쳐에서는 기존의 BFF 아키텍쳐에서 게이트 웨이에서 API Composition 역할을 하는 방식으로 이뤄집니다.

REST API의 경우 주로 Nginx와 같은 리버스 프록시를 사용하지만 GraphQL의 경우 Apollo Federation이라는 API Composer 역할과 게이트웨이 역할을 동시에 하는 컴포넌트가 필요합니다. Apollo Federation의 경우는 Docs 외에는 참고할 자료가 거의 전무하기 때문에 추후에 NestJS와 같이 사용하는 방법을 공유하고자 합니다.

간단하게 설명하자면 Apollo Federation으로 만들어진 Gateway는 각 API GraphQL Schema 파일을 문법에 맞게 작성하면 해당 도메인에 대한 요청이 들어왔을 때 도메인 소유권이 있는 API에 호출하며 Client에서 요청한 쿼리를 완성하여 반환해줍니다.

이번 Part 1에서는 마이크로 서비스를 도입하게 된 계기 그리고 어떻게 변경할지에 대해 알아보았습니다.
이후 이어지는 Part 2에서는 실질적으로 이뤄진 과정과 중간 중간에 있었던 어려움에 대해 작성해보고자 합니다.
읽어주셔서 감사합니다! Part 2에서 만나요!

2024.02.18 - [Programming/DevOps] - GraphQL 기반 애플리케이션 MSA 여정기 pt.2