카카오헤어샵의 아키텍처
모놀리틱에서 마이크로서비스로 진화 중입니다.
카카오헤어샵의 시스템 아키텍처는 Monolithic 구성으로 되어 있습니다. 그리고 하나씩 Microservice 구성으로 변경하고 있습니다. 프로젝트 내부 얘기를 하기 전에 먼저 두 용어의 정의에 대해서 알아보겠습니다.
Monolithic vs. Microservice
Monolithic은 시스템을 하나의 덩어리로 만드는 방식입니다. 일반적으로 UI를 담당하는 프론트, 비즈니스 로직을 구현한 애플리케이션, 데이터베이스로 구성되어 있습니다. 여러 인스턴스에서 실행되고 확장할 수 있습니다. 그리도 보통 RDB 1개에 데이터를 저장합니다.
Monolithic 방식은 작은 규모의 개발팀에서 좋은 효율을 발휘합니다. 하지만 시스템 요구사항이 다양해지고 개발팀 규모가 커지게 되면 점점 문제가 드러나게 됩니다.
1. 배포 횟수와 시간의 증가
- 작은 기능을 수정할 지라도 모든 인스턴스에 배포해야 합니다. 그러다 보니 배포 횟수가 증가하고 배포에 걸리는 시간도 오래 걸립니다.
2. 부분적인 scale-out 불가
- 특정 기능에 요청이 많아도 부분적인 scale-out이 불가능하고 전체 시스템을 scale-out 해야 합니다.
3. 기능 추가 시 통합 테스트가 오래 걸림
- 시스템 복잡도가 높다 보니 통합 테스트가 오래 걸립니다.
4. 프로그래밍 언어, 프레임워크 교체 불가
- 프로그래밍 언어나 프레임워크를 교체하려면 전체 시스템을 개편해야 합니다. 보통은 엄두를 낼 수 없고 경영진을 설득하기는 매우 어렵습니다.
5. 특정 기능 장애 시 전체 서비스 장애로 이어짐
- 부분의 장애가 전체의 장애로 이어집니다.
그래서 대두된 것이 Microservice입니다.
Microservice는 시스템을 기능 별로 잘게 쪼개서 별도의 애플리케이션으로 구성하고 상호 간에 HTTP 같은 프로토콜을 사용해서 연결하는 방식입니다. 시스템을 분리하게 되니 복잡도가 줄어들게 되어 위 문제점을 어느 정도 해소할 수 있습니다.
출처: https://www.sourceallies.com/2015/11/microservices-in-practice-the-positive/카카오헤어샵의 Monolithic
우리는 프로젝트 초창기에 빠른 개발 속도를 위해 Monolithic을 채택했습니다. 처음에 고객 서비스를 담당하는 Web 모듈을 만들고, 관리자를 위한 Admin을 만들었습니다. 두 모듈에서 공통으로 사용하는 기능들은 Common으로 분리하고 라이브러리 참조 형태로 구성했습니다. 그러나 2년이 훌쩍 지나면서 점차 문제점들이 하나둘씩 드러났습니다.
특히 저는 예전 회사에서 Monolithic 시스템이 비대해지면서 발생되는 문제를 겪어 보았기 때문에 빨리 Microservice로 전환하고 싶었습니다.
예전 회사는 10년 전에 세팅된 Monolithic 아키텍처를 지금까지 유지하고 있습니다. 그리고 모든 서비스들이 Common을 참조했는데, 그러다 보니 Common이 지나칠 정도로 비대했습니다. 게다가 Oracle 1 Set에 10여 개의 서비스가 물려 있다 보니 DB 장애가 발생하면 모든 서비스가 중단되는 사태가 발생했었습니다.
Microservice 적용
가장 처음에 전환한 것은 히스토리 적재 기능입니다. 카카오헤어샵은 비즈니스 히스토리를 MongoDB에 적재하고 있습니다. 서비스에서 직접 MongoDB에 접근하다 보니 Connection Pool 관리가 용이하지 않았습니다. 또한 Web은 사용자가 증가함에 따라 scale-out이 지속적으로 되고 있어서 히스토리 업무를 분리하는 것은 좋겠다고 판단했습니다. 그래서 히스토리만 남기는 웹 애플리케이션을 별도로 구성하고 기존 모듈과는 HTTP로 연결했습니다.
별도의 Microservice로 분리하니 시스템 복잡도도 떨어지고 관리가 용이해졌습니다. 그래서 이후에는 ElasticSearch를 사용한 스타일 찾기 기능도 Microservice로 전환할 계획을 갖고 있습니다.
그렇지만
카카오헤어샵의 주 기능인 1. 매장/디자이너/메뉴 관리 2. 예약/결제 3. 리뷰 작성 4. 고객 관리는 Monolithic 방식에서 Microservice의 전환이 쉽지 않은 상황입니다. 차라리 프로젝트 처음부터 Microservice를 염두에 두고 설계를 했더라면 나았을 텐데 이미 서비스가 되고 있는 상황이라 연관된 것들이 많습니다. 특히 MySQL DB에 Web, Admin, Batch, API가 모두 물려 있어서 쉽지 않은 상황입니다.
정리
현재 IT 서비스를 개발하고 있는 분이라면 Monolithic 시스템의 문제점을 알고 계시리라 생각합니다. 그럼에도 불구하고 이미 서비스 중인 시스템을 Microservice로 전환하는 것은 매우 매우 어려운 과정입니다. 그렇지만 어려운 길이라도 반드시 가야만 합니다.
왜냐하면 서비스는 시간이 지남에 따라 기능이 추가되게 되어 점점 몸짓이 커지게 됩니다. 그렇게 커지다 보면 야기되는 문제들도 필연적으로 많아지게 됩니다. 그래서 Microservice로의 전환이 반드시 필요합니다. 지금이라도 시스템을 쪼개고 경영진을 설득하십시오. 그렇지 않으면 미래에 후회하게 될 것입니다.
