Microservice를 영문 그대로 해석해보면 Micro(작은) service(서비스), 즉 작은 단위의 서비스를 의미합니다. 그럼 "작다"의 기준은 뭘까요? "작다"는 상대적인 개념이므로 이와 반대인 "크다"의 성격을 지닌 서비스는 무엇일까요? 이번 포스팅을 통해서 Microservice Architecture의 예시, 개념, 등장 배경 및 장단점 등에 대해 알아보겠습니다.
Story of Netflix
Microservice 설명에 들어가기 앞서 Microservice architecture을 가장 빠르게 도입한 회사 중 하나인 Netflix의 Microservice architecture로의 전환에 대해 소개하고자 합니다. 초창기 Netflix는 여타 회사와 마찬가지로 Monolith architecture로 프로그램을 개발하고 운영하고 있었습니다. 하지만 유저의 수, 트래픽 및 데이터의 양이 더 이상 Monolith architecture만으로 감당할 수 없는 시점이 왔고, Netflix는 대안으로 Microservice architecture을 도입했습니다. Netflix는 Microservice architecture을 도입하면서 기존 자신들이 운영하던 온프레미스(on-premise) 환경에서 클라우드 환경(AWS)으로 이전도 결심하게 됐는데, 이는 증감하는 트래픽에 유연하게 대응할 수 있는 클라우드 환경의 성격 때문이었습니다.
Netflix는 클라우드 환경 위의 Microservice architecture로 이전함으로써 다양한 이점을 얻을 수 있었습니다. 첫 번째로 유저 및 트래픽 수에 유연하게 대응할 수 있었습니다. 전 세계 곧곧 위치한 AWS의 클라우드 환경이 Netflix 서버에 발생하는 요청을 유연하게 처리할 수 있기 때문입니다. 또한 Monolith architecture을 기능별로 microservice로 분리했기 때문에, 각 microservice에 발생하는 요청량에 따라 서버의 수를 조절할 수 있었습니다. 둘째로는 개발 생산성의 향상입니다. Monolith architecture에서는 약간의 코드 실수로 전체 애플리케이션이 다운될 수 있습니다. 따라서 신규 기능을 추가하거나 코드 수정이 필요할 때 다른 기능에 영향도를 파악해야 하므로 시간이 오래 걸립니다. 하지만 Microservice architecture는 기능별로 분리된 형태이므로 비교적 신규 기능을 추가하거나 코드 수정에 시간이 덜 걸립니다. 또한 microservices로 분리하면서 팀을 더 작게 구성할 수 있게 됐는데 이는 각 팀이 담당하는 기능에 더 집중할 수 있고 이해도를 높일 수 있었습니다.
이처럼 Microservice architecture을 비교적 빠르게 도입한 Netflix는 새로운 기능을 출시하고 기존 기능을 개선하는 등의 시간을 다른 시장 참여자보다 빠르게 수행함으로써 시장 우위를 점할 수 있었습니다.
Microservice Architecture 란?
Microservice Architecture의 대가인 Chris Richardson가 정의한 Microservice는 다음과 같습니다.
Microservices - also known as the microservice architecture -
is an architectural style that structures an application as a collection of services that areHighly maintainable and testable
Loosely coupled
Independently deployable
Organized around business capabilities
Owned by a small team
Microservice란 일종의 서비스 아키텍처로 위에 명시된 특징을 지닙니다. Microservice의 특징 덕분에 여러 서비스를 운영하는 경우, 각각의 서비스에 대한 개발 및 배포 주기가 짧아진다는 장점이 있습니다. 하지만 이와 반대로 단점도 존재하기 때문에 Microservice 도입 시 고려사항이 많습니다. 그럼 Microservice가 왜 사용되기 시작했는지 살펴보겠습니다.
Why Microservice Architecture?
Microservice Architecture의 등장 배경을 말씀드리기 전에 Monolith Architecture에 대한 개념부터 짚고 넘어가겠습니다. Monolith Architecture란 하나의 프로그램에서 모든 서비스를 제공하는 설계 방식입니다. 따라서 하나의 프로그램에서 여러 서비스를 제공하며, 각 서비스는 동일한 프로그램 내의 다른 서비스들과 상호작용하며 동작합니다.
그럼 Monolith Architecture의 단점은 무엇일까요? Monolith architecture는 제공하는 서비스의 수가 적고 프로그램이 작을 때는 문제가 되지 않습니다. 오히려 하나의 프로그램 내에 모든 서비스들이 존재하므로 개발을 빠르고 쉽게 할 수 있습니다. 하지만 서비스의 수가 점차 증가하고 프로그램이 비대해지면서 문제가 발생합니다. 하나의 프로그램에서 처리해야 하는 요청의 수가 증가하는 상황을 가정해봅시다. 병렬 프로그래밍, 부하 분산, 디비 파티셔닝 등 다양한 기법을 통해서(비용을 더 지불해서) 어느 정도까지는 증가하는 요청을 감당할 수 있습니다. 하지만 증가하는 운영 비용 대비 처리 가능한 요청수 증가량이 점점 미미해지기 때문에 사실상 Monolith architecture로 감당할 수 있는 요청의 수에는 제한이 있습니다. 개발 생산성 또한 문제가 될 수 있습니다. 하나의 프로그램에서 다양한 서비스를 제공하다 보니 각 서비스 개발자들은 자신이 개발 중인 코드가 다른 서비스에 영향을 미치는지 항상 고려하면서 개발을 해야 합니다. 이는 새로운 기능을 도입하는 데 걸리는 시간을 기하급수적으로 증가시킬 수 있습니다.
그럼 Microservice Architecture은 어떻게 Monolith Architecture의 단점을 극복했을까요? Microservice Architecture는 모든 서비스를 하나의 프로그램에 포함시키는 것이 아니라 각 서비스별로 프로그램을 따로 운영합니다(DB도 따로 분리해서 운영하기도 합니다). 따라서 각 서비스는 하나의 프로그램에서 요청을 처리하고 저장하는 등 각자의 역할을 수행합니다. 이러한 방식의 장점은 서비스가 독립적으로 확장이 가능하고 개발이 가능하다는 점입니다. 즉, Monolith architecture에서 극복하기 어려웠던 확장 문제를 문제를 Microservice Architecture가 해결한다고 볼 수 있습니다.
대표적인 Microservice Architecture의 장점은 다음과 같습니다
- 확장성의 증가
- 에러의 확산을 좁은 영역으로 제한 가능
- 더욱 견고한 설계 가능
- 개발 생산성의 증가
- 작은 팀으로 개발이 가능
How to Microservice Architecture?
Microservice Architecture을 시작하는 확실한 방법이 따로 정해져 있지는 않습니다. Best practices는 존재하지만 각 팀의 상황이나 제공하는 서비스의 형태에 따라 도입하는 방식은 다양할 수 있습니다. 제가 소개해드리는 방식이 모든 상황에 적용 가능하지 않을 수 있고 상황에 따라서는 올바른 선택이 아닐 수 있습니다. 다만 Microservice Architecture을 도입할 때 고민하면 좋은 것들을 위주로 소개해드리겠습니다.
Start with monolith
서비스 개발을 시작할 때 Microservice architecture을 당장 도입하지 않아도 됩니다. 서비스 개발 초창기에는 서비스의 형태가 자주 변하고 유저의 니즈에 따라서도 쉽게 변할 수 있기 때문입니다. 불필요하게 Microservice Architecture를 도입하게 되면 오히려 운영비용과 복잡성이 증가할 수 있습니다. 다만 서비스가 확장할 때 쉽게 Microservice architecture로 분리할 수 있도록 Monolith architecture을 구축하는 것이 좋습니다.
Organize your team
Microservice Architecture 도입을 결정했다면 팀의 형태에 대해서 고민해야 합니다. Frontend, Backend, Operation 팀의 형태로 Microservice Architecture을 운영하게 되면 Microservice Architecture의 장점을 포기하게 됩니다. 이런 형태의 팀보다는 Microservice로 구분할 수 있는 서비스를 온전히 개발할 수 있는 각각의 팀을 만드는 것이 중요합니다. 이러한 팀의 형태는 각 팀의 서비스에 대한 이해도가 높기 때문에 개발 생산성이 높습니다.
Divide Monolith into Microservice
How to communicate between components
Microservice Architecture를 도입했다면 각 서비스가 어떻게 통신할지에 대한 고민도 필요합니다. 각각의 서비스들은 동일한 프로그램상에서 동작하지 않기 때문에 만약 하나의 요청이 여러 서비스에 의해 처리돼야 한다면 서비스 간 네트워크 통신이 필요합니다. 네트워크 통신 시 주의할 점은 네트워크 장애, 통신하는 서비스 장애, 응답 지연 등 다양한 장애 상황을 고려해야 합니다. 이는 Microservice Architecture을 구축할 때 어려움 중 하나입니다. 추가적으로 요청이 여러 서비스(여기서는 서버라고 생각해도 무방합니다)에 의해 처리되는 경우, 요청이 어떻게 처리됐는지 확인하기가 어려워서 오류가 발생하면 오류의 원인을 추적하기 어렵습니다.
이와 같이 서비스 간 통신 시 장애가 발생할 확률이 높고 개발 난도가 높기 때문에 통신 프로토콜 자체는 단순하게 유지하는 것이 좋습니다. 또한 서비스 간 통신 시 중간에서 데이터를 변경하는 것이 아닌, 각 서비스에서 알맞게 데이터를 처리하는 게 권고됩니다.
Divide data into bounded contexts or data domains
Microservice Architecture의 또 다른 장점으로는 기존 Monolith에서 사용하는 하나의 데이터베이스를 각 서비스가 담당하는 도메인별로 나눌 수 있다는 점입니다. 하나의 데이터베이스를 사용하게 되면 아무리 서버 레벨에서 요청에 대한 처리량을 늘리더라도 데이터베이스 병목현상 때문에 확장이 힘들게 됩니다. 하지만 Microservice Architecture에서는 각 서비스별로 데이터베이스를 독립적으로 관리할 수 있기 때문에 확장이 비교적 용이합니다.
결론
Microservice Architecture는 서비스의 확장이 쉽도록 설계하는 하나의 방식입니다. 유행한다고 해서 반드시 Microservice Architecture을 도입할 필요는 없습니다. 서비스의 구분이 명확하지 않은 상태에서 잘못 도입했다가 운영비용 증가 및 개발 난이도만 증가하게 되는 부작용을 초래할 수 있습니다. 하지만 서비스의 구분이 명확하고 잘 설계된 Microservice Architecture를 유지할 수 있다면 커져가는 서비스를 수용할 수 있는 확장성을 가질 수 있습니다.
제가 생각하는 Microservice Architecture을 사용했을 때 장점은 다음과 같습니다.
- 각 서비스 별로 프로그램의 크기가 작기 때문에 서비스와 동작원리를 이해하는 데 있어 Monolith에 비해 오랜 시간이 걸리지 않습니다.
- 서비스를 개발함에 있어 다른 서비스에 어떤 영향을 미칠지 파악하는데 시간이 줄어듭니다.
- 각 서비스에 대한 개발 및 배포 주기를 짧게 가져갈 수 있습니다.
- 팀 단위로 맡고 있는 서비스 구분을 명확히 할 수 있습니다.
물론 Microservice Architecture을 사용했을 때 단점도 존재합니다.
- 서비스 간 통신은 곧 네트워크 간 통신입니다. 네트워크 통신에 따라오는 다양한 장애 유형에 대한 고려가 필요합니다.
- 데이터베이스를 분리해서 사용하지만 종종 데이터베이스 간 동일한 데이터를 보관해야 하는 경우가 있습니다. 이런 경우 데이터베이스 간 동기화에 대해 신경 써야 합니다.
- 하나의 요청을 여러 서비스가 처리한다면, 처리단계가 복잡해집니다.
이와 같이 Microservice Architecture는 장단점이 존재합니다. 하지만 개발자로서 Microservice Architecture을 경험할 수 있다는 것은 큰 의미가 있다고 생각합니다. 분산 환경에서 서비스가 제대로 동작하기 위해 필요한 여러 기술(distributed tracing, distributed transaction, circuit breaker, asynchronous request)을 이해하고 사용해볼 수 있는 좋은 경험이 성장의 밑거름이 될 수 있기 때문입니다. 만약 Microservice Architecture을 경험할 수 있는 기회가 있다면 기회를 잡는 것을 추천드리고 싶습니다.
Reference
How to build Microservice Architecture
https://about.netflix.com/en/news/completing-the-netflix-cloud-migration