조용한 개발 노트

Event-driven은 설계보다 운영에서 실패한다Event-driven Architecture는 설계 단계에서는 그럴듯해 보인다.문제는 운영 단계다.이벤트가 늦게 처리된다중복 이벤트가 쌓인다어디서 막혔는지 알 수 없다운영 가능한 Event-driven System은 “잘 돌아간다”가 아니라문제가 생겼을 때, 우리가 통제할 수 있다는 기준으로 평가되어야 한다.1. Event 정의 체크리스트이 이벤트는 요청이 아니라 사실인가아무도 소비하지 않아도 시스템이 괜찮은가이벤트 이름이 과거형으로 표현되는가의도가 아니라 상태 변화를 표현하는가이 질문에 답하지 못하면, 그것은 Event가 아니다.2. Producer 체크리스트Producer가 Consumer의 존재를 모르는가Consumer 처리 성공 여부를 고려하지 ..

Event-driven이 항상 좋은 선택은 아니다Event-driven Architecture는 문제를 해결하는 구조이지, 만능 해법이 아니다.EDA가 실패하는 경우를 보면 기술이 아니라 사용 방식이 문제인 경우가 대부분이다.이 글에서는 Event-driven 시스템을 망가뜨리는 대표적인 안티패턴을 정리한다.안티패턴 1. 이벤트로 RPC 흉내내기가장 흔한 안티패턴은 Event를 비동기 RPC처럼 사용하는 것이다.이 이벤트는 반드시 처리되어야 한다처리 결과를 알고 싶다실패하면 바로 문제다이 기대가 생기는 순간, Event-driven의 핵심 전제가 깨진다.Event에는 응답이 없다응답이 필요하다면, 그것은 Event가 아니라 Command다.안티패턴 2. 이벤트 남용모든 상태 변경을 무작정 이벤트로 만들면..

보이지 않는 시스템은 운영할 수 없다Event-driven Architecture를 도입하면 시스템은 눈에 띄게 느슨해진다.호출 관계가 사라지고비동기 처리로 전환되며즉각적인 응답 경로가 끊어진다이 순간부터 새로운 문제가 등장한다.지금 이 이벤트는 어디까지 처리되었는가Event-driven 시스템에서 Observability는 선택이 아니라 운영의 전제다.왜 기존 모니터링은 충분하지 않은가동기 호출 기반 시스템에서는 다음 정보만으로도 운영이 가능했다.요청 성공 여부응답 시간에러율하지만 Event-driven 시스템에서는 이 정보들이 거의 의미를 잃는다.요청과 처리가 분리된다성공 시점이 명확하지 않다실패가 즉시 드러나지 않는다Observability의 관점이 바뀌어야 한다.Event-driven Observ..

순서는 직관적이지만 위험한 가정이다사람은 자연스럽게 순서를 기대한다.먼저 일어난 일나중에 일어난 일그래서 이벤트를 설계할 때 무의식적으로 이런 가정을 깔게 된다.이 이벤트는 저 이벤트 뒤에 온다하지만 Event-driven 시스템에서 이 가정은 가장 쉽게 깨진다.분산 환경에는 하나의 순서가 없다이벤트 순서가 보장되려면 다음 조건이 필요하다.단일 생성 지점단일 전달 경로단일 소비자Event-driven Architecture는 이 조건을 의도적으로 포기한다.그 결과, 전역적인 순서는 존재하지 않는다.이벤트는 언제든 다른 순서로 도착할 수 있다이벤트 순서가 깨지는 이유는 명확하다.네트워크 지연재시도에 의한 재전송Consumer 처리 속도 차이이 중 어느 하나만 있어도, 이벤트는 발생 순서와 다른 순서로 처리..

Exactly-once는 왜 매력적으로 보이는가Event-driven 시스템을 설계하다 보면 자연스럽게 이런 요구가 등장한다.이 이벤트는 정확히 한 번만 처리되면 좋겠다이 요구는 합리적으로 보인다.중복 처리 걱정이 없다상태 불일치가 사라진다로직이 단순해진다문제는 이 요구가 Event-driven 시스템의 전제와 정면으로 충돌한다는 점이다.Exactly-once가 의미하는 것Exactly-once는 흔히 오해된다.이벤트가 한 번만 전달된다Consumer가 한 번만 실행된다하지만 실제로 의미하는 바는 이것이다.결과가 한 번만 반영된다문제는 이 결과가여러 시스템에 걸쳐 있고여러 저장소에 나뉘어 있으며여러 시점에 반영된다라는 점이다.왜 Exactly-once는 구조적으로 불가능한가Exactly-once가 어려운..

Event-driven 시스템에서 실패는 예외가 아니다Event-driven Architecture를 도입하면 많은 팀이 이렇게 기대한다.이벤트는 빠르게 전달된다처리는 자연스럽게 병렬화된다장애에 강해진다하지만 운영 단계에서 가장 먼저 마주치는 현실은 이것이다.이벤트는 자주 늦고, 가끔 중복되며, 때로는 순서가 깨진다이 현상은 설계 실패가 아니라 Event-driven 시스템의 기본 특성이다.실패 모델을 이해하지 못하면 생기는 일실패 모델을 이해하지 못한 시스템은 다음과 같은 반응을 보인다.중복을 버그로 간주한다순서 깨짐을 예외 처리한다지연을 장애로 오인한다이 순간부터 EDA는 불안정한 시스템이 된다.실패를 제거하려 할수록, 시스템은 더 복잡해진다.실패 모델 1. 이벤트 유실이벤트 유실은 가장 두려워하는 ..

Event-driven은 컴포넌트 간 계약의 문제다Event-driven Architecture를 구성하는 요소는 단순해 보인다.Event를 만드는 쪽Event를 전달하는 쪽Event를 처리하는 쪽하지만 시스템이 복잡해지는 이유는 이 세 요소의 책임 경계가 흐려질 때 발생한다.이 글에서는 각 구성 요소가 무엇을 해야 하고, 무엇을 해서는 안 되는지를 정리한다.Producer의 책임Producer는 Event를 발행하는 주체다.Producer의 핵심 책임은 단 하나다.사실을 정확하게 기록하고 전달한다Producer는 다음을 책임진다.Event가 언제 발생했는지어떤 사실이 발생했는지사실을 왜곡하지 않고 표현했는지Producer는 Event의 의미에만 책임이 있다.Producer가 해서는 안 되는 것Produ..

Event-driven이 실패하는 가장 흔한 이유Event-driven Architecture를 도입했는데도 시스템이 여전히 복잡해지는 경우가 많다.그 원인을 따라가 보면 대부분 한 지점에서 멈춘다.Event, Message, Command를 구분하지 않았다이 세 개념을 섞는 순간, Event-driven 시스템은 동기 호출 시스템의 나쁜 점만 그대로 가져온다.Command는 무엇인가Command는 의도를 담은 요청이다.무엇을 해달라는 요구수신자가 정해져 있다성공 또는 실패를 기대한다Command의 핵심은 이것이다.이 작업을 수행해라즉, Command는 책임과 결과를 강제한다.동기 호출 구조는 대부분 Command 기반이다.Event는 무엇인가Event는 이미 일어난 사실이다.되돌릴 수 없다누가 소비할지..