MSA의 문제점
큰 모놀리틱을 쪼개는 것에서 시작됨
시스템이 복잡해지기 때문에 큰 Application을 여러개로 쪼개는 설계
- Loosely Coupling
신경안쓰면 Tightly Coupling이 쉽게 될수도 있다
처음의 의도는 좋았음 - 각각 도메인으로 나누고, DB도 따로 쓰고
모니터링 로거 같은걸 붙이고, 앱이 점점 늘어나면서 내부호출이 너무 많아지고
모놀리틱에서는 발견되지 않았던 복잡한 거미줄 구조가 발견되게 됨
구조적 문제점
- 개발 복잡도
- 운영에 필요한 숙련도
- 트랜젝션 관리
- 통합 테스트의 고난
- 배포 복잡도
Event Driven?
이벤트 버스가 존재하고, 이벤트 버스에는 이벤트 브로커가 존재해서 이벤트가 실려있고
양쪽으로 이벤트를 만드는 아이, 이벤트를 소비하는 아이가 있는 것이 이벤트 드리븐이다.
EDA란?
내 답변 : 서로에게 관심을 갖지 않고 관심있는 이벤트가 발생하면 골라서 쓰는 것
Producer Comsumer 구조가 있는 것 (이벤트 발행, 이벤트 소비)
메세지 브로커와 이벤트 브로커의 차이?
이벤트 브로커가 메세지 브로커를 포함하는 개념
이벤트별로 Driven해야 하는 것을 관리하는 것이 이벤트 브로커
메세지 브로커는 offset 같은게 없고 들어오는 것만 처리하는데,
이벤트 브로커는 Access Offset을 통해 접근한다 (포인터와 비슷한 개념)
또, 이벤트 브로커는 이벤트를 처리하고 삭제하지 않는다.
고로 장애 발생 시 재처리가 가능하고, 대량 스트리밍 처리가 쉽다
가장 유명한 것 중에는 Kafka, Kinesis가 있다.
Kafka?
이벤트 버스의 구현체 중 하나
로깅을 해야하고 모니터링을 해야하는 것들이 원래 복잡한 거미줄처럼 있다가,
카프카에 쌓게되면 이 쌓인 로그를 가져다가 사용할 수 있어서 훨씬 구조가 간단해짐
so, MSA의 복잡도를 해결할 수 있다. 소스와 타켓 커플링을 끊을 수 있게 되었고
토픽으로 이벤트를 관리하고 지워지지 않기 때문에 나중에 다시 찾아서도 볼 수 있다는 장점이 있다.
kafka가 인기있는 이유
짧은 시간에 많은 데이터를 컨슈머로 전달할 수가 있고, Scalability가 좋다
또한, Fault Tolerant가 높고 로그가 안지워진다는 장점
가장 먼저 나와서 인기가 있는걸수도 (링크드인에서 처음 만듬)
Kafka의 주요 개념
- Topic
- Broker
- Producer
- Consumer
- Replication
Topic
이벤트 묶음을 Topic이라고 생각하면 됨
이름을 지정할수가 있다. e.g. 주문 Topic 등등
역시나 큐이기 때문에 선입선출
Partitioning을 할 수 있는데 확장만 가능하고 축소할 수 없다.
Key가 지정되어 있으면 해당 키에 Send를 하지만 지정하지 않으면 round robin으로 이벤트를 배분
Key와 Partition은 1:1 대응이어야하고, 두개의 개수가 다르면 hashing이 해제가 됨
그러면 round robin으로 감
Broker
카프카가 설치되어 있는 서버이다. 또, Topic이 저장되는 곳이다.
삼중화 이상이 권장된다. 카프카에서 내세운 장점 중 Fault tolerence를 유지하기 위함
Producer
브로커로 토픽을 발행하는 APP
카프카 브로커와 클라이언트 버전 호환을 확인해야함 따로 확인해주지 않음
또, 브로커 ip와 포트는 2개 이상 설정하라는게 권장사항 (Fault Tolerent)
Consumer
토픽에 있는 데이터를 poling하는 APP
읽은 후 Partition offset 위치를 commit한다
브로커가 어디까지 읽었는지 offset의 위치를 관리중
데이터가 밀려 나오는게 아니고, 움직이는건 offset이다
고로 나중에 다시 읽을 수 있는 이유
Consumer Group
Comsumer Group을 설정해서 그룹별로 Partition offset이 관리된다
그룹 안에 여러개의 리스너가 존재하면 같은 이벤트를 다같이 읽을 수 있음
파티션 수를 넘지않게끔 컨슈머를 설정해둬야함
Replication
삼중화를 해두는게 권장 옵션인데, 3벌로 만들어두면 각각으로 운영을 시켜서 다른 데이터를 할 수도 있겠지만,
보통 원본과 백업용 2개의 복제본으로 둔다.
파티션별로 복제를 설정할 수가 있다.
원본을 Leader Partition으로, 복제본을 Follower Partition으로 하고
Leader를 사용할 수 없는 이슈 시, Follower 하나가 Leader가 된다.
ISR
Replication 운영 정책 (In Sync Replica)
Producer가 브로커로 이벤트를 보낼 때, ACK를 보내는데에 단계가 있다
- ACK 0 : 브로커는 리퀘스트가 들어왔다고 하면 적재하지 않고 바로 보내버림
- ACK 1 : 전송을 하고 적재를 하고 보내는 옵션이 1이다 (저장이 되었다는 걸 보증, 파티션 복제되었는지 보장하지 않음 - 원본이 죽었을 때 복제본에서 확인할 수 있을지 아닐지 모름)
- ACK 2 : 적재 완료 및 Replication까지 확인하고 ACK를 보냄
ACK 0은 속도가 빠르고 신뢰도가 낮고, ACK 2는 속도가 느리고 신뢰도가 높다
