<div id="readability-page-1" class="page"><div>
  <main>
    <ul>
<li>
<p>이전장을 통해서 내부적으로 애플리케이션의 핵심은 메시지 처리기가 되었는데, 이러한 구성에 따라서 메시지 처리기가 외부로도 메시지를 처리하도록 변경해보겠다.</p>
</li>
<li>
<p>애플리케이션은 외부에서 들어오는 이벤트를 외부 메시지 버스를 통해서 받고 (레디스 발행 / 구독 대기열을 예제로 사용한다) 출력을 이벤트 형태로 외부 메시지 버스에 발행한다.</p>
</li>
</ul>
<h3 id="분산된-진흙공-명사로-생각하기">분산된 진흙공, 명사로 생각하기</h3>
<hr>
<ul>
<li>마이크로서비스 아키텍처를 구축하는 엔지니어와 정기적으로 이야기를 할 때 기존 애플리케이션을 마이그레이션 하는 경우가 자주 있는데, 마이그레이션을 할 때 엔지니어들이 본능적으로 하는 첫 번째 일을 시스템을 명사로 나누는 것이다.</li>
</ul>
<h3 id="분산-시스템에서-오류-처리하기">분산 시스템에서 오류 처리하기</h3>
<hr>
<ul>
<li>
<p>‘모든 것은 망가진다’는 소프트웨어 엔지니어링에서 일반적인 규칙이다. 어떤 요청이 실패하면 시스템에 어떤 일이 생길까?</p>
</li>
<li>
<p>두 가지를 함께 바꿔야 하는 경우를 서로 결합됐다고 말한다. 앞 단락에서 본 연쇄적인 실패를 시간적 결합이라고 부른다.</p>
</li>
<li>
<p>시스템의 모든 부분이 동시에 제대로 작동할 때만 정상적으로 작동하는 경우를 시간적 결합이라고 한다. 시스템이 커지면 시스템 부품 중 일부의 성능이 나빠질 확률이 지수적으로 높아진다.</p>
</li>
</ul>
<h3 id="대안--비동기-메시징을-사용한-시간적-결합">대안 : 비동기 메시징을 사용한 시간적 결합</h3>
<hr>
<ul>
<li>
<p>어떻게 하면 적절한 결합을 얻을수 있을까? 이미 해답의 일부, 즉 명사가 아니라 동사로 생각해야 한다는 점에서 살펴봤다.</p>
</li>
<li>
<p>도메인 모델은 비즈니스 프로세스를 모델링하기 위함이다. 도메인 모델은 어떤 물건에 대한 정적인 데이터 모델이 아닌 동사에 대한 모델이다.</p>
</li>
<li>
<p>따라서 주문에 대한 시스템과 배치에 대한 시스템을 생각하는 대신에 주문 행위에 대한 시스템과 할당 행위에 대한 시스템등을 생각한다.</p>
</li>
<li>
<p>이런 방식으로 사물을 구분하면 어떤 시스템이 어떤일을 하는지에 대해서 생각하기가 쉽다. 주문 행위에 대해 생각해보면 우리가 정말 원한느 일은 주문을 넣었을 떄 주문이 들어가는 것이다. 다른 모든 일은 언젠가 발생한다는 것만 보장할 수 있다면 나중에 발생할 수 있다.</p>
</li>
<li>
<p>애그리게이트와 비슷하게 마이크로서비스도 일관성 경계여야 한다. 두 서비스 사이에는 최종 일관성을 받아들일 수 있고, 이는 동기화된 호출에 의존하지 않아도 된다는 뜻이다.</p>
</li>
<li>
<p>각 서비스는 외부 세계에서 커맨드를 받고 결과를 저장하기 위해 이벤트를 발생시킨다. 이런 이벤트를 리슨하는 다른 서비스는 워크 플로우의 다른 단계를 촉발한다.</p>
</li>
<li>
<p>분산 진흙공 안티 패턴을 방지하기 위해 시간적으로 결합된 HTTP API를 호출하는 대신에 비동기 메시지로 시스템을 통합한다.</p>
</li>
</ul>
<h4 id="이러한-구조가-더-좋은-이유">이러한 구조가 더 좋은 이유</h4>
<ul>
<li>
<p>각 부분이 서로 독립적으로 실패할 수 있어서 잘못된 동작이 발생했을 때 처리하기가 더 쉽다. 할당 시스템이 좋지 않은 날이라도 여전히 주문을 받을 수 있다.</p>
</li>
<li>
<p>둘째, 시스템 사이의 결합 강도를 감소시킬 수 있다. 처리 과정을 이루는 연산 순서를 바꾸거나 새로운 단계를 도입하고 싶을 떄 이를 지역적으로 할 수 있다.</p>
</li>
</ul>
<h3 id="레디스-발생--구독-채널을-통합에-사용하기">레디스 발생 / 구독 채널을 통합에 사용하기</h3>
<hr>
<ul>
<li>
<p>이 모든것이 어떻게 구체적으로 작동하는지 살펴보자. 이벤트를 시스템 밖으로 보내고 다른 시스템 안으로 넣는 서비스를 위한 메시지 버스 같은 것이 필요하다. 이런 인프라를 종종 메시지 브로커 라고부른다.</p>
</li>
<li>
<p>메시지 브로커의 역할은 발행자로부터 메시지를 받아서 구독자에게 배달하는 것이다.</p>
</li>
</ul>
<h3 id="레디스는-메시지-버스를-감싸는-다른-얇은-어댑터">레디스는 메시지 버스를 감싸는 다른 얇은 어댑터</h3>
<hr>
<ul>
<li>우리가 사용하는 레디스 발행/구독 리스너 (또는 이벤트 소비자)는 플라스크와 아주 비슷하다. 이벤트 리스너는 외부 세계를 변환해서 이벤트로 만든다.</li>
</ul>
<div><pre tabindex="0"><code data-lang="python3">r <span>=</span> redis<span>.</span>Redis(<span>**</span>config<span>.</span>get_redis_host_and_port())

