Offcanvas

How To / 개발자 / 데브옵스 / 리더십|조직관리 / 소프트스킬 / 애플리케이션

이제는 '마이크로서비스'가 대세··· 이점은? 전제조건은?

2017.06.22 Adam Bertram  |  CIO


확장성 향상
확장성은 마이크로서비스의 핵심 특징이다. 각 서비스가 별개의 구성 요소이기 때문에, 전체 애플리케이션이 아닌 하나의 기능이나 서비스만 확장할 수 있다. 비즈니스 크리티컬(기업 활동에 아주 중요한) 서비스를 여러 서버에 배포, 다른 서비스의 성능에 영향을 주지 않으면서 가용성과 성능을 높일 수 있다.

태스크마다 적합한 도구를 사용할 수 있는 능력
마이크로서비스는 특정 벤더 한 곳에 얽매일 필요가 없도록 도와준다. 태스크마다 적합한 도구를 사용할 수 있는 유연성이 확보된다. 서비스마다 언어와 프레임워크, 부수 서비스가 다르지만, 애플리케이션의 다른 서비스와 커뮤니케이션을 할 수 있다.

더 빠른 시장화(TTM)
마이크로서비스는 느슨하게 연결된 서비스로 구성되어 있기 때문에, 특정 기능을 추가하거나 수정하기 위해 전체 코드베이스를 다시 쓸 필요가 없다. 특정 서비스만 변경할 수 있다. 즉 독립적으로 테스트 및 배포가 가능하게 애플리케이션을 개발하는 방식이기 때문에 애플리케이션이나 서비스의 시장화를 앞당길 수 있다.

더 쉬운 디버깅 및 유지관리
마이크로서비스는 디버깅과 애플리케이션 테스트를 손쉽게 만들어 준다. 더 작은 모듈을 지속적으로 전달하고 테스트하는 프로세스이기 때문에, 오류가 없는 애플리케이션을 전달하는 역량을 크게 개선할 수 있다.

ROI 향상 및 TCO 경감
마이크로서비스로 리소스를 최적화 할 수 있다. 마이크로서비스의 경우, 여러 팀이 각 서비스를 개발해 배포 시간을 앞당길 수 있다. 또 필요한 경우 '방향 전환'도 더 용이하다. 개발 시간을 줄이고, 팀이 개발한 코드를 더 많이 재사용할 수 있다. 서비스를 분리하기 때문에, 비싼 머신에서 운용을 할 필요가 없다. 단순한 x86 머신이면 충분하다. 마이크로서비스는 효율성을 높여 인프라 비용을 줄이고, 다운타임을 최소화 한다.

지속적인 전달
전담팀이 UI와 데이터베이스, 서버 측면의 논리, 기술 계층 등 분리된 업무를 담당하는 획일적인 애플리케이션과 달리, 마이크로서비스는 CFT(Cross Functional Team)가 지속적인 전달 모델을 사용, 애플리케이션의 전체 수명 주기를 담당해 처리한다. 개발자와 운영 및 테스트 담당자가 동시에 하나의 서비스를 처리하기 때문에 테스트 및 디버깅이 쉽고, 속도가 빠르다. 이런 '증분적인' 개발 방식을 통해 지속적으로 코드를 개발, 테스트, 배포할 수 있다. 또 기존 라이브러리의 코드를 사용할 수 있다.

전제조건이 있다!
마이크로서비스를 받아들인 기업과 기관, 조직들이 큰 혜택을 누리고 있다. 이런 '팩트'를 무시한다면 뒤쳐질 가능성이 크다. 그렇지만 유념할 점이 있다. 마이크로서비스에 '장래성'이 있기는 하지만, 이 아키텍처를 활용할 수 없는 조직들도 있다. 이를 관리할 수 있는 역량을 갖춰야 한다. 다음은 주의 사항을 정리한 내용이다.

신속한 프로비저닝과 배포 역량이 필요
증분형 개발(incremental development)과 지속적 전달(continuous delivery)이 특징인 마이크로서비스는 '긴장을 늦추는 것'을 허용하지 않는다. 직원들은 마이크로서비스 대부분을 구현하는데 필요한 속도에 맞춰 빠르게 리소스를 프로비저닝 할 수 있어야 한다. 서버 프로비저닝에 며칠 또는 몇 달이 소요될 경우 큰 문제에 직면하게 될 것이다. 유사하게 새 서비스나 애플리케이션을 신속하게 배포할 수 있어야 한다.

확실한 모니터링
서비스마다 언어와 플랫폼, API가 다르고, 동시에 마이크로서비스 프로젝트의 여러 구성 요소에 대한 작업을 하는 여러 팀을 조율해야 한다. 따라서 전체 인프라를 효과적으로 모니터링 및 관리하기 위한 확실한 모니터링이 필요하다. 서비스 실패나 머신 중지 시간을 모를 경우, 발생한 문제를 추적할 수 없기 때문이다.

데브옵스(Devops) 문화를 수용
CFT를 가동하기 위해서는 데브옵스 프랙티스와 문화를 도입해 활용해야 한다. 기존 방식의 경우, 개발자는 기능과 기능성에만 초점을 맞추고, 운영 팀은 생산 환경에서의 도전과제 해결을 담당했다. 데브옵스는 모든 사람들이 서비스 프로비저닝(그리고 실패)을 책임지는 방식이다.

복잡하고 까다로운 테스트
마이크로서비스의 테스트는 직관적이지 않다. 각 서비스에 직접, 또는 간접 종속 요소가 존재한다. 기능을 추가하면 새로운 종속 요소가 만들어진다. 이 모두를 빨리 추적하는 것이 불가능해진다. 여기에 서비스의 수가 증가하면서 복잡성이 증가한다. 데이터베이스 오류, 네트워크 레이턴시(지연), 캐싱 문제, 서비스 가용성 문제(중단) 등, 마이크로서비스 아키텍처는 문제를 타당한 수준에서 효과적으로 관리할 수 있어야 한다. 따라서 회복 탄력성 테스트와 결함 제거(Fault Injection)가 '필수'이다.

실패(문제)를 염두에 둔 디자인
실패에 대비한 디자인(설계)가 반드시 필요하다. 시스템 다운타임, 서비스 속도 지연, 예기치 않은 응답 등 여러 실패(문제)를 처리할 준비를 해야 한다. 이와 관련해 로드 밸런싱이 중요한 역할을 한다. 그러나 '플랜 B'도 갖고 있으면 좋다. 실패(문제)가 발생한 경우에도, 전체 시스템에 대한 '크래시' 없이 해당 서비스를 강등된(낮은) 기능성으로 실행시킬 수 있어야 한다.

* Adam Bertram는 데브옵스에 초점을 두고 있는 자동화 엔지니어다. ciokr@idg.co.kr 

CIO Korea 뉴스레터 및 IT 트랜드 보고서 무료 구독하기
추천 테크라이브러리

회사명:한국IDG 제호: CIO Korea 주소 : 서울시 중구 세종대로 23, 4층 우)04512
등록번호 : 서울 아01641 등록발행일자 : 2011년 05월 27일

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

Copyright © 2024 International Data Group. All rights reserved.