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

그런데 혁신에는 애질리티(민첩성)와 속도가 요구된다는 점이 문제이다. 밀레니엄 버그를 걱정할 필요가 없었던 신생 기업들이 문제 많은 오래된 레가시 소프트웨어를 보유한 당신 회사를 가뿐히 압도하고 있다. 투자자들은 ‘넥스트 빅 씽’을 요구한다. 고객들이 대량으로 이탈한다.

이를 해결할 방법은 비대한 애플리케이션 덩어리를 없애는 것이다. 그러나 더 이상 새로운 덩어리를 만들어서는 안 된다. 마이크로 서비스 아키텍처를 이용하면 이런 목표를 달성할 수 있다. ‘큰’ 애플리케이션들을 수평으로 확장할 수 있는 ‘가벼운’ 앱으로 분리해주는 기법이다.



마이크로서비스에 대한 정의
마이크로서비스는 여러 기능을 RESTful API로 느슨하게 연동된 별개의 애플리케이션으로 분리한다. 이베이가 2006년 사용자, 아이템, 계정, 피드백, 트랜젝션, 기타 70여 요소들을 처리하는 별개의 Java Servlet 애플리케이션들을 구현한 것을 예로 들 수 있다. 이 각각의 논리 함수 애플리케이션들이 마이크로서비스다.

각 마이크로서비스는 독립돼 있다. 마이크로서비스는 데이터 계층을 공유하지 않는다. 각자의 데이터베이스와 로드 밸런스를 가지고 있다. 이런 ‘분리’가 마이크로서비스 아키텍처의 핵심 요소다. 마이크로서비스마다 각기 다른 스케일링 기법이 필요하다. 예를 들어, 일부 마이크로서비스는 관계형 데이터베이스를, 또 다른 마이크로서비스는 NoSQL 데이터베이스를 사용한다.

마이크로서비스의 이점
마이크로서비스 아키텍처는 내부 아키텍처가 크고 복잡한 큰 덩어리의 애플리케이션들을 작고 독립적이며, 확장이 가능한 애플리케이션들로 분리시킨다. 따라서 쉽게, 그리고 작게 마이크로서비스를 개발, 업데이트, 배포할 수 있다.

그런데 여기에서 의문이 제기된다. 이런 기능들을 처음부터 하나의 애플리케이션으로 구현하면 안 되는 것일까? 이론적으로 별개의 애플리케이션과 데이터 사일로로 구현해도 큰 문제가 없다는 생각이 들지 모르겠다.

예를 들어 살펴보자. 입찰이 2개인 경매가 있는 상황을 가정하자. 그러나 피드백이 있는 매출은 전체의 약 1/4이다. 입찰 서비스가 피드백 애플리케이션보다 8배 이상 분주하다는 의미다. 이를 하나의 애플리케이션으로 통합하면, 필요보다 더 자주, 더 많은 코드를 실행시키고, 업데이트 해야 한다. 여러 기능 그룹을 별개의 애플리케이션들로 분리하는 것이 합리적인 상황인 셈이다.

또 마이크로서비스 아키텍처를 도입하면, PaaS와 Docker, Linux 콘테이너 등과 연동이 가능해지는 등 여러 보이지 않는 이점과 장점이 있다.

애플리케이션을 마이크로서비스로 구현하면 애플리케이션의 유연성과 확장성이 높아진다. 팀 구축 애플리케이션 프로세스의 확장성도 높아진다. 덩어리 코드의 경우, 한 개 팀 전부가 큰 덩어리 코드를 작업해야 한다. 또 구성원이 서로 업무에 관여해야 한다. 코드의 덩어리이 커지면서 개발 속도가 크게 느려진다.

그러나 마이크로서비스 아키텍처의 경우, 분산된 소규모 개발 팀이 각자 독립적으로 마이크로서비스인 앱을 개발, 변경할 수 있다. 그러면 서비스 업그레이드와 기능 추가가 훨씬 더 용이해진다. 소프트웨어와 개발 프로세스가 모두 민첩해지는 것이다.



마이크로서비스의 도전과제
하지만 모든 아키텍처가 ‘강점’과 ‘약점’을 갖고 있기 마련이다. 장점이 확실한 마이크로서비스 아키텍처도 다루기 힘든 고유의 문제점이 있다. 분산되고 느슨하게 연결된 애플리케이션의 로깅, 모니터링, 테스트, 디버깅 문제가 대표적이다.

예를 들어, 버그가 발생했다. 어느 마이크로서비스가 문제일까? 마이크로서비스가 상호의존적이라는 부분이 이 문제를 극복하기 어렵게 만들 수 있다. 마이크로서비스는 통상 가벼운 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’에서 좀더 자세한 정보를 확인할 수 있다.

dl-ciokorea@foundryco.com