| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | |
| 7 | 8 | 9 | 10 | 11 | 12 | 13 |
| 14 | 15 | 16 | 17 | 18 | 19 | 20 |
| 21 | 22 | 23 | 24 | 25 | 26 | 27 |
| 28 | 29 | 30 | 31 |
Tags
- 코사인
- 배치처리
- 메세지브로커
- 레디스
- redissearch
- springboot
- 메시지브로커
- god object
- OOP
- DLT
- SaaS
- 자연어캐싱
- jedis
- rdb
- redis
- 객체지향적사고
- 백엔드
- 시맨틱캐싱
- 데이터유실방지
- 비동기처리
- 테스트코드
- 레디스스트림
- 마케팅 #퍼플카우 #새스고딘 #혁신 #독서 #이북
- redisstreams
- blockingqueue
- retry
- 임베딩
- aof
- Kafka
- 장애복구
Archives
- Today
- Total
목록blockingqueue (1)
pandaterry's 개발로그
운영 중 발생한 장애를 원인부터 끝까지 추적하려면, 신뢰할 수 있는 로그가 반드시 필요합니다. 특히 JPA를 사용하는 시스템에서는, 엔티티가 변경될 때마다 무엇이 바뀌었고, 누가 변경했으며, 언제 어떤 요청에서 발생했는지 그 이력을 상세히 남기는 일이 중요합니다. 많은 시스템에서는 Kafka나 Redis Stream, 또는 Change Data Capture 기반 구조를 활용합니다. 하지만 다음과 같은 환경에서는 그런 선택이 불가능합니다.외부망과 완전히 단절된 폐쇄망 환경 (군/금융기관 등)Kafka, Redis, ELK 등 인프라 설치 자체가 제한된 경우외부 브로커 없이도 로그 유실 없는 처리가 요구되는 상황실제로 제가 경험한 한 시스템은 배치 업로드 한 번에 수만 건 이상의 엔티티가 변경되는 구조였습..
개발/대규모
2025. 6. 18. 16:41