마이크로서비스 도입 이렇게 한다
중국에서 마이크로 서비스 구축 경험 때문인지 작년까지는 이곳저곳에서 관련 자문 등의 요청을 종종 받곤 했다. 그리고, 한동안은 마이크로 서비스 공부하게 책 하나 추천해주세요 같은 요청도 받았다. 마침 지인이기도 한 박재호님이 번역하신 <마이크로 서비스 도입 이렇게 한다> 책을 받아 훑어 봤는데... 구성이 꽤 충실했다.
이를 계기로 마이크로 서비스 도입과 성공 실패의 기준은 무엇인지 살펴보고, 각 장을 훑어 보며 실제 이 책을 활용해서 마이크로서비스를 도입한다고 가정했을 때, 떠오르는 생각들을 기록해본다.
마이크로 서비스를 왜 도입하는가?
안타깝게도 윗분(?)들이 시켜서 도입한다는 곳이 많았다. 설사 그러한 경우라고 해도 마이크로서비스 도입 실행을 책임지는 분은 그 의미를 충분히 이해하고 있어야 한다. 이유가 어찌되었든 마이크로서비스 도입은 상당히 큰 파장을 몰고 온다. 과거의 모노리스식(DBMS 서버 하나에 맞추는 구현법) 혹은 전사적 ERD에 입각해서 구현하던 방식에 비해 소통 비용과 협업의 복잡도가 월등히 높다. 비즈니스 변화에 유연하게 하기 위해 택하는 복잡함이란 사실을 이해하지 못하면 낭패를 볼 수 있다. <마이크로서비스 도입 이렇게 한다>의 저자 샘 뉴먼도 2장에서 비슷한 경고를 한다.
마이크로서비스는 목표가 아니다. 마이크로서비스로는 '승리'하지 못한다. 마이크로서비스 아키텍처 채택은 합리적인 의사결정에 기반한 의도적인 결정이어야 한다.
마이크로 서비스 성공의 척도
얼마전 최정우님 소개로 읽는 책 <하드씽>을 읽다가 디지털 트랜스포메이션 성공의 척도라는 것을 생각하고 기록한 일이 있다. 그 글에서도 비슷한 이야기를 했지만 응용 프로그램을 얼마나 빨리 수정해서 업데이트 할 수 있느냐가 성공의 척도다. 예를 들어 2주나 한달마다 필요한 기능을 만들어 내보낼 수 있다면 성공한 것이다. 그런데, 3개월이 더 걸린다면 완벽하게 실패했다고 볼 수 있다.
아래 그림은 필자가 차세대 프로젝트의 대안으로 제시한 차세대 프로젝트 안할 수 있게 차세대 프로젝트 하기에 삽입한 devops를 나타내는 그림이다.
마이크로 서비스 도입 기준과 성공 기준을 다뤘으니 이제는 각 장별로 인상 깊은 내용에 대해 말하려 한다.
1장. 더도 덜도 아닌 딱 마이크로서비스
1장 더도 덜도 아닌 딱 마이크로서비스 내용은 요점을 잘 짚었다. 먼저 비즈니스 도메인 중심으로 모델링하는 특징이 바로 독립적인 배포 가능성과 연결되어 있다는 점을 지적하고 있다. 이때, 프로그램의 3개 층위인 웹, 응용, 데이터가 모두 아울러서 변경할 수 있어야 독립적인 배포가 가능함을 도식화와 예시를 들어 설명하고 있다. 이는 마이크로서비스 도입할 때 꼭 알고 있어야 할 내용이다.
더불어 기술적인 측면외에 마이크로서비스 도입으로 인해 파생하는 데이터 소유권이나 주도권 문제를 다루고 있는데, 구축 과정이 아니라 릴리즈 이후 시스템 운영 과정에서 벌어질 조직 운영 방식에 대해 생각할 수 있게 한다. 또한, 다양한 양상으로 나타나는 결합도에 대해 구체적인 예를 들어 설명한다.
1장 마지막에 도메인주도설계를 마이크로 서비스 도입의 배경 지식으로 소개한다. 마이크로 서비스를 도입하기 위해 모두가 DDD를 알아야 한다고 할 수는 없지만, 적당한 프로그램 덩어리를 찾아내기 위한 지침으로 DDD의 패턴이상의 자료가 없는 것도 사실이다. 저자의 설명처럼 Aggregate1)는 혼란스러운 개념이다. 우리말로 1:1 번역하기 굉장히 난해한 말이지만, 집계라는 번역은 오해의 소지를 주는 표현인 듯도 하다.
2장. 마이그레이션 계획하기
우리 회사 CTO가 이 책의 2장을 보자마자 이렇게 말했다.
마이그레이션을 하지 말아야지
그가 하는 말은 무조건 하지 말아야 한다는 의미가 아니다. 공교롭게 필자가 바로 전에 올린 popit 글, 디지털 트랜스포메이션과 시스템 마이그레이션에서 다루는 하나의 프로젝트로 진행하는 마이그레이션을 말한다. 필자 역시 그 점에 대해서는 우리회사 CTO와 견해가 같다.
이와 같이 장 제목이 마이그레이션이라고 해서 흔히 말하는 일회적 전환으로 오해할 수 있다. 하지만, 책 내용을 보면 한국형(?) 마이그레이션에 대한 이야기가 아니다. 마이크로서비스 채택의 타당성부터 따지고 있다. 업계에서 흔히 개발 프로젝트 이전에 수행하는 IT 기획 단계에 검토할 내용을 두루 언급한다. 흔히 경영자들이 변환관리라고 부르는 조직 변화 측면부터 변화를 어떻게 계획할지 그리고 잘 되고 있는지는 어떻게 측정할지 등의 관점을 두루 다룬다. 저자가 유명한 IT 컨설팅 기업인 소트웍스ThoughtWorks 출신의 컨설턴트임이 잘 드러나는 부분이다.
3장. 모놀리스 분할
필자와 함께 중국에서 마이크로서비스 도입에 참여했던 CTO는 모놀리스 분할에 반대한다. 나는 CTO 반대 논리에 수긍했다. 모놀리스 분할이라는 관점으로 일을 끌어가기 보다는 새로운 사업에 마이크로서비스를 도입하는 것이 장점이 많다. 하지만, 그렇게 하더라도 기존의 데이터를 끌어와야 하는 일이 대부분인지라 책에서 다루는 모놀리스 리팩터링이나 점진적 재작성에서 다루는 내용들은 여전히 유효하다. 결국 필연적으로 고민해야 할 전략의 문제이기 때문에 이런 선택지가 존재한다는 사실 자체를 알고 있는 것이 더 중요할 수도 있다.
4장. 데이터베이스 분해
데이터베이스 분해는 마이크로서비스 도입의 꽃이라고 할 수 있다. 다만, 그 파급효과가 크고 기존 모놀리스 체제에 익숙한 개발자에게는 상당한 두려움을 주는 일이기 때문에 다각도로 검토할 필요가 있다. 책에서도 이를 염두하여 다양한 패턴을 들어 영양도를 가장 줄이는 방식에서 독립성을 높이는 방식까지 선택지를 설명한다.
필자도 유사문제를 다룬 글을 쓴 일이 있는데, 데이터베이스 분해는 대상 시스템 상황이나 개발팀 구성에 따라 다르기 때문에 섣불리 해결책을 말하기 어렵다. 그런 점에서 책에서 제시하는 구체적인 방법을 하나의 예시로 이해하고 각자 상황에 맞는 구현법을 찾는다는 생각으로 보면 유익할 듯하다.
마이크로 서비스 단위의 책임 할당 예시
이 책은 데이터베이스 분해를 하면 필연적으로 발생하는 데이터 동기화 방법에 단계적 접근 방식에 대해서도 예를 들어 충실하게 설명하고 있다.
5장. 마이크로서비스 도입 과정에서 직면하는 문제와 해법
실전 응용에 해당하는 구체적인 사례가 나오는데, 여기까지 읽어볼 독자는 매우 드물 수 있다. ;)
부디 이책에서 영감을 받아 제대로 실천하는 용자가 나오시길 기대한다. 필자는 중국에서 마이크로 서비스를 실제 운영 규모에서 실천해 볼 수 있었고, 그 과정 함께한 동료가 쓴 글이 있다. 이 장은 바로 아래 글과 같이 마이크로 서비스 구축이 자리를 잡아갈 때 다룰 수 있는 문제가 아닌가 싶다.