개발자 / 애플리케이션 / 클라우드

이벤트 기반 마이크로서비스를 구축할 때 알아야 하는 9가지

Adam Bellemare | InfoWorld 2023.04.28
많은 기업이 성장하다 보면 한때 잘 사용했던 모놀리식 애플리케이션이 오히려 걸림돌이 되는 시점에 이르게 된다. 기존 아키텍처로 지원할 수 없는 새로운 기능이나 더 유연한 데이터 저장 및 액세스 수단이 필요해지기 때문이다. 팀의 성장, 서로 충돌하는 성능 요구사항, 그리고 새로운 경쟁 기술도 단일 모놀리식 코드베이스에서 문제가 될 수 있다. 이벤트 기반 마이크로서비스 아키텍처는 이런 과제를 해결하는 데 도움이 된다.
 
ⓒ Getty Images Bank

마이크로서비스는 해결하고자 하는 비즈니스 문제에 따라 맞춤 구성할 수 있는 작은 전용 서비스로, 앱을 분할해 모놀리식 앱의 한계를 극복한다. 마이크로서비스는 각자 적절한 프로그래밍 언어와 프레임워크, 데이터베이스를 선택할 수 있는 자유를 제공한다. 자체적인 필요에 따라 데이터를 리모델링하고 관리 및 저장할 수 있으며, 비즈니스 문제를 해결하는 최선의 방법을 통제할 수 있게 해준다.

이벤트 기반 마이크로서비스 아키텍처에서 시스템은 이벤트를 생산하고 소비하는 방식으로 커뮤니케이션한다. 이런 이벤트 기반 서비스는 입력 이벤트 스트림(가령 아파치 카프카 주제)의 이벤트를 소비하고 특정 비즈니스 로직을 적용해 자체 출력 이벤트를 생성하고 요청-응답 액세스를 위한 데이터를 제공하고 서드파티 API와 통신하거나 기타 필요한 작업을 수행한다.

여기서는 이벤트 기반 마이크로서비스를 구축할 때 알아야 하는 사항을 정리했다. 


이벤트 기반 마이크로서비스가 적합한 경우

이벤트 기반 마이크로서비스 아키텍처를 고려 중이라면, 첫 번째 해야 할 일은 정말 필요한 것인지 확인하는 것이다. 많은 기술 의사 결정이 그렇듯이 장단점이 있기 때문이다. 모놀리식 앱은 일반적으로 데이터 저장소와 긴밀하게 결합되며, 다른 내부 기능에 빠른 데이터 액세스를 제공한다. 그러나 모놀리식 앱은 내부 데이터 모델에 따라 이런 데이터를 제공하므로 성능과 액세스도 기반 기술에 따라 좌우된다. 예를 들어, 키-값 저장소는 관계형 데이터베이스에 맞지 않고, 느슨하게 구조화된 문서를 저장하기 위한 대체재로도 좋지 않다.

이벤트 기반 마이크로서비스를 사용하면 효과를 볼 수 있다는 가장 일반적인 신호는 현재 데이터 대량 내보내기 API를 작성하거나 사용하고 있는 경우다. 마찬가지로 한 데이터베이스에서 데이터를 가져와 다른 데이터베이스로 넣기 위한 정기적인 폴링 작업을 작성하는 경우도 해당된다. 이는 임시 데이터 통신 계층의 예다. 이 데이터와 관련된 모놀리스의 비즈니스 기능이 실제로 필요하지는 않지만, 자체적으로 새로운 비즈니스 기능을 작성하기 위해 데이터는 필요하다.

과거에는 온라인 분석 처리(OLAP)를 위해 온라인 트랜잭션 처리(OLTP) 시스템에서 데이터를 추출할 때 이런 패턴을 흔히 볼 수 있었다. 그러나 데이터, 성능 요구사항, 비즈니스 수요가 폭발적으로 증가하면서 일반적인 비즈니스 데이터만으로 기능을 수행하는 모든 운영 시스템에 일반적으로 이런 추출 및 로딩 패턴이 사용되고 있다. 이벤트 기반 마이크로서비스는 첨부 전용 불변성 이벤트 로그 형태로 과거 데이터와 새로운 데이터에 액세스하는 수단을 제공한다.

