Multiple Services per Host
“Multiple Services per Host” 패턴은 마이크로서비스 아키텍처(MSA)의 배포 전략 중 하나로, 하나의 물리적 또는 가상 호스트에 여러 개의 마이크로서비스 인스턴스를 배포하는 방식이다.
이 패턴에서는 하나 이상의 물리적 또는 가상 호스트를 준비하고, 각 호스트에 여러 개의 서비스 인스턴스를 실행한다. 이는 전통적인 애플리케이션 배포 방식을 반영한 것이다.
이 패턴은 리소스 효율성과 배포 용이성이라는 장점이 있지만, 복잡성 증가와 서비스 간 격리 부족이라는 단점도 있다. 따라서 프로젝트의 요구사항과 규모에 따라 신중하게 선택해야 한다.
패턴의 변형
이 패턴에는 두 가지 주요 변형이 있다:
- 각 서비스 인스턴스가 별도의 프로세스로 실행되는 방식: 예를 들어, Java 서비스 인스턴스를 Apache Tomcat 서버의 웹 애플리케이션으로 배포하는 경우이다.
- 여러 서비스 인스턴스가 동일한 프로세스 또는 프로세스 그룹 내에서 실행되는 방식: 예를 들어, 여러 Java 웹 애플리케이션을 동일한 Apache Tomcat 서버에 배포하거나 여러 OSGI 번들을 동일한 OSGI 컨테이너에서 실행하는 경우이다.
장점
- 리소스 사용의 효율성: 이 패턴의 주요 이점 중 하나는 리소스 사용이 상대적으로 효율적이라는 점이다. 여러 서비스 인스턴스가 서버와 운영 체제를 공유한다. 특히 하나의 프로세스나 프로세스 그룹이 여러 서비스 인스턴스를 실행할 때 더욱 효율적이다.
- 배포의 용이성: 서비스를 호스트에 복사하고 실행하는 것만으로 배포가 가능하다. Java 서비스의 경우 JAR 또는 WAR 파일을 복사하고, Node.js나 Ruby와 같은 다른 언어의 경우 소스 코드를 복사하면 된다.
- 빠른 시작: 오버헤드가 없어 서비스 시작이 빠르고 원활하다.
단점
- 리소스 제어의 어려움: 서비스 인스턴스에 대한 제어가 부족하면 호스트의 메모리를 과도하게 사용할 수 있다. 인스턴스 간 격리가 부족하여 한 서비스의 작은 중단이 다른 서비스에 빠르게 영향을 줄 수 있다.
- 모니터링의 어려움: 여러 서비스 인스턴스가 동일한 프로세스에 배포된 경우, 각 서비스 인스턴스의 리소스 소비를 모니터링하기 어렵다. 또한 각 인스턴스를 완전히 격리하는 것이 불가능하다.
- 복잡성 증가: 독립적인 서비스 간의 통신을 신중하게 처리해야 하며, 시스템 지연이 발생할 때 더 많은 복잡성이 나타날 수 있다. 각 서비스가 별도의 데이터베이스를 가지므로 트랜잭션 관리가 복잡해질 수 있다. 또한 서비스 테스트 시 종속된 서비스를 먼저 확인해야 하며, 각 서비스가 자체 로그를 가지므로 디버깅이 복잡해질 수 있다.
사용 시 고려사항
- 이 패턴은 동일한 서비스의 여러 인스턴스를 별도의 프로세스에서 실행하려는 경우에 사용한다.
- 리소스를 효율적으로 활용하고, 충돌하는 리소스 요구사항과 의존성 버전의 위험을 줄이며, 배포 속도를 높이고, 각 인스턴스를 개별 프로세스로 실행할 수 있는 유연성을 제공한다.
- 서비스 계정 관리에 주의를 기울여야 한다. 예를 들어, 관리형 서비스 계정(MSA)을 사용할 때는 한 호스트에서 여러 서비스에 동일한 MSA를 사용하거나 각 서비스에 다른 MSA를 사용할 수 있다.