MS 애저 PaaS가 남달라 보이는 이유

마이크로소프트(MS)는 지난달 새로운 ‘서비스형 플랫폼(PaaS)’인 ‘애저 서비스 패브릭’을 공개했다. 외부에 PaaS 2.0으로 알려졌던 이 개발 플랫폼은 경쟁작과 남다른 접근법을 갖고 있다.

MS에 따르면, 애저 서비스 패브릭(Azure Service Fabric)은 대규모(hyper-scale) 서비스 구축과 운영 시 안정성 및 확장성을 제공하는 개발 플랫폼으로 묘사된다.

MS는 “인프라 자원의 가용성과 애플리케이션 수요를 본질적으로 이해하고, 업데이트를 자동화하며, 대규모 인프라에서 셀프힐링과 고가용성, 서비스 지속성 등을 제공한다”고 설명했다.

MS는 최근 열린 연례 개발자컨퍼런스 ‘빌드2015’에서 애저 서비스 패브릭의 자세한 아키텍처를 공개했다. MS는 이 플랫폼에 ‘마이크로서비스’와 ‘액터 모델 프로그래밍’을 결합했다고 발표했다.

장점이 타 클라우드 서비스와 크게 다르지 않은 수식어로 묘사되기 때문에 차별점을 느끼기 힘들다. 하지만 안을 뜯어보면 아키텍처 측면에서 남다른 부분을 확연히 드러낸다. 한국MS 김재우 부장에게 자세한 설명을 들어봤다.

마이크로서비스는 과거 서비스오리엔트아키텍처(SOA)의 진화 버전이다. 애플리케이션의 구성요소를 작은 단위로 쪼개 각 요소를 하나의 독립적인 앱으로 만들고, 요소들을 API로 조합해 애플리케이션으로 만드는 아키텍처다.

액터 모델 프로그래밍은 1973년 칼 휴이트가 제안한 개념이다. ‘스레드’나 ‘객체’와 구별되는 추상으로, 각 액터는 내부에 로직과 상태를 갖고 싱글스레드로 특정 작업을 순차적으로 실행한다. 다른 액터나 스레드의 간섭을 받지 않고 비동기식으로 작동한다. 액터 내부에서 일어나는 일은 ‘공유’되지 않는다.

일반적으로 마이크로서비스는 ‘업무(task)’란 추상화 단위로 쪼개진다. 반면, MS는 마이크로서비스를 ‘액터(Actor)’란 단위로 만든다. 엄밀하게 보면 다르지만, 각 액터는 객체지향프로그래밍(OOP)의 ‘오브젝트(Object)’를 독립된 앱으로 만들었다고 생각하면 유사하다. 서비스 추상화 수준이 매우 세밀하다는 얘기다.

업무량이 늘어나면 액터의 클러스터를 만들어 확장해 대처한다. 액터에 ID를 붙여 관리하고, 액터 간 정보교환은 메시지 패싱으로 한다.

오래 묵은 액터 모델이 최근 개발자 사이에서 주목받는 이유는 ‘동시성(concurrency)’과 ‘상태(state)’의 문제를 해결하는 합리적 방안을 제시하기 때문이다. 동시다발적으로 수많은 사용자가 집중접속하는 대규모 서비스의 등장으로, 이를 떠받칠 안정적이고 확장가능한 IT인프라 설계가 애플리케이션 차원에서 이뤄져야 하는 상황이다.

김재우 부장은 “서로 다른 축으로 발전해온 두 갈래의 기술적 논점이 하나의 제품으로 만났다는 게 큰 의미를 갖는다”며 “프로그래밍에서 만악의 근원이라 할 ‘상태(state)’ 문제를 해결하고, 개발 편의성을 높인 것”이라고 설명했다.

일단 상태란 무엇일까. 상태는 시공간적 변화를 표현하는 말이다. 이를 수학이나 물리학으로 설명하려면 복잡한 증명이 필요하다. 김재우 부장의 설명이다.

“수학엔 상태란 개념이 없다. 여기서 상태란 특정 시점에 어떤 물체가 있는 상황이다. 시간이 흐르면, 상태는 달라진다. 장독에 된장을 담고, ‘된장독1’이란 ID를 붙였다고 하자. 그리고 얼마 뒤 된장을 조금 퍼냈다. 그 된장독은 처음 만들었던 된장독1과 같은 것일까? 수학에선 둘을 같다고 본다. 그러나 현실은 물체가 같아야 같은 것이다. 컴퓨터가 시간의 흐름에 따라 변화하는 상태를 '다르다'고 추상적으로 이해하게 해야 하는데, 이 작업이 매우 어렵다.”

