윤남매 아빠's 스토리

안녕하세요! 여러분의 아키텍처 길잡이, 팬돌프입니다.지난 4편에서 우리는 언제 죽을지 모르는 불안한 컨테이너 환경에서 데이터를 영구적으로 보존하는 PV/PVC와, 순서와 고유성을 보장하는 StatefulSet에 대해 알아보았습니다. 이제 K8s는 단순한 웹 서버를 넘어, 거대한 데이터베이스까지 품을 수 있는 완벽한 인프라가 되었습니다.그렇다면, 우리가 앞선 연재에서 피땀 흘려 배웠던 [Apache Spark]와 [Apache Flink] 같은 분산 데이터 처리 엔진도 K8s 위에 올릴 수 있을까요?과거 빅데이터 생태계의 절대 권력자였던 하둡(Hadoop)과 YARN을 밀어내고, 이제 전 세계의 데이터 플랫폼은 쿠버네티스를 향해 대이동을 하고 있습니다. 오늘은 빅데이터 파이프라인을 클라우드 네이티브로 이주..

안녕하세요! 여러분의 아키텍처 길잡이, 팬돌프입니다.지난 3편에서 우리는 Ingress를 통해 복잡한 트래픽을 단 하나의 진입점으로 우아하게 정리해 냈습니다. 이제 사용자들은 길을 잃지 않고 여러분의 서비스에 도착할 수 있게 되었습니다.하지만 인프라를 구축하다 보면 반드시 마주치게 되는 가장 두렵고 까다로운 관문이 하나 남았습니다. 바로 '데이터(Data)'입니다.앞서 K8s의 핵심 철학을 설명할 때, "Pod는 언제든 죽을 수 있는 소모품이다"라고 강조했습니다. 그렇다면 우리가 정성껏 구축한 Vector DB, Kafka의 메시지, 그리고 Flink의 RocksDB 상태 데이터가 들어있는 Pod가 죽어버리면 어떻게 될까요? 새로 뜬 Pod는 백지상태일 테니, 그동안 쌓인 소중한 데이터가 흔적도 없이 증..

안녕하세요!드디어 대장정의 마지막 순간이 왔습니다. 지난 1편부터 7편까지 우리는 Flink의 탄생 배경부터 시간(Time), 상태(State), 윈도우(Window), 그리고 복합 이벤트 처리(CEP)까지 숨 가쁘게 달려왔습니다. 코드는 완벽하고, 로직은 아름답습니다.하지만, 진짜 승부는 개발 환경이 아닌 '프로덕션(Production)'에서 시작됩니다."어제까진 잘 돌았는데, 이벤트 터지니까 갑자기 지연(Lag)이 미친 듯이 늘어나요!" "TaskManager 메모리가 계속 터집니다. 살려주세요!"오늘은 땀 냄새나는 현장의 이야기입니다. 무한한 데이터가 쏟아지는 운영 환경에서 살아남기 위한 가장 강력한 무기, 백프레셔(Backpressure) 해결 전략과 메모리 튜닝, 그리고 현대 인프라의 표준인 K..

안녕하세요!지난 6편에서는 복잡한 스트리밍 로직을 우아한 SQL 문법으로 풀어내는 마법, 그리고 시계열 조인(Temporal Table Join)에 대해 알아보았습니다. 이제 여러분은 흐르는 데이터의 통계를 내고 집계하는 작업의 달인이 되셨습니다.하지만, 비즈니스 현장에서는 단순한 '통계' 이상의 능력을 요구할 때가 많습니다. "최근 1시간 총매출"을 구하는 건 SQL이나 Window API로 충분하지만, 다음과 같은 시나리오는 어떨까요?"어떤 유저가 ①비밀번호를 3회 연속 틀린 후, ②5분 이내에 성공적으로 로그인해서, ③평소와 다른 IP로 100만 원 이상을 결제하면 즉시 계정을 동결해라!"이것은 데이터의 합계나 평균을 구하는 문제가 아닙니다. 시간의 흐름에 따라 발생하는 이벤트들 사이의 '인과관계'..

안녕하세요! 지난 3편에서는 끊임없이 흐르는 데이터 속에서 과거의 기억을 잃지 않기 위해, Flink가 상태(State)와 RocksDB를 어떻게 활용하는지 알아보았습니다. 이제 우리 시스템은 데이터를 놓치지도 않고, 과거의 내역도 안전하게 기억할 수 있게 되었습니다.그런데 분석(Analytics)의 관점에서 보면 아주 근본적인 문제가 하나 남아있습니다. 데이터는 "무한히" 들어옵니다. 무한한 데이터에 대고 "매출 합계(sum())를 구해줘!"라고 하면, 컴퓨터는 언제 정답을 내놓아야 할까요? 영원히 합계만 구하다가 끝날 것입니다.집계(Aggregation)를 하려면 반드시 '끝'이 있어야 합니다. 그래서 우리는 무한한 스트림을 특정 기준에 따라 유한한 조각으로 잘라내야 합니다. 이 자르는 기술이 바로 ..

