[도서] 마이크로서비스 도입 이렇게 한다

들어가기 앞서

난 마이크로서비스 아키텍처가 막연하게 서비스를 나눈 것으로만 생각했었다. 내가 관련된 일을 하게 될거란 생각을 하지 못한 것 이다.. ㅋㅋ

시간이 흘러 어느덧 관심이 생기고 마이크로서비스 아키텍처에 관해 공부를 하기 시작했다. 그러나 정말 생소한 개념이 너무 많았다. 그리고 풀리지 않은 의문이 생기기 시작했다. 인터넷을 뒤져봐도 정해진 정답이 없기에 궁금해 미쳐버릴 것만 같았다!!

• 서비스를 어떻게 쪼개야되지?
• 사내 조직 구성과 연관이 클까?
• 데이터베이스도 분해해야돼?
• 분해된 데이터베이스의 트랜잭션 관리는 어떻게 해야되는가?

궁금증을 안고 책을 읽기 시작했다.

책 정보

• 마이크로서비스 도입 이렇게 한다
• Sam Newman 지음, 박재호 옮김
• 상세 정보

읽고 나서

마이크로서비스 아키텍처를 무조껀 적용해야될까?

새로 생기는 프로젝트에 마이크로서비스 아키텍처를 적용하고 계속 확장해나가는 것이 좋을 것이다.라고 생각했었다. 그러나 그것은 잘못된 생각이었던 것이다. 마이크로서비스 아키텍처는 모놀리스에 비해 복잡하여 구성 비용이 많이든다. 높은 비용을 무릎쓰고 마이크로서비스 아키텍처를 적용해서 구성을 했다고 쳐보자. 프로젝트는 시작한지 얼마되지 않았다. 프로젝트 기획이 예상했던 방향하고 갑자기 틀어지거나 핵심 부분을 변경할 수 있을 것이다. 왜냐하면 이제 시작한 프로젝트이기 때문에. 그럼 그 때마다 각각의 서비스를 전부 수정하고 구조를 재구성할 것이냐? 이것 또한 비용이 많이 들 것이다. 마이크로 서비스 아키텍처를 적용할 땐 얻는 이익하고 들어가는 비용을 계산하고 미래에 계속 유지됨으로 이익이 생기는지를 계산해봐야될 것이다. 위의 예시처럼 도입을 늦추는 것도 한 방법이 될 것이다.

서비스는 기준으로 분해하고 구성 하는가?

서비스를 구성할 때에는 조직 구성, 비즈니스 등 여러가지 요소가 들어간다. 이러한 요소를 이용하여 도메인 주도 설계 (DDD)를 함으로써 확실한 경계를 구성하여 도메인을 설계하여야 할 것이다. 이를 바탕으로 마이크로서비스를 구성하면 좋은 설계가 될 것이다.

트랜잭션 관리

Two-Phase Commit

첫 번째로 Two-Phase Commit이다. 말 그대로 커밋을 voting 단계와 commit 단계로 2단계로 수행하는 것이다. 각각의 데이터베이스 워커에 커밋의사를 확인하고 모든 워커가 커밋의사를 표시하면 커밋을 수행하는 것이다. 한 워커라도 커밋 의사를 표시안하면 모두 롤백된다. 그러나 여기서 헛점이 있다. 일단 2PC를 각각의 DB가 지원을 해야되고 모두 커밋을 할때까지 데이터는 Lock 상태가 된다. 긴 Lock 상태는 큰 문제를 야기하기 쉽상이다. 그리고 가장 중요한 문제는 동시성을 지원하지 않는다는 것이다. 분명 커밋이라는 동시성을 지원하지 않는 다는 것이 무슨말이냐?란 생각이 들 것이다. 일단 커밋의사가 확인되면 코디네이터가 커밋 요청을 동시에 여러 DB로 보낼 것이다. 그리고 각각의 DB에서 커밋을 진행할 것이다. 여기서 각각의 워커가 응답하는 시간도 다르고 동시에 커밋이 끝난다는 보장이 없다. 한 마디로 각각의 워커가 응답하는 속도가 느릴 수록 데이터 불일치 시간이 길어지는 것이다.

Saga 패턴

위의 2PC 커밋은 비효율 적이고 완전하지않다는 것을 깨달았을 것이다. Saga 패턴은 여러 변경사항을 조정하고 자원을 Lock 상태로 만들지 않는다. 이게 무슨말이냐? Saga 패턴의 내용은 복잡하다. 간단하게 설명하면 한 요청이 왔다고 하자. 그 요청안에는 여러 단계의 데이터 수정이 필요하다. 각각의 단계에서는 데이터베이스에 실제로 Commit하여 반영한다. 그럼 만약 중간 단계에서 실패가 나면 어떻게 되는가? 각 단계를 구현할 때 성공해서 DB에 변경사항을 반영(Commit)하는 코드, 실패했을 때 DB 변경사항을 DB에서 원래대로 되돌리는 코드(Commit)가 필요하다. 재밌는 점은 실제로 반영된 데이터를 직접 되돌려야되는 로직이 더 필요한 것이다. 만약에 중간 단계에서 실패가 일어나면 하나씩 전단계씩 되돌아가며 실패 로직을 수행하면 되는 것 이다.

• 정상로직: 주문 성공 -> 결제 성공 -> 배송 성공
• 실패로직: 주문 성공 -> 결제 성공 -> 배송 실패 -> 결제 원복 -> 주문 원복

물론 2PC 커밋에 비해 복잡하나 DB를 이용하는게 아닌 논리적인 관점에서 데이터의 안정성을 보장할 수 있는 것이다. 물론 구성은 더욱 복잡할 것이다.

이 Saga 패턴에도 두 가지 종류가 있는데 중앙집중형인 Orchestrated saga와 분산형인 Choreographed saga가 있다. Orchestrated saga는 해당 로직을 한 서비스에서 관리를 하는 것이다. 중앙에서 관리하기에 오류 발생시 추적이 용이하고, 비즈니스 로직을 한 눈에 파악할 수 있다. 그러나 해당 Orchestrated saga에 여러 서비스의 비즈니스 로직이 포함되어 관리되기에 관리 주체자가 늘어난다. Choreographed saga는 메시지 큐 등을 이용하여 한 로직에 대한 이벤트를 분산처리 하는 것이다. 여기서 각 로직에 대한 책임은 해당 서비스에 있기 때문에 해당 서비스 관리자에 책임이 있어 관리가 용이할 것이다. 그러나 오류 발생시 추적은 쉽지않다. 또한 두 Saga 패턴에 어울리는 비즈니스 로직이 있으니 로직, 관리주체 등을 고려하여 두 Saga 패턴을 이용하면 될 것이다. 꼭 한 가지만 쓰란 법은 없는 법!

추가적으로

이 책은 옮기신 분이 잘 옮겨주셔서 책 읽는데 거부감이 들지 않는다. 그리고 내용이 실제 구현하는 실습 위주보다는 이론 위주이고 설명이 쉽게 되어있기에 입문자에게 강추한다.