Kwin's Development Diary.

[Kubernetes] Pod가 다시 실행되면 이전 작업도 복구될까?

Kubernetes는 Pod가 비정상적으로 종료되었을 때 설정된 정책과 컨트롤러에 따라 컨테이너를 재시작하거나 새로운 Pod를 생성할 수 있다. 그렇다면 Pod에서 실행 중이던 데이터 처리 작업도 중단된 지점부터 복구되는 걸까? 외부 데이터를 수집하고 PostgreSQL에 적재하는 파이프라인을 생각해보자.외부 데이터 수집 ↓데이터 정규화 ↓PostgreSQL 적재 수집한 레코드 1,000건을 처리해야 하는 상황에서 500건까지 처리한 뒤 Pod가 종료되었다고 가정해보자. Kubernetes가 새로운 Pod를 생성하면 501번째 레코드부터 이어서 처리할까?아니면 1,000건을 처음부터 다시 처리할까?500건을 이미 PostgreSQL에 저장했다면 Pod가 종료되었을 때 해당 데이터는 ..

오늘 유튜브에 '2026 당근 빌더 밋업 | Product Day: 개발 딸깍, 디자인 딸깍, 운영 딸깍'이라는 제목으로 업로드된 발표를 봤다. 발표에서 특히 기억에 남았던 표현은 '지속 가능한 딸깍'이었다. 단순히 반복되는 일을 자동화하는 것이 아니라, 그 일을 계속해서 직접 수행하지 않아도 되는 구조를 만드는 것.이 이야기를 들으면서 이전에 중복 데이터 판정 시스템을 설계했던 경험이 떠올랐다.당시에는 사람이 직접 판단하던 일을 최대한 자동화하는 것이 좋은 시스템을 만드는 방법이라고 생각했다. 하지만 실제 데이터를 다루면서 자동화의 범위를 넓히는 것보다 더 중요하게 고민해야 할 문제가 있다는 것을 알게 됐다.1. 85%라는 기준이 충분하지 않았던 이유여러 외부 사이트에서 데이터를 수집하다 보면 서로 다..

외부 데이터를 수집하는 파이프라인을 개발하면서 한 가지 고민이 생겼다. API 요청도 정상적으로 끝났고, 파싱 과정에서도 예외가 발생하지 않았다.데이터베이스 적재까지 완료됐기 때문에 Airflow에서도 Task는 success 상태였다. 그런데 실제 적재된 데이터를 확인해보면 상황이 달라질 수 있다. 평소 1,000건 정도 수집되던 데이터가 갑자기 10건밖에 수집되지 않았거나, 필수값이 비어 있거나, 정상적으로 존재해야 하는 참조 코드가 잘못되어 있을 수도 있다. HTTP 요청: 성공파싱: 성공DB 적재: 성공Airflow Task: success하지만 수집 데이터는 비정상코드의 실행만 놓고 보면 파이프라인은 성공했다. 그렇다면 데이터 파이프라인에서 '성공'은 어디까지를 의미하는 걸까? 이번에는 코드가 ..

Airflow를 사용하다 보면 TaskInstance의 상태를 자주 확인하게 된다. 정상적으로 실행되고 있는지 확인하기 위해 running 상태를 보고, 실행이 지연되고 있다면 scheduled나 queued 상태에 머물러 있는지 확인하고 실행에 실패하면 failed나 up_for_retry 상태를 확인하면서 문제의 원인을 찾는다. 나 역시 Airflow를 운영하면서 이런 상태들을 계속 확인해왔지만,막상 각각의 상태가 Airflow 내부에서 어떤 단계에 해당하는지 설명하려고 하니 정확하게 알고 있지 못했다. 그래서 이번에는 실제로 Task가 실행되기까지 어떤 일이 일어나는지 알아보려고 한다.@task로 작성한 함수는 언제 실행될까?TaskFlow API를 사용하면 일반 Python 함수에 @task를 붙..

이전에는 외부 API를 호출하는 Extract Task에서 Retry를 어떻게 설정해야 하는지 정리해봤다. 처음에는 실패한 Task를 다시 실행하는 것만 생각했지만, 여러 Task가 같은 외부 API를 사용하고 있다면 Retry가 오히려 외부 서버의 부하를 증가시킬 수도 있었다. 그래서 Retry 횟수뿐만 아니라 Backoff를 통해 언제 다시 요청할 것인지도 생각해야 했고, 글을 정리하면서 마지막에는 또 다른 의문이 남았다. 여러 DAG가 같은 외부 API를 호출하고 있다면 전체 요청량은 어떻게 제한해야 할까? Airflow에는 Pool이라는 기능이 있다 나도 외부 API를 사용하는 Task의 동시 실행 수를 제한할 때 Pool을 사용해왔기 때문에 대략적인 사용 방법은 알고 있었다. 하지만 막상 다시 ..

