마이크로서비스, 어떤 조직에 가장 성공적일까

Pivotal | Pivotal 2018.11.30
ⓒPivotal

마이크로서비스는 독립 부서에서 단일 용도의 서비스를 지속적으로 전달하는 것을 최우선으로 하는 아키텍처 접근 방식을 의미한다. 마이크로서비스 모델은 자주 배포되지 않으며 하나의 단위로서 규모가 정해져 긴밀하게 통합되는 기존의 모놀리식 소프트웨어의 대척점에 있다. 모놀리식 접근 방식이 잘 맞는 앱이나 조직도 일부 있지만, 더욱 강화된 민첩성과 확장성이 필요한 기업에서는 마이크로서비스에 주목하는 추세다.
 
 ⓒPivotal


왜 마이크로서비스인가?

더 적극적인 고객 요구 대응

마이크로서비스 아키텍처를 도입한 기업은 고객이 원할 때 고정된 릴리즈 일정에 발목잡히지 않고 신속하게 중요 기능을 배포할 수 있다.
 

더욱 우수한 소프트웨어 팀 처리량

마이크로서비스는 애자일(Agile)과 데브옵스(DevOps) 원칙을 지원하며, 소프트웨어 부서가 특정 기능을 작업하는 동시에 병렬 실행이 가능하도록 돕는다.
 

개선된 시스템 확장성과 신뢰성

성공적인 마이크로서비스 아키텍처에는 중단이 없다. 반복 가능한 자동화 시스템 의존도가 높아 세심하게 조정된 서비스를 지원하며, 개별 구성 요소가 제 기능을 다하지 못하는 상태에서도 시스템이 계속 실행될 수 있도록 설계된 패턴을 사용한다.
 

마이크로서비스 아키텍처를 고려할 때 확인할 점

마이크로서비스가 모든 조직이나 애플리케이션에 적합한 것은 아니며, 적절히 구현되지 않으면 높은 비용 부담으로 이어질 수 있다. 마이크로서비스를 도입하기 전에 아래 사항들을 고려하는 것이 좋다.
 

조직이 준비되어 있는가?

마이크로서비스 전환은 전사적 전환만큼이나 기술적 전환이기도 하다. 팀은 자동화 중심의 지속적인 전달 접근 방식을 받아들여 소프트웨어를 구축할 준비가 되어 있어야 한다. 귀사는 기능형 사일로를 제거할 준비가 되어 있으며 서비스를 구축하고 운영할 자급자족형 팀이 있는가? 귀사의 변경 관리 프로세스는 직원의 개입없는 배포 파이프라인을 견딜 수 있는가?
 

개발자가 열성적인가?

모든 애플리케이션이 마이크로서비스 처리를 보장하지는 않는다. ‘마이크로서비스를 무조건적으로 미는’ 분위기가 만연한 요즘에는 더더욱, 개발자라면 굳이 변경하라는 비즈니스적 요구가 없는 기존 애플리케이션에 대해서도 상당한 시간을 들여 코드를 작성해야 할지 모른다. 느리게 변화하는 애플리케이션이나 중대한 업무 기능을 수행하는 애플리케이션인 경우 모놀리식 상태를 유지하는 것이 나을 수도 있다. 마이크로서비스는 복잡성을 추가하는 대신 민첩성을 높인다. 새로 계약을 맺기 전에 기존의 구성이 더 필요한 것은 아닌지 확인하자.
 

우리 회사의 서비스는 조화롭게 구성되어 있는가?

마이크로서비스는 상호 간에 느슨하게 연결되어 있는데다 지속적으로 변경된다. 현행 서비스 URL이나 탄력적인 서비스 인스턴스 루트 트래픽을 어떻게 찾고 있는가? 서비스는 어떻게 데이터를 교환하는가? 대부분의 경우 서비스 검색, 부하 분산, 메시징을 처리하기 위해 현재 구현되어 있는 기술은 마이크로서비스가 도입하는 역동성에는 참담할 정도로 부적합하다.
 

복잡한 환경에서의 2일차 관리는 어떠한가?

