이벤트 기반 마이크로서비스: 진화적 개발 달성

애플리케이션 성장을 위한 솔루션

모든 소프트웨어는 단일 아이디어에서 시작하여 소프트웨어 확장이 필요한 아이디어를 기반으로 합니다. 이 게시물은 이벤트 기반 마이크로서비스를 사용하여 애플리케이션을 가장 잘 성장시키는 방법을 설명하고 각 결정의 장점을 설명합니다.

하드웨어 확장

애플리케이션의 소프트웨어가 성장함에 따라 결국 서버가 제공할 수 있는 한계에 도달하게 됩니다. 하드웨어가 애플리케이션과 함께 확장되는 방식에 대한 결정이 필요합니다. 2가지 솔루션이 있습니다.

수직적 확장 —더 큰 단일 서버로 더 많은 성능을 제공합니다.
수평적 확장 — 애플리케이션이 분산되어 있는 여러 대의 소규모 서버.

수평적 확장의 장점

비용 절감 — 많은 소형 서버가 대형 서버 1대보다 저렴합니다.
안정성 — 다른 곳의 스파이크는 로컬 서버에 영향을 미치지 않습니다.
무한한 확장성 — 수직형은 당신이 찾을 수 있는 가장 큰 서버의 상한선을 가지고 있고 수평형은 더 많은 서버를 추가할 수 있습니다.

수평 크기 조정은 일반적으로 선호되는 방법입니다.

응용 프로그램을 분할하는 방법

여러 서버를 사용하기로 결정한 다음 해당 서버에서 애플리케이션을 분할하는 것에 대해 생각해야 합니다. 어떻게 해야 할까요?

옵션 1: 모듈식 모놀리스라고도 하는 미니 서비스:

이는 종속 모듈식 서비스 모음으로 정의되며 , 이는 서비스가 서로 종속됨을 의미합니다. 한 서비스에 문제가 있으면 전체 시스템에 문제가 있는 것입니다.

이 옵션은 전체 기업의 범위를 포함하므로 소프트웨어를 확장하기 어렵고 업데이트는 시스템의 여러 부분에 영향을 미치며 개발자가 이해하고 테스트하기 어렵게 만듭니다. 이 옵션은 일반적으로 함수가 실행 전에 첫 번째 함수가 완료될 때까지 기다려야 함을 의미하는 동기 통신을 사용합니다. 그러나 이 옵션도 실행하기 쉽고 복잡성이 낮습니다. 이것은 분산 아키텍처입니다.

옵션 2: 마이크로서비스:

Martin Fowler 는 마이크로 서비스를 "독립적으로 배포 가능한 서비스 모음" 으로 정의합니다 . 즉, 독립적으로 확장 가능하여 비용과 리소스를 절약할 수 있고, 서비스에 국한된 오류 격리 기능이 있으며, 공급업체 종속성을 방지하는 기술에 구애받지 않습니다.

이 옵션은 단일 비즈니스 도메인의 범위를 가지며 느슨한 결합을 제공하고 각 서비스에는 확고한 모듈 경계가 있습니다. 이러한 경계로 인해 특정 팀이 각 서비스를 소유하고 관리하는 것이 매우 쉬워집니다. 이 옵션은 일반적으로 기능이 동시에 실행될 수 있음을 의미하는 비동기 통신을 사용합니다. 이 옵션은 더 많은 서비스를 쉽게 추가하고 더 큰 민첩성을 허용하는 혁신적인 디자인을 채택합니다. 이것은 통합 아키텍처입니다.

이미지 제공: Gartner

마이크로서비스는 얼마나 커야 합니까?

마이크로서비스를 결정한 후에는 인지부하 측면에서 마이크로서비스의 크기와 크기에 대해 생각해야 합니다.

"인지 부하: 작업 기억에서 사용되는 정신적 노력의 총량". — 존 스웰러

Daniel Terhorst-North 는 마이크로서비스가 "머리에 맞는 소프트웨어"의 크기여야 하며 Team Topologies 의 가르침 에 따라 "소프트웨어 서비스의 크기를 팀이 처리할 수 있는 인지 부하로 제한해야 합니다"라고 말했습니다. 이것은 실수, 소유권 및 이해하기 쉬운 코드가 적다는 것을 의미합니다.

무엇을 나눌 것인가

제품에서 이음새를 찾아야 합니다. 그들은 비즈니스 관점에서 자연스럽게 어디에 속합니까? 도메인 주도 설계 사용 — 소프트웨어 코드의 구조와 언어가 비즈니스 도메인과 일치해야 한다는 개념.

Conway의 법칙을 고려하여 팀이 서비스를 소유해야 하는 소프트웨어 경계에 대한 팀 우선 접근 방식이 필요합니다.

"조직은 커뮤니케이션 구조의 복사본인 애플리케이션 디자인을 생성하도록 제한되어 있습니다." - Conway의 법칙

대신 '역 Conway의 법칙'을 사용하십시오. 팀과 조직 구조를 발전시켜 원하는 아키텍처를 홍보하십시오. 이상적으로는 기술 아키텍처가 비즈니스 아키텍처와 동형을 나타낼 것입니다.

서비스 통합 방법

이제 애플리케이션을 서비스로 분할했으므로 이러한 서비스가 통신할 수 있도록 이러한 서비스를 함께 통합해야 합니다. 서비스를 통합하는 4가지 일반적인 방법이 있습니다.