전통적인 애플리케이션은 쪼갤 수 없는 수준으로 긴밀히 통합된 형태다. 이 경우 성능을 높이는 방법은 하드웨어를 업그레이드하는 것이다. 그러나 인터넷 시대의 서비스는 최고사양의 하드웨어라도 그 많은 접속량을 처리할 수 없다. 내부에 발생하는 여러 병목지점 때문이다. 이에 서버 대수를 늘리고 빠른 네트워킹으로 업무를 분산하는게 해법으로 제시되기도 했다. 그러나 ‘상태’가 병목지점에서 말썽을 일으킨다. ‘동시성’에서 충돌을 일으켜 데이터 오류를 만들어내는 것이다.

확장성있고 빠른 서비스를 유지하려면 상태를 DB에서 처리하고, 컴퓨트 클러스터는 상태를 신경쓰지 않는 ‘스테이트리스(stateless)’ 아키텍처를 설계해야 한다. 오늘날 많이 활용되는 ‘웹-미들웨어-데이터베이스’ 3계층(tier) 모델이 스테이트리스 아키텍처다.

“상태가 컴퓨트에 포함돼 있다는 건 식당에서 일어나는 업무를 보면 이해하기 쉽다. 식당종업원을 서버라 치면, 손님에게 주문을 받아서 머리속에 기억하고 주방에 전달하는 식이다. 혹 종업원이 중간에 어딘가 사라질 경우 손님 주문이 주방에 전달되지 않는다. 가상머신(VM), 컨테이너, 콤포넌트 등을 스테이트리스 아키텍처로 만들어야 대규모로 확장할 수 있다는 건 분산처리의 기본이다. 도커든 JEE든 샌드박스 형태로 다른 프로세스와 독립적으로 동작하는 하나의 패키지를 만드는 거다. 그런데 애초에 가상화는 성능 좋은 하드웨어를 싱글스레드 하나에 쓰기엔 아까우니 효용성을 높이려 에뮬레이터와 VM을 만들고, VM을 정적인 하드웨어처럼 사용하는 콘셉트를 반영했다. 이게 오해를 낳았다. VM을 하드웨어로 생각하고 설계하다보니 상태를 뺄 이유가 없었고 당연히 클라우드서 실패했다. 클라우드는 하드웨어를 머리 속에서 지우고 애플리케이션을 만들어야 한다. ”

스테이트리스 아키텍처의 속도를 높이기 위해 큐와 캐시가 사용된다. 김 부장의 설명이 이어진다.

“서버와DB 사이의 입출력(IO)이 가장 비싼 IO니 이를 줄이면서 속도도 빠른 메모리에 쓰는 것처럼 하고, 일정기간 동안 상태를 사라지지 않게 한다. 상태를 공유하는 캐시를 만드는 것이다. 예를 들면 식당에 화이트보드를 만들고, 종업원은 주문 받은 내용을 보드에 적는다. 주방은 보드에 적힌 것만 보고 요리를 만든다. 기본적인 IO가 많아지면 큐를 쓴다. 대기시켰다가 먼저 것을 처리하면 다음 것을 처리하는 것이다. 3티어 서비스 패턴의 데이터 워크플로는 ‘잡-큐’의 반복이다. 이 경우 구조가 매우 복잡해지는데, 큐 짜는 것과 캐시 클러스터를 유지하는 것도 프로그래밍 해야 하는 부분이다.”

MS 애저 서비스 패브릭은 크게 2종류의 애플리케이션프로그래밍인터페이스(API)와 ‘서비스 패브릭’으로 구성된다.

API는 ‘릴라이어블 서비스(Reliable Service) API’와 ‘릴라이어블 액터(Reliable Actor) API’로 나뉜다. 이중 릴라이어블 서비스 API는 앞선 스테이트리스 아키텍처 구성을 쉽게 해주는 ‘릴라어블 딕셔너리(상태 캐시)’와 ‘릴라이어블 큐’를 제공한다.

