모놀리식 어플리케이션에서 마이크로서비스로의 전환

모놀리식 어플리케이션은 모든 것이 서로 강하게 결합해 구성되며, 전체가 단일 운영체제 프로세스로 실행되기 때문에 하나의 개체로 개발, 배포, 관리해야 한다. 어플리케이션을 조금만 변경해도 전체 어플리케이션을 다시 배포해야 하므로 개발과 배포, 관리의 경계는 시간이 지나면서 모호해진다. 결국 시스템 전체의 품질이 저하된다. 

 

일반적으로 모놀리식 어플리케이션을 실행하려면 어플리케이션을 실행하는 데 필요한 리소스를 제공할 수 있는 소수의 강력한 서버가 있어야 한다. 시스템상 증가하는 부하를 처리하려면 CPU, 메모리, 그 밖의 서버 구성 요소를 추가해 서버를 수직적으로 확장하거나(스케일링 업) 서버를 추가하고 셋업해 어플리케이션의 복사본을 여러 개 실행함으로써 모든 시스템을 수평적으로 확장할(스케일링 아웃) 수 있다. 스케일링 업은 대개 어플리케이션을 변경할 필요가 없지만 상대적으로 비용이 많이 들고, 실제로도 한계가 있다. 반면 스케일링 아웃은 하드웨어 비용이 상대적으로 저렴하지만 어플리케이션의 코드를 대폭 변경해야 하는 상황이 발생했을 때 수평적으로 확장하기 어렵거나 불가능한 경우도 있다. 모놀리식 어플리케이션 중 일부를 확장할 수 없다면 어떤 식으로든 모놀리식을 분리해야 하는데, 분리할 수 없다면 전체 어플리케이션을 확장할 수 없다. 

 

 

마이크로서비스로 어플리케이션 분리하기

 

이런저런 문제로 인해 복잡한 모놀리식 어플리케이션을 마이크로서비스라는 더 작은 독립적으로 배포 가능한 구성 요소로 쪼개야 한다. 각 마이크로서비스는 독립적인 프로세스로 실행되며 단순하고 잘 정의된 인터페이스 API를 통해 다른 마이크로서비스와 통신한다. 

 

마이크로서비스는 일반적으로 RESTful API를 제공하기 위해 HTTP와 같은 동기 프로토콜을 이용해 통신하거나 AMQP와 같은 비동기 프로토콜을 이용해 통신한다. 프로토콜은 간단하고 대부분의 개발자가 잘 이해하고 있으며 특정 프로그래밍 언어에 독립적이다. 각각의 마이크로서비스는 구현하기에 가장 적합한 언어로 작성할 수 있다. 

 

마이크로서비스는 상대적으로 정적인 외부 API가 있는 독립형 프로세스이기 때문에 개별적으로 개발하고 배포할 수 있다. 마이크로서비스 중 하나만 변경되더라도 마이크로서비스가 제공하는 API가 이전 버전과 호환되는 방식으로 변경되거나 변경 자체가 없다면 다른 서비스를 변경하거나 다시 배포하지 않아도 된다. 

 

 

마이크로서비스의 확장

 

모놀리식 시스템은 시스템 전체를 확장해야 하지만 마이크로서비스를 서비스별로 확장할 수 있다. 따라서 리소스가 부족한 서비스가 있다면 해당 서비스만 확장하고, 그 외의 서비스를 그대로 둬도 된다. 예를 들어 특정 구성 요소는 복제돼 여러 서버에 배포된 다수의 프로세스가 실행되고, 반면 단일 어플리케이션 프로세스로 실행되는 구성 요소도 있다. 특정 시스템에서 운영 중인 모놀리식 어플리케이션의 일부가 확장 가능하지 않아 수평 확장이 불가능하다면 어플리케이션을 마이크로서비스로 분할해 스케일링 아웃을 가능하게 하고, 그렇지 않은 부분은 수평 대신 수직으로 확장할 수 있다. 

 

 

마이크로서비스 배포

 

마이크로서비스에도 단점은 있다. 배포 가능한 시스템 구성 요소가 적은 경우 이를 관리하는 것은 쉽다. 선택 사항이 많지 않기 때문에 각 구성 요소를 배치할 곳을 결정하는 작업은 간단하다. 하지만 구성 요소의 수가 증가하면 배포 관련 조합의 수가 증가할 뿐만 아니라 구성 요소 간 상호 종속성의 수도 훨씬 더 복잡해지기 때문에 배포와 관련된 결정이 점점 더 어려워진다. 

 

마이크로서비스를 팀으로서 함께 작업을 수행하므로 서로를 통신할 수 있어야 한다. 이들을 배포할 때 누군가 또는 뭔가는 단일 시스템으로써 함께 작동할 수 있도록 모든 마이크로서비스를 올바르게 구성할 수 있어야 한다. 마이크로서비스가 중가함에 따라, 특히 서버 장애 시 운영 관리팀이 해야할 일을 고려해보면 지루하고 오류가 발생하기 쉽다. 

 

또한 마이크로서비스는 여러 프로세스와 시스템에 분산되어 있기 때문에 실행 호출을 디버그하고 추적하기 어려운 문제가 있다. 다행히 이제는 이런 문제를 Zipkin과 같은 분산형 추적 시스템으로 다룰 수 있게 됐다. 

 

 

환경 요구 사항의 다양성

 

마이크로서비스 아키텍처의 구성 요소는 독립적으로 배포될 뿐만 아니라 독립적인 방식으로 개발된다. 구성 요소의 독립성과 각 구성 요소를 개발하는 팀이 따로 있기 때문에 각 팀의 상황에 따라 다른 라이브러리를 사용하고 바꾸는 것으로 다른팀을 방해하지 않아야 한다. 어플리케이션이 동일한 라이브러리의 다른 버전을 필요로 하는 경우, 어플리케이션의 구성 요소들 간 종속성 차이는 피할 수 없다. 

 

서로 다른 버전의 공유 라이브러리가 필요하거나 다른 환경 사양이 필요한 동적으로 링크된 어플리케이션을 배포하면 프로덕션 서버에서 이를 배포하고 관리하는 운영팀에게 악몽 같은 일이 찾아올 수 있다. 동일한 호스트에 배포해야 하는 구성 요소의 수가 많을수록 요구 사항을 충족시키면서 종속성을 관리하는 것은 더욱 어려워진다.