마이크로소프트 나노 서버와 데브옵스의 미래

포괄적인 프로그래밍이 가능한 미래의 클라우드 인프라를 위한 플랫폼에서 나노 서버, 코어OS와 같은 가벼운 운영체제가 중요한 역할을 할 것이다.

프로그래머가 인프라스트럭처에 신경을 쓸 이유가 무엇인가? 따지고 보면 프로그래머는 그저 코드를 쓰고, 이 코드를 스테이징 환경으로 옮기면 된다. 그러면 운영팀이 해당 코드를 사용자와 접하는 애플리케이션 형태로 전달한다.
하지만 요즘은 그렇지 않다. 프로그래머는 신속하게 전달이 가능하며 유연하게 작동하고 미래지향적 소프트웨어 정의 데이터센터의 기능을 활용하는 애플리케이션을 만들어야 한다.

마이크로소프트가 최근 발표한 나노 서버(Nano Server)는 이 추세를 반영하는 흥미로운 제품이다. 하이퍼바이저와 컨테이너를 위해 가볍고 배포가 간편한 기본 OS를 제공하도록 설계된 나노 서버는 프로그램 가능한 인프라와 운영체제가 만나는 지점이라고 보면 된다. 경량화된 리눅스로서 도커 컨테이너 실행용으로 인기를 얻고 있는 코어OS의 윈도우 판이라고 할 수 있다.

나노 서버를 겉으로 보면 부가적인 UI를 모두 제거한 윈도우 서버처럼 보일 수 있지만, 사실 기능을 프로그램 방식으로 제공하기 위한 플랫폼이다. 즉, 파워쉘의 DSC(Desired State Configuration) 도구를 사용해서 필요에 따라 기능을 배포할 수 있다.

애플리케이션에 필요한 서비스에 대한 세부 정보가 “레시피”에 포함되는 셰프(Chef)와 같은 구성 관리 도구와 궁합이 잘 맞는다. 나노 서버를 사용하면 OS를 배포할 수도 있고 DSC 작동을 트리거하는 간편한 방법으로 특정 애플리케이션에 필요한 서비스를 구성하고 배포할 수도 있다.

나노 서버와 셰프의 조합은 운영팀 관점에서 흥미로운 옵션을 제공한다. 애플리케이션 인프라 관리 책임의 상당 부분이 데브옵스로 넘어가기 때문이다. 운영팀은 여러 개의 서버 이미지를 관리할 필요 없이 관리 및 패치가 가능한 하나의 기본 OS 이미지만 두면 된다. 앱에 필요한 서비스와 기능은 데브옵스팀이 담당한다.

애플리케이션을 지원하기 위해 고도로 확장 가능하고 유연한 클라우드 서비스를 제공하게 되면 이러한 책임 주체의 변화를 어떻게 관리할지에 대해서도 생각해야 한다. 컨테이너화는 운영체제에서 애플리케이션을 추출할 수 있게 해주는데, 다양한 가상화 기술은 인프라에 대해서도 같은 작업을 가능하게 해준다.

대부분의 경우 프로그래머는 확정된 서버 인스턴스가 확정된 애플리케이션 요소를 호스팅하는 정적 인프라를 위한 애플리케이션을 설계한다. 익숙한 MVC와 MVVM 패턴에서는 이 모델이 잘 통한다. 즉, 엔드포인트에서 데이터를 가져와서 이를 처리하고 포맷해 다른 엔드포인트로 전달하는 애플리케이션을 구축한다. 그러나 수천, 어쩌면 수백만 개의 엔드포인트에서 오는 정보를 처리해야 하는 미래의 사물 인터넷 애플리케이션은 어떻게 해야 할까? 그 많은 엔드포인트 모두 서버는 말할 것도 없고 서로 간에도 동기화되지 않는다.

가장 오래된 설계 패턴 중 하나가 여기에 잘 맞는다. 바로 액터(actor) 패턴이다. 비동기 메시지를 처리하고 관리하기 위해 만들어진 액터 패턴은 얼랭(Erlang)과 같은 함수형 언어의 핵심이며, 많은 대규모 클라우드 AI 시스템, 그리고 바쇼(Basho)의 리악(Riak)와 같은 분산 NoSQL 데이터베이스에 사용되고 있다(그 중 상당수가 얼랭으로 만들어짐). 액터는 강력한 도구이며 태생적으로 확장성도 뛰어나다. 서비스에 새 액터를 추가할 때 메시지가 적절히 전달되도록 주소록을 업데이트하기만 하면 된다.

액터 패턴은 상당히 광범위하게 적용할 수 있다. 예를 들어 액터는 노드-레드(node-red) 애플리케이션에서 Node.js 스위칭 요소로 손쉽게 볼 수 있으며, AWS 람다 또는 애저 이벤트 허브가 트리거하는 서비스의 경우도 마찬가지다. 미래의 개발자들은 이런 식으로 생각하게 된다. 왜냐하면 마인크래프트(Minecraft) 환경도 이런 방식으로 움직이기 때문이다!

언제, 어디서 올지 모르는 장치 메시지를 처리하면서 이벤트를 스트림 또는 작업으로 변환해야 하거나 단순히 데이터로 저장해야 하는 사물 인터넷에서 액터는 중요한 도구다. 또한 액터는 IoT 애플리케이션을 확장하는 데 있어서도 핵심적이다. 액터를 마이크로서비스라고 생각하면 된다. 즉, 액터 메시지는 엔터프라이즈 서비스 버스에서 군더더기를 없앤 가벼운 버전이다.

액터를 컨테이너에, 그 다음 씬(thin) OS에 연계하면 애플리케이션을 쉽고 빠르게 확장하고 OS 배포와 구성, 운영을 간소화할 수 있다. 새로운 서비스 인스턴스가 필요하다면 새 컨테이너를 시작하기만 하면 된다. 새 서비스 인스턴스를 ms 단위로 스폰할 수는 없지만 서비스가 실행되면 인프라스트럭처를 프론트 로딩하고 새 배포를 트리거할 수 있다. 유보된(suspended) 가상머신은 비용이 저렴하며, 새 VM을 지원하기 위해 소프트웨어 정의 네트워크를 재구성하는 데 소요되는 시간도 매우 짧다. 특히 나노 서버나 코어OS가 기반 OS인 경우는 더욱 그렇다.

애자일 개발 원칙에도 나오듯이 프로그램 가능한 인프라는 코드를 전달하고 사용자가 이미 애플리케이션으로 일을 시작한 이후 새로 끼워 넣는 요소가 아니라 제 1 원칙으로 생각하는 것이 가장 좋다. 애플리케이션과 인프라가 어떻게 상호 작용하는지에 대한 이해가 개발 프로세스에 포함되어야 배포 버튼을 누른 후 바로 실무 작업을 시작할 수 있다.

특히 컨테이너를 다루는 데 최적화된 새로운 세대의 OS인 경우, 확장 가능한 설계 패턴을 기반으로 하는 마이크로서비스를 성공적으로 구현하기 위해서는 개발과 운영을 하나로 모으는 것이 핵심이다. 이는 개발 팀이 데브옵스를 심층적으로 받아들여야 하고, 이를 관리하는 데 사용되는 인프라스트럭처와 도구가 모든 작업의 일부가 되어야 함을 의미한다.  editor@itworld.co.kr