<span>def</span> <span>main</span>():
    orm<span>.</span>start_mappers()
    pubsub <span>=</span> r<span>.</span>pubsub(ignore_subscribe_messages<span>=</span><span>True</span>)
    pubsub<span>.</span>subscribe(<span>'change_batch_quantity'</span>)

    <span>for</span> m <span>in</span> pubsub<span>.</span>listen():
        handle_change_batch_quantity(m)

<span>def</span> <span>handle_change_batch_quantity</span>(m):
    logging<span>.</span>debug(<span>'handling </span><span>%s</span><span>'</span>, m)
    data <span>=</span> json<span>.</span>loads(m[<span>'data'</span>]) <span># 시스템 진입점에서 해야할 일은 JSON을 역직렬화 하고 역직렬화한 객체를 Command로 변환해서 서비스 계층으로 넘기는 일이다.</span>
    cmd <span>=</span> commands<span>.</span>ChnageBatchQuantity(ref<span>=</span>data[<span>'batchref'</span>], qty<span>=</span>data[<span>'qty'</span>])
    messagebus<span>.</span>handle(cmd, uow<span>=</span>unit_of_work<span>.</span>SqlAlchemyUnitOfWork())

</code></pre></div><ul>
<li>
<p>반대 방향의 변환 (도메인 이벤트를 공개 이벤트로 변환)을 처리하는 다운 스트림 어댑터를 만든다.</p>
</li>
<li>
<p>메시지 발행은 아래 코드와 같이 발행한다.</p>
</li>
</ul>
<pre tabindex="0"><code>r = redis.Redis(**config.get_redis_host_and_port())


def publish(channel, event: events.Event):  # 여기서는 하드 코딩한 채널을 사용하지만, 이벤트 클래스 / 이름과 적절한 채널을 맵핑하는 정보를 저장할 수도 있다. 이렇게 하면 메시지 유형 중 일부에 대해 다른 채널을 사용할 수도 있다.
    logging.debug('publishing: channel=%s, event=%s', channel, event)
    r.publish(channel, json.dumps(asdict(event)))

</code></pre><h3 id="외부로-나가는-새-이벤트">외부로 나가는 새 이벤트</h3>
<hr>
<pre tabindex="0"><code>@dataclass
class Allocated(Event):
    orderid: str
    sku: str
    qty: int
    batchref: str
