lambda 아키텍처 vs kappa 아키텍처

FullStack으로 일 하다가, 팀의 규모가 20여명 정도로 커지는 바람에 FE/BE를 나누게 되면서 작년부터 저는 BE영역에서 일 하고 있습니다.
그러다 보니 데이터 관련한 아키텍처들에 관심이 많아졌고, 어떻게 하면 이해가 쉬운 구조이면서 이슈 없는 데이터 플로우 구조를 만들 수 있을까 고민 하고 있습니다. 그러던 와중에 생소한 용어를 듣게 되어 간단하게 공유하고자 합니다.
Ref.

• https://www.credera.com/insights/modern-data-architecture-an-overview-of-lambda-and-kappa-architectures
• https://www.qlik.com/blog/lambda-or-kappa-the-need-for-a-new-data-processing-architecture

그러던 중에 위와 같은 용어와 글들을 접하게 되었습니다.

lambda architecture

Lambda architecture의 경우 batch processing, realtime stream processing이 결합된 구조입니다.

장점

• 속도, 안정성이 우수하다.
  • 장애시, batch layer로 데이터 재구성 가능
• 확장이 용이하다.

  단점

• 중복 모듈이 많아진다.
• 같은 코드가 batch layer, stream layer에 중복 된다.
• batch, stream에서 재처리를 할 수도 있다.

kappa architecture

Ref. https://hazelcast.com/glossary/kappa-architecture/

Kappa architecture의 경우 realtime stream processing만 이용하는 구조입니다.

장점

• 리소스 절감 (batch layer가 없음)
• 데이터 생성 / 처리하는 부분이 단일화 되어 시스템 이해가 쉬울 수 있다.

단점

• 중복 이벤트 처리나, 이벤트 상호 참조 혹은 순서 관련 처리에 대한 설계가 필요로 함.
• 예를 들어 장애 발생시, 데이터 재생 관련한 부분 처리의 어려움

결과적으로 무조건 어떤게 더 나은지?를 비교하긴 어려워 보입니다.
저도 경험해본 바는 lambda architecture를 경험해본 사람이라서, kappa의 경우는 좀 경험치가 없다보니, 좋은 것 같다가도 데이터 스트리밍의 재생 부분이 관건이지 않을까 싶습니다.
특히나, CRUD의 요청 스트리밍에 대한 순서 보장이나, 데이터 핸들링 오류시의 다음 스트리밍에 대한 처리가 중요해보이는데, 아직 시도해본적이 없는 구조라 조금 더 공부 해야 할 것 같습니다.