이전에는 Airflow Task에서 데이터를 Load하던 중 실패했을 때 Retry가 발생하면 어떤 문제가 생길 수 있는지 정리해봤다.[Apache Airflow] Task Retry, 다시 실행해도 안전한가? - Load [Apache Airflow] Task Retry, 다시 실행해도 안전한가? - LoadAirflow로 데이터 수집 파이프라인을 만들다 보면 외부 API 장애나 네트워크 문제처럼 일시적인 오류가 발생할 수 있다. 이런 경우를 대비해서 대부분의 Task에 Retry를 설정해서 사용해왔다.default_argkwin0825.tistory.com DB에 일부 데이터가 이미 저장된 상태에서 Task가 다시 실행될 수 있기 때문에 단순히 Retry를 설정하는 것만으로는 안전한 재처리를 보장할 ..

Airflow로 데이터 수집 파이프라인을 만들다 보면 외부 API 장애나 네트워크 문제처럼 일시적인 오류가 발생할 수 있다. 이런 경우를 대비해서 대부분의 Task에 Retry를 설정해서 사용해왔다.default_args = { "retries": 3, "retry_delay": timedelta(minutes=5),}실패하면 일정 시간이 지난 뒤 다시 실행되기 때문에 처음에는 Retry를 설정해두면 장애가 발생하더라도 어느 정도 안전하게 처리할 수 있다고 생각했다.(여기서 말하는 Retry는 DAG 전체를 다시 실행하는 것이 아니라, 실패한 Task를 다시 실행하는 Task Retry를 의미한다) 그렇다면 실패한 Task가 다시 실행될 때, 첫 번째 실행에서 이미 처리된 데이터는 어떻게 되는..

데이터 엔지니어로 일하면서 Python, Airflow, PostgreSQL, Kafka 등 여러 기술을 사용해왔다.업무에서 계속 사용하는 기술이다 보니 자연스럽게 어느 정도는 알고 있다고 생각했다. 직접 데이터 파이프라인을 만들고 운영하면서 문제가 발생하면 원인을 찾아 해결하기도 했으니, 적어도 내가 사용하고 있는 기술에 대해서는 어느 정도 이해하고 있다고 생각했던 것 같다. 그런데 최근 문득 내가 데이터 엔지니어로서 어느 정도 수준인지 궁금해졌다.경력이 오래된 것도 아니고, 그렇다고 이제 막 일을 시작한 것도 아니다 보니 스스로 객관적으로 판단하기가 쉽지 않았다.그래서 새로운 기술을 더 공부하기 전에 지금까지 사용해온 기술들을 내가 어느 정도까지 이해하고 있는지 하나씩 점검해보기로 했다.생각보다 익숙..

collections.defaultdict: 파이썬 collections 모듈에 있는 딕셔너리 서브 클래스이다.: 일반 dict와 거의 동일하게 동작하지만, 존재하지 않는 키에 접근했을 때 자동으로 기본값을 생성하여 넣어주는 기능이 있다.from collections impor defaultdict - dict: 존재하지 않는 키에 접근시 KeyError 발생- defaultdict: 존재하지 않는 키에 접근시 미리 지정한 함수를 호출하여 기본값을 만든 뒤, 그 값을 해당 키에 저장하고 반환 사용법생성 방법from collections import defaultdict# 기본값으로 설정할 자료형을 객체 생성시 선언해준다# int: 0d = defaultdict(int)# list: []d = defaul..

[ 지원서 제출 ]2024년 3월, 당시 학부생 7번째 학기(4학년 1학기)가 막 시작되어 열심히 살겠다는 생각은 언제나 가슴 한편에 자리하고 있었지만 열심히 사는 것이 대체 어떤 것인지 몰라 답답하던 참이었다. 그러던 중 학교 벽면에 붙은 카카오테크 캠퍼스 2기(이후 카테캠)를 모집한다는 공고를 우연히 보게 되었지만, 카카오라는 네임벨류에 겁먹어 내가 감히 지원해도 될까라는 생각에 지원할 생각을 하지 못했다. 이후 카테캠 모집 마감일이 다가오고 주변에서는 카테캠에 지원했다는 사람들의 소식이 들려오기 시작하면서 왜 해보지도 않고 포기해야 하지?라는 생각이 들어 안되더라도 해보고 탈락하는 게 마음이 편할 것 같아 지원해 보았다. 이러한 마음을 먹고 나서 집에 들어와 나는 곧바로 카테캠 홈페이지를 들어가 ..