이벤트 기반 마이크로서비스는 여러 부서와 팀에 동일한 데이터 모음에 대한 액세스를 일관적으로 제공해야 하는 경우에도 효과적이다. 예를 들어, 판매 데이터가 이벤트 스트림으로 패키징되면 분석팀은 이를 구독하기만 하면 팀이 사용하는 판매 데이터가 주문 처리팀에서 사용하는 데이터와 동일하다는 것을 확신할 수 있다. 이벤트 스트림은 데이터 통신 계층을 위한 기반을 제공해서 점 대 점, 임시, 전용 연결의 복잡함을 없애고 이를 하나의 스트림 모음으로 대체해 손쉽게 소비할 수 있도록 한다.


최신 클라우드 서비스를 활용하라

기업이 만드는 각각의 새로운 서비스에는(마이크로서비스든 아니든) 배포 파이프라인, 컨테이너 관리, 모니터링, 확장 서비스가 필요하다. 수십 개의 마이크로서비스에는 하나의 모놀리식 서비스보다 더 많은 오버헤드와 관리가 필요하다. 이런 오버헤드를 보통 “마이크로서비스 세금”이라고 표현한다. 운영을 간소화, 자동화하면 비용을 줄일 수 있지만, 예전에는 이를 달성하기 위해서는 상당한 투자가 필요했다.

지금은 관리형 클라우드 서비스에 의존해 마이크로서비스 세금을 줄일 수 있다. 도커화된 서비스를 쿠버네티스에 배포하고 관리, 모니터링, 확장하는 것은 오늘날 매우 일상적이고 쉬운 일이다. 마찬가지로 컨플루언트 클라우드(Confluent Cloud) 같은 클라우드 서비스를 통해 카프카 주제를 만들고 관리하기도 매우 쉽다.

“관리형”과 “완전 관리형” 서비스의 차이에 주의해야 한다. 완전 관리형 서비스를 선택하면 실제 비즈니스 운영에 전념하면서 모든 유지보수, 모니터링, 확장, 보안 요구사항은 서비스 제공업체에 아웃소싱할 수 있다. 클라우드 서비스를 활용하면 사전 마이크로서비스 세금 없이 마이크로서비스로 프로토타입을 만들고 실험할 수 있다. 사용해 보고 가장 유용한 부분과 기술을 채택하면 된다.


작게 시작하고 기존 시스템에서 확장하라

마이크로서비스 아키텍처로의 전환은 뜯어내고 대체하는 형태가 돼서는 안 된다. 실제 비즈니스 요구를 충족하는 구체적인 사용례를 파악하는 것부터 시작하라. 예를 들어, 새로운 문서 기반 검색 기능을 가동하기 위해 한 데이터베이스에 있는 관계형 테이블 4개의 데이터를 소싱 및 리모델링해야 할 수 있다. 스트리밍되지 않는 기존 데이터 소스를 이벤트 기반 아키텍처로 통합하려면 어떻게 해야 할까?

카프카 커넥트(Kafka Connect)는 데이터베이스 테이블을 자체 이벤트 스트림으로 부트스트랩하는 좋은 방법이다. 다양한 온프레미스 및 클라우드 데이터베이스에 연결하고 과거 데이터의 스냅샷을 생성하고 데이터를 필터링하며, 열을 마스킹하는 외에도 많은 일을 할 수 있다. 소스 데이터베이스는 카프카 커넥트와는 독립적으로 유지되므로 기존 시스템에 영향을 미치지 않으면서 중요한 비즈니스 데이터를 점증적으로 소싱할 수 있다.

기존 모놀리식 애플리케이션을 필요한 기간만큼 유지하면서 점증적으로 마이크로서비스를 구축할 수 있다. 양자택일의 문제가 아니라, 필요한 추가적인 데이터와 기능을 비즈니스에 맞는 속도로 노출하는 것이다.


요구사항에 맞는 마이크로서비스를 구축하라

비슷한 문제에는 대체로 비슷한 데이터가 필요하므로 마이크로서비스를 설계할 때는 구체적이고 밀접하게 관련된 비즈니스 문제를 해결하도록 설계해야 한다. 마이크로서비스를 비즈니스 문제에 맞춘다는 것은 비즈니스가 변경되지 않는 한 마이크로서비스를 변경해야 할 필요가 거의 없다는 의미다. 예를 들어, 전자상거래 비즈니스는 결제 처리용, 재고 관리용, 배송용으로 각각 하나씩 마이크로서비스를 둘 수 있다. 배송 워크플로우에 변화가 생기면 배송 마이크로서비스만 영향을 받는다.

