Offcanvas

개발자 / 디지털 트랜스포메이션 / 비즈니스|경제 / 애플리케이션

'소프트웨어 개발을 가뿐하게'··· 마이크로서비스 이해하기

2017.12.01 Lucas Carlson  |  InfoWorld


예를 들어, 버그가 발생했다. 어느 마이크로서비스가 문제일까? 마이크로서비스가 상호의존적이라는 부분이 이 문제를 극복하기 어렵게 만들 수 있다. 마이크로서비스는 통상 가벼운 JSON REST API를 통해 서로 통신한다. REST 인터페이스의 경우, 앞선 세대의 XML-RPC 및 SOA 보다 느슨하게 정의하는 경향이 있다. 이 가벼운 API는 더 유연하고, 더 쉽게 확장할 수 있다. 그러나 모니터링이 필요하고, 문제나 버그가 발생할 수도 있는 새로운 인터페이스를 추가시킨다.

큰 덩어리 형태를 의미하는 모놀리식(monolithic) 애플리케이션들의 경우, 코드에 디버깅을 추가하고, 논리적으로 모든 실행 계층을 조사해 문제를 초래하는 부분을 발견할 수 있다. 그러나 느슨하게 정의된 API를 통해 서로 통신하는 수백, 수천의 분리된 마이크로서비스들의 경우 이것이 불가능하다.

그렇지만 주도면밀한 계획을 통해 이런 도전과제를 극복할 수 있다. 도움을 주는 디버깅 도구들도 있다. 단 각자의 상황에 따라 솔루션을 구현해야 할 확률이 높다는 알아야 한다.

마이크로서비스와 콘테이너, PaaS의 관계
마이크로서비스를 사용하기 위해 PaaS나 Linux 콘테이너를 사용해야 한다는 ‘오해’들을 많이 한다. 이는 사실이 아니다. 마이크로서비스 없이 PaaS와 Linux 콘테이너를 사용할 수 있다. 마찬가지로 PaaS나 Linux 콘테이너 없이 마이크로서비스를 사용할 수 있다. 반드시 서로가 필요한 것은 아니다.

하지만 서로를 보완하는 역할을 한다. 헤로쿠(Heroku) 같은 퍼블릭 클라우드, 클라우드 파운드리(Cloud Foundry)나 오픈시프트(OpenShift) 같은 프라이빗 클라우드에 기반을 둔 PaaS 환경은 작게 쪼개진 수 많은 애플리케이션 실행을 최적화시킨다. 330만 C++ 명령줄의 애플리케이션을 PaaS 플랫폼으로 ‘포팅’하는 상황은 상상하기 어렵다.

만약 애플리케이션을 독립적이며, 독립적으로 확장이 되는 작은 ‘비트’ 크기의 애플리케이션으로 분리하려 한다면, 그런데 이 ‘비트’ 크기의 애플리케이션이 PaaS 환경에 적합한 경우가 아주 많다.

마찬가지로 리눅스 콘테이너 또한 모놀리식 애플리케이션보다는 마이크로서비스 같이 작고 상태(state)가 없는 애플리케이션에 더 적합하다.

가상머신과 리눅스 콘테이너의 가장 큰 차이점은 ‘상태(State)’ 개념의 유무이다. 가상머신은 상태를 유지하도록 구성할 수 있다. 반면 리눅스 콘테이너 아키텍처는 본질적으로 기본 이미지로부터 무엇이든 구현한다. 리눅스 콘테이너에 상태 폴더를 마운트할 수 있다. 그러나 변경을 해야 콘테이너 자체가 바뀔 것이다.

마이크로서비스의 수평 ‘스케일링’ 개념은 무공유, 무상태 애플리케이션 개념을 지원한다. 기반이 되는 파일 시스템을 저장하지 않고, 수정하지 않는다. 마이크로서비스를 리눅스 콘테이너와 통합하는 이유가 여기에 있다. 둘다 상태를 보존하지 않기 때문이다.