“애저 서비스 패브릭의 한축인 ‘릴라이어블 서비스 API’가 스테이트리스 아키텍처의 데이터 플로우 구축을 편하게 해준다. 스테이트풀 방식의 모형을 플랫폼 프레임워크 수준에서 안정화시킨 것이다. 지속성 있는 상태를 유지하기 위해 릴라이어블 딕셔너리나 큐를 넣어 설계하면 된다. 개발자는 캐시 구성과 서버 적재, 네트워킹 등을 신경쓰지 않아도 된다. 고가용성이나 재해복구 같은 건 밑단의 서비스 패브릭이 알아서 자동화한다. 인프라 운영과 구성에 대한 편의성이 좋아진 것이다.”

릴라이어블 액터 API는 컴퓨트 안에 상태와 로직을 함께 담는 ‘스테이트풀(stateful)’ 아키텍처를 구축하게 해준다. 이를 통해 서비스 디자인이 단순해지고, 레이턴시가 제거된다.

앞선 설명에서 ‘상태’를 컴퓨트(미들웨어) 계층에서 빼내야 대규모로 확장가능한 분산처리가 가능하다고 했다. 그렇다면, MS가 컴퓨트 계층에 다시 상태를 집어넣으라고 언급하는 게 혼란스러울 수 있다. 답은 ‘액터 모델’에 있다.

애저 서비스 패브릭의 혁신성 중 하나가 릴라이어블 액터 API다. 액터는 로직과 큐(캐시)를 담고, 상태도 담은 오브젝트다. 릴라이어블 서비스 API보다 높은 추상화 수준을 갖고 있다는 게 김 부장의 설명이다.

“물리적 개념을 완전히 없애고, 각 클래스 하나가 하나의 앱으로서 싱글스레드로 작동한다. 순차적으로 스테이트를 엄격히 하면서, 각 액터는 비동기로 병행 작동한다. 백엔드의 서비스 패브릭은 스테이트를 엄격히 관리하는 역할을 한다.”

액터 하나는 싱글스레드다. 한번에 하나의 계산만 하고, 몰리는 작업은 대기시켜 액터와 액터는 간섭하지 않으므로 상태의 충돌이 일어나지 않는다. 작업량이 집중되는 액터만 클러스터로 만들면 된다. 스테이트풀 아키텍처가 가능해진다.

단, 액터 모델을 실제로 사용하려면 새로운 언어와 프레임워크를 익혀야 했다. MS는 액터 모델을 C#이나 자바처럼 쓸 수 있게 해 진입장벽을 낮췄다.

“C#이나 자바처럼 프로그래밍하면서 액터 프레임워크를 쓸 수 있게 만든 게 릴라이어블 액터 API다. 자바나 C#이란 레거시가 워낙 강하고, 액터 모델 프레임워크를 쓰기 낯설어하는 풍토를 감안한 것이다. 어쨋든 새로운 프레임워크를 익힌다는 건 운영 부담을 키우는 거다.”

서비스 패브릭은 액터들의 복잡한 네트워킹 토폴로지를 엄격히 관리하면서 상태 문제를 해결하는 핵심이며, ‘멀티머신-멀티스레드’를 구현하는 중추다. HA, DR, 프로그래밍모델, 하이브리드 오퍼레이션, 고집적, 하이퍼스케일, 데이터 파티셔닝, 롤링업그레이드, 자동 롤백, 로레이턴시, 헬스모니터링, 셀프힐링, 컨테이너 오케스트레이션 및 수명주기 관리, 로드밸런싱 등의 기능을 제공한다.

“제공하는 기능은 개발자가 골치아파하는 문제들이다. 코딩에 집중하기도 어려운데 인프라를 구현해야 하니 실패하기 쉽다. 서비스 패브릭을 쓰면 개발자는 코딩만 신경쓰면 된다.”

액터 모델로 마이크로서비스를 구성하면, 각 액터가 싱글스레드로 동시에 실행되니 빠른 성능을 구현할 수 있다. 세밀히 추상화됐다는 건 애플리케이션 실행 프로세스가 아주 정밀하게 분업화됐다는 뜻이다.

그러나 액터모델의 문제점도 있다. 잘게 쪼개는 만큼 마이크로서비스 관리가 복잡해진다는 것이다. 서비스 패브릭이란 플랫폼은 관리자 역할 혹은 애플리케이션 프록시 역할을 한다.

