고양이 두 잔

목차 크론탭으로도 되는데, 왜 에어플로우인가 | 에어플로우 · MWAA 입문 (1)함수에 데코레이터 하나, 그게 DAG였다 | 에어플로우 · MWAA 입문 (2)서버는 안 만졌는데, 파이프라인이 돈다 | 에어플로우 · MWAA 입문 (3) 들어가며이 글은 에어플로우로 만든 파이프라인을 아마존 MWAA(Managed Workflows for Apache Airflow, 아마존의 관리형 에어플로우 서비스)로 운영하는 방법을 다룬다. 1부와 2부에서는 에어플로우의 개념과 DAG 작성법을 살펴보았다. 그러나 실제 서비스에서는 에어플로우를 실행할 서버를 계속 운영해야 한다. 이 운영 부담을 덜어 주는 것이 관리형 서비스인 MWAA다. 이번 편은 MWAA가 무엇을 대신 맡는지, 그리고 파이프라인을 어떻게 배포하는지..

목차 크론탭으로도 되는데, 왜 에어플로우인가 | 에어플로우 · MWAA 입문 (1)함수에 데코레이터 하나, 그게 DAG였다 | 에어플로우 · MWAA 입문 (2)서버는 안 만졌는데, 파이프라인이 돈다 | 에어플로우 · MWAA 입문 (3) 들어가며이 글은 에어플로우에서 DAG(Directed Acyclic Graph, 방향성 비순환 그래프)를 실제로 작성하는 방법을 다룬다. 1부에서는 크론의 한계와 에어플로우의 핵심 개념을 살펴보았다. 이번에는 그 개념을 코드로 옮겨 파이프라인을 직접 만들어 본다. 작성 방식은 데코레이터(decorator, 함수 위에 붙여 기능을 더하는 파이썬 문법)를 사용하는 TaskFlow API를 중심으로 한다. TaskFlow API는 에어플로우 2.0에서 도입된, 함수를 그대로..

목차 크론탭으로도 되는데, 왜 에어플로우인가 | 에어플로우 · MWAA 입문 (1)함수에 데코레이터 하나, 그게 DAG였다 | 에어플로우 · MWAA 입문 (2)서버는 안 만졌는데, 파이프라인이 돈다 | 에어플로우 · MWAA 입문 (3) 들어가며데이터 파이프라인은 여러 작업을 정해진 순서대로 실행하는 흐름이다. 많은 개발자는 처음에 크론(cron, 유닉스 계열 운영체제의 시간 기반 작업 예약 도구)으로 이 흐름을 자동화한다. 크론은 간단한 작업을 정해진 시각에 돌리는 데에는 충분하다. 그러나 작업이 서로 얽히고 그 수가 늘어나면 크론만으로는 관리가 어려워진다. 이 글은 크론의 한계에서 출발해 아파치 에어플로우(Apache Airflow)가 왜 필요한지 설명한다. 또한 이어지는 편에서 다룰 아마존 MWA..

목차 대용량 쿼리 시리즈대용량 데이터가 느린 이유와 최적화의 원리 | 대용량 쿼리 (1)느린 쿼리, 인덱스와 실행계획으로 잡기 (PostgreSQL) | 대용량 쿼리 (2)분산 처리 입문: 셔플과 파티셔닝, 조인 전략 | 대용량 쿼리 (3)수억 행을 견디는 DB 설계: 파티셔닝과 샤딩 | 대용량 쿼리 (4)PostgreSQL VACUUM과 커넥션 풀링, 운영의 함정 | 대용량 쿼리 (추가) 들어가며1편에서 4편까지가 쿼리를 빠르게 만들고 데이터를 설계하는 이야기였다면, 이 글은 그 데이터베이스를 살아 있게 유지하는 이야기다. 쿼리를 아무리 잘 짜고 인덱스를 잘 걸어도, PostgreSQL을 운영하다 보면 쿼리 계획과는 무관한 곳에서 시스템이 무너진다. 그 대표적인 두 함정이 autovacuum이 뒤처져 ..

목차 대용량 쿼리 시리즈대용량 데이터가 느린 이유와 최적화의 원리 | 대용량 쿼리 (1)느린 쿼리, 인덱스와 실행계획으로 잡기 (PostgreSQL) | 대용량 쿼리 (2)분산 처리 입문: 셔플과 파티셔닝, 조인 전략 | 대용량 쿼리 (3)수억 행을 견디는 DB 설계: 파티셔닝과 샤딩 | 대용량 쿼리 (4)PostgreSQL VACUUM과 커넥션 풀링, 운영의 함정 | 대용량 쿼리 (추가) 들어가며앞선 세 편은 데이터가 쌓인 뒤에도 되돌릴 수 있는 처방, 즉 진단과 튜닝, 그리고 분산 처리를 다루었다. 이번 편은 한번 정하면 되돌리기가 매우 어려운 결정, 즉 설계를 다룬다. 설계가 까다로운 이유는, 수억 행이 쌓인 뒤에 바꾸려면 테이블을 통째로 다시 만들다시피 해야 하기 때문이다. 그래서 데이터 타입과 ..

