앞서 이 글은 전문가가 아닌 우리FISA F4팀의 MSA 도전기이자 성장 기록임을 사전에 말씀드립니다.
내용적으로 잘못된 부분이 있다면 언제든 코멘트 또는 soohyuk96@gmail.com 으로 연락주시면 감사하겠습니다.

서론

안녕하세요. F4팀의 Tech Lead 엄준표(엄수혁)입니다.

지난번 블로그에서는 저희팀이 프로젝트 아키텍처로 MSA를 채택하게 된 이유에 대해 PM님께서 설명을 잘 해주셨는데, 이번에는 어떤 서비스를 제공하는 프로젝트를 진행할 지 그리고 다시 한번 MSA를 채택한 이유에 대해 설명드리겠습니다.

저희 팀 F4가 선정한 주제는 미술품 경매 (B2C) 사이트이며,
구체적으로 설명하자면 은행과의 협업 통장을 통해 미술품 경매에 참여할 수 있는 사이트를 제작하려고 합니다.

단순 교육장에서 진행하는 프로젝트에서 굳이 MSA?🙄 라는 의문점이 들 수 있습니다.

그련데도 저희팀 F4에서 MSA를 채택하게 된 이유는 명확합니다.
규모가 작은 프로젝트의 경우 빠른 속도로 개발하기 위해 MSA(Micro-Service Architecture) 보다 MA(Monolithic Architecture)가 적합하다는 것에 대해 인지하고 있으나, 클라우드 엔지니어링 교육 과정에서 배운 기술들을 활용하여 설계/개발부터 운영 측면까지 고려해봤을 때 MSA를 채택했을 때 얻을 수 있는 이점이 명확하기 때문에 이와 같은 이유로 저희팀 F4는 MSA 구조를 채택하게 되었고, 팀 목표는 아래와 같습니다.

F4팀의 MSA GOALS

  1. 서비스를 공통된 기능에 맞게 명확하게 분리하여 서비스 간의 의존성을 낮춘다.
  2. 각각의 서비스가 빠르게 배포될 수 있는 환경을 만든다.
  3. 서비스의 HA와 확장성을 확보한다.
  4. 하나의 장애가 서비스 전체적 장애를 발생시키는 상황을 배제한다.


자, 그러면 저희 팀 F4의 MSA를 위한 서비스 분리 과정을 함께 보시죠!

MSA 서비스의 분리

저희 팀은 기존 MA 환경에서 MSA로 구현하는 것이 아닌 처음부터 MSA 환경으로 프로젝트를 진행해야 하다 보니 명확한 서비스에 대한 분리가 필요했습니다. 그러기 위해서 모두 한 곳에 모여 어떤 기능이 필요한지? 어떤 데이터를 각각의 서비스가 관리해야하는지? 브레인스토밍을 통해 다양한 아이디어를 공유하고 프로젝트의 필요한 것들을 종합하기 시작했습니다.

브레인스토밍[출처 freepik]

종합된 내용를 통해 팀원들과 많은 조사와 회의를 통해 MSA의 적합한 DDD 개발을 채택했고, 이를 위해 각 비지니스 도메인을 분리하기 위한 몇 가지 규칙을 정했습니다.

  1. 단일 책임 원칙을 유지하는가?
  2. 서비스 간의 의존성이 높은가?
  3. 어떠한 기술 스택이 필요한가?
  4. 분리된 데이터 저장소가 필요한가?


위와 같은 규칙을 통해 서비스를 분리한 이유는

첫번째 MSA 핵심 목적인 높은 응집도 낮은 결합성을 갖은 구조를 설계하기 위해선 각각의 서비스가 무슨 역할을 해야하는지 명확히 할 필요성이 있습니다. 따라서 하나의 도메인은 특정 서비스에 관련된 하나의 책임만을 갖는것이 각 서비스간의 의존성을 줄이고, 변경으로 인한 타 MS에 영향을 끼칠 우려가 없습니다.

두번째 각 서비스별 유사한 환경을 갖게 되지만 서비스별 필요로 하는 기술 스택이 상이합니다. 따라서 별도의 기술 스택이 필요한 기술이 있다면 해당 서비스는 분리해야 한다 판단했습니다.

마지막으로 세번째 각각의 서비스가 독립된 데이터베이스를 관리할 정도로 데이터 양이 방대한지 여부에 따른 서비스 분리는 한 DB가 감당해야 하는 트랜잭션의 양을 해소시킬 수 있는 방법이 무엇일까? 고민 끝에 기준의 척도로 잡았습니다.

서비스 아키텍처

저희 팀은 보다 나은 프로젝트 설계를 하기 위해 지금까지도 다양한 래퍼런스들을 조사하고, 매일 끊임없이 우리의 생각이 맞는지 토론을 합니다. 아직 완성 단계는 아니지만 아래의 사진은 현재까지 진행된 아키텍처 설계이자, 고뇌의 결과물입니다.

Meeting

[윗쪽 오른쪽 사진 속 순서대로 혁잔디, 프린스초이, 김지후, 엄준표 입니다 ㅎㅎ]

어플리케이션 아키텍처

Architecture

저희가 설계한 아키텍에 대해 간단하게 설명드리겠습니다.

  • Front(Client)에서 받은 요청을 Spring Cloud Gateway 수신하여 필요로 하는 API 요청을 위한 인증/인가를 확인합니다.
  • G/W는 인증/인가된 유저에 한해서 Eureka 서비스에 등록된 각각의 MS 정보를 가져와, API를 해당 MS에 라우팅 시킵니다.
  • 각각의 MS는 통신을 하기 위해 FeignClient/Kafka 프로듀서/컨슈모 구조로 각각의 서버가 통신을 합니다.
  • 경매에 데이터 정합을 위해 kafka를 통해 전체 경매 데이터 로그를 기록합니다.

    • 시스템 아키텍처

    시스템 아키텍처 같은 경우 아직 변경 중에 있어 추후 올리도록 하겠습니다.

    참고

    https://techblog.lotteon.com/%EB%89%B4%EC%98%A8%EC%9D%B4%EB%93%A4%EC%9D%98-%EC%B2%AB-msa-%EC%84%9C%EB%B9%84%EC%8A%A4-%EB%8F%84%EC%A0%84%EA%B8%B0-d336186a7e31
    https://www.bucketplace.com/post/2022-01-14-%EC%98%A4%EB%8A%98%EC%9D%98%EC%A7%91-msa-phase-1-%EB%B0%B1%EC%97%94%EB%93%9C-%EB%B6%84%EB%A6%AC%EC%9E%91%EC%97%85/