2019.02.14

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

Bob Violino | 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자 소프트웨어의 취약성을 식별하여 해결해야 한다. 보안 유지에 필수적이다. 총체적으로 어떻게 작동하며 잠재적인 문제 영역이 어디인지 파악하기 위해 소프트웨어 생태계에 대한 전체론적인 접근방식을 취하는 것이 중요하다"라고 말했다.




2019.02.14

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

Bob Violino | 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자 소프트웨어의 취약성을 식별하여 해결해야 한다. 보안 유지에 필수적이다. 총체적으로 어떻게 작동하며 잠재적인 문제 영역이 어디인지 파악하기 위해 소프트웨어 생태계에 대한 전체론적인 접근방식을 취하는 것이 중요하다"라고 말했다.


X