목차 대용량 쿼리 시리즈대용량 데이터가 느린 이유와 최적화의 원리 | 대용량 쿼리 (1)느린 쿼리, 인덱스와 실행계획으로 잡기 (PostgreSQL) | 대용량 쿼리 (2)분산 처리 입문: 셔플과 파티셔닝, 조인 전략 | 대용량 쿼리 (3)수억 행을 견디는 DB 설계: 파티셔닝과 샤딩 | 대용량 쿼리 (4)PostgreSQL VACUUM과 커넥션 풀링, 운영의 함정 | 대용량 쿼리 (추가) 들어가며2편까지는 한 대의 데이터베이스 안에서 쿼리를 빠르게 만드는 방법을 다루었다. 그러나 1편에서 보았듯, 가장 큰 기계의 천장에 닿거나 데이터가 한 대에 들어가지 않으면 여러 대로 나누는 분산 처리로 넘어가야 한다. 이 편은 그 분산 처리의 일반 개념을 다루되, 사실상 표준으로 자리 잡은 Spark의 용어와 동작..

목차 대용량 쿼리 시리즈대용량 데이터가 느린 이유와 최적화의 원리 | 대용량 쿼리 (1)느린 쿼리, 인덱스와 실행계획으로 잡기 (PostgreSQL) | 대용량 쿼리 (2)분산 처리 입문: 셔플과 파티셔닝, 조인 전략 | 대용량 쿼리 (3)수억 행을 견디는 DB 설계: 파티셔닝과 샤딩 | 대용량 쿼리 (4)PostgreSQL VACUUM과 커넥션 풀링, 운영의 함정 | 대용량 쿼리 (추가) 들어가며1부에서는 대용량 데이터가 느린 이유와 최적화의 공통 원리를 다루었다. 이번 편은 그 원리 가운데 단일 데이터베이스에서 되돌릴 수 있는 처방, 즉 튜닝을 PostgreSQL 기준으로 구체화한다. 모든 손질은 진단이 먼저이므로, 어디가 왜 느린지를 실행계획으로 읽는 데서 출발한다. 그다음 전체 탐색을 줄이는 인덱..

목차 대용량 쿼리 시리즈대용량 데이터가 느린 이유와 최적화의 원리 | 대용량 쿼리 (1)느린 쿼리, 인덱스와 실행계획으로 잡기 (PostgreSQL) | 대용량 쿼리 (2)분산 처리 입문: 셔플과 파티셔닝, 조인 전략 | 대용량 쿼리 (3)수억 행을 견디는 DB 설계: 파티셔닝과 샤딩 | 대용량 쿼리 (4)PostgreSQL VACUUM과 커넥션 풀링, 운영의 함정 | 대용량 쿼리 (추가) 들어가며데이터의 양이 적을 때는 쿼리를 어떻게 작성하든 결과가 빠르게 돌아온다. 그러나 데이터가 수억 행 규모에 이르면 같은 쿼리가 갑자기 수십 초씩 걸리기 시작한다. 이 차이는 쿼리 문장의 우열보다 데이터가 물리적으로 어디에 있고 얼마나 움직이는지에서 비롯된다. 이 글은 대용량 데이터가 왜 느려지는지를 먼저 살피고..

목차 들어가며리눅스(Linux, 서버 환경에서 가장 널리 쓰이는 운영체제) 서버는 클라우드와 웹 백엔드, 컨테이너(container, 애플리케이션을 격리해 실행하는 가상 단위)의 기반을 이루며 그만큼 공격의 표적이 된다. 2026년 현재 침해 사고의 60퍼센트 이상이 복잡한 제로데이(zero-day, 공개되거나 고쳐지기 전에 악용되는 알려지지 않은 취약점)가 아니라 잘못된 설정에서 비롯되는 것으로 보고된다. 공격은 자동화되어, 취약한 서버를 찾아 악용하기까지 걸리는 시간이 몇 주가 아니라 몇 시간 단위로 줄었다. 이런 환경에서 단일한 방어선 하나에 의존하는 방식은 더 이상 전략이 아니라 요행에 가깝다. 다층 방어(Defense in Depth, 여러 겹의 통제를 쌓아 한 겹이 뚫려도 다음 겹이 막는 설계..

목차 들어가며앞 글에서 다룬 하둡(Hadoop)은 거대한 데이터를 여러 대의 컴퓨터에 나누어 저장하고 처리하는 길을 열었다. 그러나 하둡의 처리 방식인 맵리듀스(MapReduce)는 단계마다 디스크에 결과를 기록해 속도가 느렸다. 이 한계를 넘어서기 위해 등장한 것이 아파치 스파크(Apache Spark)이다. 스파크는 데이터를 디스크가 아니라 메모리에서 처리해 훨씬 빠른 속도를 낸다. 이 글은 스파크라는 이름을 처음 들어 보는 독자도 따라올 수 있도록 기초부터 설명한다. 스파크가 왜 등장했는지, 무엇이며 어떻게 빠른지, 그리고 지금 어디에 서 있는지를 차례로 다룬다.맵리듀스는 너무 느렸다단계마다 디스크에 쓰는 맵리듀스의 한계하둡의 맵리듀스는 데이터를 맵 단계와 리듀스 단계로 나누어 처리한다. 문제는 각..