25.04.18 금, Twitter

 

 

 

 

 

✅ Q1) ElasticSearch는 eventual consistency인데, 실시간 요구사항은 어떻게 처리해?

📌 요점 정리:

• ElasticSearch는 지연된 동기화이기 때문에, 방금 작성한 데이터가 바로 검색되지 않을 수 있음
• 실시간 요구사항이 있을 경우엔 이걸 보완해야 함

🧠 제안된 전략 해석:

• 본인 트윗 (MongoDB): 실시간 보장을 위해 원본 데이터를 DB에서 직접 가져옴
• fallback API: ES에 없다면 MongoDB로 fallback
• hybrid: ES + DB 혼합 전략 → 속도는 ES, 신뢰도는 DB

예시: /search?q=duh&mine=true

• → 내 게시물만 검색할 땐 정확도가 중요하니 MongoDB에서 직접 조회

자동완성: ES n-gram tokenizer 사용

• 빠르게 검색어 자동완성 제공 가능

---

✅ Q2) 비동기 fanout + eventual consistency 상황에서 캐시와 DB 사이 일관성 보장은?

📌 주요 키워드 해설:

• Write-through: 캐시와 DB에 동시에 write → 강한 일관성
• Write-behind + TTL fallback: 캐시에 먼저 쓰고 나중에 DB에 반영 + TTL로 expire → 성능↑, 일관성은 보완 필요
• Partition key = authorId:
  • fanout 시 동일 author의 데이터는 동일 파티션으로 묶음
  • 순서 보장 (Kafka 등에서 중요)
• Timestamp:
  • 이벤트 충돌이나 중복 처리 방지
  • 가장 최신 데이터만 처리하도록 정렬/필터 기준으로 활용

💡 핵심 전략:

• 캐시에 오래된 데이터가 남아있을 수 있으니 TTL 설정
• timestamp 기반으로 최신 데이터만 남기기
• 파티션 키를 잘 잡아 순서 보장 + 충돌 최소화

---

✅ Q3) DB와 Kafka 사이에서 이벤트 일관성 보장 방법은?

📌 핵심 전략: Event Outbox Pattern

• DB 트랜잭션 안에 "이벤트 로그(outbox)" 테이블을 같이 씀
• 서비스 로직 성공 시, DB와 outbox에 동시에 commit
• Kafka connector나 Debezium이 outbox 테이블만 읽어서 Kafka로 publish

🧠 왜 필요?

• DB에 저장은 됐는데 Kafka에 안 실리는 경우 방지
• Kafka → DB or DB → Kafka 사이의 분산 트랜잭션을 우회

 

 

 

 

추천 서비스 (ML Engineering)