마이크로서비스 경계를 비즈니스 사용례에 맞추면 기능이 한 서비스에 캡슐화되므로 의도하지 않거나 우발적인 변경의 위험이 줄어든다. 더 복잡한 사용례에서는 비즈니스 워크플로우가 여러 마이크로서비스에 걸치는 경우도 드물지 않다. 다만 원자적 작업은 일관성을 위해 한 서비스 내에 유지되어야 한다.


마이크로서비스의 수는 적게 유지하라

마이크로서비스의 크기가 작을 필요는 없다. 사실 마이크로서비스는 비즈니스 문제의 하위 집합을 위한 전용 서비스라고 생각하는 편이 도움이 된다. 많은 사람이 빠지는 함정 중 하나는 모든 단일 기능마다 마이크로서비스를 구축해서 결국 수백, 또는 수천 개의 서비스가 난립하게 되는 것이다. 이벤트 기반 마이크로서비스 아키텍처의 목적은 최대한 많은 서비스를 만드는 것이 아니라, 당면한 작업에 적절한 툴을 사용한 전용 솔루션을 구현하는 데 있다.

비즈니스 기능을 추가할 때는 먼저 기존 서비스에 적절히 통합할 수 있는지를 확인하라. 기능 추가가 기존 서비스에 대한 타당한 확장이라면 불필요할 수 있는 새로운 서비스를 구축하는 것보다 나은 선택이다. 예를 들어, 확장된 재고 관리 기능이라면 비슷한 또 다른 마이크로서비스가 아니라 재고 관리 마이크로서비스 안에 포함되는 기능으로 구현하는 것이 좋다.

모든 것을 처음부터 마이크로서비스로 만들 필요는 없다. 모듈형 모놀리스 프레임워크를 사용해서 솔루션 프로토타입을 제작하는 것도 합리적인 방법이다. 이렇게 하면 API 경계가 확고하고 관심사 분리(separation of concerns, SoC)가 가능하다. 전체 프로토타입 모놀리스를 하나의 대형 마이크로서비스로 취급하면서 이벤트 스트림에서 읽고 필요에 따라 쓸 수 있다. 비즈니스 사용례가 강화되고 더 명확해지면 일부 모듈을 필요에 따라 자체 마이크로서비스로 분할할 수 있다. 필요할 때만 새 마이크로서비스를 도입하되, 특히 처음 시작할 때는 적을수록 좋다는 것을 유념해야 한다.


카탈로그를 사용하라

마이크로서비스와 이벤트 스트림이 늘어나면 사용량과 메타데이터를 관리하고 검색하고 추적할 방법이 필요하게 된다. 카탈로그는 크게 다음 2가지 기능을 제공한다.
 
  • 이벤트 스트림의 소유자가 누구인지, 어느 데이터를 포함하는지, 어느 스키마와 구조를 사용하는지 확인
  • 이미 존재하는 마이크로서비스는 무엇인지, 누가 소유하는지, 어느 이벤트 스트림과 API를 담당하는지 확인

처음 시작할 때는 공유 스프레드시트와 같은 간단한 방법으로 메타데이터를 카탈로그화할 수 있지만, 비즈니스가 성장하면 전용 메타데이터 서비스로 전환해야 한다. 오픈소스로는 아파치 아틀라스(Atlas)가 많이 사용되지만, 현재 사용 중인 클라우드 서비스 제공업체에서 솔루션을 찾아보는 것이 더 쉽다. 컨플루언트 클라우드의 스트림 카탈로그(Stream Catalog)가 대표적이다.


승인된 툴박스를 만들어라

이벤트 기반 마이크로서비스의 장점 중 하나는 다양한 프로그래밍 언어, 프레임워크, 데이터베이스 및 툴을 포함해 기술에 대한 선택의 폭을 넓혀준다는 점이다. 혁신과 접근성 측면에서는 좋지만 개발자가 너무 많은 기술, 특히 잘 알려지지 않았거나 당장 유행하는 기술을 사용하는 경우 문제가 될 수 있다.

