[카테고리:] 기술스택

Flink CDC & Iceberg & EKS 로우레벨 딥다이브 (준구 형님 x 깹)

일시: 2026-04-28 참여: 준구 형님(Boss), 깹(Kkaeb) 주제: EKS 볼륨 전략, Flink Stateful 관리, Debezium CDC to Iceberg 파이프라인 정밀 설계 📜 실시간 대화 원문 로그 (100% 무삭제) 🔄 준구 형님 x 깹 대화 실시간 기록 (클릭하여 펼치기) 준구 형님: 근데 궁금한 것. eks의 볼륨은 이런 개념은 아닌가 깹: 와, 준구 형님! 질문의 흐름이 자연스럽게 클라우드…

오후 5:58 7월 7, 2026
[2편] Debezium CDC to Iceberg 정밀 설계 (Incremental Snapshot & Upsert)

주제: Kafka 기반 CDC 데이터를 Flink를 이용해 Iceberg v2 테이블에 실시간 정합성을 유지하며 적재하는 전략 참여: 준구 형님, 깹 💡 핵심 요약 (TL;DR) 하이브리드 부트스트래핑: 과거 데이터는 Redshift Native Write로 Iceberg에 초기 적재. 현재 데이터는 Debezium(Schema-only)으로 빈로그만 낚아채서 Flink로 전달. 겹치는 구간은 WHERE sys_mdfy_dtm > ‘기준시점’ 필터로 물리적 결계를 쳐서 중복 차단. Deduplication (중복 제거)…

오후 5:58 7월 7, 2026
[1편] EKS 스토리지 아키텍처 끝판왕 정리 (EBS vs EFS vs S3)

주제: EKS 환경에서의 볼륨 관리와 Stateful 애플리케이션(DB, Flink) 배포 전략 참여: 준구 형님, 깹 💡 핵심 요약 (TL;DR) EKS 볼륨의 진실: EBS(RWO)는 1대1 전용 SSD임. 속도는 빠르지만 공유 불가. EFS(RWX)는 공유는 되지만 네트워크 방식이라 DB용으로는 개느림. Multi-Attach EBS는 물리적으로만 꽂아줄 뿐, 정합성 관리는 헬게이트임. StatefulSet의 존재 이유: 포드가 죽어도 EBS(PVC)가 포드 번호를 따라다님. 덕분에 S3에서…

오후 5:58 7월 7, 2026
DB 아키텍처 로우레벨 끝장 토론 (준구 형님 x 깹)

일시: 2026-04-28 참여: 준구 형님(Boss), 깹(Kkaeb) 주제: Oracle RAC, AWS Aurora, Sharding, Replication 등 현대 DB 아키텍처의 로우레벨 동작 원리 분석 💡 1. 핵심 개념 Q&A 요약 (Study Note) Q1. Oracle RAC는 왜 1황인가? 핵심 기술은? A: Shared Disk Active-Active 구조의 정점임. 모든 노드가 동시에 쓰기가 가능하며, Cache Fusion 기술을 통해 디스크가 아닌 인터커넥트(광케이블)로 메모리…

오후 5:58 7월 7, 2026
Airflow 스케줄링 최적화 딥다이브 (Cron vs Timedelta)

(부제: 논리적 시간(Logical)과 물리적 시간(Physical) 분리하기) 개발자에게 “00시”는 하루의 끝이 아니다. 하루의 시작이자, 가장 예민한 시간이다. 500개가 넘는 배치가 동시에 “나부터 실행시켜줘!”라고 아우성치는 그 시간, 우리 데이터 팀의 슬랙은 항상 불타고 있었다. 1. The Dilemma: 정합성이냐, 효율성이냐 (죽느냐 사느냐) 데이터 엔지니어라면 누구나 겪는 가불기(딜레마)가 있다. 비즈니스 (Logical): “어제 매출 데이터는 오늘 00시 기준으로 마감되어야 하잖아요.”…

오후 5:57 7월 7, 2026
증분 Sequence 기반의 대용량 로그 테이블 ETL 경험기

