마이크로서비스 아키텍처 구축(전면 개정판)

313

8

장

배포

고 필자는 여전히 그렇게 생각한다.

여러 단점 중 첫 번째는 필연적으로 기술 선택을 제한한다는 것이다. 즉, 기술 스택을 받아들여

야 한다. 이는 서비스 자체 구현을 위한 기술 선택뿐만 아니라 시스템의 자동화 및 관리 측면에

서 선택할 수 있는 선택지도 제한할 수 있다. 곧 논의하겠지만, 여러 호스트를 관리하는 오버

헤드를 해결할 한 가지 방법은 자동화를 사용하는 것이므로 이 문제를 해결하기 위한 선택지를

제한하는 것은 두 배의 피해를 줄 수 있다.

또한 이러한 애플리케이션 컨테이너가 제공하는 기능의 가치에도 의문을 제기하고 싶다. 그들

중 다수는 인메모리 공유 세션 상태를 저장하기 위한 세션 클러스터를 관리하는 기능을 선전하

지만, 이는 서비스를 확장할 때 발생하는 문제로 인해 어떠한 경우에도 절대 피하고 싶은 것이

다. 그리고 애플리케이션 컨테이너가 제공하는 모니터링 기능은

10

장에서 볼 수 있듯이 마이

크로서비스 세계에서 수행하려는 일종의 통합 모니터링을 고려할 때 충분하지 않을 것이다. 또

한 그중 다수는 시작 시간이 상당히 느리며 개발자 피드백 주기에 영향을 미친다.

다른 문제들도 있다.

JVM

과 같은 플랫폼 위에서 애플리케이션의 수명주기를 적절하게 관리하

는 것은 단순히

JVM

을 다시 시작하는 것보다 문제가 많고 더 복잡할 수 있다. 동일한 프로세스

를 여러 애플리케이션이 공유하므로 리소스 사용 및 스레드 분석도 훨씬 더 복잡하다. 특정 기

술의 컨테이너에서 가치를 얻더라도 공짜가 아님을 기억하라. 그중 다수가