Page History
...
Kafka의 Broker 수가 많아질수록 Throughput 향상 및 Partition 분산이 가능하지만 비용 증가
Zookeeper는 Kafka 3.5 이후로 KRaft 모드로 대체 가능 (ZK 제거 → EC2 2~3대 절감 가능)
앱 수가 늘어나면 Consumer Scaling 필요 → App용 EC2 추가 필요
디스크 IOPS는 별도 요금 (EBS 스토리지)
우리는 다른 서비스에서 이미 카프카를 도입해 숙련도 숙련도가 있는 상황이지만 , 지금 당장 카프카를 새로운 서비스에 신규로 설치하고
한가지 어플리케이션에서 처리하는 녀석을 생산자/소비자로 설계할 시간과 인프라확보를 못해둔 상황이였으며
...
지금 당장 카프카를 도입하기에는
인프라확보및 이것을 전반적으로 활용할 설계준비가 아직안된 상태로 기능검증이 끝내고 오픈베타중인 상황으로
바로 그랜드 오픈준비를 후속으로 해야하는 상황이였습니다.
서비리스 웹 서비스의 자원문제
최근의 웹서비스들은 아예 서버리스로 가거나 클라우드 장치들을 대부분 활용하면서, 값싼 어플리케이션이 돌아가는 EC2또는 POD는 CPU및 메모리가
놀기사작했습니다. DB및 PasS 클라우드 장치에 비교하면 어플리케이션을 작동하는 EC2는 거의 놀고 있습니다.
간혹 API어플리케이션을 스케일아웃 하는 전략으로 분산처리가 될것으로 기대하는 경우가 있는데 단일지점 병목을 무시하게되면 성능 임계치를 더 가속화할 뿐입니다.
이 문제를 해결하기 위해, EC2의 남아도는 자원을 활용하는 액터모델을 이용한 StateFull 방식을 빠르게 채택하기로 하였습니다.
오버엔지니어링에서 고민
여기서 개발기간이 아주 크게 증가한다고 해도 오버엔리지어링 수치가 높아질수 있습니다. - 아래는 재미삼아 GPT의뢰 만들어본 공식
📌 OverEngineering Index (OEI) 공식:
📊 변수 정의:
| 변수 | 설명 |
|---|---|
C (Complexity Level) | 설계 복잡도 (1~10, 시스템 구조, 메시징, DB샤딩, CQRS 등 도입 요소 수 기준) |
T (Time Pressure) | 개발 완료까지 남은 시간에 대한 압박 수준 (1~10, 작을수록 급박) |
L (Learning Load) | 팀 전체의 학습 곡선 부담 (도입 기술에 익숙하지 않을수록 높음, 1~10) |
D (Dev Resource) | 가용 개발자 수 × 숙련도 (팀 역량 지수, 예: 숙련된 3명 → 3×0.9 = 2.7) |
P (Project Priority) | 프로젝트의 긴급성과 ROI 우선도 (1~10, 높을수록 정당한 투자) |
주어진 시간은 1주일이내 우리는 다음과 같은 방법을 사용하기로 했습니다.
FSM Actor를 이용한 준 실시간 벌크처리
전략은 간단합니다. 인메모리에서 짧은기간 큐에보유하고 있다가 적절한 순간 모은데이터만큼만 벌크처리를 하는것입니다.
이 전략은 모은 개수만큼 커넥션수를 절약할수 있으며 이벤트를 적재하고 즉시 꺼내 사용안해도 되는 케이스에서 이용가능한 전략입니다.
- https://doc.akka.io/libraries/akka-core/current/typed/fsm.html - Akka제공 FSM컨셉
- 코프링기반 액터모델 연구코드 - 물론 이 방법을 채택하기전 어느정도 학습을 하고 있는 상태였습니다. 학습곡선 비용을 미리 최소화
위 와같은 장치를 채택 한다고 해도~ 메시지 전송수준을 어디까지 높일것인가? 도 비용으로 바라볼수 있습니다.
💡 선택 기준 요약표
전송 수준 | 중복 | 손실 | 처리 비용 | 사용 예시 |
|---|---|---|---|---|
At Most Once | ❌ | ✅ | 💲 (낮음) | 로그, 알림 |
At Least Once | ✅ | ❌ | 💲💲 (중간) | 주문, 결제 |
Exactly Once | ❌ | ❌ | 💲💲💲 (높음) | 금융, 정산 |
...
🔍 인프라 비용 고려 팁
로그나 비동기 알림은
At Most Once로 충분 → 비용 절감결제, 주문처리는
At Least Once+ 중복제거 로직 추가로 타협 가능회계, 정산은
Exactly Once필수지만, 서비스 경계를 좁히면 필요한 범위를 최소화할 수 있음
여기까지가 팀원에게 코칭한 내용이며, 여기서 더 업그레이드해 메시지 전송 수준(Message Delivery Semantics) 까지 고려한 팀원이 해결하고 작성한 테크를 소개합니다.
코드완성후 PR 과정 - 우리는 AI를 통한 PR을 프로덕트레벨에 이미 적용해 사용중에 있습니다.
제목 : Akka를 이용한 대규모 데이터 처리 로직 최적화
작성자 : BlumnAI CRM팀 개발자 데니아
1. Pekko(Akka)란?
Pekko(Akka의 Apache 포크)는 Actor 모델에 기반한 고성능 비동기 메시지 기반 시스템을 개발하기 위한 툴킷입니다.
...
| Code Block | ||
|---|---|---|
| ||
ActorSystem
└─ ActorManager
└─ BulkManagerActor (부모)
├─ BulkWorkerActor#1 (자식)
└─ BulkWorkerActor#2 (자식) |
4. 데이터 처리 순서
추가 참고 자료
https://doc.akka.io/libraries/akka-core/current/typed/fsm.html