Micro Service Architecuture Trade-Offs

마틴 파울러(Martin Fowler)가 Microservice Trade-Offs라는 글을 게시 하였다. 마이크로 아키텍쳐 서비스에 대한 장단점에 대해서 설명한 글로 이 내용을 보고 내용을 요약해보고자 한다.

[Micro Service Architecture]

마이크로서비스가 제공하는 이득

Strong Module Boundaries

마이크로 서비스의 가장 큰 장점은 모듈경계가 명확하다.

사람들은 (decoupled)잘 분리된 소프트웨어 모듈이 좋다는 점에 모두 동의한다. 모듈형 시스템의 장점은 시스템의 변경 사항이 발생할 경우 변경할 작은 범위만을 이해하고 처리하면 된다. 이구조는 소프트웨어의 규모가 커지거나 개발하는 팀의 규모가 커질때 더욱 중요하다. 마이크로서비스는 각각의 팀이 독립적인 단위로 의사소통을 할 수 있는 패턴을 구축하는 것이 가능하게 만든다.

기존 모노리스 방식도 좋은 모듈형 구조를 갖지 못할 이유가 없지만 시간이 지나면서 소프트웨어가 점점 커지고 개발자가 늘어남에 따라 점차 망가지게 된다. 모듈을 분리하는 것으로 각 모듈간의 참조 관계에는 벽이 생기게 되는데 모노리스 방식에서는 이런 벽을 쉽게 지름길을 만들어 우회 하여 빠르게 사용할 수 있다. 이 방식이 모듈화된 구조를 망치고 팀의 생산성을 떨어트린다. 모듈을 분리된 서비스로 두는것은 경계를 더욱 단단하게 만들고 나쁜 코드를 작성하는것을 더욱 어렵게 제한한다. 제대로 된 경계를 가지지 못한다면 모듈의 분리는 장점이 아닌 핸디캡으로 변하게 된다.

Independent Deployment

최근엔 수많은 소프트웨어가 출시되고 많은 조직이 지속적인 배포(ContinuousDelivery)를 활용해 하루에서 여러번 배포를 수행한다. 대형 모노리스시스템에서는 작은 변경해도 전체를 다시 배포해야 했고 배포과정중 시스템 전체에 문제가 생길지도 모르는 문제가 발생할 수도있다. 하지만 마이크로 서비스에서는 가각의 서비스를 독립적으로 배포하는 것이 가능하다. 이것은 변경 사항에 대해서만 배포하는것을 가능하게 하였고 반영한 서비스의 문제가 발생해도 시스템 전체를 마비시키는 영향을 주지 않는다.

Technology Diversity

각각의 마이크로 서비스가 독립적으로 배포가능한 단위가 된 이후로 기술 선택에 있어 자유로워 졌다. 다른 언어, 다른 프레임웍, 다른 저장기술등을 사용해 특정 문제에 대한 더 적합한 방법을 사용할 수 있게 해준다. 기술다양성에 대한 토론은 특정 문제에 더 적합한 도구를 선택하는것이 주로 다뤄지지만 가장 큰 이점은 버전관리 이다. 모노리스의 경우 한가지 버전의 라이브러리만 사용할 수 있고  필요에 의해 버전을 올린다면 다른 부분에도 영향을 미칠수가 있다. 라이브러리의 버전관리 문제는 코드의 규모가 커질수록 더욱 어려워진다. 마이크로서비스는 시스템을 점진적으로 하나씩 변환해가며 그때마다 최상의 기술을 적절하게 활용할 수 있다.

마이크로서비스에서 발생하는 비용

Distribution

마이크로 서비스는 모듈화를 향상시키기 위해 분산시스템을 사용한다. 하지만 이 분산시스템이라는것 자체 만으로 문제가 발생한다.

첫 번째는 속도다. 분산시스템의 원격호출은 기본적으로 느리다. 만약 원격 서비스 호출내에서 또다른 원격 호출을 하게 된다면 응답시간은 끔찍하게 지연되는 특성이 있다. 

그리고 또 한가지는 신뢰성이다. 프로세스내에서 함수를 호출하면 동작하는것을 기대 하지만 원격호출은 언제든지 실패할 수 있다. 대다수의 마이크로서비스에서 가장 실패하기 쉬운 부분이며 이를 위해 실패를 위한 디자인Design for failure을 해야한다.

Eventual Consistency

마이크로 서비스는 탈중앙적인 데이터 관리라는 칭찬 받을 만한 구조를 갖고 있다. 하지만 이로 인해 최후 정합성에 대한 이슈가 발생한다. 모노리스 에서는 단일 트렌잭션에서 여러가지 업데이트를 갱신할 수 있다. 하지만 마이크로서비스에서 여러 리소스를 동시에 갱신해야 할 일이 있을때 나타나는 분산된 트랜잭션은 눈살을 찌푸리게 한다. 그래서 개발자는 항상 정합성 문제에 대해 주의하고, 코드가 잘못된 결과를 만들기 전에 동기화 해야 할 부분은 없는지 감지하는 부분을 처리해야 한다. 

Operational Complexity

독립적인 단위로 빠르게 배포가 가능하다는 점은 개발에 있어 큰 축복이지만 수많은 작은 마이크로서비스를 관리하게 되었다는 점은 부담이 될 수 밖에 없다. 이를 위해 서비스를 관리하고 모니터링할 필요가 생기더라도 운영 복잡성은 증가한다. 마이크로서비스에 찬성하는 사람들은 서비스가 작아질수록 이해하기 쉽다고 이야기 하지만 상호 연결성이 산재해 있고 복잡도가 제대로 제거되지 않는다면 서비스 사이의 디버깅이 어려워지는 등 컴포넌트간 잘못된 상호 연결로 인해 운영의 복잡성이 증가 한다. 

정리

각 아키텍처마다 각각의 비용과 이점은 각각이 시스템에서 다른 무게를 갖고, 이점과 비용이 뒤바뀔 수도 있다. 대다수의 사람들이 모노리스에 비해 마이크로서비스를 강조하는데 더 일반적인 상황에 적합하기 때문에지만 만약 시스템의 복잡도를 모노리스 아키텍처에서 감당할 수 있다면 마이크로 서비스를 사용하지 않아야 한다. 모노리스와 마이크로서비스는 양자택일의 문제가 아니다. 어떤 시스템은 두 아키텍처 중 어디에도 맞지 않을 수도 있다. 시스템에 맞는 적합한 아키텍처를 선택하고 적용하는것이 중요하다.

• http://martinfowler.com/articles/microservice-trade-offs.html (원문)
• http://haruair.com/blog/3066 (번역)