한빛출판네트워크

'마이크로서비스'라는 용어는 마틴 파울러(Martin Fowler)와 제임스 루이스(James Lewis)가 최초로 제안했다.

[Monoliths and Microservices (출처. https://oreil.ly/ejm5V)]

마이크로서비스는, 소프트웨어 애플리케이션을 독립적으로 배포 가능한 서비스군으로 설계하는 특정한 방식이다. 

이러한 아키텍처 스타일을 명확하게 정의할 수는 없으나 비즈니스 수행에 따른 조직, 자동화된 배포, 엔드포인트 인텔리전스, 프로그래밍 언어와 데이터 제어의 탈중앙화 등 다양한 면에서 공통적으로 보이는 뚜렷한 특성을 지닌다.

마이크로서비스를 도입하면 애플리케이션은 여러 컴포넌트로 분리되며 각기 다른 팀이 독립적으로 개발하고 배포한다. 소프트웨어 개발 속도는 빨라지지만 대규모 릴리스 일정을 수립하고 조율할 필요성은 감소하게 된다. 

각 마이크로서비스를 담당하는 팀은 서로 독립적이며 자신의 고객(내, 외부)에게 필요한 비즈니스 요건에 대응한다. 마이크로서비스는 각기 다른 클라우드 리소스에 수평적으로 조절된 규모로 다중 배포되며 네트워크상의 다양한 프로토콜을 이용해 서로 통신한다.

이러한 아키텍처는 기존의 모놀리식 애플리케이션에서 볼 수 없었던 많은 도전 과제를 수반한다. 모놀리식 애플리케이션은 주로 일정한 서버를 두고 배포되며 신중한 계획에 따라 드물게 릴리스된다. 

이때 소프트웨어 릴리스 과정은 시스템의 변화와 불안정을 유발하는 주된 요인이다. 마이크로서비스는 데이터 전송과 통신량으로 추가 비용과 레이턴시가 발생하며 잠재적으로 사용자 경험을 저하시킨다. 

이제는 수십, 수백 개의 마이크로서비스가 맞물려 사용자 경험을 만들어낸다. 마이크로서비스는 서로 독립적으로 릴리스되지만 의도치 않게 서로 영향을 미칠 수 있다. 물론 사용자 경험도 같은 영향을 받는다.

이렇게 분산된 시스템을 관리하려면 새로운 관행, 도구, 엔지니어링 문화가 필요하다. 릴리스 속도를 향상시키는 대가로 소프트웨어의 안정성을 포기할 필요는 없다. 사실 이들은 서로 밀접하게 연관되어 있다. 

효율적인 플랫폼 엔지니어링 팀 문화

마이크로서비스를 관리하려면 조직 내부에서 사용할 통신 규약과 지원 프레임워크를 선정하고 표준화시켜야 한다. 

팀마다 자체적으로 온전한 개발 스택을 갖추고 관리하는 방식은 매우 비효율적이다. 마치 분산 애플리케이션의 각 요소가 서로 통신할 때처럼 마찰이 생기기 마련이다. 

보통은 플랫폼팀이 구성되어 표준화를 담당하며 그 외 팀은 각자의 비즈니스 요구 사항을 개발하는 데 집중한다. 관문을 세우는 대신 팀이 저마다 찾아낸 길을 가도록 둔다. 그런 다음 각 팀의 방식을 배우고 조직 전체에 일반화시킨다.

"시스템의 구조는 필연적으로 그 시스템을 설계하는 조직의 커뮤니케이션 구조를 닮는다."

- 콘웨이의 법칙, Conway’s Law -

아래의 [그림1]은 전문성을 기준으로 구성된 엔지니어링 조직들을 나타낸다. 왼쪽부터 차례대로 인터페이스 및 사용자 경험 설계, 백엔드 서비스 구축, 데이터베이스 관리, 네트워크 자원 관리에 전문적이다.

[그림1. 기술적으로 서로 격리된 조직]

[그림2]는 한 팀 안에서 여러 기능을 감당하도록 구성된 교차 기능(cross-functional)팀을 보여준다. 이러한 조직의 작업 주기가 더 빠르다는 사실은 콘웨이의 법칙을 방증한다. 

팀마다 기술적 전문 분야가 다르면 새로운 비즈니스 요구 사항이 생길 때마다 결국 모든 분야를 다시 조율해야 하기 때문이다.

[그림2. 교차 기능팀]

하지만 이러한 시스템은 명백한 낭비다. 특히 각 팀의 전문가가 서로 독립적으로 같은 분야를 개발한다는 점에서 더욱 그렇다. 

'사이트 신뢰성 엔지니어링' 관련 서적에서 보이는 구글의 조직과 달리, 넷플릭스는 사이트 신뢰성을 전담하는 엔지니어가 없었다. 

넷플릭스의 소프트웨어 프로덕트는 대부분 자바로 개발되고 수평적으로 확장되는 스테이트리스 마이크로서비스다. 프로덕트 간 동질성이 매우 높았기 때문에 프로덕션 엔지니어링을 중심으로 기능을 집중시키는 방식이 효율적이었다. 

구글의 프로덕트들은 자율주행차, 검색, 모바일 기기, 브라우저 등 서로 매우 이질적이다. 넷플릭스의 프로덕트는 특정 플랫폼에서 실행되는 일련의 비즈니스 애플리케이션으로 구성되며 소수의 언어(handful of language)로 개발된다. 

자신의 조직은 구글과 넷플릭스 중 어느 쪽을 더 닮았는가?

교차 기능팀과 전문성으로 격리된 팀은 마치 스펙트럼의 양극단과 같다. 플랫폼 엔지니어링을 효과적으로 발휘하면 팀마다 특정 분야의 전문가를 보유해야 할 필요성이 줄어든다. 

[그림3]은 플랫폼 엔지니어링을 도입한 조직으로, 양극단의 혼합적인 형태를 띤다. 중앙에 위치한 플랫폼 엔지니어링팀은 프로덕션팀을 고객처럼 여길 때 가장 강력한 위력을 발휘한다. 고객은 끊임없이 확보해야 할 대상인 동시에 제어할 수 없는 존재다. 

[그림3. 플랫폼 엔지니어링을 도입한 프로덕션팀]

모니터링 도구를 전사적으로 도입하는 경우를 예로 들어보자. 

먼저 각 마이크로서비스에 모니터링 기능을 공통 라이브러리로 탑재시키고, 기존에 정립된 보편적 가용성 척도를 공유한다. 

각 프로덕션팀은 약간의 시간을 들여 자신의 비즈니스 영역에 해당하는 고유한 가용성 척도를 추가한다. 

필요에 따라 중앙 관제팀과 정보를 공유하거나 효과적인 시그널 수립에 대해 조언을 하기도 한다

소프트웨어에는 끝이 없다 

소프트웨어는 마치 바다나 별, 또는 코드 속의 버그들처럼 끊임없이 이어진다. 몇 십년간 소프트웨어 분야에 종사한 사람이라면 누구나 공감할 것이다. 

끝없이 꼬리를 물고 이어지는 소프트웨어 유지보수야 말로 가장 값비싼 노력이 필요한 영역이다. 

테스트, 지속적 통합(CI), 지속적 전달(CD), 클라우드 컴퓨팅, 마이크로서비스 등 소프트웨어 분야의 괄목할만한 움직임 중 상당수가 이러한 인식을 바탕으로 등장했다. 

처음에 프로덕션을 만드는 것은 쉽다. 그러나 관련 기술들은 프로덕션 제작의 하위 절차들에 적용된다. 이러한 최적화는 주기적으로도 계속되어야 한다. 

구글 VS 넷플릭스의 문화

사이트 신뢰성 공학(site reliability engineering, SRE)이라는 용어의 발원지는 분명 구글이다. 그러나 SRE를 통해 해소할 수 있는 개발과 운영 사이의 병목 구간은 구글에만 존재했던 것은 아니다. 

MSA(MicroService Architecture) 분야의 대표 선도 기업인 넷플릭스 또한 필연적으로 같은 문제를 고심하고 자구책을 모색했을 것이다. 

넷플릭스는 구글보다 덜 정형화된 방식이 잘 맞았다. 서비스 가용성을 전담하는 팀이 따로 없었고 프로덕션팀 내부의 엔지니어도 프로덕트와 SRE 담당을 따로 구분하지 않았다. 조직 간에 오류 예산 같은 명시적인 상호작용도 없었다. 

어느 방식이 옳다 그르다 가릴 수는 없다. 그렇다. 지금 자신의 조직과 잘 맞는 형태는 무엇인지 고민하고 찾아보는 시간이 필요하다.

이 글은 <자바 마이크로서비스를 활용한 SRE> 도서 내용 일부를 발췌 편집하여 작성되었습니다. 넷플릭스에서 발아한 개발 문화, 그리고 손에 잡히는 SRE까지 그에 관한 보다 자세한 정보는 하기 책에서 만나볼 수 있습니다. 

『자바 마이크로서비스를 활용한 SRE』