<aside> 💡 이 시리즈는 MicroServiceArchitecture (이하MSA)를 알게되고 적용을 해보며 배운것들을 내 맘대로 풀어쓰는 글입니다. 글의 오타, 내용의 오류의 지적과 질문은 언제나 환영입니다. 😇
</aside>
[그림 1. 현재 아키텍처]
회사에 입사하고 신규 프로젝트를 시작했을 당시 기존 서비스와 연동 되는게 아무 것도 없을거라는것을 들었다. 그래서 기존 서비스를 생각조차 하지 않은 상태에서 설계를 들어갔다. 그런데 개발을 끝내고 서비스를 시작할때쯤 되어 회원정보를 연동 해야하는 요구 사항이 생겼다. 처음에는 입사동기분이 zongji라는 라이브러리를 통해서 기존 디비의 binlog를 가지고 새로운 서비스의 회원상태를 연동시켜주는 작업으로 해결을 했었다. 그러다가 회원가입의 주체가 새로운 디비가 먼저 업데이트 되어야하는 상황이 왔고 HTTP Api를 통해 연동을 하게 되었다. 그래서 현재 [그림 1.]과 같은 아키텍처가 만들어 졌다.
처음 MSA를 알게 된건 1년전쯤 회사 동료에게서 MSA란걸 듣게 되었고 찾아보았다. 개념만 찾아보고 든 생각은 "어? 이거 되게 좋은 아키텍처 같은데? 우리회사가 지금 만들어져있는걸 이런 아키텍처로 뜯어고치면 정말 좋을거 같다" 라는 생각이 들었다. 하지만 당장 개발해야할 프로젝트들이 산더미 처럼 들어왔고 각 서비스별로 모놀리식 구성이 되었고 디비가 같은 상태를 공유해야하는 이상한 아키텍처가 탄생하게 되었다.
기존 구성되어있던 프로젝트도 리펙토링이 필요했지만 거기에 새로운 개발이 들어가면서 시간에 쫒기면서 개발하다 보니 구조자체가 이상해 지게 되었다. 이런 상황에 B2C 런칭을 위해 팀빌딩이 새롭게 되면서 CTO님과 인프라쪽으로 팀장이 합류 하셨고 회사 비지니스를 설명 드리고나서 MSA로 가자는 요청을 받았고 그 의견에 동의해서 MSA로 가기로 하였다. 하지만 나를 포함 주니어 백엔드 개발자가 2명인 상황에서 아무것도 모르고 MSA를 도전하게 되었다.
마이크로서비스(microservice)는 애플리케이션을 느슨하게 결합된 서비스의 모임으로 구조화하는 서비스 지향 아키텍처(SOA) 스타일의 일종인 소프트웨어 개발 기법이다. 마이크로서비스 아키텍처에서 서비스들은 섬세(fine-grained)하고 프로토콜은 가벼운 편이다. 애플리케이션을 더 조그마한 여러 서비스로 분해할 때의 장점은 모듈성을 개선하고 애플리케이션의 이해, 개발, 테스트를 더 쉽게 해주고 애플리케이션 침식에 더 탄력적으로 만들어 준다.[1] 규모가 작은 자율적인 팀들이 팀별 서비스를 독립적으로 개발, 전개, 규모 확장을 할 수 있게 함으로써 병렬로 개발할 수 있게 한다.[2] 또, 지속적인 리팩터링을 통해 개개의 서비스 아키텍처가 하나로 병합될 수 있게 허용한다.[3] 마이크로서비스 기반 아키텍처는 지속적 배포와 전개(디플로이)를 가능케 한다.[1][4]
MSA를 하며 알게된 단어