마이크로서비스

마이크로서비스란?

마이크로서비스는 애플리케이션 구축을 위한 아키텍처 기반의 접근 방식입니다. 마이크로서비스를 전통적인 모놀리식(monolithic) 접근 방식과 구별 짓는 기준은 애플리케이션을 핵심 기능으로 세분화하는 방식입니다. 각 기능을 서비스라고 부르며, 독립적으로 구축하고 배포할 수 있습니다. 이는 개별 서비스가 다른 서비스에 부정적 영향을 주지 않으면서 작동(또는 장애가 발생)할 수 있음을 의미합니다.

가장 최근 온라인 구매 사이트에 방문했던 때를 떠올려 보세요. 제품을 검색하기 위해 사이트에 있는 검색창을 사용했을 것입니다. 이러한 검색이 하나의 서비스가 됩니다. 또한 구매자 선호도 데이터베이스에서 추출한 관련 상품에 대한 추천 내역을 볼 수 있습니다. 그것 역시 하나의 서비스입니다. 온라인 장바구니에 항목을 추가하셨나요? 마찬가지로, 그것 또한 하나의 서비스입니다.

이렇듯 마이크로서비스란 애플리케이션의 핵심 기능이며 다른 서비스들과 독립적으로 작동합니다. 마이크로서비스 아키텍처는 애플리케이션의 핵심 기능을 느슨한 구조의 서비스 단위로 결합한 것이 아니라 불가피한 장애, 확장성, 신규 기능 통합에 대비할 수 있도록 개발팀 및 서비스 간 커뮤니케이션 구조를 조정하는 것입니다.

이를 실현하는 방법은 무엇일까요? 서비스 지향 아키텍처(SOA)의 기본 사항을 채택하여 마이크로서비스를 배포하는 것입니다.


어디서 많이 들어 본 내용 같으신가요?

애플리케이션을 핵심 기능으로 세분화하고 모놀리식 방식과는 다른 내용들이 익숙하게 들리신다면, 그 이유는 마이크로서비스의 아키텍처 기반 스타일이 소프트웨어 설계 방식으로 이미 확고히 자리잡은 SOA에서의 개념과 유사하기 때문입니다.

애플리케이션 개발 초기에는 기존 애플리케이션에 최소한의 변경 사항이 있어도 자체적인 QA(Quality Assurance) 주기에 따라 대규모 업데이트를 해야 했습니다. 전체 애플리케이션의 소스 코드는 하나의 배포 유닛(.war 또는 .ear 등)으로 내장되기 때문에 이런 방식을 종종 "모놀리식"이라고 부릅니다. 일부 애플리케이션의 업데이트로 인해 오류가 발생할 경우, 전체를 오프라인으로 전환하고 운영 규모를 축소시킨 다음 문제를 해결해야 했습니다. 이러한 방식은 소규모 애플리케이션에서 여전히 실행 가능하지만, 성장하는 기업들은 다운타임을 감당할 수 없습니다.

서비스 지향 아키텍처는 애플리케이션을 별개의 재사용 가능한 서비스 단위로 분할하며 이 서비스들은 엔터프라이즈 서비스 버스(ESB)를 통해 통신합니다. 이러한 아키텍처에서는 특정 비즈니스 프로세스를 기반으로 구성된 개별 서비스가 통신 프로토콜(SOAP, ActiveMQ, Apache Thrift 등)을 준수하며 ESB를 통해 공유됩니다. 즉 이러한 서비스 요소가 ESB를 통해 통합되어 하나의 애플리케이션을 구성하는 것입니다.

이러한 방식에서는 서비스의 구축, 테스트, 수정을 동시에 수행할 수 있기 때문에 더 이상의 모놀리식 개발 주기는 필요가 없습니다. 뱐면 ESB는 전체 시스템의 단일 장애점(single point of failure)을 나타내기 때문에 이러한 방식에서 모놀리식 제거는 새로운 모놀리식을 만들어낼 뿐이며, 잠재적으로 ESB가 전체 조직의 자체적인 장애 요소로 작용할 수 있는 것입니다.


그렇다면 SOA와 마이크로서비스의 차이점은 무엇일까요?

마이크로서비스는 스테이트리스(stateless) 방식으로 서로 통신을 할 수 있으므로 이러한 방식으로 구축된 애플리케이션은 내결함성이 더 높고 단일 ESB에 대한 의존성은 더 낮습니다. 또한 마이크로서비스가 프로그래밍 언어에 구속 받지 않는 애플리케이션 프로그래밍 인터페이스(API)이기 때문에 개발팀이 자체 툴을 선택할 수도 있습니다.

SOA의 본질적 기능을 감안하면 마이크로서비스는 완전히 새로운 개념은 아닙니다. 마이크로서비스는 컨테이너화 기술의 발달에 힘입어 유용성이 향상되었습니다. 이제는 Linux 컨테이너를 활용해 애플리케이션의 여러 조각들을 독립적으로 작동시킬 수 있으며, 각 개별 요소 및 라이프사이클에 대한 통제력은 훨씬 강화되었습니다.

어떤 새로운 아키텍처든 가장 어려운 부분은 처음 시작 단계입니다. 새로운 애플리케이션을 만들고 싶으신가요? 아니면 오래된 애플리케이션을 혁신하고 싶으신가요? 어느 쪽을 선택하든 마이크로서비스 구축의 장점과 과제를 생각해 보셔야 할 것입니다.


마이크로서비스 아키텍처의 장점은 무엇일까요?