</code></pre><ul>
<li>이 이벤트는 주문 라인 상세 정보, 어떤 배치에 주문 라인이 할당됐는지 등 할당에 대해 알아야할 필요가 있는 모든 내용을 저장한다.</li>
</ul>
<h3 id="내부-이벤트와-외부-이벤트-비교">내부 이벤트와 외부 이벤트 비교</h3>
<hr>
<ul>
<li>
<p>내부와 외부 이벤트의 구분을 명확히 하면 좋다. 일부 이벤트는 밖에서 들어오지만 일부 이벤트는 승격되면서 외부에 이벤트를 발행할 수 있다.</p>
</li>
<li>
<p>하지만 모든 이벤트가 다 외부에 이벤트를 내보내지는 않는다. 이벤트 소싱을 사용할 경우에는 이런 특징이 특히 중요하다.</p>
</li>
</ul>
<h3 id="정리">정리</h3>
<hr>
<ul>
<li>
<p>이벤트는 외부에서 들어올 수도 내부에서 외부로 발행할 수도 있다. 우리가 만든 <code>publish</code> 핸들러는 이벤트를 레디스 메시지 채널의 메시지로 변환한다.</p>
</li>
<li>
<p>우리는 이벤트를 통해서 외부 세계와 이야기를 하며, 이런 종류의 시간적인 결합을 사용하면 애플리케이션 통합 시 상당한 유연성을 얻을 수 있다.</p>
</li>
<li>
<p>하지만 여러 가지 이벤트 통지에 대해 실행되는 논리적인 흐름이 존재한다면 프로그램 본문에서는 이러한 흐름이 명시적이지 않기 때문에 이러한 흐름을 알아보기 어렵다. 따라서 이벤트 통지를 사용한 시스템의 디버깅이나 변경이 어려워 질 수 있다.</p>
</li>
</ul>
<h3 id="참고-문헌">참고 문헌</h3>
<hr>
<ul>
<li><a href="https://www.aladin.co.kr/shop/wproduct.aspx?ItemId=271944317&amp;start=slayer">파이썬으로 살펴보는 아키텍처 패턴</a></li>
</ul>

    <a href="../../../../"> &gt;&gt; Home</a>
  </main>
</div></div>

Home on 개발자 이동욱

Lee Dong Wook

이전장을 통해서 내부적으로 애플리케이션의 핵심은 메시지 처리기가 되었는데, 이러한 구성에 따라서 메시지 처리기가 외부로도 메시지를 처리하도록 변경해보겠다.
애플리케이션은 외부에서 들어오는 이벤트를 외부 메시지 버스를 통해서 받고 (레디스 발행 / 구독 대기열을 예제로 사용한다) 출력을 이벤트 형태로 외부 메시지 버스에 발행한다.
분산된 진흙공, 명사로 생각하기
마이크로서비스 아키텍처를 구축하는 엔지니어와 정기적으로 이야기를 할 때 기존 애플리케이션을 마이그레이션 하는 경우가 자주 있는데, 마이그레이션을 할 때 엔지니어들이 본능적으로 하는 첫 번째 일을 시스템을 명사로 나누는 것이다.
분산 시스템에서 오류 처리하기
‘모든 것은 망가진다’는 소프트웨어 엔지니어링에서 일반적인 규칙이다. 어떤 요청이 실패하면 시스템에 어떤 일이 생길까?
두 가지를 함께 바꿔야 하는 경우를 서로 결합됐다고 말한다. 앞 단락에서 본 연쇄적인 실패를 시간적 결합이라고 부른다.
시스템의 모든 부분이 동시에 제대로 작동할 때만 정상적으로 작동하는 경우를 시간적 결합이라고 한다. 시스템이 커지면 시스템 부품 중 일부의 성능이 나빠질 확률이 지수적으로 높아진다.
대안 : 비동기 메시징을 사용한 시간적 결합
어떻게 하면 적절한 결합을 얻을수 있을까? 이미 해답의 일부, 즉 명사가 아니라 동사로 생각해야 한다는 점에서 살펴봤다.
도메인 모델은 비즈니스 프로세스를 모델링하기 위함이다. 도메인 모델은 어떤 물건에 대한 정적인 데이터 모델이 아닌 동사에 대한 모델이다.
따라서 주문에 대한 시스템과 배치에 대한 시스템을 생각하는 대신에 주문 행위에 대한 시스템과 할당 행위에 대한 시스템등을 생각한다.
이런 방식으로 사물을 구분하면 어떤 시스템이 어떤일을 하는지에 대해서 생각하기가 쉽다. 주문 행위에 대해 생각해보면 우리가 정말 원한느 일은 주문을 넣었을 떄 주문이 들어가는 것이다. 다른 모든 일은 언젠가 발생한다는 것만 보장할 수 있다면 나중에 발생할 수 있다.
애그리게이트와 비슷하게 마이크로서비스도 일관성 경계여야 한다. 두 서비스 사이에는 최종 일관성을 받아들일 수 있고, 이는 동기화된 호출에 의존하지 않아도 된다는 뜻이다.
각 서비스는 외부 세계에서 커맨드를 받고 결과를 저장하기 위해 이벤트를 발생시킨다. 이런 이벤트를 리슨하는 다른 서비스는 워크 플로우의 다른 단계를 촉발한다.
분산 진흙공 안티 패턴을 방지하기 위해 시간적으로 결합된 HTTP API를 호출하는 대신에 비동기 메시지로 시스템을 통합한다.
이러한 구조가 더 좋은 이유
각 부분이 서로 독립적으로 실패할 수 있어서 잘못된 동작이 발생했을 때 처리하기가 더 쉽다. 할당 시스템이 좋지 않은 날이라도 여전히 주문을 받을 수 있다.
둘째, 시스템 사이의 결합 강도를 감소시킬 수 있다. 처리 과정을 이루는 연산 순서를 바꾸거나 새로운 단계를 도입하고 싶을 떄 이를 지역적으로 할 수 있다.
레디스 발생 / 구독 채널을 통합에 사용하기
이 모든것이 어떻게 구체적으로 작동하는지 살펴보자. 이벤트를 시스템 밖으로 보내고 다른 시스템 안으로 넣는 서비스를 위한 메시지 버스 같은 것이 필요하다. 이런 인프라를 종종 메시지 브로커 라고부른다.
메시지 브로커의 역할은 발행자로부터 메시지를 받아서 구독자에게 배달하는 것이다.
레디스는 메시지 버스를 감싸는 다른 얇은 어댑터
우리가 사용하는 레디스 발행/구독 리스너 (또는 이벤트 소비자)는 플라스크와 아주 비슷하다. 이벤트 리스너는 외부 세계를 변환해서 이벤트로 만든다.
r = redis.Redis(**config.get_redis_host_and_port())
def main():
    orm.start_mappers()
    pubsub = r.pubsub(ignore_subscribe_messages=True)
    pubsub.subscribe('change_batch_quantity')
    for m in pubsub.listen():
        handle_change_batch_quantity(m)