마이크로서비스와 SOA의 관계
마이크로서비스는 SOA(서비스 지향형 아키텍처) 의 ‘사촌’이다. 그러나 큰 차이점이 있다. 표면적으로 SOA는 SOAP 및 XML-RPC로 연결되고, 마이크로서비스는 JSON으로 연결된다. 그러나 어떻게 보면, 이런 연결 API 형식은 겉보기 차이에 불과하다.

유사하게 SOA는 엔터프라이즈 서비스 버스를 사용하고, 마이크로서비스는 가벼운 Pub-sub 서비스 버스를 사용한다. 기본 개념은 유사하다. 더 가볍다는 차이점이 있다.

마이크로서비스 아키텍처와 SOA의 가장 큰 차이점은 마이크로서비스의 경우 독립적으로 배포할 수 있어야 하지만, SOA 서비스는 모놀리식으로 구현되는 경우가 많다는 것이다.

마이크로서비스는 어떤 상황에 적합할까?
일단 마이크로서비스는 ‘한계’에 도달했을 때의 ‘대응책’이라는 점을 기억하는 것이 중요하다. 기존의 모놀리식 애플리케이션 아키텍처를 더 이상 확장할 수 없는 상황이 도래하곤 한다. 모든 성공한 소프트웨어 프로젝트에서 발생하는 문제이다. 데이터베이스가 감당할 수 없을 정도로 커졌고, 코드가 수백 만 줄에 달한다. 또는 더 이상 빨리, 쉽게 기능을 추가할 수 없다.

아직 이런 한계점에 도달하지 못했다면, 즉 레가시 애플리케이션에 아무런 문제가 없고 큰 변경이 필요 없다면, 마이크로서비스 도입이 큰 혜택을 가져오지 못할 수도 있다.

어떻게 도입하건 마이크로서비스는 개발 프로세스에 문제와 어려움을 초래한다. 이런 새로운 서비스를 계속해 실행하면서 어려움에 직면할 수도 있다. 쿠베르네티스(Kubernetes) 같은 서술적(Declarative) 오케스트레이션 도구를 도입해 일부 조정을 할 수도 있다. 복잡한 마이크로서비스 아키텍처의 경우, 도입될 수 밖에 없는 새로운 소프트웨어 패턴을 다뤄야 하는 문제가 있다.

하지만 마이크로서비스는 과거 SOA만큼 까다롭지 않다. 정말 규모가 작은 소프트웨어 프로젝트로 마이크로서비스를 구현할 수도 있다. 시작부터 기존 코드를 모두 다룰 필요도 없다.

혁신에 뒤쳐져 있고, 감당할 수 없는 아주 큰 애플리케이션이 있다면, 마이크로서비스가 필요하다. 대안으로 시작부터 마이크로서비스 기반의 애플리케이션을 구축하는 방법을 고려하는 것도 현명하다.

이베이는 마이크로서비스 아키텍처를 활용, 대규모로 확장을 할 수 있었고, 코드의 확장성과 유지관리 용이성을 높였다. 그 결과 비즈니스 혁신에 박차를 가했고, 제품 전달 주기를 앞당겼고, 더 나아가 보안까지 강화했다. 구글, 아마존, 트위터, 페이팔, 넷플릭스 또한 유사한 경험을 했다. 이들 회사 가운데 상당수는 마이크로서비스를 더욱 손쉽게 도입할 수 있게 해주는 퍼블릭 도구도 개발했다.

레가시 코드 유지관리에 어려움을 겪고 있고, 혁신 방법을 모르거나, 새로운 형태의 애플리케이션을 도입하고 싶다면, 애플리케이션 개발에 마이크로서비스를 활용하는 것을 검토할 이유가 충분하다.

* Lucas Carlson은 오픈소스 엔지니어이자 저술가, 기업가다. ‘lucascarlson.net’에서 좀더 자세한 정보를 확인할 수 있다. 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.