컨테이너와 마이크로서비스, 어디서부터 시작해야 하나

컨테이너가 언론의 관심을 끄는 이유는 명확하다. 개발자의 일상이라는 측면에서 컨테이너는 혁신적이다. 인터프리트 언어가 컴파일 언어보다 더 높은 생산성을 가져다 주는 것과 마찬가지로, 컨테이너는 가상머신을 사용해서 몇십 분이 아니라 몇초 만에 기능적인 환경을 만들 수 있게 해주므로 개발자의 소중한 시간을 절약해 준다. 개발자는 기다리는 시간을 줄이고 코딩에 더 많은 시간을 투자할 수 있다.

컨테이너를 통해 더 쉽게 구현되는 마이크로서비스는 아키텍처 측면에서 컨테이너 못지않게 혁신적이다. 문제를 더 작은 조각으로 분할할 수 있는 기능은 항상 예상 밖의 이점을 제공하는데, 컨테이너는 이전에는 불가능했던 규모로 이 기능을 제공한다.

그러나 엔터프라이즈 IT 생태계에서는 개발자 생산성만 중요한 것이 아니다. 마찬가지로 아키텍처 효율성 역시 좋긴 하지만 항상 최우선 순위가 되지는 않는다. 전통적인 애플리케이션과 정립된 운영 프로세스가 있는 대규모 IT 조직에게 컨테이너 ‘올인’은 처리해야 할 레거시 문제가 없는 클라우드 태생의 기업에서만큼 쉽고 빠른 방법이 아니다.

그렇다고 대규모 IT 조직의 현대화에서 컨테이너가 설 자리가 없다는 뜻은 아니다. 사실 엔터프라이즈 IT는 과거에도 구조적인 변화를 유발한 두 가지 기술을 통해 지금과 동일한 상황에 직면한 적이 있으며, 위험을 낮추는 적당한 속도로 큰 변화를 수용하는 데는 혼합된 아키텍처가 적합하다는 사실을 발견했다. 그 두 가지 기술이란 바로 자바와 가상화다.

자바를 기다리며
엔터프라이즈 IT는 전통적으로 비용 절감에 중점을 두므로 변화를 꺼린다. 1990년대 초반 대규모 IT 조직에 속한 개발자는 대부분 C++를 사용했다. 당시는 네트워킹 활용도를 높이기 위해 클라이언트-서버가 모놀리식 애플리케이션을 서서히 대체하는 중이었고 개발자의 지상 과제는 모든 유닉스 변형에서 실행 가능하도록 코드를 작성하는 것이었다. 기반 운영체제가 HP-UX, AIX 및 기타 유닉스 변형 등으로 다양했고 서로 다른 라이브러리가 무수히 많았으므로 이 작업은 결코 쉽지 않았다. 코드가 각 대상 운영 체제에서 제대로 컴파일되도록 하기 위해 make 파일과 header 파일에 복잡하고 정교한 분기를 두는 경우가 일반적이었다.

이후 자바가 등장했다. 자바는 개발자가 각 운영체제의 복잡함을 이해해야 할 필요성을 없애고 이 복잡성을 대신 자바 가상머신에 집어넣었다. 개발자가 코드를 자바 바이트 코드로 컴파일하면 이 파일은 명령을 OS별 라이브러리 호출로 변환하도록 만들어진 JVM을 통해 인터프리트된다.

이 아이디어의 혁신성 또는 개발자 생산성에 미칠 수 있는 영향은 그야말로 엄청났다. 문제는 당시는 베어 메탈 서버의 시대였고 운영 담당자들은 단순히 개발자의 일상을 편하게 하고자 런타임에 또 다른 추상화 계층을 도입한다는 아이디어에 냉담했다는 점이다. 애플리케이션은 수명의 대부분을 개발이 아닌 프로덕션 현장에서 보내게 되는데, 개발자의 생산성에 연연할 필요가 무엇인가? 궁극적으로 자바는 개발자들의 부담을 덜어 자바가 약속한 서비스 지향 아키텍처의 개선을 포함한 더 큰 사안에 집중할 수 있게 해주겠지만, 아직은 아니다.

가상화로의 카운트다운
자바가 등장하고 약 10년 뒤 가상화가 나왔을 때도 IT는 똑 같은 논쟁에 휩싸였다. VM 이전 시대의 애플리케이션은 예상 피크 부하를 처리할 수 있는 규모로 구성된 베어 메탈 서버에서 실행됐지만 그 피크 부하가 현실화되는 경우는 드물었다. 그러나 IT 담당자 입장에서 용량 요구를 모자라게 예측할 때 발생하는 위험(예를 들어 해고)은 남아돌게 예측할 때의 위험(낮은 하드웨어 사용률)보다 컸다.

이후 닷컴 거품 시대를 거쳐 IT 예산이 빠듯해지자, IT 임원들은 용량의 25%를 밑돌게 운영되는 베어 메탈 서버들이 널렸다는 사실을 인식했다. 그제서야 “동일한 물리적 하드웨어에서 여러 개의 애플리케이션을 실행해 비용을 절감할 수 있지 않을까?”라는 생각을 하게 되었을 것이다.

