모놀리스와 마이크로서비스에 대하여

마이크로서비스(및 그와 자주 언급되는 BFF인 컨테이너)가 이제 모든 개발자들의 마음과 생각을 사로잡기 시작했습니다. 마이크로서비스의 느슨하게 결합된, API 전용, 세부적인 설계 원칙을 채택하는 것은 신생 기업뿐만이 아닙니다. 대기업도 이 게임에 참여하고 있습니다.

채택이 증가함에 따라(클라우드 인프라 모니터링 제공업체 인 Datadog는 2014년 9월 이후 12개월 동안 약 5배의 성장을 보였습니다) 모놀리식 애플리케이션의 죽음과 전혀 부적절한 아키텍처를 그저 시대에 뒤떨어진 것이 아니라 그저 나쁘다고 선언하는 목소리가 커지고 있습니다.

하지만 Gigaom의 최근 기사에서 언급했듯이 , 잭해머를 꺼내 모든 모놀리식을 수백 개의 서로 다른 마이크로서비스로 분해하기 전에 고려해야 할 상충 사항이 있습니다. 그런데 이건 새로운 개념이 아닙니다. 마이크로서비스의 창시자인 마틴 파울러는 오래전에 이러한 상충 관계에 대해 글을 썼 으며 마이크로서비스를 "맹목적 도입"으로만 간주될 수 있는 것에 대해 경고했습니다.  사실, Gigaom 기사는 일반적으로 Fowler와 동일한 요점을 더 간결한 형식으로 다루고 있습니다.

두 가지 모두에 대한 TL;DR을 찾고 있다면 기본적으로 이렇게 결론지어집니다. 마이크로서비스는 운영상의 복잡성을 증가시키고 성능 측면에서 애플리케이션 경험에 부정적인 영향을 미칠 수 있습니다. 둘 다 바람직하지 않고 종종 의도치 않은 결과이므로 데이터 센터에 있는 그 사람이 우화적인 잭해머로 작업을 시작하기 전에 미리 이해해야 합니다.

그런데, 로리가 왜 신경 쓰는 거지? 결국 그녀도 F5도 애플리케이션을 구축하거나 디자인하는 사업을 하고 있지 않습니다. F5는 모놀리스, 마이크로서비스 또는 차세대 앱 아키텍처인지 여부에 관계없이 이러한 앱을 제공할 것입니다.

모두 사실입니다. 하지만 저희는 이러한 애플리케이션을 제공하는 애플리케이션 서비스를 구축하고 배포하는 사업을 하고 있으며, DevOps와 마이크로서비스(및 컨테이너 열풍)와 같은 최근의 움직임은 저희 도메인에 동일한 질문을 던집니다. 즉, ADC 플랫폼에 일반적으로 배포되는 앱 서비스를 마이크로서비스 아키텍처에 더 긴밀하게 부합하는 모델에서 보다 세분화되고 애플리케이션과 관련된 서비스 로 분해해야 할까요?

아직도 상쇄에 대한 이야기

앱 아키텍처나 앱 서비스 아키텍처에 대해 이야기하든, 그러한 결정을 내리기 전에 관련된 상충 관계를 이해하는 것이 답입니다.

플랫폼(모놀리식) 접근 방식

이는 모든 유형의 애플리케이션을 보호하고 확장하며 최적화하는 데 필요한 앱 서비스를 제공하는 전통적인 접근 방식입니다. 서비스는 단일 공유 플랫폼에 배포됩니다. 기본 프록시의 아키텍처로 인해 이 접근 방식은 성능을 향상시킨다는 장점이 있습니다. 그 이유는 모든 요청(및 응답)이 동일한 환경을 벗어나지 않고도 필요한 서비스를 거칠 수 있기 때문입니다. 즉, 추가적인 네트워크 홉(및 관련 지연 시간)이나 연결(리소스, 지연 시간)이 필요하지 않습니다. 각 서비스는 여전히 개별적으로 확장 및 관리가 가능하지만, 모두 단일 공유 하드웨어(COTS 또는 맞춤형)에 종속됩니다. 이는 공유 하드웨어가 하나가 아닌 여러 서비스에 영향을 미치는 단일 장애 지점이라는 것을 의미합니다.

앱당 프록시(마이크로서비스) 접근 방식

이 모델은 DevOps 및 새로운 애플리케이션 아키텍처 관행과 더 긴밀하게 연계됩니다. 각 서비스는 개별적으로 배포, 관리 및 확장됩니다. 이렇게 하면 추가적인 관리 비용이 발생하지만(결국 관리해야 할 인스턴스가 더 많아지니까요) 각 서비스를 동일한 플랫폼에 배포하면 비용 중 일부를 완화할 수 있으며, 다양한 공급업체의 서비스를 "혼합하여 일치"시킬 수 있는 기능도 제공합니다. 이 접근 방식의 장점은 서비스를 애플리케이션 아키텍처와 더 밀접하게 연관시킬 수 있고 따라서 인기 있는 자동화 프레임워크와의 통합을 포함하여 애플리케이션 아키텍처의 일부로 포함할 수 있다는 것입니다.

동일한 단점(즉, 성능 및 복잡성 증가)은 애플리케이션 제공을 복합 애플리케이션 서비스로 분해하는 것과 관련됩니다. 반대로, 개발자가 마이크로서비스를 채택하고 모놀리스를 피하는 이유, 즉 민첩성, 다양성, 모듈성에 대한 욕구는 애플리케이션 제공에도 해당합니다.

저는 간단히 Martin Fowler의 말을 인용하겠습니다. " 많은 개발팀은 모놀리식 아키텍처보다 마이크로서비스 아키텍처 스타일이 더 나은 접근 방식이라고 생각합니다. 하지만 다른 팀에서는 이것이 생산성을 저하시키는 부담으로 작용한다고 느꼈습니다. 모든 아키텍처 스타일과 마찬가지로 마이크로서비스는 비용과 이점을 가져옵니다. 현명한 선택을 하려면 이러한 사항을 이해하고 귀하의 특정 상황에 적용해야 합니다."

이 진술은 응용 프로그램 서비스에도 마찬가지로 잘 적용됩니다. 전통적인(모놀리식) 방식과 현대적인(마이크로서비스) 방식은 모두 제공, 보안 및 최적화하려는 애플리케이션의 맥락에서 고려해야 할 비용과 이점을 가지고 있습니다.