코딩 해파리

들어가며현재 프로젝트 목표 중에 높은 트래픽 상황을 견디며 처리하는 성능이 좋은 서버를 구축하는 부분이 있었습니다. 하지만, 기존에는 주문 생성 이벤트가 들어올 때마다 매번 DB에 쓰기 작업을 수행하도록 설계되어 있었기 때문에, 주문이 발생하였을 때 상품 재고 감소 처리 로직(재고 차감 로직)에서 심각한 성능 저하가 발생했습니다. 이렇게 많은 이벤트를 단건 단위로 처리하다 보니, 트래픽이 폭주할 때 자원 사용량 증가로 시스템 전반에 병목 현상이 생겼습니다.이 글에서는 이벤트 배치 처리 방식을 도입하여 성능을 최적화한 과정을 공유합니다. 기존 문제점N건의 이벤트에 대해 N번의 DB 쓰기주문 생성 이벤트가 1건 들어올 때마다 상품 서비스에서 재고 차감 로직을 실행 → DB에 직접 쓰기.이벤트가 폭발적으로 증..

- 개발 환경 - 애플실리콘 MacOSGCP - GKE   마주했던 문제 상황... 1. GCP에서 Google K8s Engine을 통해 애플리케이션을 배포2. GCP의 Managed Kafka가 아직 베타인건지... 제대로된 안내 or 레퍼런스가 존재 x -> 포기3. 인프라 담당한 팀원이 Confluent Kafka 공식 사이트의 Helm 차트 안내서를 통해 카프카를 통합 배포4. 현재 Outbox - CDC 패턴을 적용하여 Debezium이 필요5. 통합 배포된 Kafka Connector에 Debezium 플러그인이 필요 이런 상황을 겪으신 분들이 있을지... 모르겠지만... ㅎㅎ;;해결책을 공유해보겠습니다원래 로컬에서 테스트할 때는 Debezium이 미리 설치된 이미지를 쓰기 때문에 당연히 문..

들어가며이 포스팅은 "MSA 환경에서 이벤트를 주고받으며 프로세스를 진행할 때 발생할 수 있는 데이터 정합성 불일치 문제 발생"을 주제로 합니다. 제 졸업 프로젝트에서 MSA를 적용할 때, 서비스를 분리하기만 하면 끝나는 줄 알았지만 실제론 이벤트가 중복 처리되거나 외부시스템(DB)이 커밋을 실패하거나... 하는 등의 이유로 전체 데이터 정합성이 깨질 수 있는... 곤란한 일이 생길 수 있다는 사실을 깨닫고 많은 고민을 하며 해결했던 과정을 정리해보았습니다.1. 네트워크와 브로커는 100% 신뢰가 어렵다네트워크 장애로 인하여 패킷 손실 혹은 타임아웃 등으로 인해 오프셋이 커밋되지 않는 등의 이유로 재전송이 여러 번 이뤄져 중복 이벤트 컨슘 상황이 발생할 수 있습니다. 또한, 모종의 이유로 이벤트를 발행한..

들어가며졸업 프로젝트를 진행하기에 앞서 처음 마주한 고민은 "모놀리식(Monolithic) 구조로 갈까, 아니면 MSA(Microservices Architecture)로 갈까?"라는 질문이었습니다. 사실 초기에는 하나의 애플리케이션으로 통합해버리면 개발과 배포가 간편할 것이라 생각했는데, 실제로 조사하고 실험해보니 예상치 못한 문제들이 나타났습니다. 이번 포스팅에서는 제가 왜 MSA를 도입해야겠다고 결심하게 됐는지(모놀리식 대비 MSA의 강점)와 분산된 서비스들 간에 어떻게 데이터를 주고받을 것인지(Remote API vs Message Queue)에 대해 정리하려고 합니다. 1. 왜 MSA를 도입했나? — 모놀리식과의 비교1.1 모놀리식의 장점개발 초기 편리성: 초기에는 한꺼번에 빌드하고 배포하면..

이 졸업 프로젝트 관련 포스팅들을 적기에 앞서,저는 어느 정도 규모가 큰 서비스 기업에서 유난히 많이 채택하는 기술,코드 수준의 설계 원칙, 아키텍처에 대한 선택의 이유가 항상 궁금했습니다. 대표적으로 아키텍처 구조로는 MSA(Microservices Architecture)와 EDA(Event-Driven Architecture)가 있었고,기술로는 Kafka, Kubernetes(K8S), Redis 등이 있었습니다.코드 수준의 설계 원칙으로는 DDD(Domain-Driven Design), 헥사고날 아키텍처, TDD(Test-Driven Development) 등이 있었습니다.또한, 많은 기업들이 채용 공고에서 요구하는 '대용량 트래픽 경험'이라는 표현을 보면서, 그것이 얼마나 어렵고 고려할 사항이 ..