마이크로서비스로 이전하기··· ‘현장의 조언 8가지’

CIO
마이크로서비스로의 이전은 애플리케이션 개발에 있어 상전벽해 수준의 변화를 의미한다. 그 과정에서 수반되는 복잡성을 해소할 방안을 정리했다. 
 
ⓒ Image Credit : Getty Images Bank



오늘날 새로운 애플리케이션 개발에 있어서 특히 중요한 것 중 하나가 제공 속도다. 애자일 트렌드로 인해 소프트웨어 개발이 쉽고 빨라야 한다는 분위기가 조성됐다. 애플리케이션 개발 가속화에 도움이 되는 기술 트렌드 중 하나는 마이크로서비스의 등장이다.  

마이크로서비스는 느슨하게 연동된 서비스들의 총합체로서, 애플리케이션을 구조화하는 SOA(Service-Oriented Architecture)의 변종이다. 애플리케이션을 소규모 서비스로 분할할 때의 이점에는 모듈 방식이 포함되며, 이를 통해 애플리케이션을 개발하여 시험하기가 쉬워진다.

“마이크로서비스는 팀의 권한을 증진시키고 연계성을 낮추어 각 팀이 더욱 빠르게 혁신하고 팀간 소통을 줄이면서 아키텍처, 언어, 프레임워크에 대해 스스로 결정할 수 있는 자율성이 보장된다"라고 버라이존 미디어 그룹의 엔지니어링, 스포츠, 미디어 제작 엔지니어링 부사장 EJ 캠벨이 말했다.

그는 이어 "팀들이 마이크로서비스를 도입하면서 시작부터 제작까지의 사이클 시간이 크게 감소했다. 많은 팀들이 인간의 개입 없이 하루에도 몇 번씩 마이크로서비스를 배치하고 있으며 시험, 코드 검토, 정교한 CI/CD(Continuous Integration/Continuous Delivery) 파이프라인에 의존하여 변경사항을 안전하게 제공하고 있다"라고 덧붙였다.

해당 기업의 YDFP(Yahoo Daily Fantasy Product)는 핵심 게임 플레이 서비스, 스포츠 데이터 서비스, 지갑 서비스, 여러 내부 지원 서비스 등의 여러 마이크로서비스로 구성된다. "각 서비스는 자체적인 연속 배치 파이프라인, 고립된 데이터 스토어, 개발과 운영을 담당하는 각 팀이 있다"라고 캠벨이 설명했다.

그러나 마이크로서비스를 이용하기란 호락호락하지 않을 수 있다. 대표적인 문제로는 서비스들 사이의 적절한 경계 결정, 마이크로서비스 환경에서 팀들 사이의 코드 공유의 어려움 극복하기, 팀들이 독립적으로 코드를 공개하기 때문에 발생하는 변화 관리의 복잡성 등이 포함된다.

마이크로서비스로 이행하면 상전벽해를 겪게 되며 조직은 이런 대대적인 변화에 대비해야 한다.

"마이크로서비스로 발전하는 것은 말에서 자전거 또는 자전거에서 자동차로 발전하는 것과 같다."고 SBD(Solutions By Design)의 프로그램 차장 제이 버처는 표현했다. SBD는 마이크로서비스 기반 IT 접근방식으로 이행하는 연방기관들에게 마케팅, 의사소통, 기술 서비스를 제공하는 기업이다.

버처는 이어 "우리는 발전 단계를 거치면서 더 많은 것들이 이동하게 되었다. 각각은 자체적인 유지보수 수준이 필요하며 많은 요소를 지원하고 감독해야 하기 때문에 솔루션의 복잡성이 증가할 뿐 아니라 관련된 비용도 높아진다. 따라서 우리는 최고의 기술 결정뿐 아니라 비용 효율성도 확보하기 위해 결정을 정밀하게 조사해야 한다"라고 말했다.

또 다른 문제는 보안이다. 버처는 "애플리케이션 전반에 걸쳐 단일 검증 솔루션을 이행할지 아니면 각 마이크로서비스가 자체 검증 프로세스를 확보해야 하는지 결정해야 한다. 사례 별로 각 프로젝트팀이 이런 사항을 결정해야 한다"라고 전했다. 마이크로서비스 환경에서 참고할 만한 조언을 정리했다.

도메인 주도적 디자인을 도입하라
버처에 따르면 마이크로서비스 구성의 핵심은 서비스들을 느슨하게 연계시키고 단일 책임 원칙을 적용하는 것이다. 

그는 "다양한 개발 방법과 방법론이 있지만 도메인 주도적 디자인과 마이크로서비스가 가장 적합한 것으로 보인다"라며 SBD의 팀들은 대부분의 팀 상호 의존성을 없애는 효율적인 개발 패턴을 생성하는 애플리케이션을 구축하기 위한 주제와 관련된 접근방식인 도메인 지향적인 디자인을 이용한다고 전했다. 

그는 "업무상 도메인과 마이크로서비스의 상관관계는 기본적으로 1:1이다. 따라서 각 개발팀은 도메인 그리고 해당 마이크로서비스 개발을 담당한다. 이를 통해 책임이 명확해져 병렬 개발 프로젝트 중 발생할 수 있는 가외성이 제한된다"라고 말했다.