def handle_change_batch_quantity(m):
    logging.debug('handling %s', m)
    data = json.loads(m['data']) # 시스템 진입점에서 해야할 일은 JSON을 역직렬화 하고 역직렬화한 객체를 Command로 변환해서 서비스 계층으로 넘기는 일이다.
    cmd = commands.ChnageBatchQuantity(ref=data['batchref'], qty=data['qty'])
    messagebus.handle(cmd, uow=unit_of_work.SqlAlchemyUnitOfWork())
반대 방향의 변환 (도메인 이벤트를 공개 이벤트로 변환)을 처리하는 다운 스트림 어댑터를 만든다.
메시지 발행은 아래 코드와 같이 발행한다.
r = redis.Redis(**config.get_redis_host_and_port())
def publish(channel, event: events.Event):  # 여기서는 하드 코딩한 채널을 사용하지만, 이벤트 클래스 / 이름과 적절한 채널을 맵핑하는 정보를 저장할 수도 있다. 이렇게 하면 메시지 유형 중 일부에 대해 다른 채널을 사용할 수도 있다.
    logging.debug('publishing: channel=%s, event=%s', channel, event)
    r.publish(channel, json.dumps(asdict(event)))
외부로 나가는 새 이벤트
@dataclass
class Allocated(Event):
    orderid: str
    sku: str
    qty: int
    batchref: str
이 이벤트는 주문 라인 상세 정보, 어떤 배치에 주문 라인이 할당됐는지 등 할당에 대해 알아야할 필요가 있는 모든 내용을 저장한다.
내부 이벤트와 외부 이벤트 비교
내부와 외부 이벤트의 구분을 명확히 하면 좋다. 일부 이벤트는 밖에서 들어오지만 일부 이벤트는 승격되면서 외부에 이벤트를 발행할 수 있다.
하지만 모든 이벤트가 다 외부에 이벤트를 내보내지는 않는다. 이벤트 소싱을 사용할 경우에는 이런 특징이 특히 중요하다.
정리
이벤트는 외부에서 들어올 수도 내부에서 외부로 발행할 수도 있다. 우리가 만든 publish 핸들러는 이벤트를 레디스 메시지 채널의 메시지로 변환한다.
우리는 이벤트를 통해서 외부 세계와 이야기를 하며, 이런 종류의 시간적인 결합을 사용하면 애플리케이션 통합 시 상당한 유연성을 얻을 수 있다.
하지만 여러 가지 이벤트 통지에 대해 실행되는 논리적인 흐름이 존재한다면 프로그램 본문에서는 이러한 흐름이 명시적이지 않기 때문에 이러한 흐름을 알아보기 어렵다. 따라서 이벤트 통지를 사용한 시스템의 디버깅이나 변경이 어려워 질 수 있다.
참고 문헌
파이썬으로 살펴보는 아키텍처 패턴

파이썬으로 살펴보는 아키텍처 패턴 - 10장 (이벤트를 사용한 마이크로서비스 통합)

댓글