2016.11.14
Brandon Butler | Network World
블랙 프라이데이와 사이버 먼데이는 일반 사용자들에게는 가슴 설레는 쇼핑시즌이면서, 소매 유통 업체들에겐 일년 중 가장 바쁜 시기다. 로드&테일러(Lord&Taylor), 색스 5th 애비뉴(Saks 5th Avenue)를 비롯, 다수의 브랜드를 소유하고 있는 헛슨스 베이 컴퍼니(HBC, Hudson’s Bay Company)에 지난해 쇼핑 시즌은 새롭게 업데이트 웹사이트를 테스트 해 볼 좋은 기회였다.
HBC가 사용하는 애플리케이션 서버와 전자 상거래 플랫폼은 오라클 웹로직(Oracle WebLogic)과 레드프레이리(RedPrairie)의 블루 마티니(Blue Martini)로 매우 널리 보급된 플랫폼이었다. 수 년간의 개발과 개정을 거친 스택은 큰 문제는 없었지만, HBC 인프라 엔지니어링 팀 관리자 매튜 픽은 “배치하기도, 변형하기도, 업그레이드 하기도 힘들다는 단점이 있었다”고 말했다. 픽은 올해 초 클라우드 벤더 조이언트가 개최한 컨퍼런스에서 HBC의 디지털 변혁에 대한 프레젠테이션을 하기도 했다.
HBC 엔지니어들은 이러한 문제를 해결할 방법을 모색했고, 답은 의외로 간단했다. 마이크로서비스와 컨테이너였다.
HBC엔지니어링 팀은 PDP(Product Detail Page)를 리플랫포밍 프로젝트의 출발점으로 삼았다. PDP는 전자상거래 앱에서 제품 설명과 이미지를 저장하는 부분이다. PDP는 원래 앱 안에 내장돼 있지만, 엔지니어 팀은 이 페이지를 12개의 마이크로서비스로 분해해 각각을 애플리케이션 컨테이너에 담았다(하나는 이미지를 로딩하고, 다른 하나는 텍스트를 보관하는 식으로 말이다).
픽은 마이크로서비스 기반 아키텍처로의 전환이 여러 가지 장점이 있었다고 말한다. 업그레이드가 훨씬 쉬워졌고, 문제가 생겼을 때 원인을 찾아내기가 비교적 용이하며 해결이 훨씬 능률적이다. 예를 들어 가격 리포팅 기능에 문제가 생겼을 경우, 마이크로서비스 아키텍처 하에서는 문제 발생 지점이 해당 서비스만으로 국한되기 때문에 그 서비스를 담당하는 팀에서 이를 해결할 수 있다. 마이크로서비스와 컨테이너 기반 아키텍처의 도입은 또한, 모바일 뷰와 반응적 디자인을 지원하기 위한 더 큰 전략의 일부이기도 했다.
작년 블랙 프라이데이나 사이버 먼데이 시즌에 새로운 PDP를 테스트한 HBC는 그러나 전체 트래픽을 전부 다 새로운 아키텍처로 시험하기 보다는 일부 트래픽만 PDP 마이크로서비스로 처리하는 방식으로 테스팅을 진행했다. 만에 하나라도 새로운 방식에 문제가 있을 경우 해당 트래픽만 셧다운하고 기존 방식대로 트래픽을 처리할 수 있게 하기 위해서였다. “1년 중 가장 중요한 쇼핑 시즌에 지나친 모험을 하고 싶지는 않았다. 하지만 언젠가는 반드시 새로운 테크놀로지를 시험해 봐야 하는 시점이 오게 마련이다”라고 작년 쇼핑 시즌을 회상하며 픽은 말했다.
마이크로서비스 아키텍처에 기반한 애플리케이션 개념을 시도하고 있는 것은 HBC만은 아니다. 마이크로서비스는 지난 2년간 여러 기업들 사이에서 상당한 호응을 얻어왔으며 특히 새로운 코드를 빠르게 쓰고 배치하며 복잡한 앱을 더 쉽게 관리할 수 있다는 장점이 많은 개발자들에게 어필했다. 하지만 여느 테크놀로지와 마찬가지로 마이크로서비스 역시 아직 해결해야 할 부분이 남아 있는 듯하다.
마이크로서비스란 무엇인가?
마이크로서비스에 대한 전문가들의 여러 가지 설명이 있지만, 하나의 통일된 정의는 아직 없는 것 같다. 간단히 설명하자면, 하나의 거대한 단일체로서의 애플리케이션을 제작하는 대신, 애플리케이션을 구성하는 각각의 요소들을 따로 개발해 조합하는 방식이라 할 수 있다. IDC애널리스트 알 힐와는 이를 다음과 같이 설명한다. “(마이크로서비스는) 애플리케이션의 각 요소가 개별적, 독립적으로 설계 및 개발되는, 분할적 구조의 소프트웨어 아키텍처라 할 수 있다.”이렇게 제작된 개별 요소는 API를 통해 하나로 통합된다. 즉 여러 개의 레고 조각에 해당하는 앱이나 서비스를 API라는 요소를 통해 하나의 통일된 앱으로 조립하는 것에 가깝다.
어디서 많이 들어 본 얘기 같지 않은가? 애플리케이션 기능을 서비스 단위로 분할한다는 이 개념은 10여년 전 유행했던 SOA(Service Oriented Architecture)에서의 개념과 비슷하다.
클라우드 테크놀로지 파트너(Cloud Technology Partners) 부대표 데이빗 린치컴은 “기업들이 마이크로서비스에 관심을 갖는 주된 이유 중 하나는 컨테이너를 이용한 마이크로서비스 개념에 대한 관심, 그리고 서비스 중심의 아키텍처에 대한 새로운 접근 방식을 모색하고 있던 기업들의 필요와 맞아 떨어졌기 때문이다”라고 말했다.
이처럼 SOA와 마이크로서비스는 개념적으로 유사하기는 하나, SOA는 단일의 프로그래밍 언어와 개발 환경에 국한되어 있고 전통적인 인프라 요소를 사용했다는 점에서 마이크로서비스와 구분된다. 이에 비해 마이크로서비스는 더 작고 독립적인 프로세스로 구성된, 더욱 애자일한 애플리케이션 개발 방법론이라 할 수 있다. 마이크로서비스 아키텍처 하에서 앱을 구성하는 각 서비스들은 각기 다른 프로그래밍 언어를 이용할 수 있으며, 그럼에도 불구하고 표준 API와 가상 또는 공용 클라우드 환경 등 차세대 인프라를 통해 서비스간 커뮤니케이션이 가능하다.
마이크로서비스의 장점
마이크로서비스 아키텍처는 분명히 여러 가지 장점이 있다.
민첩성. 애플리케이션 요소를 서비스 단위로 분해했기 때문에 각 요소를 독립적으로 개발할 수 있다. 스타트업 코드 저장소이자 깃허브의 라이벌 깃랩(GitLab) CEO 시드 시브란지는 “더 이상 개발 팀 전체가 하나의 구호에 맞춰 일사분란 하게 움직일 필요가 없다”고 말했다. 하나의 앱에 100 명의 개발자가 매달려 일을 하는 것이 아니라 10 명씩 10개의 팀으로 나뉘어져 앱의 각 요소들을 따로 개발하기 때문이다. 업데이트 역시 사전에 정해진 스케줄에 따라 전체 앱을 다 업데이트 하는 것이 아니라 각 요소 별로 새로운 기능이 완성될 때마다 바로 내놓을 수 있다.
데미지 최소화. 설령 앱의 특정 요소나 서비스에 문제가 생겨도 오류로 전체 앱이 다 마비되는 일은 일어나지 않는다. 451 리서치의 애널리스트 도니 버크홀츠는 “문제 발생 시 그 영향 범위를 최소화 하는 것이 포인트”라고 말했다. 예를 들어 은행 웹사이트를 마이크로서비스 방식으로 제작했다고 해보자. 송금 기능에 문제가 발생해도 여전히 잔액 조회는 가능하다. 즉 서비스가 서로 독립적으로 제작, 배치됐기 때문에 (적어도 이론적으로는) 한 요소에 문제가 발생해도 다른 서비스들은 이에 영향 받지 않고 정상적으로 구동하는 것이다.
개발 팀의 독립적인 작업이 가능. 마이크로서비스 아키텍처 하에서는 각 개발 팀이 다른 개발팀과 관계 없이 독립적으로 애플리케이션 요소를 제작할 수 있다. 이렇게 개별적으로 제작된 요소들은 공통 API를 통해 하나의 애플리케이션으로 통합된다. 시브란지는 팀 별로 하나의 분야에 집중할 수 있기 때문에 코딩의 퀄리티도 높아진다고 말한다. 각 팀이 자신이 맡은 분야에 있어 일종의 전문가가 되어 작업할 수 있게 되는 것이다.
이렇게 글로 쓰는 것은 쉽지만, 실제 마이크로서비스 아키텍처에 기반한 애플리케이션 제작은 그리 녹록하지 않아 보인다.
극복해야 할 과제들
451 리서치 애널리스트 버크홀츠는 애자일이나 데브옵스 마인드셋을 가진 팀일수록 마이크로서비스 애플리케이션 방식에 더 잘 적응 할 것이라고 말한다. 데브옵스란 개발(developer)과 운영(operation) 기능을 문자 그대로, 혹은 팀 방식으로 통합하는 것을 말한다.
이런 환경이 일단 조성되면, 코드를 쓰고, 테스트하고, 배치하는 작업은 매우 빠르게 진행된다. 실제로 많은 데브옵스 샵들이 개발 및 테스팅, 제작 평가 앱에 가상화, 클라우드 환경 등 자동화된 셀프 서비스 인프라를 도입하고 있기 때문이다.
451 리서치의 조사 결과에 따르면 조사 대상 기관의 2/3이 애플리케이션 개발에 애자일 방법론을 도입하고 있었으며 40% 가량은 데브옵스 방식을 채택하고 있었다. 이들이 바로 버크홀츠가 말한, 마이크로서비스 아키텍처에 바로 적응할 수 있는 기관들이다. 그러나 이러한 차세대 애플리케이션 개발 트렌드에 익숙지 않은 기관의 경우 마이크로서비스 구조로의 이전이 더 힘들게 느껴질 수도 있다.
이런 애자일한 환경에서는 대부분 애플리케이션 컨테이너가 사용된다. HBC의 픽에 따르면, 컨테이너와 마이크로서비스는 거의 공생 관계에 있다. 하나의 애플리케이션을 구성하는 여러 파트를 분할할 경우 이를 컨테이너에 기반해 운용하므로 개발자와 인프라 오퍼레이션 팀 간의 원활한 협업이 가능해진다는 것이다. 앱을 컨테이너에서 구동하고, 그 컨테이너를 위한 인프라를 마련하는 작업이 개발팀과 오퍼레이션 팀간에 적절히 이루어지기 때문이다.
마이크로서비스가 가져오는 인프라 상의 변화는 이뿐만이 아니다. 포레스터 사 애널리스트 데이브 바톨레티는 개발자들이 새로운 아키텍처를 수용함에 따라 IT 인프라의 역할도 변할 수 밖에 없다고 말한다.
“마이크로서비스 아키텍처를 수용한 개발자들이 일일이 IT에 VM을 요구하지는 않을 것”이라고 그는 설명했다. 그보다는 API를 통한 인프라 리소스의 즉각적 가용성을 기대할 것이다.
물론 이러한 인프라 환경을 지원하는 툴이 없지 않다. VM웨어나 오픈스택의 사설 클라우드 소프트웨어를 이용해 내부 클라우드를 구성할 수도 있고, IT가 직접 인프라를 제작하지 않아도 아마존, 마이크로소프트, 구글 등의 공용 클라우드 플랫폼을 이용할 수도 있다. 인프라 컨트롤 자동화를 위해 클라우드 파운드리나 레드 햇등의 PaaS 플랫폼을 이용하는 것도 하나의 옵션이다.
사물 인터넷과 같은 이벤트 중심 애플리케이션에는 소위 말하는 ‘서버리스(serverless)’ 컴퓨팅 플랫폼이 이상적이다. 이러한 플랫폼의 도입과 함께 IT의 역할은 인프라를 제공하는 것에서 개발자들이 직접 마이크로서비스를 디플로이 할 수 있는 환경을 조성해 주는 쪽으로 변화해가게 된다.
언제 어떻게 사용해야 가장 효율적일까
마이크로서비스 아키텍처가 모든 유형의 앱에 다 최선인 것은 아니다. 버크홀츠는 다수의 요소로 분해될 수 있을 만큼의 복합성을 띤 앱이라야 한다고 말한다. 한두 가지 기능으로만 구성된 단순한 앱의 경우(몇 주 동안만 운영될 목적으로 제작된 마케팅 캠페인 웹사이트가 좋은 예)에는 마이크로서비스를 굳이 이용할 필요가 없다. 반면 사물인터넷 데이터 스트리밍을 처리하기 위한 앱처럼 복잡하고 많은 요소들로 구성된 앱은 구성요소 단위로 분할해 개발 및 관리할 시 마이크로서비스 아키텍처의 장점을 톡톡히 누릴 수 있다.
마이크로서비스 시도가 성공적이었던 HBC역시 신중한 변화를 추구한다. 적어도 당분간은 컨테이너와 마이크로서비스 아키텍처에 기반한 애플리케이션과, 데이터베이스 및 기타 레거시 플랫폼 등 다른 시스템에 기반해 제작된 애플리케이션을 함께 운용할 계획이라고 픽은 밝혔다. “PDP 시도가 성공적이었으니, 점차 다른 것들도 마이크로서비스 아키텍처로 이전해 갈 것이다. 그렇지만 서두르지는 않을 생각이다”라고 그는 말했다.
또한, 애플리케이션의 어떤 기능, 요소를 분할할지 결정하는 것도 중요한 문제다. DISYS 컨설턴시의 글로벌 서비스 부대표 아마르 아바스는 다양한 마이크로서비스 요소들을 각기 독립적으로 운용하는 것이 도움이 된다고 조언한다. 요소간 데이터 전송이나 공유가 필요한 앱의 경우 마이크로서비스 스타일로 제작하는 것이 오히려 앱 속도를 느리게 만들 수도 있다.
아바스는 “요소간 커뮤니케이션에 걸리는 시간이 요소 프로세싱에 걸리는 시간보다 더 길다면 매우 비효율적일 것이다”라고 말했다. 그 어느 요소도 다른 요소에 완전히 의존하지 않도록 전체 시스템을 설계하는 것이 최선이다. 이렇게 함으로써 각 서비스가 개별적, 독립적으로 기능하며 마이크로서비스 아키텍처 하에서도 효율성을 잃지 않게 된다.
버크홀츠 역시 마이크로서비스가 새 애플리케이션 제작이나 새로운 서비스 요소를 제작할 때 많이 사용되는 이유도 이와 같다고 강조했다. 또, “기존 앱을 이전하는 데는 매우 많은 비용이 든다. 이러한 이전 비용을 절약할 수 있다는 장점 때문에 마이크로서비스가 인기 있는 것”이라고 설명했다. editor@itworld.co.kr
추천기사