코드 라이브러리에 대한 가이드라인을 수립하라
마이크로서비스 세계에서는 팀들 사이에서 코드를 공유하기가 훨씬 힘들 수 있다. 캠벨은 “모놀리스스는 공통 코드가 호출 방법이다. 이와 달리 마이크로서비스를 이용할 때는 독립적인 서비스에 아키텍처 공통성을 고려하거나 코드를 공유된 라이브러리에 패키지화해야 한다"라고 말했다.

이런 라이브러리의 도입은 느릴 때가 많다. 또 변화를 위해서는 라이브러리 소유자와 여러 서비스들 사이의 조율이 필요하다. "따라서 조직은 공통 라이브러리에 대한 탄탄한 일련의 가이드라인과 롤아웃에 대한 기대치를 도입해야 한다"라고 캠벨이 말했다.

마이크로서비스들 사이에서 데이터베이스를 공유하지 말라
버처는 자사의 경우 분리된 서비스를 구축할 때 개발팀들이 [백엔드] 시스템에 연결된 자체 데이터베이스를 구축할 수 있도록 허용함으로써 다른 개발팀의 의존성을 제한하고 있다고 전했다..

그는 "여러 개발팀은 다른 모두가 흡수할 수 있도록 저작물을 백엔드로 전송하며, 이 정보는 데이터팀이 관리한다. 이는 P&P(Plug and Play) 개념에도 적용된다. 서비스를 대체해야 하는 경우 새 것으로 옮기기만 하면 된다. 전구를 교환하는 것과 비슷하며, 단지 조금 더 복잡할 뿐이다"라고 말했다.

마이크로서비스는 설계상 모듈식이기 때문에 개발 프로세스는 주로 P&P이며 이에 따라 문제를 매우 쉽게 해결할 수 있다.

버처는 "코드는 플랫폼 전반에 걸쳐 전파되지 않기 때문에 문제를 특정 소스로 신속하게 고립시킨 후에 마이크로서비스 내에서 추적할 수 있다. 이 덕분에 마이크로서비스 별로 단편적인 업데이트와 업그레이드가 가능하여 애플리케이션을 손쉽게 업데이트할 수 있다. 전체를 대체하는 대신에 한 번에 시스템의 일부만 업그레이드하는 것을 상상할 수 있는가? 이 개념 하나로 시스템 개발이 혁신된다"라고 말했다.

SBD의 경우 미국 전역의 다양한 위치에 개발팀이 분포되어 있어 마이크로서비스의 이점이 증폭됐다. 특히 사우스캐롤라이나의 찰스턴에 사는 팀 구성원들은 솔루션에 연결되는 자체적인 마이크로서비스를 개발하고 있기 때문에 개발 독립성의 수준이 더 크다고 그는 덧붙였다.

보안 문제를 해결하라
IT와 관련된 모든 것들과 마찬가지로 마이크로서비스도 자체적인 보안 문제가 있다. 기업들은 소프트웨어 개발 라이프사이클 중 알려진 취약성을 조기에 자주 스캔해야 한다고 전자상거래, 결제, 마케팅 서비스 제공 기업 디지털 리버(Digital River)의 CIO 라이언 더글라스가 말했다.
 
그는 "빠르게 변화하는 세상에서 운영되는 IT팀이라면 자체 솔루션뿐만이 아니라 제3자 소프트웨어의 취약성을 식별하여 해결해야 한다. 보안 유지에 필수적이다. 총체적으로 어떻게 작동하며 잠재적인 문제 영역이 어디인지 파악하기 위해 소프트웨어 생태계에 대한 전체론적인 접근방식을 취하는 것이 중요하다"라고 말했다.


한편 마이크로서비스를 이용할 때 소프트웨어 패치 배치가 훨씬 쉽다. 단순히 자체 코드에만 적용되는 것이 아니다. 더글라스는 "IT 엔지니어는 자체 소프트웨어 개발과 함께 제3자 소프트웨어의 취약성을 시험할 수 있다. 취약성이 발견되는 경우 이전의 모놀리스 코드 개발보다 픽스를 더욱 신속하게 배치할 수 있다"라고 설명했다. 

복잡한 관계를 피하라
대규모 마이크로서비스 배치 시 복잡한 관계가 너무 쉽게 발생할 수 있다고 CSC 및 HP의 기업 사업부 합병 후 형성된 IT서비스 제공 기업 DXC 테크놀로지의 애플리케이션 서비스 CTO JP 모겐탈이 지적했다.

그는 "조직이 시스템 아키텍처 확보에 대해 주의하지 않는 경우 (마이크로서비스 사용을 유도하는) 반복적인 데이터 경로가 존재할 수 있다. 독립적인 교차 기능팀과 서비스 저장소 이용 사이에서 시스템이 마이크로서비스의 원리를 무효화시키는 의존성이 나타날 수 있다"라고 설명했다.