그런데 A라는 애플리케이션이 B라는 애플리케이션과 동일한 베어 메탈 서버에서 실행되면서 메모리 누수를 일으키는 경우, B 애플리케이션은 아무 문제가 없음에도 이웃을 잘못 뒀다는 이유만으로 갑자기 성능 문제를 겪게 된다. 여러 애플리케이션이 동일한 하드웨어를 공유하되 이웃 애플리케이션으로 인한 문제를 줄일 수 있는 일종의 경계를 구현하는 기술이 있다면 사용률을 개선할 수 있을 것이다.

그래서 가상화가 나왔다. 가상화는 이 문제를 해결했지만, 과거의 자바와 마찬가지로 애플리케이션과 하드웨어 사이에 운영 담당자들이 기피하는 추상화 계층을 더했다. 새 물리적 하드웨어를 받을 때까지 몇 주, 몇 달을 기다릴 필요 없이 몇 분 만에 VM을 만들 수 있게 되었으므로 가상화는 자바와 마찬가지로 개발자의 생산성에 도움이 됐다. 또한 자바와 마찬가지로 명확한 이점(VM 생성을 자동화하여 환경을 복제하거나 용량을 늘려 예상치 못한 수요 변화에 대처하는 기능)에도 불구하고 초기에는 도입에 어려움을 겪었다.

컨테이너의 패러다임
자바와 가상화는 각각의 장벽을 어떻게 돌파했을까? 두 기술의 도입 문제는 모두 혼합 아키텍처를 통해 해결됐다. 흔히 볼 수 있었던 타협안은 운영 측에서 웹 계층이 온전히 자바에서 실행되도록 허용하는 대신 물리적 로드 밸런서를 통제 하에 두고 베어 메탈 하드웨어에서 데이터베이스를 실행하는 형태다. 이후 자바 기반 모델이 운영 측면에서도 마찬가지로 큰 유연성을 제공한다는 사실을 깨달은 후 운영 담당자들은 아키텍처에 계층을 추가하는 데 동의했고, 결국 대부분의 조직에서 서비스 지향 아키텍처가 구현됐다.

가상화가 도입될 때도 이와 똑 같은 혼합 아키텍처 패턴이 나타났다. 먼저 개발 및 테스트 워크로드가 가상화됐다. 그리고 수요가 높을 때 자주 병목 지점이 되는 곳에 사용자가 신속하게 리소스를 추가할 수 있다는 측면에서 가상화는 (자바가 그랬듯이) 웹 계층에 적합한 것으로 인정됐다. 이는 데이터베이스와 로드 밸런서를 보호되는 상태로 유지하면서 웹 계층에 대한 운영 부서의 문제를 해결했다.

엔터프라이즈 환경에서 컨테이너의 도입 역시 비슷한 패러다임을 따르고 있다. 운영 전문가는 3계층 웹 애플리케이션을 단일 가상머신 상에 배치하고, 이 가상머신이 모든 계층을 컨테이너로 구동하면 식으로 컨테이넌 기술을 시작할 필요가 없다. 대신 다수의 컨테이너로 단일 가상머신 상에서 웹 팜을 구동하는 것으로 첫 단계를 시작할 수 있다. 그리고 이들 컨테이너가 기존 로드밸런서나 데이터베이스 팜과 커뮤니케이션하도록 한다. 이런 식으로 운영팀은 컨테이너 혁명에 현재 경험하고 있는 익숙한 방법으로 접근할 수 있고, 배치나 확장, 마이크로서비스 개선 등의 실험을 시작할 수 있다.

마이크로서비스는 운영 전문가들에게 또 다른 것이다. 마틴 파울러의 훌륭한 정의는 다음과 같다.

“간단히 말해 마이크서비스 아키텍처 방식은 단일 애플리케이션을 작은 서비스의 집합으로 개발하는 접근 방식으로, 각 서비스는 각자의 프로세스 내에서 구동되고, 가벼운 메커니즘을 이용해 커뮤니케이션한다. 이들 서비스는 비즈니스 기능을 중심으로 구축되고, 완전히 자동화된 배치 장치를 이용해 독립적으로 배치할 수 있다.”

마이크로서비스가 해제하는 비즈니스 기능과 자동화는 컨테이너의 진정한 이점으로, 이들 독집적으로 배치할 수 있는 서비스를 위한 도구가 된다. 컨테이너가 개발 개발자에게 가져다 주는 단기적인 생산성 향상 효과도 좋지만, 조직이 얻을 수 있는 장기적인 생산성 향상 효과는 훨씬 크다. 컨테이너는 각 팀이 작은 서비스들을 함께 이어 맞추는 것으로 더 신속하게 비즈니스 문제에 대한 해법을 만들어 낼 수 있다.

결론적으로 혼합 아키텍처 접근법은 컨테이너와 관련된 모두가 각각 편안한 속도를 얻을 수 있다. 이런 패러다임은 이미 자바와 가상화를 통해 두 번이나 성공적인 것으로 확인됐다. 혼합 아키텍처에서 물리 하드웨어와 애플리케이션 간의 추상화는 엄청한 유연성을 가져다 주며, 개발자의 생산성과 관련된 여러 우려나 성능 문제 등의 오래 된 주장을 재탕할 필요도 없다. 혼합 아키텍처는 기업이 스스로의 속도를 정할 수 있도록 해 주며, 마이크로서비스의 엄청난 이점을 바로 얻을 수 있도록 해 준다.  editor@itworld.co.kr