넷플릭스(Netflix)에는 다양한 마이크로 서비스가 들어있다.
단순히 영상을 찾아서 보는 것 같지만, 사용자 계정을 관리하거나, 영상을 추천해 주거나, 영상을 재생 또는 스트리밍 하거나, 구독료를 납부하기 위한 결제를 하는 서비스 등이 각각 독립적인 서비스로 운영되고 있다.
가짜인 짭플릭스(Jobflix)를 하나 만든다고 하자, 넷플릭스를 따라 보이는 대로 만들어서, 검색도 가능하고, 영상을 재생할 수도 있지만, 독립적이지 않을 수 있다. 이때 짭플릭스는 마이크로 서비스를 제공한다고 하기 어려울 수 있을 것이다.
검색과 재생, 2개의 서비스는 똑같이 제공되는데, 마이크로 서비스는 어떻게 구분하는 게 좋을까?
마이크로 서비스 또는 마이크로 서비스 아키텍처라는 용어가 있다. 마이크로 서비스는 애플리케이션을 작고 독립적인 서비스들로 나누어 개발하고 운영하는 소프트웨어 설계 방식을 의미한다. 기존의 하나의 서비스로 제공하는 방식과 비교해 개발, 배포, 확장이 유연한 특징을 가지고 있다.
마이크로 서비스를 이용해 소프트웨어를 설계했을 때, 유연하고, 확장이 편리해진다는 장점이 있다.
- 유연한 확장성 : 서비스별로 독립적인 확장이 가능해 성능 최적화가 수월해진다.
- 개발 속도 향상 : 분리된 서비스 별로, 팀 별로 개별 서비스 개발이 가능해지기 때문에 병렬 개발이 가능해진다.
- 배포 및 유지보수 : 서비스 단위로 배포할 수 있어서 장애 발생 시 특정 서비스만 수정이 가능하다.
- 폭넓은 기술 사용 : 개별 서비스에 맞도록 프로젝트에 맞는 기술을 유연하게 선택할 수 있다.
하나의 큰 프로젝트가 있다면, 마이크로 서비스는 서비스별로 완전한 분리가 가능한지로 개념을 정할 수 있다.
- 배포 독립 : 서비스마다 다른 서비스에 영향을 주지 않고 독립적으로 배포, 업데이트할 수 있어야 함.
- 팀 분리 : 마이크로 서비스는 독립적으로 개발, 팀별로 책임을 나누어 관리.
- 다양한 기술 선택 가능 : 서비스별로 프로그래밍 언어와 데이터베이스까지도 다양하고 유연하게 선택할 수 있어야 함.
- 경량화 통신 : Rest API, gRPC, 메시지 큐 등을 활용해 서비스 간 통신하면서 데이터를 주고받을 수 있어야 함.
- 개별적인 확장 : 필요한 서비스만 확장이 가능해야 함.
말머리에서 검색 서비스와 재생 서비스를 제공하는 넷플릭스와 짭플릭스의 비교하는 글을 썼다.
어떤 관점에서 넷플릭스는 마이크로 서비스이고, 짭플릭스는 마이크로 서비스가 아닐까?
예를 들어, 넷플릭스와 짭플릭스에서 특정 검색어의 입력을 필터링해서 막아야 되는 기능이 추가되어야 한다고 가정하자.
넷플릭스는 마이크로 서비스로 구현되어 있어서, 검색 서비스와 재생 서비스가 분리되어 있기 때문에, 검색 서비스를 담당하는 팀에서 검색 서비스를 수정하고, 검색 서비스 모듈만 새롭게 고치고, 검색 서비스만 배포하면, 빠르게 적용할 수 있다.
하지만, 짭플릭스는 넷플릭스를 보이는 그대로 하나의 서비스로 따라 만들었기 때문에, 검색 서비스를 수정하기 위해서는 짭플릭스 프로젝트를 모두 열어서, 검색 서비스를 수정해야 한다. 재생 서비스에 사소한 문제가 발생했을 때, 쉽게 고쳤지만, 검색 서비스가 다 완료되어야 같이 빌드하고 배포가 가능해서 지연이 생긴다. 이러한 방식은 마이크로 서비스라고 볼 수 없다.
이렇게 같아 보이는 하나의 거대한 서비스에도, 마이크로 서비스인지, 아닌지에 따라서 확장성과 유지보수, 개발 속도 등 큰 차이점을 보이게 된다.
독립적이고 편해 보이는 마이크로 서비스도 단점이 있을까?
안타깝지만, 모든 게 완벽한 설계방식은 없다. 마이크로 서비스라도 단점이 있다.
- 서비스가 많아질수록 모니터링, 로깅, 장애 대응이 복잡해질 수 있다.(운영 복잡성)
- 서비스마다 개별적인 데이터베이스를 운영해야 하기 때문에, 데이터 일관성을 유지하기 어렵다.(데이터 관리 어려움)
- 필요시, 서비스마다 통신을 해야 하기 때문에 지연시간을 고려해야 하고, 장애 발생 가능성이 생긴다.(통신 비용 증가)
짭플릭스처럼, 하나의 서비스로 이용 가능한 기능을 분리하다가 서비스가 많아지게 되면, 각 서비스 사이의 통신 비용이나 데이터 관리 비용이 생각보다 커지고, 복잡해지는 단점이 있다.
설계만 잘한다면, 마이크로 서비스 방식은 혁신에 가까울 수 있다.
그러기 위해서는 가장 먼저 생각해야 할 것이 적절한 서비스의 분할이다. 독립성의 장점을 깨우친 나머지, 너무 세분화하여 서비스를 분할하다 보면, 복잡도가 증가하고, 성능에까지 영향을 미칠 수 있다. 서비스를 분할할 때, 적절한 기준으로 정하는 것이 중요하다.
또한 마이크로 서비스는 필연적으로 빌드하는 프로젝트가 나뉘게 되고, 배포 역시 독립적이게 되는데, 자동화된 배포나 운영 도구를 활용해 운영 부담을 줄이는 것도 중요하다. 아무리 독립적이라도, 결국엔 하나의 거대한 프로젝트이기 때문에 자동화된 관리 도구의 역할은 무척 중요하다.
설계에서부터, 마이크로 서비스는 서비스 간 통신이 필수적이다. 따라서 효율적인 서비스 간 통신 전략을 수립해야 하고, 실시간 모니터링과 로그 분석도 체계적으로 구축해 놓을 필요가 있다.
마이크로 서비스를 이용하면 대규모 애플리케이션의 개발과 유지보수를 용이하게 만든다. 하지만, 오히려 마이크로 서비스를 이용하지 않는 게 나을 수도 있을 정도로 도입 과정에서부터 확실한 설계와 확장 가능성을 고려해야 한다. 적절한 설계 원칙과 운영 전략을 수립하면, 마이크로 서비스는 훌륭한 선택이 될 것이다.
'IT 정보 > 용어' 카테고리의 다른 글
| JSON이란? 비동기 통신의 필수 요소? (0) | 2025.04.08 |
|---|---|
| RPC란? 분산 시스템을 위한 원격 프로시저 호출 (0) | 2025.04.07 |
| 쇼어 알고리즘이란? 양자 컴퓨팅을 사용한 혁신 알고리즘 (0) | 2025.04.04 |
| 스마트 미터링이란? 실시간 에너지 관리의 시작 (2) | 2025.04.02 |
| 스로틀링이란? 자동차에서 온 용어 스로틀링의 의미 (2) | 2025.03.20 |