단일 마이크로서비스는 시스템 전체에 큰 영향을 끼치지 않고 변경하거나 제거할 수 있어야 한다. 모겐탈은 기업 아키텍처를 포함시켜 마이크로서비스 디자인을 검증하는 것이 가장 좋다고 귀뜸했다.

애플리케이션을 처음부터 구축하는 것을 고려하라
부동산 서비스 제공 기업 CMH(Carrington Mortgage Holdings)은 자사의 소비자 직접 담보 플랫폼 ‘Vylla.com’의 기술 아키텍처를 마이크로서비스로 옮겼다.

회사의 존 니콜라스 CTO는 "마이크로서비스로의 마이그레이션을 결정했을 때 직면한 문제 중 하나는 애플리케이션을 분할하거나 전체적으로 재작성할지를 선택하는 것이었다"라고 전했다.

그는 이어 "사전 설정된 일부 비즈니스 요건으로 인해 우리는 매우 짧은 기간 안에 새로운 기능을 제공해야 했다. 처음에는 단일 아키텍처로 통합하려 시도했으며 결과가 성공적이었다. 하지만 기존의 기능 대부분을 새로 작성하는 것보다 분할하는 것이 더욱 어려울 것이라는 사실을 깨달았다"라고 말했다.

이를 염두에 두고 개발팀이 결정한 최선의 방책은 새 애플리케이션을 처음부터 개발하는 것이었다. "엄청난 일이었고 모든 팀원들이 많은 노력을 기울여야 했지만 해당 이전 이후로 짧은 기간 동안 이미 그만한 가치가 있다고 입증되었다"라고 니콜라스가 말했다.

마이크로서비스를 성공적으로 배치하기 위해서는 상당한 기술 투자가 필요하기 때문에 새로운 기술이 성능을 개선하거나 운영 효율성을 어떻게 개선하는지 개요하는 명확히 정의된 비즈니스 사례가 있어야 한다고 니콜라스가 말했다.

그는 "여기에서 필수적인 요건은 적절한 인재를 찾는 것이다. 이를 수행한 경험이 있는 엔지니어링 설계자를 찾기가 쉽지 않다. 우리는 적절한 아키텍처를 이해하는 강력한 엔지니어링팀과 애플리케이션을 중심으로 시험하면서 자동화를 구축하는 강력한 품질확보팀을 구성할 수 있었다"라고 말했다.

확장 시의 성능을 측정하라
모놀리식(monolithic) 애플리케이션의 경우 전체를 확장해 서버를 추가하는 방식으로 수요 증가에 대응할 수 있다. 그러나 마이크로서비스에서는 다른 특성을 보인다고 인공지능을 이용해 생산성 소프트웨어를 제공하는 스팟큐(SpotCues)의 공동 설립자 프라빈 카니아디가 말했다.

카니아디는 "마이크로서비스의 경우 모듈식 아키텍처를 통해 시스템의 일부만 확장할 수 있다. 하지만 마이크로서비스는 확장성에 대해 전혀 다른 접근방식이 필요하다. 왜냐하면 마이크로서비스 아키텍처 배치가 함께 동작하는 여러 서버와 가상화에서 구동하는 여러 구성 요소로 구성될 수 있기 때문이다"라고 말했다.

이로 인해 확장할 개별적인 구성 요소를 식별하는 문제가 추가된다. "성과 측정이 필요한 곳이 있으며 애플리케이션 제공 컨트롤러와 같은 툴은 성능 문제를 측정하여 감지하는데 도움이 될 수 있다"라고 카니아디가 말했다.

그는 또 기업들은 비즈니스 우선순위에 기초하여 성능 및 신뢰성을 위해 각 마이크로서비스에 SLA(Service Level Agreement)를 정의하는 것을 고려해야 한다고 조언했다.

변화관리에 집중하라
기업들이 모톨리식에서 마이크로서비스 아키텍처로 이전해 성과를 거두기 위해서는 변화 관리 및 변화 관리 프로세스를 업데이트해야 한다.

"더욱 빠른 개발 프로세스도 좋지만 변화 관리와 기타 중요한 거버넌스 프로세스를 생략함으로써 마이크로서비스의 이점이 상실되어서는 안 된다."고 IT 채널 영업 시장의 클라우드 서비스 제공 기업 아반트 커뮤니케이션(Avant Communications)의 CCO(Chief Cloud Officer) 론 헤이만이 말했다.

그는 "애자일 개발 라이프사이클에 맞추어 변화 관리와 통제 프로세스를 일치시켜야 한다"라고 말했다.
 

---------------------------------------------------------------
마이크로서비스 인기기사

->"마이크로서비스는 답이 아니었다"··· 세그먼트가 모놀리식으로 돌아온 이유
->마이크로서비스를 위한 서비스 메시 기술 ‘이스티오’가 뜨는 이유
-> 칼럼 | 마이크로서비스가 디지털 미래의 초석인 이유
-> 기고 | 마이크로서비스 아키텍처로 전환하면서 저지르는 3가지 실수
-> 이제는 '마이크로서비스'가 대세··· 이점은? 전제조건은?
->'소프트웨어 개발을 가뿐하게'··· 마이크로서비스 이해하기
---------------------------------------------------------------
ciokr@idg.co.kr