파일 전송 — 파일에 데이터를 기록한 다음 다른 서비스로 보내 읽기.
공유 데이터베이스 — 모든 서비스가 데이터를 저장하고 액세스하는 하나의 데이터베이스입니다.
RMI(원격 프로시저 호출)/RPC(원격 프로시저 호출) — 다른 서비스의 함수에 데이터를 보내고 출력을 수신합니다.
메시징 — 데이터를 메시지 버스로 보내면 메시지 버스가 해당 데이터를 다른 서비스로 비동기식으로 전달하는 책임을 집니다.

enterpriseintegrationpatterns.com의 이미지

메시징 사용의 장점

비동기식 안정적인 전달 - 메시지를 보내고 동시에 다른 서비스로 보내는 메시지 버스를 신뢰할 수 있습니다.
보내기 및 잊어버리기 — 소스 서비스는 메시지 버스에 메시지를 보내는 책임만 지며 잊어버릴 수 있습니다.
범용 연결 — 메시지 버스는 다양한 서비스와의 연결이 내장되어 있으며 쉽게 통합되어야 합니다.
오버로딩 없음 — 수신기가 요청을 소비하는 속도를 제어하므로 서비스 오버로딩이 없습니다.
Disconnected Operation — 다른 것에 의존하지 않고 클라이언트는 여전히 메시지 버스에 액세스할 수 있습니다.
이벤트 소싱 사용 가능 — 애플리케이션 상태에 대한 모든 변경 사항은 이벤트 시퀀스로 저장됩니다.

통합 문제

서비스 통합에는 3가지 주요 문제가 있습니다.

네트워크는 신뢰할 수 없고 느립니다.
두 응용 프로그램은 다릅니다.
변화는 불가피합니다 — 애플리케이션은 시간이 지남에 따라 변경됩니다.

우리는 다음과 같은 이유로 메시징을 선택합니다.

파일 전송보다 즉각적이며 공유 데이터베이스보다 캡슐화되고 원격 프로시저 호출보다 안정적입니다.

이벤트 기반 아키텍처란 무엇입니까?

AWS는 이벤트 기반 아키텍처를 "분리된 서비스 간에 트리거하고 통신하기 위해 이벤트를 사용하는 것"으로 정의합니다. 우리는 마이크로서비스가 이벤트를 생성하고 이를 메시지 버스로 보낸 다음 이를 다른 분리된 마이크로서비스로 보내 어떤 작업을 트리거함으로써 이를 달성합니다.

이벤트 기반 아키텍처와 다른 아키텍처의 뚜렷한 차이점은 이벤트가 관찰 가능하고 지시되지 않는다는 것입니다. 이를 통해 명확한 경계를 가질 수 있으며 다른 서비스에 대한 지식 없이 여러 기능을 한 번에 실행할 수 있습니다.

AWS의 이미지 — James Beswick

이벤트 기반 아키텍처에는 4가지 구성 요소가 있습니다.

이벤트 프로듀서
이벤트 버스
이벤트 라우터
이벤트 소비자

이벤트 생성자는 이벤트 버스로 전송되는 이벤트를 생성합니다. 그런 다음 이벤트 라우터는 이벤트를 적절한 이벤트 소비자에게 보냅니다.

AWS에서는 Amazons EventBridge 서비스를 사용하여 이를 다시 생성할 수 있습니다. 이벤트 생성자를 이벤트 소스, 이벤트 소비자를 대상, 이벤트 라우터를 규칙이라고 하며 이벤트 소스에서 이벤트 패턴을 트리거한 다음 대상으로 라우팅하도록 규칙을 구성합니다.

진화적 개발

궁극적으로 우리는 내일 레거시 코드를 오늘 작성하고 있으므로 진화적으로 만들자!

위의 단계는 진화적 개발을 달성하도록 설정했으며 Strangler 패턴 을 사용하여 이벤트 라우터를 사용하여 데이터를 새 서비스 및 이전 서비스로 전송함으로써 레거시를 위협하지 않고 소프트웨어를 발전시킬 수 있습니다.

스트랭글러 패턴 은 단계적 접근 방식으로 기존 기능을 새로운 애플리케이션 및 서비스로 교체하여 레거시 시스템을 점진적으로 마이그레이션하는 방법입니다. — N Natesan

저는 고압에서 설계 및 구축된 많은 시스템과 함께 작업했으며 모든 승인 기준을 충족하지만 다음에 일어날 일에 대해서는 거의 생각하지 않습니다. 사람들은 마치 비즈니스가 정상으로 돌아가야 하는 유동적인 상태에 있는 것처럼 프로젝트가 완료되고 요구 사항 목록의 끝이라는 생각에 더 편안합니다. 성공적인 소프트웨어를 개발하려면 항상 변화하는 환경의 이점을 실현하기 위해 항상 선회하면서 변화하는 표준 상태에 더 익숙해져야 합니다. 훨씬 적은 노력으로 이러한 방식으로 기술에서 더 많은 가치를 얻을 수 있으므로 진화적 아키텍처가 필요합니다. 이를 통해 레거시를 위협하지 않고 독립적으로 빠르게 아이디어를 구축할 수 있으므로 고객에게 최상의 아이디어를 제공하고 이점을 더 빨리 실현할 수 있습니다.

출처 : https://itnext.io/event-driven-microservices-achieving-evolutionary-development-278c18caf6a3