한빛출판네트워크

마이크로서비스란

마이크로서비스란 작고 자율적으로 협업하는 서비스를 의미한다. 이 정의를 구체적으로 해부하고 마이크로서비스를 차별화하는 특성에 대해 살펴보자.

1.1.1 작고, 한 가지 일을 잘하는 데 주력

코드베이스codebase(옮긴이_ 코드베이스란 소프트웨어 시스템, 애플리케이션, 컴포넌트를 빌드하는 데 사용되는 코드의 전체 집합으로, 일반적으로 작성한 코드 파일을 의미한다. 여기서는 원문 의미를 살려 코드베이스로 표기한다)는 새로운 기능을 추가하면서 성장한다. 하지만 시간이 지날수록 매우 방대해져서 어디를 변경해야 할지 파악하기 어려워진다. 명확하고 모듈화된 모놀리식monolithic 코드베이스를 추구하더라도 중간 경계의 어딘가가 빈번히 무너지기 시작하고, 버그를 고치거나 어려운 구현을 하는 과정에서 유사한 기능과 연관된 코드가 곳곳으로 퍼져나간다.

모놀리식 시스템(옮긴이_ 데이터 입력, 출력, 프로세싱, 에러 처리, UI(사용자 인터페이스)와 같은 구분된 기능들이 분리되어 있지 않고 혼합된 구조의 시스템을 말한다)에서 우리는 코드를 더 응집cohesive하고, 추상화 또는 모듈화하면서 앞에서 언급한 위협에 대항한다. 응집력, 즉 관련된 코드들을 함께 그룹화하려는 힘은 마이크로서비스의 중요한 개념이다. 로버트 C. 마틴Robert C. Martin은 단일 책임 원칙Single Responsibility Principle(http://bit.ly/1zOFMxl)에서 다음과 같이 강조했다. “같은 이유로 변경되는 것들은 한데 모으고, 서로 다른 이유로 변경되는 것들은 분리하라.”

마이크로서비스는 독립적인 서비스에 대해 동일한 접근 방식을 취한다. 주어진 기능과 관련 코드들이 명확히 제자리에 있도록 하면서 서비스 경계를 비즈니스 경계에 일치시킨다. 그리고 이 서비스의 명확한 경계를 지키면서 서비스가 지나치게 커지는(모든 골칫거리를 만들어내는) 것에 대한 유혹을 회피한다.

필자는 “얼마나 작아야 작은 것인가?”라는 질문을 자주 받는다. 일부 프로그래밍 언어는 다른 언어보다 표현력이 좋아서 훨씬 더 적은 줄 수로도 더 많은 일을 할 수 있다. 따라서 코드 줄 수를 기준으로 제시하는 것은 문제가 있다. 또한 우리는 그 자체가 수많은 코드로 구성된 복합적인 종속성에 대해서도 고려해야 한다. 게다가 우리 도메인 영역 중 일부는 합당한 이유로 복잡해진 만큼 더 많은 코드가 필요할 수 있다. 실제로 호주의 부동산 매매정보 사이트인 RealEstate.com.au의 존 이브스Jon Eaves는 경험적으로 ‘마이크로서비스란 2주 안에 재작성될 수 있는 것’이라고 특정한다.

마이크로서비스의 크기에 대해 필자가 말할 수 있는 다소 진부한 다른 답변은 ‘충분히 작아서 더 이상 작아질 수 없는 크기’다. 필자는 컨퍼런스에서 발표할 때 ‘지나치게 큰 시스템을 관리중이며 이를 작게 세분화하기 원하는 사람’이 있는지 매번 물어보는데, 거의 모든 사람이 손을 든다. 우리는 어떤 것이 지나치게 큰 것인지에 대해서는 매우 잘 인지하고 있는 것 같다. 따라서 코드가 너무 크다고 느껴지지 않는 한 아마 아직까지는 충분히 작다고 할 수 있다.

얼마나 작은지에 대한 답변을 하기 위해서는 서비스가 팀 구조와 서로 얼마나 적절하게 배치되어 있는지 아는 게 중요하다. 만약 코드베이스가 한 팀이 감당하기에 너무 크다면 작게 나누는 것이 당연하다. 조직의 배치에 대해서는 1.2.5절에서 더 이야기하자.

얼마나 작은 것이 충분히 작은 것인지에 관해 논할 때 필자는 다음과 같은 생각을 한다. 서비스가 작아질수록 마이크로서비스 아키텍처의 혜택과 단점은 더 극대화되며, 서비스를 작게 만들면 만들수록 상호의존성에 의한 문제는 줄어든다. 더 많은 구성 요소를 추가해서 발생하는 몇몇 복잡성에 대해서는 이 책 전반에 걸쳐 살펴볼 것이다. 이러한 복잡성을 다루는 데 능숙해질수록 더 작은 서비스를 추구할 수 있다.

1.1.2 자율성

마이크로서비스는 분리된 개체다. 이것은 PaaS Platform as a Service: 서비스로서의 플랫폼(옮긴이_ 개발을 위한 플랫폼 구축 없이도 필요한 개발 요소들을 웹에서 쉽게 빌려 쓸 수 있게 하는 모델) 상의 격리된 서비스이거나 운영체제 상의 프로세스가 될 수 있다. 우리는 여러 가지 서비스를 동일 머신에 넣는 것을 피하려 한다. 다만 요즘 세상에 머신의 정의가 매우 모호하다는 점은 짚고 넘어갈 필요가 있다. 나중에 논의하겠지만 이러한 격리가 약간의 부담을 주더라도 결과적으로 얻어지는 단순화를 통해 분산 시스템을 더 쉽게 추론할 수 있고 더 새로운 기술들을 통해 이러한 배포 형태와 관련한 많은 어려움을 극복할 수 있다.

서비스 간의 분산도를 높이고 서비스 간에 밀접하게 연결되어 생기는 문제점을 줄이기 위해 서비스 사이의 모든 통신은 네트워크 호출을 통해 이루어진다. 이 서비스들은 서로 독립적으로 변경될 수 있어야 하고, 소비자consumer(옮긴이_ 여기서는 서비스를 호출하는 다른 서비스가 될 수 있다)를 변경할 필요 없이 독립적으로 배포될 수 있어야 한다. 이때 우리는 서비스가 무엇을 외부에 드러내고 무엇을 내부에 두어야 하는지 고민해야 한다. 너무 많이 외부에 드러내면 소비자 서비스가 내부 구현과 엮이게 된다. 이 경우 서비스를 변경할 때 소비자와 조율할 게 그만큼 많아지므로 결과적으로 자율성이 줄어든다.

우리 서비스는 애플리케이션 프로그래밍 인터페이스application programming interface (API)를 공개하며, 이 API를 통해 상호 협업하는 서비스들과 통신한다. 우리는 기술이 소비자와 결합되지 않도록 어떤 기술이 적절한지 고민해야 한다. 이것은 다양한 기술을 선택할 수 있도록 기술 중립적인technology-agnostic API를 선택함을 의미할 수 있다. 이 책에서는 구현 방식에 영향받지 않는 좋은 API의 중요성에 관해 자주 언급할 것이다.

결합을 없애지decoupling 않고는 모든 것이 소용없어진다. 황금률은 ‘다른 변경 없이 특정 서비스만 변경하고 배포할 수 있는가?’다.

서비스를 잘 분리하려면 서비스를 올바르게 모델링하고 API를 제대로 만들어야 한다. 그 방법에 대해서는 앞으로 많이 이야기하겠다.