골라밥이 MSA 를 채택한 이유

골라밥이 궁금하신 분들은 다음 노션 사이트를 참고해주세요!

💡 해당 글은 SA를 전문적으로 공부한 전문가가의 MSA 에 대한 소개글이 아닌,
개발자가 되고싶은 학생으로서 여러 문서들과 컨퍼런스를 통해 안 MSA 라는 아키텍처를 실제 서비스에 적용하기까지의 고민과, MSA 를 서비스에 적용한 이유와 적용과정에서 나온 문제점에 대한 글입니다!
오류를 발견한다면 언제든 댓글로 지적 부탁드려요!

골라밥, 불편의 불편을 해결하려는 서비스

골라밥은 교내 급식에 대한 학생들의 불만을 해소하고자 학생회에서 진행했던 급식 선호도 조사의 불편함을 개발자 스럽게 해결하기 위해 만들어진 서비스입니다!
기존 GoogleForm 을 통한 급식 메뉴 선호도 조사는

• 투표 항목이 너무 많고
• 투표 결과의 가독성이 떨어지며
• 수동으로 그 많은 급식 메뉴들을 입력해야하는

불편함이 있었습니다. 따라서 골라밥은 1일 3회 조식/중식/석식 시간대별로, 학생들이 가장 많이 사용했던 디스코드 의 챗봇을 통해 나이스 API 에서 받아온 급식 메뉴들에 대한 투표를 클릭 한번으로 할 수 있도록 하였습니다.
또한, 웹을 통해 급식 투표 결과를 막대그래프 형식으로 쉽게 볼 수 있도록 하였죠.

MSA, 많이 들어봤었는데?

Micro Service Architecture 의 약자로, 현재 가장 핫한 소프트웨어 아키텍처입니다.
MSA 를 가장 성공적으로 적용한 기업인 Netflix 는 MSA 를 다음과 같이 정의하였었는데요

loosely coupled service oriented architecture with bounded contexts
Bounded Contexts 간의 느슨한 결합으로 이루어진 SOA(서비스 지향 아키텍처)

• Bounded Contexts
  각 관심사(도메인)간의 경계 혹은 하나의 관심사의 범위를 말합니다. (자세한 내용은 링크를 참고해주세요)
• loosely coupled (느슨한 결합)
  말 그대로 각 서비스간 결합이 느슨해야한다는 것 입니다. 하나의 서비스의 갱신(변화)에 다른 서비스가 영향을 받는 일이 최소화 되어야한다는 것 입니다.
  MSA 에서는 각 서비스를 하나의 독립된 서비스로서 작동할 수 있도록 해서 각 서비스간의 결합을 느슨하게 만들어야한다는 것이죠.
  여러분의 서비스에서 단축URL 을 사용하기위해 NaverShortURL API 를 사용한다 할 때, 여러분의 서비스와 NaverAPI 정도의 결합성을 띄고 있어야 한다는 것 입니다.
• SOA
  서비스 지향 아키텍처의 약자로, 서비스별로 인스턴스를 나누는 방식의 아키텍처라고 보시면 됩니다. (자세한 내용은 링크를 참고해주세요)

즉, 각 도메인의 범위를 확실하게 나누어, 도메인별로 독립된 서비스를 구성하는 SOA 의 파생형 아키텍처 라고 생각하시면 됩니다!
MSA 에 대해 더욱 자세히 알고싶으신가요?

교내 서비스엔데 굳이 MSA 를?

많은 개발자분들이 MSA 를 대규모 서비스에서나 적용할법한 아키텍처 로 인식하고 있었습니다. 바로 "MSA를 적용하는 비용" 떄문이었는데요. API 통신이 늘어남에 따른 성능이슈부터, 정확한 명세의 필요 까지, MSA 의 비용상 단점은 너무나도 명확하였습니다.

그럼에도 골라밥이 MSA 를 채택한 이유는 기존 모놀리식 아키텍처나 SOA 에 비해 MSA 가 가지는 강점이 너무 매력적이었기 때문입니다.

도대체 어떤 장점들이 있길래 골라밥 개발에 MSA 를 사용하게 된걸까요?

기술스택이 달라도 돼!

골라밥은 전공동아리 도토리에서, 모두가 함께 프로젝트를 해보자! 라는 생각에서 나온 프로젝트입니다.
따라서, 프로젝트의 퀄리티도 중요하지만 모두가 참여할 수 있는 것 이 더욱 중요하였죠.
하지만, 동아리원들의 기술스택은 각양각색 하였으니... 당장 백엔드 부분도 SpringBoot 사용자와 Nest js 사용자로 나뉘게 되었죠.
이러한 기술스택의 차이를 해결하기 위해서는 서비스를 나눌 필요가 있었습니다.
따라서, 나이스 API 에서 투표할 급식 정보를 가져오는 기능 을 lunch-server 로 분리하여 Nest JS 로 구현하게 되었습니다.

MSA 가 빛을 발하는 순간, "협업"

이로서, 서로 다른 스택을 가진 개발자간의 협업문제는 해결하였지만, 예상치도 못했던 문제가 생기게 되었습니다.