마이크로서비스는 분산형 개발을 통해 팀의 역량과 일상적인 업무 능력을 향상시킵니다. 또한, 동시에 여러 마이크로서비스를 개발하는 것도 가능합니다. 다시 말해, 동일한 애플리케이션 개발에 더 많은 개발자들이 동시 참여할 수 있으므로 개발에 소요되는 시간을 단축할 수 있습니다.

출시 기간 단축

개발 주기가 단축되기 때문에 마이크로서비스 아키텍처는 보다 민첩한 배포 및 업데이트를 지원합니다.

높은 확장성

특정 서비스에 대한 수요가 증가함에 따라 필요에 따라 여러 서버 및 인프라에 배포할 수 있습니다.

뛰어난 복구 능력

이러한 독립적인 서비스들은 제대로 구축되기만 한다면 서로에게 영향을 주지 않습니다. 즉, 모놀리식 애플리케이션 모델과는 달리 한 부분에 장애가 발생하더라도 전체 애플리케이션이 다운되지 않습니다.

손쉬운 배포

마이크로서비스 기반 애플리케이션은 전통적인 모놀리식 애플리케이션에 비해 더욱 모듈화되고 규모가 작아졌기 때문에 배포에 따르는 우려 사항들이 사라졌습니다. 이를 위해서는 더 많은 협업이 필요하지만, 그 결과는 몇 배로 나타날 수 있습니다.

편리한 액세스

하나의 큰 애플리케이션을 더 작은 조각으로 분할했기 때문에, 개발자들이 각 조각을 파악하고 업데이트하며 개선하기가 용이해졌습니다. 이로 인해 애자일 방식과 결합할 경우 개발 주기를 더욱 가속화할 수 있습니다.

향상된 개방성

다중 언어 지원(Polyglot) API를 사용하기 때문에 개발자들은 필요한 기능에 맞는 최적의 언어와 기술을 자유롭게 선택할 수 있습니다.


당면 과제

귀사에서 마이크로서비스 아키텍처로의 전환을 고려 중이라면 애플리케이션뿐만 아니라 직원들의 업무 방식의 변화도 고려해야 합니다. 조직적, 문화적 변화를 과제의 일부분으로 인식하는 이유는 각 팀마다 자체적인 배포 주기가 있으며 고유한 고객군에 대한 고유한 서비스를 제공하기 때문입니다. 이러한 점은 일반적으로 개발자들이 우려하는 사항은 아닐지 모르지만 성공적인 마이크로서비스 아키텍처에는 반드시 필요한 사항입니다.

문화와 프로세스 이외에도 복잡성과 효율성은 마이크로서비스 기반 아키텍처의 두 가지 주요 과제입니다. Red Hat Mobile의 플랫폼 아키텍트인 John Frizelle는 2017년 Red Hat Summit에서 8가지 과제 범주를 제시했습니다:

  1. 구축: 서비스 간 종속성을 파악하는데 시간을 투입해야 합니다. 이러한 종속성 때문에 하나의 빌드를 완료하면 여러 다른 빌드가 트리거될 수 있음을 인지해야 합니다. 또한 마이크로서비스가 귀사의 데이터에 미치는 영향을 고려해야 합니다.
  2. 테스트: 통합 테스트뿐만 아니라 엔드-투-엔드 테스트를 수행하기가 그 어느 때보다 어렵고 중요해질 수 있습니다. 서비스가 서로 지원하도록 하기 위해 아키텍처를 어떻게 구성했는지에 따라, 아키텍처의 한 부분에 장애가 발생하면 떨어져 있는 다른 부분에 장애를 일으킬 수 있다는 점을 유의해야 합니다.
  3. 버전 관리: 새로운 버전으로 업데이트할 때는 이전 버전과의 호환성에 문제가 발생할 수 있다는 점을 염두에 두어야 합니다. 이 부분을 해결하기 위해 조건부 로직을 구축할 수도 있지만, 그렇게 하면 다루기 힘들고 관리가 복잡해질 수 있습니다. 그 대안으로 서로 다른 클라이언트용으로 여러 라이브 버전을 사용할 수도 있지만, 이 경우 유지 관리가 더 복잡해질 수 있습니다.
  4. 배포: 초기 구축 단계에서는 이 부분도 과제 범주에 들어갑니다. 배포를 쉽게 하려면 우선 상당한 정도의 자동화에 투자해야 합니다. 마이크로서비스의 복잡성 때문에 사람이 수동으로 배포하는 것이 버거워지기 때문입니다. 서비스 롤 아웃을 어떻게, 어떤 순서로 할지 고민해 보시기 바랍니다.
  5. 로그 관리: 분산 시스템에서는 모든 내용을 한 곳에 모을 수 있는 중앙집중식 로그가 필요합니다. 그렇지 않으면 확장 시에 이를 관리하기가 불가능해집니다.
  6. 모니터링: 문제의 근원을 정확히 집어내려면 시스템을 중앙에서 파악할 수 있는 능력이 무엇보다 중요합니다.
  7. 디버그: 원격 디버그는 선택 사항이 아닙니다. 그 방식으로는 수십, 수백 개의 서비스를 관리할 수 없기 때문입니다. 안타깝게도 현재로서는 디버그 방법에 대한 정답이 없습니다.
  8. 연결성: 중앙집중식 또는 통합형 여부에 관계 없이 서비스 검색을 고려해야 합니다.

마이크로서비스의 더 큰 가능성을 살펴보세요