관리 대상 항목의 수가 늘어나면 운영 위험도 늘어난다. 수백, 수천대의 서버에 그만큼의 마이크로서비스를 생성할 경우 새로운 접근 방식을 취하지 않는다면 관리가 복잡해질 것이 틀림 없다. 기본 장비의 패치나 업그레이드는 어떻게 진행하는는가? 종속성을 추적하고 위험 애플리케이션을 식별할 수 있는가? 최신 애플리케이션 구성이 적용된 마이크로서비스 인스턴스를 최신 상태로 유지하는 문제는 어떻게 되나? 마이크로서비스 플랫폼 빌드에 사용되는 구성 요소와 서비스를 실행할 대상은 향후 수년 동안 조직의 민첩성에 크나큰 영향을 미칠 것이다.
 
ⓒPivotal


마이크로서비스 Vs. 기존의 아키텍처 핵심 비교

단일 목표 집중식 Vs. 광범위한 목표 범위

마이크로서비스는 하나에만 집중하고, 그 하나를 잘 해낸다. 마이크로서비스는 문제가 되는 특정 도메인을 대상으로 하고 데이터를 비롯해 관련 경험이 들어 있는 모든 것을 보유한다. 마이크로서비스라는 용어에서 ‘마이크로’는 크기가 아니라 범위를 의미한다. 반면 기존의 아키텍처에서 단단하게 통합된 소프트웨어 패키지의 솔루션들은 동시에 많은 비즈니스 문제들을 해결하여 한다.
 

느슨한 결합 Vs. 단단한 결합

마이크로서비스 아키텍처는 가능하면 서비스 자급자족화와 다른 서비스에 대한 하드 코딩 참조를 회피할 것을 요구한다. 기존 아키텍처의 시스템은 보통 주의깊게 구성된 단계별 절차를 따르지 않으면 배포 불가능한 독립적 구성 요소가 거미줄처럼 엉켜있는 상태이다. 
 

지속적 전달 Vs. 정해진 일정에 따른 전달

마이크로서비스는 요구가 지속적으로 변화하는 앱을 다루는 팀에 적합하다. 최대한 신속하게 시장에 가치를 전달하기 위해 마이크로서비스는 자동화 과정을 거쳐 정기적으로 프로덕션에 전달된다. 

반면, 기존 아키텍처는 정해진 일정에 따라 애플리케이션을 개발하고 업데이트한다. 대체로 분기나 연간 주기에 따라 진행된다. 
 

고유한 서비스 수명 주기를 가진 독립 팀 보유 Vs. 다수의 팀에서 서비스 수명 주기 보유

마이크로서비스 변환은 팀 구조뿐 아니라 기술에도 적용된다. 마이크로서비스는 독립적인 팀에 의해 빌드, 전달, 실행된다. 모든 서비스에 필요한 것은 아니지만 비즈니스 중심 서비스에 특히 강력한 모델이다. 기존의 아키텍처에서 프로젝트 팀은 소프트웨어의 최초 버전 구축을 담당하고 다음 프로젝트를 위해 해체된다. 소프트웨어 관리는 운영팀으로 이관된다. 
 

크기와 무관한 분산형 시스템을 강조하는 디자인 패턴 및 기술 보유 Vs. 프로세스를 우선 적용하는 디자인 패턴 및 기술 보유

기존의 아키텍처는 프로덕션에 대한 핵심 개발 단계, QA, 제품 릴리즈에 집중된 사일로형 도구와 프로세스가 모놀리식 소프트웨어를 생산한다. 이러한 모놀리식 소프트웨어를 제작한 것과 동일한 접근 방식과 도구로는 마이크로서비스를 빌드하고 실행할 수 없다. 마이크로서비스 아키텍처는 서비스 검색, 메시징, 네트워크 라우팅, 오류 감지, 로깅, 스토리지, 정체성 등의 성능에 따라 달라진다. 

회사명 : 한국IDG | 제호: ITWorld | 주소 : 서울시 중구 세종대로 23, 4층 우)04512
| 등록번호 : 서울 아00743 등록발행일자 : 2009년 01월 19일

발행인 : 박형미 | 편집인 : 박재곤 | 청소년보호책임자 : 한정규
| 사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2024 International Data Group. All rights reserved.