2011년 그 개념이 처음 만들어진 마이크로서비스(Microservice)는 이내 미래지향적 애플리케이션 개발 기업과 조직 사이에서 반향을
그렇다면 마이크로서비스 아키텍처란 정확히 무엇일까? 내가 속한 조직의 문화, 스킬, 필요 사항에 부합할까? 애플리케이션 개발 프로젝트에 마이크로서비스를 고려해야 하는 7가지 이유, 성공하기 위해 필요한 5가지 전제조건을 알아봤다.
마이크로서비스의 이점
서비스 지향형 아키텍처(SOA)의 변종인 마이크로서비스는, 애플리케이션들을 느슨하게 연결된 서비스들로 해체할 수 있는 아키텍처를 의미한다. 세분화 된 서비스와 가벼운 프로토콜이 특징인 마이크로서비스는 높은 모듈성을 제공하고, 애플리케이션을 더 쉽게 개발, 테스트, 배포, (더 중요하게)변경 및 유지관리 할 수 있다.
십중팔구 현재 몸담고 있는 기업과 기관, 조직에는 전체 애플리케이션을 획일적 시대에 개발된 애플리케이션들이 많을 것이다. 하나의 코드베이스 위에 구현하기 위해 중앙화된 다계층 아키텍처를 사용했던 애플리케이션들 말이다.
이런 클라이언트-서비스 모델은 데스크톱이 IT를 지배했던 시절에는 탁월한 선택이었다. 그러나 모바일 장치와 클라우드가 증가 또는 부상하면서, 다양한 장치에서 상시 백엔드 데이터를 사용할 수 있도록 만들어야 한다. 그런데 획일적인 아키텍처는 여기에 도움을 주지 않는다. 변경을 할 때마다 전체 애플리케이션을 업데이트해야 하기 때문이다.
또 기능을 추가하거나 새롭게 조정을 하려 시도할 때마다 새로운 버그가 발생할 가능성이 있다. 더 큰 단점은 모든 것이 하나의 코드베이스에 묶여 있기 때문에 특정 기능이나 서비스를 확장할 수 없다는 것이다. 무조건 전체 애플리케이션을 확장해야 하는데, 이는 많은 비용을 발생시킨다.
그런데 마이크로서비스는 코드를 별개 프로세스를 실행하는 독립적인 서비스로 세분화 시킨다. 서로 통신하는 독립 서비스를 조율하면서 특정 서비스의 아웃풋을 다른 서비스의 인풋으로 사용한다.
마이크로서비스는 애플리케이션이 지원할 장치들을 정확히 알기 어려운 경우에 특히 유용하다. 장치나 플랫폼을 가리지 않는 마이크로서비스는 기업이 웹과 모바일, IoT, 웨어러블, 피트니스 트래커 등 여러 환경과 플랫폼에 일관된 사용자 경험을 제공하는 애플리케이션을 개발할 수 있도록 해준다. 현재 넷플릭스(Netflix), 페이팔(PayPal), 아마존(Amazon), 이베이(eBay), 트위터(Twitter) 등 많은 엔터프라이즈가 마이크로서비스를 사용하고 있다.
예를 들어, 월마트 캐나다(Walmart Canada)는 2012년 소프트웨어 아키텍처를 마이크로서비스로 리팩토링(refactor) 했다. 분당 600만 페이지뷰를 처리할 방법이 없었기 때문이었다. 마이크로서비스 도입한 결과 즉시 전환율이 급증하는 성과를 일궈냈다. 여기에 더해 다운타임을 최소화 시켰고, 비싼 대량 상용 하드웨어를 저렴한 가상 x86 서버로 교체해서 20~50%의 비용을 절감할 수 있었다.
월마트나 아마존 규모의 조직이 아닌 경우에도, 마이크로서비스가 전달하는 가치로부터 혜택을 누릴 수 있다. 다음은 마이크로서비스로 전환했을 때 누릴 수 있는 혜택 일부를 정리한 내용이다.
‘회복 탄력성’ 강화
마이크로서비스는 전체 애플리케이션을 별개로 기능하는 서비스로 분산화 및 세분화 시킨다. 코드의 문제점 하나가 여러 서비스나 기능에 영향을 주는 획일적인 아키텍처와 다르게 영향을 최소화 할 수 있다. 유지관리를 위해 몇몇 시스템을 정지시키는 경우에도 사용자 경험 손상이 최소화될 수 있다.
확장성 향상
확장성은 마이크로서비스의 핵심 특징이다. 각 서비스가 별개의 구성 요소이기 때문에, 전체 애플리케이션이 아닌 하나의 기능이나 서비스만 확장할 수 있다. 비즈니스 크리티컬(기업 활동에 아주 중요한) 서비스를 여러 서버에 배포, 다른 서비스의 성능에 영향을 주지 않으면서 가용성과 성능을 높일 수 있다.
태스크마다 적합한 도구를 사용할 수 있는 능력
마이크로서비스는 특정 벤더 한 곳에 얽매일 필요가 없도록 도와준다. 태스크마다 적합한 도구를 사용할 수 있는 유연성이 확보된다. 서비스마다 언어와 프레임워크, 부수 서비스가 다르지만, 애플리케이션의 다른 서비스와 커뮤니케이션을 할 수 있다.
더 빠른 시장화(TTM)
마이크로서비스는 느슨하게 연결된 서비스로 구성되어 있기 때문에, 특정 기능을 추가하거나 수정하기 위해 전체 코드베이스를 다시 쓸 필요가 없다. 특정 서비스만 변경할 수 있다. 즉 독립적으로 테스트 및 배포가 가능하게 애플리케이션을 개발하는 방식이기 때문에 애플리케이션이나 서비스의 시장화를 앞당길 수 있다.
더 쉬운 디버깅 및 유지관리
마이크로서비스는 디버깅과 애플리케이션 테스트를 손쉽게 만들어 준다. 더 작은 모듈을 지속적으로 전달하고 테스트하는 프로세스이기 때문에, 오류가 없는 애플리케이션을 전달하는 역량을 크게 개선할 수 있다.
ROI 향상 및 TCO 경감
마이크로서비스로 리소스를 최적화 할 수 있다. 마이크로서비스의 경우, 여러 팀이 각 서비스를 개발해 배포 시간을 앞당길 수 있다. 또 필요한 경우 ‘방향 전환’도 더 용이하다. 개발 시간을 줄이고, 팀이 개발한 코드를 더 많이 재사용할 수 있다. 서비스를 분리하기 때문에, 비싼 머신에서 운용을 할 필요가 없다. 단순한 x86 머신이면 충분하다. 마이크로서비스는 효율성을 높여 인프라 비용을 줄이고, 다운타임을 최소화 한다.
지속적인 전달
전담팀이 UI와 데이터베이스, 서버 측면의 논리, 기술 계층 등 분리된 업무를 담당하는 획일적인 애플리케이션과 달리, 마이크로서비스는 CFT(Cross Functional Team)가 지속적인 전달 모델을 사용, 애플리케이션의 전체 수명 주기를 담당해 처리한다. 개발자와 운영 및 테스트 담당자가 동시에 하나의 서비스를 처리하기 때문에 테스트 및 디버깅이 쉽고, 속도가 빠르다. 이런 ‘증분적인’ 개발 방식을 통해 지속적으로 코드를 개발, 테스트, 배포할 수 있다. 또 기존 라이브러리의 코드를 사용할 수 있다.
전제조건이 있다!
마이크로서비스를 받아들인 기업과 기관, 조직들이 큰 혜택을 누리고 있다. 이런 ‘팩트’를 무시한다면 뒤쳐질 가능성이 크다. 그렇지만 유념할 점이 있다. 마이크로서비스에 ‘장래성’이 있기는 하지만, 이 아키텍처를 활용할 수 없는 조직들도 있다. 이를 관리할 수 있는 역량을 갖춰야 한다. 다음은 주의 사항을 정리한 내용이다.
신속한 프로비저닝과 배포 역량이 필요
증분형 개발(incremental development)과 지속적 전달(continuous delivery)이 특징인 마이크로서비스는 ‘긴장을 늦추는 것’을 허용하지 않는다. 직원들은 마이크로서비스 대부분을 구현하는데 필요한 속도에 맞춰 빠르게 리소스를 프로비저닝 할 수 있어야 한다. 서버 프로비저닝에 며칠 또는 몇 달이 소요될 경우 큰 문제에 직면하게 될 것이다. 유사하게 새 서비스나 애플리케이션을 신속하게 배포할 수 있어야 한다.
확실한 모니터링
서비스마다 언어와 플랫폼, API가 다르고, 동시에 마이크로서비스 프로젝트의 여러 구성 요소에 대한 작업을 하는 여러 팀을 조율해야 한다. 따라서 전체 인프라를 효과적으로 모니터링 및 관리하기 위한 확실한 모니터링이 필요하다. 서비스 실패나 머신 중지 시간을 모를 경우, 발생한 문제를 추적할 수 없기 때문이다.
데브옵스(Devops) 문화를 수용
CFT를 가동하기 위해서는 데브옵스 프랙티스와 문화를 도입해 활용해야 한다. 기존 방식의 경우, 개발자는 기능과 기능성에만 초점을 맞추고, 운영 팀은 생산 환경에서의 도전과제 해결을 담당했다. 데브옵스는 모든 사람들이 서비스 프로비저닝(그리고 실패)을 책임지는 방식이다.
복잡하고 까다로운 테스트
마이크로서비스의 테스트는 직관적이지 않다. 각 서비스에 직접, 또는 간접 종속 요소가 존재한다. 기능을 추가하면 새로운 종속 요소가 만들어진다. 이 모두를 빨리 추적하는 것이 불가능해진다. 여기에 서비스의 수가 증가하면서 복잡성이 증가한다. 데이터베이스 오류, 네트워크 레이턴시(지연), 캐싱 문제, 서비스 가용성 문제(중단) 등, 마이크로서비스 아키텍처는 문제를 타당한 수준에서 효과적으로 관리할 수 있어야 한다. 따라서 회복 탄력성 테스트와 결함 제거(Fault Injection)가 ‘필수’이다.
실패(문제)를 염두에 둔 디자인
실패에 대비한 디자인(설계)가 반드시 필요하다. 시스템 다운타임, 서비스 속도 지연, 예기치 않은 응답 등 여러 실패(문제)를 처리할 준비를 해야 한다. 이와 관련해 로드 밸런싱이 중요한 역할을 한다. 그러나 ‘플랜 B’도 갖고 있으면 좋다. 실패(문제)가 발생한 경우에도, 전체 시스템에 대한 ‘크래시’ 없이 해당 서비스를 강등된(낮은) 기능성으로 실행시킬 수 있어야 한다.
* Adam Bertram는 데브옵스에 초점을 두고 있는 자동화 엔지니어다.
dl-ciokorea@foundryco.com
