"마이크로서비스 아키텍처는 모두를 위한 게 아니다. IT자원을 충분히 운용할 수 없는 소기업에게 해당되는 말이다. 기존 시스템을 충분히 잘 활용중인 기업도 굳이 마이크로서비스로 새롭게 시스템을 꾸지 않아도 된다. 이런 회사에게는 데브옵스 문화조차 잘 맞지 않을 것이다."
4일 미국 지디넷 칼럼에 인용된 ‘프로덕션레디 마이크로서비스’의 저자 수잔 파울러 스트라이프 엔지니어의 조언이다. 수잔 파울러는 우버의 마이크로서비스팀 출신 엔지니어다.
그는 최근 인포큐의 토마스 베츠와 인터뷰에서 "마이크로서비스 프로젝트에 최적의 도전자는 확장성 문제에 빠져있는 기업"이라고 주장했다.[인터뷰 원문 바로가기]
그에 따르면, 마이크로서비스는 확장성 제약 때문에 성능과 안정성 문제를 겪고, 애플리케이션에서 어떤 작업도 할 수 없으며, 개발자의 민첩함이 멈춰버린 상황에서 애플리케이션 관리를 도와준다.
수잔 파울러는 "많은 조직들이 잘 기능하는 마이크로서비스 아키텍처를 완성하기 어렵다"며 "수많은 시스템이 마이크로서비스 아키텍처를 고려하지 않고 설계됐기 때문"이라고 설명했다.
그는 "결과적으로 많은 마이크로서비스들이 고립되거나 격리된 환경에서 설계되고 만다"고 지적했다.
그는 마이크로서비스를 도입할 때 개발자가 시스템운영에 필요한 충분한 기술적 역량을 익혀야 한다고 강조했다. 빠른 개발 과정에서 운영의 중요성을 무시하기 쉬워지므로 개발자 자체가 운영을 잘 이해해야 한다는 설명이다.
2014년 마이크로서비스의 원리를 정리한 마틴 파울러는 마이크로서비스를 다음과 같이 정의한다.
"마이크로서비스 아키텍처 스타일은 단일 애플리케이션을 소형 서비스들의 모음으로 개발하려는 시도이며, 각 서비스는 HTTP 리소스 API 같은 경량의 메커니즘으로 자체적인 프로세스와 소통 속에서 움직인다."
수잔 파울러는 "마이크로서비스 아키텍처는 명쾌하지 않기에 많은 좌절과 혼란을 낳는다"며 "누구는 애플리케이션을 도커 컨테이너에 넣으면 마이크로서비스라고 하고, 누구는 각 마이크로서비스가 완전히 독립적인 인프라에서 홀로 움직여야 마이크로서비스라고 하는데 모두 사실과 다르다"고 지적했다.
수잔 파울러는 "마이크로서비스가 무엇인지 명쾌하게 하려면 시스템의 추상화를 사용해야 한다"며 "마이크로서비스는 4계층으로 정리할 수 있다"고 설명했다.
그는 마이크로서비스 아키텍처를 하드웨어, 커뮤니케이션, 애플리케이션, 마이크로서비스 등 4계층으로 정리했다.[수잔 파울러 블로그 바로가기]
하드웨어 계층은 컨피규레이션 관리 툴, 데이터베이스, 서버, 호스트레벨 로그 및 모니터링, 운영시스템, 자원 격리, 리소스 추상화 등을 포함한다.
커뮤니케이션 계층은 DNS 엔드포인트, 로드밸런싱, 메시징, 네트워크, 원격 프로시저 콜(RPC), 서비스 디스커버리, 서비스 레지스트리 등을 포함한다.
관련기사
- 디지털 시대, 왜 마이크로서비스인가2017.02.08
- 데브옵스 ‘지속적 개선’이라 부르자2017.02.08
- 마이크로서비스와 API 구축의 3대 원칙2017.02.08
- 데브옵스 시작하기, 무엇이 필요한가2017.02.08
애플리케이션 계층은 개발 파이프라인, 개발 환경, 마이크로서비스 레벨 로그 및 모니터링, 셀프서비스 내부 개발 툴, 테스트-패키지-빌드-릴리스 툴 등을 포함한다.
마이크로서비스 계층은 마이크로서비스 자체를 의미한다.