최근 마이크로서비스 아키텍처에 관한 관심이 뜨겁습니다.
전통적인 애플리케이션 개발, 배포, 운영을 위한 환경과 마이크로서비스 아키텍처의 가장 큰 차이는?
네, 공유입니다. 전통적인 비즈니스 애플리케이션 운영 아키텍처는 계층화되어 있고, 각 계층은 독립적으로 자원을 사용합니다.
가상 머신 중심의 인프라 가상화가 일반화되면서 CPU, 메모리 자원은 공용 자원이 되었죠. 하지만 가상 머신 기반으로 아키텍처를 구성하는 것은 전통적인 방식과 크게 다르지 않습니다. 자원이 모자라면 가상 머신을 늘려 가는 식으로 대응하죠. 반면에 마이크로서비스 아키텍처 환경은 다릅니다. 공유의 폭이 운영체제와 애플리케이션 런타임 환경까지 더 넓어집니다. 당연히 애플리케이션 운영은 가상 머신보다 더 작은 단위로 쪼개집니다. 말 그대로 마이크로서비스 아키텍처입니다.
마이크로서비스 아키텍처의 경우 애플리케이션 개발자와 소유자는 인프라를 잘 몰라도 됩니다. 물리적 자원은 물론이고 애플리케이션 실행 환경까지 공유하다 보니 인프라와 플랫폼이 아니라 코드에만 집중해도 됩니다. 이런 이유로 마이크로서비스 아키텍처 관련 광고 문구에 개발자는 개발에만 집중할 수 있다는 문구가 따라다니는 것이죠.
세상에 완벽한 아키텍처가 어디 있겠습니까. 마이크로서비스 아키텍처도 약점이 있습니다. 본 글에서는 ADC(Application Delivery Controller) 측면에서만 바라보겠습니다. ADC, 네 로드밸런싱 측면에서 보면 마이크로서비스 아키텍처는 Shadow IT 문제가 생기기 쉽습니다. 이게 무슨 소리냐 하면 마이크로서비스 아키텍처 환경에서 처리되는 엄청난 양의 API 호출과 응답 트래픽을 처리하기 위해 쓰는 소프트웨어 기반 로드밸런서로 인한 Shadow IT 문제가 생긴다는 것입니다.
용어 정리부터 하겠습니다. Shadow IT란 개념은 간단히 말해 IT 관리자의 승인 없이 인프라, 플랫폼 곳곳에서 IT 기술/솔루션이 사용되는 것을 말합니다. 주로 개발자나 애플리케이션 소유자가 필요에 의해 설치하거나 구성해 쓰죠. IT 관리자에게 이들 기술은 그림자 속, 즉 보이지 않는 곳에서 쓰이는 것입니다. Shadow IT가 문제가 되는 이유는 IT 환경을 복잡하게 만든다는 것이죠. 문제가 생겼을 때 해당 원인이 IT 책임자/관리자의 통제 영역 밖에 있는 Shadow IT 부문에 있다면? 시쳇말로 문제 해결을 할 방법이 없습니다.
ADC의 경우 마이크로서비스 환경에서 HAProxy나 NGINX 같이 오픈 소스로 쉽게 구할 수 있는 것을 개발자와 애플리케이션 소유자가 많이 씁니다. 이들 소프트웨어 기반 오픈 소스 ADC가 전사적 운영 전략과 책임 아래에 쓰인다면 Shadow IT 문제가 없겠죠. 하지만 대부분 IT 관리자 승인 없이 개인적 판단으로 씁니다.
IT 관리자의 선호는 전통적인 3티어 구조나 마이크로서비스 아키텍처나 다를 것 없습니다. 인접 장비와 솔루션에 영향을 주지 않는 엣지 단 장치를 추가해 로드밸런싱 같은 기능이 돌아가는 것을 선호합니다. 이게 되어야 운영에 대한 가시성과 통제력을 확보하기 더 쉽기 때문이죠.
마이크로서비스 아키텍처, 편리함을 앞세울 것이 아니라 ADC에 대한 통제력을 보장하는 범위에서 아키텍처를 가져가는 것이 현명하지 않을까요? 참고로 넷플릭스의 경우 하루에 처리되는 API 트래픽이 수십억 건이라고 합니다. 이런 부하를 어떻게 인프라와 플랫폼 구성을 간소하게 가져가면서 처리할 것인지? 현명한 아키텍트의 혜안이 필요한 시기가 아닐까 합니다.
