이 프로젝트에서 가장 많이 배운 건 코드를 짤 때가 아니라 뭔가 터졌을 때였다.4편은 운영 중에 실제로 발생한 사고들을 시간 순서 없이, 기억나는 것들 위주로 정리한 글이다.비용 절감을 위해 인프라를 내렸다가 다시 올리는 작업을 했다. KDS를 삭제하고 재생성하면 Fi

Flink가 실시간을 담당한다면, Airflow는 하루치 데이터를 정제하고 쌓는 역할이다.그리고 그 위에 Bedrock AI 채팅과 SageMaker 예측 모델이 올라간다.S3 Data Lake를 세 계층으로 나눴다. 처음엔 "굳이 이렇게까지 해야 하나?" 싶었는데,

센서 데이터 1개가 Slack Alert이 되기까지 걸린 시간은 약 6초였다.이 편에서는 Generator부터 Flink 이상탐지까지, 데이터가 실제로 흘러가는 경로를 따라간다.Generator는 가상 로봇 1,000대를 시뮬레이션하는 Python 프로세스다. K8s

이전 글에서 데이콘 스마트 제조 AI 해커톤 PRISM을 소개했는데, 사실 그 프로젝트의 뼈대는 몇 달 전부터 혼자 만들던 미니 프로젝트에서 왔다. PRISM에서 Bedrock AI 연동, XGBoost 예측 모델, Kinesis 스트리밍을 비교적 빠르게 붙일 수 있었

데이콘 스마트 제조 AI 해커톤 본선 (2025.05.22) 참가 후기인과추론 + Multi-Agent로 제조 현장 문제를 풀어본 이야기해커톤이 끝났다.사실 제조 공정 쪽은 완전 문외한이었다. 기계가 어떻게 돌아가는지도 몰랐고, OEE가 뭔지도 몰랐고, CNC 머신이

데이터 파이프라인을 설계할 때 가장 경계해야 할 것은 '목적 없는 도구의 맹목적인 도입'이다. 특히 로컬 환경에서 수집한 데이터를 클라우드로 전송하는 하이브리드 아키텍처에서는 각 컴포넌트의 리소스 효율성과 책임 분리(Separation of Concerns)가 시스템의

데이터 레이크하우스 아키텍처인 메달리온 아키텍처(Medallion Architecture)를 구현하며, S3에 저장된 Raw 데이터를 Bronze 계층(Athena/Glue)으로 구조화하는 작업을 진행했습니다.저장 포맷: Parquet (Snappy Compressed

ASAC 2기 데이터 엔지니어링 실습으로 S3를 Data Lake로 삼고 AWS Athena를 연동하는 기본 파이프라인을 구축하던 중 오류가 발생했습니다.데이터 원본: S3 S3 data/basic 경로에 다중 JSON(dict 형태)이 나열된 a.txt 파일 업로드.

AWS Managed Service for Apache Flink(구 Kinesis Data Analytics) 환경에서 PyFlink를 활용해 Kinesis Data Streams(KDS)의 실시간 데이터를 집계하는 파이프라인을 구축하던 중 발생한 일련의 오류와 해결

실시간 스트리밍 데이터를 다룰 때, 발생하는 모든 로그를 S3에 실시간으로 '직접' 꽂아 넣는 것은 안티 패턴(Anti-pattern)이다. S3에 자잘한 파일이 무수히 쌓이게 되면(Small File Problem), 추후 Athena나 Spark로 데이터를 읽어 들

Airflow를 활용해 신용 평가 데이터를 DB에 적재하는 파이프라인을 구축하던 중 발생한 두 가지 주요 에러와 해결 과정을 정리한다.문제 상황신용 평가 API 호출 결과를 파싱하여 DB 적재 함수(\_load_users_credit)로 전달하는 과정에서 발생했다. d

데이터 엔지니어의 관점에서 팩트와 시스템 아키텍처 분석이 돋보이도록 Velog 포스팅 초안을 작성해 드립니다. 복사하여 바로 벨로그에 붙여넣고 일부만 다듬어 발행하시면 됩니다. [Airflow 트러블슈팅] 동일한 dag_id를 여러 파일에 사용하면 벌어지는 참사 (f

좋아 👍실무 트러블슈팅 기록용으로 깔끔하고 기술 중심으로 정리해줄게.(복붙해서 바로 velog에 올려도 되는 구조)Airflow 웹서버 컨테이너를 재시작했는데 아래와 같은 에러가 발생했다.그리고 localhost:8080 접속이 되지 않는 상황.Airflow는 웹서버

데이터 파이프라인을 구축하고 운영하다 보면, 수많은 작업(Task)들의 순서를 제어하고 실패 시 재시도 처리 등을 관리해야 하는 상황에 직면하게 됩니다. 기존에는 운영체제의 Cron을 사용하여 스케줄링을 처리하는 경우가 많았으나, 작업 간의 복잡한 의존성을 관리하거나

인프라 설계 시 보안 강화를 위해 DB 서브넷을 외부 인터넷과 완전히 격리(Isolated)하는 아키텍처를 채택하곤 합니다. 그러나 이 과정에서 고가용성(HA)을 위한 데이터 동기화 메커니즘과 네트워크 엔드포인트의 역할을 혼동하여 불필요한 설계를 추가하는 실수가 빈번히

Bastion Host의 정의: 외부 인터넷에서 프라이빗 서브넷에 있는 자원에 안전하게 접근하기 위한 '프록시(Proxy)' 역할의 서버.필요성: 프라이빗 서브넷은 공인 IP가 없어 직접 접속이 불가능하다. 하지만 관리자는 패치나 설정을 위해 접속해야 하므로, 퍼블릭에

EKS 클러스터에서 EBS CSI Driver를 설정하던 중, 크게 두 가지 단계에서 에러가 발생했습니다.증상: waiter state transitioned to Failure, Error: failed to create iamserviceaccount(s)원인: -

메인 타이틀: EKS 테라폼 배포 실패? "싹 다 지우기" 전 반드시 체크해야 할 3가지 팩트서브 타이틀: IAM 권한, KMS 충돌, 그리고 State 파일의 늪에서 탈출하기EKS 클러스터 배포 후 kubectl get nodes를 입력했을 때 No resources

Kubernetes에서 HPA를 사용하면 Pod 개수는 자동으로 늘릴 수 있다.하지만 Pod가 늘어났을 때 이를 실제로 수용할 Node 자원이 부족하면 일부 Pod는 Pending 상태로 남게 된다.이때 필요한 것이 Node Autoscaling이다.대표적인 도구가 C

왜 테라폼을 사용해야 할까요? 실무에서 테라폼을 도입하면 얻을 수 있는 구체적인 장점들은 다음과 같습니다:장애 방지 및 신속한 복구: 수동 작업 시 발생할 수 있는 실수를 방지하고, 장애 발생 시 코드를 통해 빠르게 동일한 환경을 재구축할 수 있습니다.업무 효율성 (칼