[마소 394호] 제대로 구성하는 마이크로서비스 아키텍처

입력 2018.10.30 10:01

소프트웨어 전문지 마이크로소프트웨어 394호는 클라우드(Cloud)와 백엔드(Back-End)를 주제로 담았습니다. 트래비스CI, 데브옵스, PaaS, 마이크로서비스 아키텍처 등 마소 394호의 주요 기사들을 IT조선 독자에게도 소개합니다. [편집자주]

마이크로서비스 아키텍처! 마이크로가 들어간 이름치고는 다루는 범위가 넓으며, 아키텍처가 들어간 이름치고는 무엇 하나 쉽사리 결정해주지 않는다. 이 까다로운 녀석을 사내 백오피스 시스템에 적용하면서 얻은 경험과 결과물을 공유해보고자 한다.

버즈니가 운영 중인 모바일 홈쇼핑 포털 앱 홈쇼핑모아는 홈쇼핑과 T커머스 등 16개 채널을 한 곳에 모은 서비스다. 홈쇼핑모아를 위한 주요 개발 영역에는 서비스에 직접 사용되는 영역(프론트엔드 및 서비스 API) 외에도 백오피스(관리자 페이지 및 API) 영역이 있다. 이 글은 백오피스 영역에 마이크로서비스 아키텍처를 적용하게 된 이야기를 다룬다. 크게 세 가지 파트인 분해(Decomposition), 배포(Deploy), 인터페이스(Interface)로 나눠 설명하겠다.

백오피스 영역은 초기부터 규모가 절대 작지 않았다. 생방송 상품, 상품의 검색 키워드, 광고, 이벤트, 설문 조사, 고객 관리, 푸시 등 관리 페이지 자체만 20여 페이지가 넘게 있었다. 프론트엔드 개발자와 백엔드 개발자가 장고(Django) 프레임워크 안에서 함께 개발하고 있었고, 구조적으로 API, 클라이언트, 데이터베이스까지 다 한곳에 모인 모놀리틱(Monolithic Architecture) 아키텍처였다. 테스트와 빌드는 간편했고, 새로운 기능을 추가할 때 프레임워크 위에 소스만 추가하면 됐다. 다만 문제점은 시간이 흐르면서 복합적으로 나타났다.

버즈니는 2018년 상반기 직군 중심 구조에서 직무 중심으로 조직구조를 개편했다. 이는 프로젝트를 진행하면서 직무적 유관도와 업무 이해도가 적은 직군 중심의 팀 단위로 움직이기보다 프로젝트에 필요한 직무의 사람을 중심으로 업무를 진행하며, 각 구성원이 역할과 책임을 가지고 기민하게 움직일 수 있도록 하기 위함이다. 하지만 모놀리틱 아키텍처 구조에서는 경계의 애매함으로 관련자에게 적당한 역할과 책임을 나눠 주는 데 한계가 있었다.

버즈니의 백오피스 마이크로서비스 아키텍처. / 마이크로소프트웨어 394호 발췌
모놀리틱 아키텍처에서는 폴리글랏(Polyglot)하게 개발을 할 수 없다. 다시 말하면 요구 사항을 가장 잘 만족시킬 수 있는 적합한 언어, 프레임워크, 디자인 패턴을 선택할 수 없다. 이는 기술적 비효율로 이뤄질 수 있을 뿐 아니라, 개발자의 성장을 막는 요소로 작용하기도 한다.

또한 프로젝트의 절대적인 크기 자체가 커지며 생기는 문제점도 있다. 빌드 및 배포 시간이 늘어나며 패키지 관리가 힘들어진다. 개발을 시작하기 전 프로젝트 구조 및 히스토리를 파악하는데 필요한 시간 또한 늘어나게 된다.

마이크로서비스 아키텍처에는 정해진 정답은 없다는 말을 강조하고 싶다. 마이크로서비스 아키텍처는 태생적으로 많은 기업의 각기 다른 사례에서 생겨났기 때문이다. 다양한 옵션 및 패턴이 존재하며 상황에 맞게 적용하면 된다.

유민정 필자의 ‘제대로 구성하는 마이크로서비스 아키텍처’에 대한 자세한 내용은 ‘마이크로소프트웨어 394호(https://www.imaso.co.kr/archives/3939)’에서 확인할 수 있다.


키워드

관련기사를 더 보시려면,

[마소 394호] RxJava로 생각하기 오세용 기자
[마소 394호] 플라스크 효과적으로 사용하기 오세용 기자
[마소 394호] 스토리체인이 사이드체인을 선택하기까지 오세용 기자
[마소 394호] 모바일 앱 테스트 자동화용 디바이스팜 구축 오세용 기자
[마소 394호] 되돌아 보는 1만 개의 클라이언트 문제 오세용 기자
[마소 394호] 클릭만으로 도커 개발 환경을 완성시켜주는 애저 PaaS 오세용 기자
[마소 394호] DDD와 MSA로 쇼핑몰 구축하기 오세용 기자
[마소 394호] 이스티오 서비스 메시를 이용한 MSA 구축 오세용 기자
[마소 394호] 아마존 API 게이트웨이와 AWS 람다로 구성하는 다운로드 서버 오세용 기자
[마소 394호] AWS EC2와 트래비스CI를 활용한 무중단 배포 서비스 오세용 기자
[마소 394호] 스타트업의 좌충우돌 CI/CD 구성 오세용 기자
[마소 394호] AWS 이메일 서비스 써보니 오세용 기자
[마소 394호] 클라우드의 성능 품질 이야기 오세용 기자
[마소 394호] 클라우드 시대 토종 호스팅 업체의 변신 오세용 기자
[마소 394호] 데이터베이스의 게임 체인저, 오라클 클라우드 오세용 기자
[마소 394호] 알아두면 쓸데없는 신비한 TLS 1.3 오세용 기자
[마소 394호] 다시 보는 PaaS, 어디서 와서 어디로 가는가 오세용 기자
[마소 394호] 코드로 관리하는 인프라스트럭처, 테라폼 오세용 기자
[마소 394호] 더 웨더 컴퍼니의 데브옵스 오세용 기자
[마소 394호] 사설 클라우드의 끝판왕 오픈스택 오세용 기자
[마소 394호] 개발운영 퀀텀 점프를 위한 도커 오세용 기자
[마소 394호] IT 서비스와 모니터링 역사 오세용 기자
[마소 394호] 오픈스택 커뮤니티 동고동락 오세용 기자
[마소 394호] 데브옵스를 꿈꾸는 개발자를 위한 안내서 오세용 기자