• 같은 스택을 가진 SpringBoot 개발자들 중에서도 Github Branch 를 사용한 협업방식이나, 도메인형 패키지 구조에 어려움을 느끼는 분들이 계셧으며,
• 프로토타입 제작 도중 잘못된 PR로 인해, 완전히 다른 도메인에까지 영향을 끼치는 일도 발생했거든요.

따라서, 이러한 협업중의 문제를 막기 위해서, 아예 서비스를 분리한 후 각 서비스간의 정보교환을 위한 API 명세 를 만들고,
이를통해 BE개발자분들을 총 3개의 작은 그룹으로 나누어 자율적으로 개발할 수 있도록 하였습니다.
이렇게 할 경우, 기존처럼 한 도메인의 오류가 다른 도메인에까지 큰 영향을 끼치는 일은 막을 수 있다고 생각했거든요.

MessageQueue? 굳이 써야해요?

네. 골라밥은 Message Queue 를 쓰지 않았습니다
MQ 를 도입하지 않았는데 어떻게 MSA 를 채택했냐고 할 수 있을까요? CNCF 에서도 표준 MSA 의 구성요소중 하나로 MQ 를 뽑았는데 말이죠.
이는 MSA 에서 Message Queue 가 필요한 이유가 저희 서비스와는 무관하기 때문이었습니다.

저희 서비스는 말그대로 "교내 서비스" 였기 때문에,
라즈베리 파이에서 Docker 없이 바로 돌릴 수 있을정도로 규모가 작았고,
투표 집계같은 데이터의 수정이, 정해진 시각에 매일 1번씩밖에 일어나지 않았습니다.
따라서 데이터, 서비스의 동기화 이슈가 발생하지 않을것 이라고 단언할 수 있었고,
굳이 복잡한 MQ 를 도입할 필요성을 느끼지 않았습니다. (실제로 아직까지 데이터 동기화 관련 이슈가 발생한적은 없습니다.)

오히려 작은 서비스인 것이, MSA 를 도입하기 쉬웠던 것 이죠.

하지만... API 명세는?

위에서 설명한 이점들로, MSA 를 채택하긴 하였지만, MSA 의 단점들 또한 명확했기에 이에대한 해결이 필요하였습니다.
초기 골라밥의 경우, 빠른 기간내로 출시를 해야하였기에, API 명세를 노션으로 빠르게 작성하고,
API 연동에 대한 이슈는, 직접 서버를 돌려가며 수기로 해결을 하였죠 😥

따라서 골라밥이 한창 서비스중인 현재는 Swagger API 와 RestDoc 을 활용하여 API 별 문서를 작성하였습니다!
또한, lunch server 를 제외한 서버들은 전부 SpringBoot 를 사용하여 개발하였기 때문에, JVM 환경에서 사용 가능한 통신규격 라이브러리를 개발하게 되었습니다
통신규격이면 라이브러리가아니라 API 아니냐고요?

너무 커져버린 Discord 모듈

개발을 진행하다보니, Discord bot 모듈이 점점더 커져나가게 되었습니다.
빠른 릴리즈를 위해 명확한 Testing 을 거치지 않다보니, 코드의 신뢰성을 떨어졌고
그 상태에서 모듈이 더욱 커지다보니, 작은 변경에도 커다란 오류가 따라오게 되었습니다..
또한, Discord 모듈 자체가 담당하는 기능이 많아지다보니 더이상 장애에 유연한 서비스 라곤 할 수 없게 되었죠.
MSA 를 적용함으로 얻은 장점이, 테스팅의 부재와 서비스의 규모확장으로 인해 사라진 것 이었습니다.

따라서, Discord 모듈을 분할하기로 하였습니다.

우선, Discord 모듈에서 담당하고 있던 회원 인증과 회원정보 저장 로직을 AccountServer 라는 새로운 모듈에게 위임하였고, 복잡한 JDA 로직을 Cacophony 라는 자체 제작 DiscordAPI Client (wrapping library) 로 대체하여, 코드의 간결성을 늘렸습니다.

또한 분할하는 과정에서 나온 새로운 모듈들을 아예 Golabab V2 부터 적용하기로 하였습니다 (변경점이 너무나도 많았거든요)

글을 마치며

기술 트랜드는 점점, 모놀리식에서 SOA 로 SOA 에서 MSA 로 점점 큰것에서 작은것으로 변화해가고 있습니다. 하나의 뛰어난 서비스보다 여럿의 서비스들의 상호작용이 더욱 뛰어난 성능을 발휘할 때도 있다는거죠.
개인적으로 이러한 MSA 방식에서 한명의 뛰어난 개발자보단 여럿의 개발자들이 함께 개발하는것이 더욱 높은 효율을 내고, 이를 위해 협업이 필수인 현재 개발 트랜드를 떠올리게 되었습니다

물론, MSA 가 무조건적으로 좋다는것은 아닙니다. 아직 명확한 단점이 존재하는, 때에 따라 좋은 아키택처 인 셈이죠.

그러니 가장 중요한것은 자신의 서비스에 가장 적절한 아키텍처를 선택하는 것 과 이를 위한 고민이 아닐까요?

긴 글 읽어주셔서 감사합니다! 😀