2016.11.11

"개념부터 과제까지" 마이크로서비스 완전분석

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와 가상 또는 공용 클라우드 환경 등 차세대 인프라를 통해 서비스간 커뮤니케이션이 가능하다.



2016.11.11

"개념부터 과제까지" 마이크로서비스 완전분석

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와 가상 또는 공용 클라우드 환경 등 차세대 인프라를 통해 서비스간 커뮤니케이션이 가능하다.



X