“로그 테이블 created_at에 인덱스 하나만 걸어주시면 안 될까요?”“테이블 사이즈가 수십 TB인데 인덱스만 TB 단위입니다. 안 됩니다.” 데이터 엔지니어로서 대용량 로그성 데이터를 다루다 보면 필연적으로 마주치는 상황이다. UPDATE 없이 쌓이기만 하는(Append-only) 로그 테이블인데, 너무 거대해서 날짜 컬럼(created_at)에 인덱스조차 걸 수 없는 상황.이 글은 그런 척박한 환경에서 Primary Key(Sequence) 하나만 믿고 고속으로 데이터를 퍼 날랐던 전략과, 그…

오후 1:26 2월 6, 2026
[Troubleshooting] Spark가 데이터를 두 번 읽는 방법: JDBC 파티셔닝과 격리 수준의 환장 콜라보

“어제 매출이 왜 2배로 뛰었죠? 마케팅 대박 났나요?”“아뇨… 그럴 리가요…” (등줄기에 땀이 흐른다) 1. 사건의 발단: “데이터가 뻥튀기 됐어요” 어느 평화로운 오전, 분석가님으로부터 메시지가 왔다. 후행 마트 테이블의 집계 수치가 평소보다 훨씬 높게 나온다는 것.확인해 보니 특정 시간대의 데이터가 정확히 중복(Duplicate) 적재되어 있었다. PK가 중복되었으니 당연히 Sum 집계는 뻥튀기될 수밖에. 사용 중인 기술 스택은 AWS…

오전 9:03 2월 6, 2026
[Troubleshooting] 00시 정각의 비극: 클라우드의 배신과 네트워크의 역습 (MWAA & Glue)

“클라우드는 무한하지 않다. 특히 내 지갑과 IP 주소, 그리고 오토스케일링 속도는 더더욱.” 1. 00시 정각, 대혼돈의 서막 우리 팀은 AWS MWAA(Managed Workflows for Apache Airflow)와 AWS Glue를 사용해 ODS 데이터를 적재한다.테이블 500개, 관련 Task만 2,000개가 넘는 이 거대한 파이프라인이 매일 00시 00분 00초에 동시에 출발 신호탄을 쏘아 올린다. 이론상으로는 아름다워야 했다.MWAA는 알아서 오토스케일링이 되고, Glue는…

오후 3:55 1월 30, 2026
[Troubleshooting] 분석가님의 쿼리가 회사의 새벽을 멈춘 날 (feat. Redshift Lock)

00시 정각. 데이터 엔지니어에게는 가장 긴장되는 시간이다. 수백 개의 파이프라인이 동시에 돌아가며 데이터를 쏟아내는 이 시간에, 갑자기 지옥문이 열렸다. 1. 상황 발생: “배치는 돌고 있는데 데이터가 안 들어온다?” 여느 때와 다름없이 자정 배치가 시작됐다. 그런데 아침에 출근해서 확인해 보니, ODS(Operational Data Store) 테이블 갱신 작업이 Running 상태로 6시간째 멈춰 있었다. 이건 100% Lock 문제다. 그것도…

오후 1:31 1월 30, 2026
[홈서버 구축기 3편] 서버 OS & 개발 환경 세팅 (feat. WSL2, Docker)

지난 2편에서 고성능 미니 PC 세팅을 마쳤으니, 이제 본격적으로 서버를 굴릴 환경을 만들 차례다. 1. 고민의 시작: OS는 뭘로 하지? 처음엔 서버니까 당연히 우분투 서버(Ubuntu Server)를 깔까 고민했다. 하지만… 나는 뼛속까지 윈도우(Windows) 유저다. 리눅스 커맨드 라인이 익숙하긴 해도, GUI 환경에서 오는 그 편안함을 포기할 순 없었다. 게다가 메인 PC로도 쓸 거라서 리눅스 데스크톱은 좀… 그래서…

오전 12:35 12월 25, 2025