이런 문제를 해결하려면 주요 이해관계자와의 합의를 통해 지원할 기술 툴박스를 결정해야 한다. 과도하게 제한적이면 안 되지만 불필요한 툴과 기술까지 지원하는 것은 바람직하지 않다. 비용과 복잡성, 관리 오버헤드가 증가하기 때문이다. 툴박스에는 애플리케이션 템플릿, 코드 생성기, 이벤트 생성기, 테스트 프레임워크, 모니터링 프레임워크 및 프로그래밍 언어 등이 포함된다.

개발자가 툴박스를 벗어나 작업하려고 한다면 ‘다른 방법으로는 불가능한 비즈니스 기능을 달성하기 위한 목적’과 같은 타당한 이유가 있는지 확인해야 한다. 이 경우 툴박스를 확장해서 새 옵션을 포함하기 위한 사례 연구로 삼을 수 있다. 새로 추가되는 모든 것에는 지원이 필요하므로 신중해야 한다.

일반적으로는 기업에 필요한 마이크로서비스를 개발자가 최대한 쉽게 구축하고 유지할 수 있도록 하는 것에 목표를 둬야 한다. 서비스의 골격이 포함된 깃허브 저장소를 생성하고 테스트 프레임워크를 구축하는 등의 빠른 시작 기능을 만들 수도 있다.


전체 통합과 단위 테스트를 활용하라

이벤트 기반 마이크로서비스는 전체 통합 및 단위 테스트와 잘 맞는다. 이벤트 기반 마이크로서비스의 주 입력 형태인 이벤트는 폭넓은 입력과 코너 케이스를 다룰 수 있도록 손쉽게 구성할 수 있다. 이벤트 스키마는 테스트해야 하는 값의 범위를 제한하고 입력 테스트 스트림을 구성하는 데 필요한 구조를 제공한다.

일반적으로 특정 이벤트가 있는 입력을 로드하는 방법으로 마이크로서비스에 대한 “블랙박스 테스트”를 하고 그 결과를 볼 수 있다. 카프카 이벤트의 경우 카프카에는 자바 기반 인메모리 테스트 브로커가 내장돼 있는데, 이 브로커를 시작하면 프로그래밍 방식으로 이벤트를 생성하고 결과를 평가할 수 있다.

컨테이너 기반 마이크로서비스 통합 테스트는 컨테이너화된 자체 병렬 카프카 인스턴스를 가동하거나 간단히 클라우드 클러스터에 연결하는 식으로 할 수 있다. 이벤트를 생산해서 소비한 다음 마지막에 모두 추려낸다.

단위 테스트의 경우 마이크로서비스도 다른 대부분 애플리케이션 아키텍처와 비슷하다. 단위 테스트를 사용해 모든 기능을 테스트해서 출력이 예상된 출력과 일치하는지 확인한다. 단위 테스트는 애플리케이션이 배포되는 즉시 제대로 작동하도록 하고 의도하지 않은 사고로부터 애플리케이션을 보호하는 데 있어 중요하다.


이벤트 스트림은 다양한 요구를 충족해야 한다

이벤트 기반 통신이 새로운 것은 아니지만, 대부분의 현대 기업에서 요구사항이 변했다. 데이터 집합이 훨씬 더 커졌기 때문에 단일 모놀리스는 현대 기업의 복잡하고 다양한 요구사항을 처리하기에는 부족하다. 이벤트 기반 마이크로서비스는 현재의 요구사항을 충족하기 위한 강력하고 유연한 방법을 제공한다. 이벤트 스트림은 데이터 통신의 기반을 형성해 다른 서비스에서 적절히 소비하고 사용할 수 있는 신뢰할 수 있는 공급원을 제공한다.

마이크로서비스는 비즈니스 문제 해결에 적절한 툴을 사용할 수 있는 유연성과 선택권을 제공한다. 오늘날의 최신 클라우드 서비스를 활용하면 플랫폼 작업 시간을 줄이고 문제 해결에 훨씬 더 많은 시간을 투자할 수 있다. 이 가이드가 놀라울 만큼 강력하고 유연한 모델을 처음 다루는 데 필요한 기본 지식을 제공했기를 바란다.
editor@itworld.co.kr

회사명 : 한국IDG | 제호: ITWorld | 주소 : 서울시 중구 세종대로 23, 4층 우)04512
| 등록번호 : 서울 아00743 등록발행일자 : 2009년 01월 19일

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

Copyright © 2024 International Data Group. All rights reserved.