“액터모델과 마이크로서비스는 복잡한 토폴로지 네트워크를 만들기 때문에 관리 측면에선 복잡해진다. 이게 서비스 패브릭의 존재 이유다. 첫째, 서비스 부하분산이 스케일아웃 방식에 맞게끔 옆으로 펼쳐져야 하는데, 펼쳐야 할 때와 줄여야 할 때, 펼쳐야 하는 것과 펼치지 말아야 하는 것을 정확히 구분해줘야 한다. 본질적으로 순차적인 작업은 마이크로서비스로 쪼개면 안 된다. 어느 코드 모듈에 트래픽이 많이 몰린다고 하면 거기에 HA, DR을 하면 된다. 둘째, 각 요소가 제각각의 개발 프레임워크나 라이브러리를 사용할 수 있다. 요소별로 각기 업데이트가 이뤄져야 한다. 서비스 패브릭은 이런 분산 개발환경에 적합하다.”

애저 서비스 패브릭의 또 다른 장점은 가용성이다.

"애플리케이션을 구성하는 각 액터는 5개로 복제돼 각 하드웨어에 하나씩 분산 배치된다. 한 액터가 ‘프라이머리’ 고, 나머지 4개가 HA를 위한 ‘세컨드리’다. 읽기 작업은 프라이머리에서 종결된다. 쓰기 작업은 프라이머리에 새 내용을 넣고, 달라진 내용을 다른 세컨드리에 업데이트하는 것으로 종결된다. 프라이머리 액터가 장애를 일으키면, 다른 하드웨어에 있는 세컨드리 하나를 프라이머리로 지정하고, 그 사이 새로운 세컨드리를 만든다. 이를 사람이 할 수도 있다. 하지만, 앱 하나에 무수한 액터가 조합돼 있으므로 그 복잡성에 따른 업무부담이 너무 크다. 서비스 패브릭은 5카피 형태를 하나의 마이크로서비스에서 자동화한다.”

기존의 애플리케이션은 작은 업데이트라도 전체 운영을 중단해야 했다. 마이크로서비스는 독립된 요소기 때문에 애플리케이션 내부에서 발생하는 문제점을 개별적으로 관리하고, 업데이트할 수 있게 된다. 문제 원인이 되는 요소를 찾아 그것만 업데이트하면 된다. 액터 모델은 이 관리를 한층 더 세밀하게 할 수 있다.

업데이트 중엔 기존 요소를 활용해 애플리케이션을 계속 운영할 수 있다. 업데이트가 종료되면 기존 요소를 업데이트된 요소로 갈아끼우면 된다. 달리는 자동차를 멈추지 않고, 타이어를 교체하는 것과 같다.

MS는 애저 서비스 패브릭에 사용된 기술을 내부 현업 시스템에 5년 간 적용해 사용해왔다고 밝혔다. 액터모델과 마이크로서비스를 결합한 ‘애저 서비스 패브릭’은애저의 코어 인프라, 애저 도큐먼트DB, 인튠, 비즈니스용 스카이프, 파워BI, 애저 SQL데이터베이스, 빙 코타나, 애저 이벤트허브 등에 사용되고 있다고 한다. 그만큼 검증된 기술이란 얘기다. 단, 내부에서 쓰는 플랫폼을 대외 서비스에 맞게 최적화해 내놓았다는 설명이다.

김재우 부장은 마이크로서비스, 액터모델, 그리고 ‘애저 서비스 패브릭’에 대한 과도한 흥분은 금물이라고 강조했다.

“뭐든지 오버 엔지니어링이 문제를 일으킨다. 마이크로서비스와 액터모델 사용엔 전체 애플리케이션과 인프라에 대한 명확한 설계가 필수다. 마이크로서비스에 대한 적합성도 따져서 써야 한다. 요즘 도커로 마이크로서비스를 많이 만든다. 그러나 도커 자체가 마이크로서비스 자체를 가능하게 하는 건 아니다. 마이크로서비스는 SW를 잘 설계하는 사람이 할 수 있는 일이다. 마이크로서비스에 적합하지 않게 설계된 애플리케이션은 도커든 릴라이어블 액터 API든 아무리 좋은 수단이 있어도 제대로 돌아가지 않는다.”