안녕하세요!지난 2편에서는 지연되는 데이터를 우아하게 처리하기 위해 Flink가 사용하는 워터마크(Watermark)와 시간의 마법에 대해 알아보았습니다. 이제 데이터가 제때 도착하든 늦게 도착하든, 정확한 타이밍에 계산을 마감할 수 있게 되었습니다.그런데 여기서 근본적인 질문이 하나 생깁니다. "스트리밍은 데이터가 끊임없이 흘러가는 파이프라면서요? 그럼 방금 지나간 데이터는 어디에 기억해 두나요?""최근 10분간 유저 A가 장바구니에 담은 상품 목록", "어제부터 지금까지 발생한 총매출액". 이런 계산을 하려면 과거의 데이터를 '기억'해야 합니다. 무한한 데이터 스트림 속에서 시스템의 메모리가 터지지 않게 안전하게 기억을 관리하는 기술!오늘은 Flink를 단순한 파이프가 아닌 강력한 애플리케이션(Sta..

안녕하세요! 지난 1편에서는 Flink가 어떻게 Spark의 한계를 넘어 '밀리초 단위의 찐(True) 스트리밍'을 구현하는지 알아보았습니다. 데이터가 컨베이어 벨트를 타듯 들어오는 즉시 처리되는 그 짜릿한 속도감, 기억하시죠?하지만 실시간 데이터 처리의 세계에 발을 들이는 순간, 우리는 아주 골치 아픈 철학적 문제에 직면하게 됩니다. 바로 '시간(Time)'입니다.모바일 게임 유저가 지하철에서 몬스터를 잡았는데 인터넷이 끊겼습니다. 이 데이터가 다음 날 아침 서버에 도착했다면, 이 몬스터 사냥은 어제 일어난 일일까요, 오늘 일어난 일일까요?오늘은 완벽한 실시간 처리를 위해 반드시 정복해야 하는 Flink의 핵심 개념, 시간의 3가지 정의와 지연 데이터를 우아하게 제어하는 마법사 '워터마크(Waterma..

안녕하세요! 지금까지 우리는 Spark를 통해 거대한 데이터를 요리하는 법을 배웠습니다. 그런데 혹시 이런 의문이 들지 않으셨나요?"Spark도 실시간 처리(Spark Streaming)가 된다던데, 왜 다들 찐(True) 실시간 처리를 하려면 Flink를 써야 한다고 말하는 걸까?"1초의 지연도 수백만 원의 손실로 이어지는 금융권의 이상 거래 탐지(FDS), 수백만 명의 유저가 동시에 접속하는 게임의 실시간 랭킹 시스템, 클릭하는 즉시 상품이 바뀌는 맞춤형 추천 시스템.이런 극단적인 초실시간(Real-time) 환경에서는 기존의 도구들이 한계를 드러냅니다.오늘부터 시작하는 새로운 연재, 그 첫 번째 시간으로 왜 우리가 Apache Flink라는 새로운 세계로 넘어가야 하는지 그 근본적인 이유와 핵심 아..

안녕하세요!데이터 엔지니어링의 끝판왕, '초실시간(Real-time) 스트리밍'의 세계로 오신 것을 환영합니다! Spark Streaming이 훌륭한 도구이긴 하지만, 태생적으로 데이터를 잘게 쪼개어 처리하는 '마이크로 배치(Micro-batch)' 방식이기에 수 초의 지연(Latency)이 발생합니다.하지만 금융권의 이상 거래 탐지(FDS), 초당 수백만 건이 발생하는 클릭 로그 분석, 실시간 추천 시스템에서는 밀리초(ms) 단위의 반응 속도가 필요합니다. 이때 혜성처럼 등장해 업계 표준으로 자리 잡은 진정한 스트리밍 엔진, Apache Flink의 모든 것을 바닥부터 최상위 운영 노하우까지 낱낱이 파헤쳐 보겠습니다.📋 Apache Flink 연재 시리즈 리포트제1편. [서론] 왜 Flink인가? M..

안녕하세요! 여러분의 AI 엔지니어링 가이드, 팬돌프입니다.지금까지 우리는 데이터를 수집(Kafka)하고, 가공(Spark)하고, 저장(Iceberg)하는 '데이터 엔지니어링의 정석'을 밟아왔습니다. 이 과정을 통해 여러분은 방대한 데이터를 안전하고 효율적으로 관리할 수 있게 되었습니다.하지만 2024년, 데이터 플랫폼의 트렌드는 "저장(Storing)"에서 "이해(Understanding)"로 넘어가고 있습니다. 단순히 텍스트를 저장하는 것을 넘어, 컴퓨터가 그 텍스트의 '의미'를 이해하게 만드는 기술이 필요해진 것이죠.오늘부터 시작하는 [Vector DB & RAG] 시리즈는 여러분의 데이터 시스템에 AI라는 두뇌를 장착하는 과정입니다. 그 첫 번째 시간, AI가 인간의 언어를 숫자로 이해하는 마법,..

안녕하세요! 여러분의 데이터 아키텍처 길잡이, 팬돌프입니다.드디어 Apache Iceberg 완전 정복 시리즈의 마지막 편에 도착했습니다. 지난 7편 동안 우리는 Iceberg의 철학부터 구조, 트랜잭션, 그리고 타임 트래블 같은 고급 기능까지 깊이 있게 파헤쳤습니다. 이론적인 무장은 이제 완벽합니다.하지만 구슬이 서 말이라도 꿰어야 보배겠죠? 오늘은 이 강력한 기술을 여러분의 현업 시스템에 실제로 적용하는 방법을 다룹니다.데이터 가공(ETL)의 제왕 Apache Spark, 그리고 초고속 대화형 쿼리의 강자 Trino(구 PrestoSQL). 이 두 엔진을 Iceberg와 연결하여 진정한 데이터 레이크하우스를 구축하는 설정법과, 운영자가 반드시 챙겨야 할 유지보수 루틴까지 꽉 채워 담았습니다.대장정의 ..

안녕하세요! 여러분의 데이터 지킴이, 팬돌프입니다.지난 6편에서는 데이터의 수정과 삭제 성능을 최적화하는 COW와 MOR 전략에 대해 깊이 있게 다뤘습니다. 이제 데이터 레이크에서도 수정과 삭제가 자유로워졌죠.하지만 사람이라면 누구나 실수를 합니다. "아차! WHERE 조건을 빼먹고 DELETE를 날려버렸네?" "배포된 배치 코드가 버그 때문에 데이터를 다 망가뜨려 놨어!"기존 데이터베이스나 하둡 환경에서 이런 일이 발생하면 등줄기에 식은땀이 흐르고 백업본을 찾아 헤매야 했습니다. 하지만 Apache Iceberg를 사용하는 여러분은 커피 한 잔의 여유를 가지셔도 됩니다.Iceberg에는 버튼 하나로 과거의 상태로 되돌아가는 타임머신, 시간 여행(Time Travel) 기능이 내장되어 있으니까요. 오늘은..

안녕하세요! 여러분의 데이터 아키텍처 길잡이, 팬돌프입니다.지난 시간, 우리는 Iceberg가 어떻게 파일 시스템 위에서 트랜잭션(ACID)을 보장하는지 배웠습니다. 데이터의 안정성이 확보되었으니, 이제 성능을 고민할 차례입니다.데이터 레이크에서 가장 골치 아픈 작업은 바로 데이터 수정(UPDATE)과 삭제(DELETE)입니다."100GB짜리 파일에서 딱 한 줄만 고치고 싶은데, 파일 전체를 다시 써야 하나요?"이 질문에 대한 Iceberg의 대답은 두 가지입니다. "완벽하게 다시 쓰거나(COW)" 아니면 "변경분만 살짝 메모해 두거나(MOR)".오늘은 Iceberg 성능 튜닝의 핵심이자, 데이터 엔지니어라면 반드시 선택해야 할 기로인 Copy-on-Write (COW)와 Merge-on-Read (MO..

안녕하세요! 여러분의 믿음직한 데이터 아키텍처 파트너, 팬돌프입니다.지난 시간까지 우리는 Iceberg의 구조적 혁신(메타데이터 계층)과 사용자 편의성(숨겨진 파티셔닝)에 대해 알아보았습니다. 이것만으로도 훌륭하지만, 아직 "S3를 DB처럼 쓴다"는 말을 증명하기엔 부족합니다.데이터베이스(RDB)의 가장 큰 미덕이 무엇일까요? 바로 신뢰입니다. 내가 데이터를 넣는 도중에 누가 조회를 해도 이상한 데이터가 보이지 않아야 하고(Isolation), 동시에 여러 명이 수정을 시도해도 데이터가 꼬이지 않아야 합니다(Atomicity).기존의 파일 시스템 기반(Hive)에서는 불가능했던 이 꿈같은 이야기를, Apache Iceberg가 어떻게 실현했는지 그 강력한 트랜잭션과 동시성 제어 기술을 파헤쳐 보겠습니다...

안녕하세요! 여러분의 데이터 아키텍처 가이드, 팬돌프입니다.지난 시간, 우리는 Iceberg가 데이터 파일 변경 없이 스키마를 자유자재로 바꾸는 '스키마 진화'에 대해 배웠습니다. 엔지니어의 유지보수 고통을 덜어주는 아주 고마운 기능이었죠.오늘은 엔지니어를 넘어 데이터를 조회하는 분석가(Analyst)와 사용자들이 환호할 만한 기능을 소개합니다.혹시 Hive나 기존 데이터 레이크 환경에서 "파티션 컬럼을 WHERE 절에 안 넣어서 전체 데이터(Full Scan)를 다 읽어버리는 사고"를 겪어보신 적 있나요? 쿼리 한 번 잘못 날렸다가 클러스터가 멈추고 비용 폭탄을 맞는 끔찍한 경험이죠.Apache Iceberg의 숨겨진 파티셔닝(Hidden Partitioning)은 이러한 Human Error를 시스템..