| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 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 |
- node
- Jenkins
- Airflow
- JavaScript
- openlens
- IntelliJ
- chart.js
- aws
- codedeploy error
- codepipeline
- SQL
- VPN
- kubeflow
- bootstrap
- Spring
- codebuild
- docker
- aws cicd
- java bigdecimal
- AWS CI/CD 구축하기
- Kafka
- redis
- chartjs
- Flux
- Python
- codedeploy
- Spring Error
- PostgreSQL
- COALESCE
- 도커
- Today
- Total
목록분류 전체보기 (633)
Small Asteroid Blog
Claude Code를 쓰면서 느낀 불편함Claude Code로 프로젝트 작업을 하다 보면 이런 상황이 반복된다."DTO는 record로 만들어줘" (3번째 말하는 중)"@Autowired 말고 생성자 주입으로 해줘" (또...)"Controller에 @Transactional 붙이지 마" (이것도 또)Claude Code는 세션이 바뀌면 기억이 초기화된다. 그래서 매번 같은 컨벤션을 반복해서 알려줘야 한다. 프로젝트가 커질수록 이 반복이 쌓인다.이걸 해결하려고 하네스(Harness) 라는 개념을 적용해봤다. 하네스가 뭔데?한 줄로 요약하면, Claude Code가 동작하는 환경을 세팅하는 것이다.┌─────────────────────────────────────────┐│ CLAUDE.md ..
1. 전체 흐름 (핵심 구조)실무에서는 보통 아래 흐름으로 구성된다.Service → DB (Outbox) → Debezium (CDC) → Kafka → Flink → Redis / DB / Kafka이 구조의 목적은 단순하다.👉 DB에서 발생한 이벤트를 안전하게 꺼내서 → 실시간으로 처리 → 서비스에서 활용 2. 각 컴포넌트 역할 (실무 기준)Kafka: 이벤트를 모아두고 전달하는 중심Kafka는 모든 이벤트가 모이는 허브 역할이다.서비스에서 발생한 클릭, 주문, 로그 같은 데이터를 일단 Kafka로 보내고,이후 시스템들이 이를 가져가서 사용한다.실무에서 중요한 포인트는 두 가지다.Partition + Key 설계userId / productId 기준으로 ..
Loaded CoreSimulatorService is no longer valid for this processReact Native / Expo 개발 중 iOS Simulator를 실행하려고 할 때 다음과 같은 오류가 발생했다.Xcode Simulator 서비스 버전 충돌이었다. 문제 상황다음과 같은 상황에서 발생한다.Xcode 업데이트 이후Simulator가 이미 실행 중이던 상태CoreSimulator 서비스가 이전 버전으로 실행 중 다음과 같은 상황이라서 Connection refused 오류가 발생한다.Xcode 업데이트↓Simulator 서비스는 이전 버전 상태↓CoreSimulator 버전 충돌↓Simulator 연결 실패 해결 방법핵심은 Simulator 관련 프로세스를 완전히 종료..
Consumer Lag이란Kafka에서 Consumer Lag은 다음을 의미한다.Lag = Topic의 최신 offset - Consumer가 읽은 offset즉 Consumer가 메시지를 얼마나 뒤쳐져서 읽고 있는지를 나타낸다.Lag이 줄어들지 않는다는 것은 보통 다음 중 하나다.Consumer가 메시지를 읽지 못하는 경우Offset commit이 되지 않는 경우Consumer Group이 정상 등록되지 않은 경우 문제 상황Kafka 기반 스트림 처리 시스템을 운영하면서 만난 이슈에 대한 내용이다.Kafka Topic에는 메시지가 계속 들어오고 있었는데 Consumer Lag이 줄어들지 않고 계속 쌓였다.더 이상한 점은 Lag이 많이 쌓인 이후 Consumer Group 자체가 보이지 않는 것처럼 보이..
Kafka와 Flink를 사용하면 실시간 데이터 처리 파이프라인을 쉽게 구축할 수 있다.대표적인 구조는 다음과 같다.Producer → Kafka → Flink Stream Processing → Sink(DB, ElasticSearch, etc)하지만 스트림 처리 시스템은 Batch 시스템과 다른 특성 때문에 예상하지 못한 장애가 자주 발생한다.실제 운영하면서 자주 마주치는 Kafka + Flink 스트림 처리 장애 5가지를 정리해봤다. 1️⃣ Consumer Lag이 계속 증가하는 문제증상Kafka Topic에 메시지는 계속 쌓이는데 Consumer Lag이 줄어들지 않는다.Kafka CLI나 Kafbat/kafka UI 로 확인하면 다음처럼 Lag이 계속 증가한다.TOPIC PARTITIO..
문제 상황Flink Streaming Job에서 다음과 같은 문제가 발생했다.Kafka 메시지는 정상적으로 들어옴집계 결과를 DB에 저장하는 로직 사용대부분 데이터는 정상 저장하지만 마지막 메시지에 대한 결과가 DB에 저장되지 않았다.즉, 마지막 이벤트가 메모리에 남아있는 상태로 Job이 끝나버렸다. 사용한 Window 방식Flink SQL에서 다음과 같은 방식으로 집계를 사용하고 있었다.TUMBLE window+ event time+ watermark예시SELECT user_id, COUNT(*)FROM tableGROUP BY user_id, TUMBLE(event_time, INTERVAL '1' MINUTE) 왜 마지막 데이터가 저장되지 않을까원인은 Event Time 기반..