Kafka랑 YARN 중에 고르는 줄 알았다 — 서비스 뒤의 구조를 알아가는 중

About this offer

오늘은 프로젝트의 더블노드 구성을 돌아보다가 질문 하나가 생겼다. “우리 분산 처리한 부분 있잖아. Kafka를 쓸지, YARN을 쓸지 선택했던 거야?” Kafka도 분산 시스템이고, YARN도 분산 처리할 때 등장한다. 여기에 Kubernetes까지 나오니 머릿속에서는 전부 비슷한 자리에 놓여 있었다. 이름은 들어봤는데, 서로 무엇을 대신할 수 있는지는 흐릿했던 것이다. 이 질문을 시작으로 이야기를 이어가다 보니 프론트엔드와 백엔드 뒤에 있는 구조가 조금씩 보이기 시작했다. 나중에 또 헷갈릴 것 같아서, 오늘 이해한 흐름을 남겨보려고 한다. 이 글은 기술별 도입 가이드보다는, 각 기술이 서비스의 어느 부분을 맡는지 정리한 학습 기록이다. 일단 Kafka와 YARN은 같은 선택지가 아니었다 가장 먼저 정리한 건 역할이었다. 기술 맡는 역할 떠올릴 질문 Kafka 이벤트를 받아 보관하고 전달한다 들어오는 데이터를 어떻게 전달하고 다시 읽을까? Spark 데이터를 나눠 실제 계산을 수행한다 이 많은 데이터를 어떻게 집계할까? YARN 여러 서버의 실행 자원을 관리한다 계산할 프로그램에 어느 서버의 CPU와 메모리를 줄까? HDFS 파일을 저장하고 접근하게 한다 처리할 원본과 결과를 어디에 둘까? 이렇게 놓으니 조금 명확해졌다. Kafka와 YARN은 둘 중 하나를 골라 끼우는 부품이 아니었다. Kafka는 데이터가 흘러가는 쪽에 있고, YARN은 그 데이터를 처리할 프로그램의 실행 자원을 관리하는 쪽에 있다. 실제 계산은 Spark가 한다. 예를 들어 이런 조합도 가능하다. 수집 프로그램 → Kafka → Spark → 처리 결과 저장 ↑ 실행 자원은 YARN이 관리 물론 모든 서비스에 이 구성이 필요한 것은 아니다. 중요한 건 함께 사용할 수 있는 서로 다른 역할이라는 점이다. 그럼 우리 더블노드에서는 누가 무엇을 했을까? 우리 Classet에서 이야기한 더블노드는 기존 데이터를 Spark로 처리하면서, 데이터 서버와 서비스 서버 양쪽에 계산을 맡기는 구성이었다. HDFS 는 양쪽에서 접근할 입력·출력 파일을 제공했다. YARN 은 두 서버에서 Spark가 실행될 자원을 관리했다. Spark executor 는 할당된 자원 위에서 실제 계산 작업을 수행했다. executor는 Spark 애플리케이션의 계산 작업을 실행하는 프로세스다. Spark의 driver가 작업을 조정하고 executor들에게 태스크를 보낸다. 우리 구성에서는 서비스 서버에 YARN의 NodeManager를 추가해 계산에 참여시켰다. 여기서도 하나 구분할 게 있다. 계산에 참여하는 서버가 두 대라는 것과, HDFS 저장 노드를 두 대로 늘렸다는 것은 다른 이야기다. 해당 분산 처리 실험에서는 HDFS DataNode를 추가하지 않았다. 이제 이 작업을 설명한다면 이렇게 말하는 게 맞다. “Spark의 분산 연산을 두 EC2에 배치하기 위해 YARN을 활용했다.” 기존 파일을 묶어서 계산하는 작업이었으니, 두 노드로 분산하기 위해 Kafka를 추가할 필요는 없었다. 또 이 구성은 필요할 때 전환해서 사용한 것이지, 두 노드가 항상 떠 있다는 의미도 아니다. Kafka는 실시간 처리할 때만 쓰는 걸까? 처음에는 “아, Kafka는 실시간성이 중요할 때 쓰는 거구나” 하고 이해했다. 틀린 방향은 아니지만, 그것만으로 설명하기에는 빠지는 부분이 있었다. Kafka는 계속 들어오는 데이터를 다룰 때 유용하다. 동시에 데이터를 만드는 쪽과 처리하는 쪽의 속도가 달라도 일을 이어갈 수 있게 해준다. 뉴스가 평소에는 조금씩 들어오다가 어느 순간 몰린다고 해보자. 처리 프로그램이 전부 즉시 처리하지 못해도 Kafka에 보관된 이벤트를 자기 속도에 맞춰 읽을 수 있다. 서로 다른 프로그램이 같은 이벤트를 각자 활용하거나, 보관 기간 안의 데이터를 다시 읽는 것도 가능하다. 주문 서비스로 생각하면 더 와닿는다. 주문 발생 → 주문 데이터 저장 → 사용자에게 응답 │ └→ 주문 이벤트 → Kafka ├→ 알림 처리 ├→ 매출 통계 └→ 추천 반영 주문 하나 때문에 알림, 통계, 추천이 모두 끝날 때까지 기다릴 필요가 없도록 후속 작업을 나눌 수 있는 것이다. 다만 그림처럼 선을 연결했다고 끝나는 건 아니다. 주문은 저장됐는데 이벤트 전달에 실패하면 어떻게 할지, 같은 이벤트를 두 번 받으면 어떻게 할지, 통계 반영이 늦어져도 괜찮은지 등을 설계해야 한다. Kafka를 넣으면 자동으로 모든 처리가 실시간이 되는 것도 아니다. 소비자가 처리하는 속도가 느리면 데이터는 계속 쌓인다. 도구가 해결해 주는 문제와 새로 관리해야 하는 문제가 함께 생긴다. Kubernetes는 YARN과 조금 더 가까웠다 그다음 질문은 자연스럽게 이거였다. “그러면 Kubernetes는 또 다른 역할이야?” Kubernetes는 여러 서버에서 컨테이너가 어디에, 몇 개, 어떤 상태로 실행될지 관리한다. 컨테이너가 종료되면 원하는 실행 상태를 회복하고, 배포나 확장도 관리한다. YARN과는 관리하는 대상과 방식에 차이가 있지만, Spark를 여러 서버에서 실행할 자원을 관리한다는 면에서는 역할이 겹친다. 그래서 Spark를 실행할 클러스터 관리자를 고른다면 다음이 비교 대상이 된다. YARN Spark Standalone Kubernetes 우리는 기존 Hadoop·YARN 환경을 확장해서 두 서버가 계산에 참여하도록 구성했다. Kubernetes를 사용했다면 Spark 실행 환경도 그에 맞게 구성해야 했을 것이다. 그리고 Docker와 Kubernetes도 구분해야 한다. Docker는 프로그램과 필요한 환경을 이미지로 묶어 컨테이너로 실행하는 데 사용하고, Kubernetes는 여러 서버에 걸친 컨테이너 실행을 관리한다. Docker를 쓴다고 Kubernetes가 반드시 따라오는 건 아니다. 작은 서비스라면 한 서버와 Docker Compose로도 충분히 운영할 수 있다. 여기서부터 서비스가 조금 다르게 보이기 시작했다 지금까지 서비스를 떠올릴 때 가장 먼저 그렸던 구조는 이거였다. 사용자 → 프론트엔드 → 백엔드 → DB 틀린 그림은 아니다. 사용자의 요청이 어떻게 처리되는지 잘 보여준다. 다만 이 그림에는 아직 답하지 않은 질문이 많다. “백엔드는 어느 컴퓨터에서 계속 실행하지?” “사용자가 입력한 도메인은 어떻게 그 서버를 찾아가지?” “DB에 들어 있는 통계 데이터는 누가 만들어 놓았지?” “프로그램이 죽거나 데이터 갱신이 멈추면 어떻게 알지?” 이 질문들을 따라가면 서비스에 적어도 세 가지 흐름이 있다는 걸 알 수 있다. 1. 사용자의 요청을 처리하는 흐름 사용자가 상품 목록을 열면 프론트엔드가 API를 호출하고, 백엔드가 DB를 조회해서 결과를 돌려준다. 실제 환경에서는 도메인을 주소로 연결하는 DNS, 통신을 암호화하는 HTTPS, 요청을 전달하는 프록시나 로드밸런서도 관여한다. 브라우저 → 서비스 진입점 → 백엔드 → 서비스 DB HTTPS 요청 전달·분산 프론트엔드와 백엔드가 하나씩 있다고 서버도 두 대인 건 아니다. 한 서버에 여러 프로그램을 띄울 수도 있고, 같은 백엔드를 여러 서버에 복제해서 실행할 수도 있다. 2. 서비스에 필요한 데이터를 준비하는 흐름 오늘의 인기 상품, 월별 매출 통계, 수많은 뉴스에서 뽑아낸 이슈는 처음부터 DB에 완성된 형태로 들어 있지 않다. 원본을 가져오고, 중복과 오류를 정리하고, 집계나 분석을 거쳐 만들어야 한다. 외부 API·파일·사용자 행동 기록 ↓ 수집 ↓ 원본 저장 ↓ 정제·분석·집계 ↓ 서비스용 결과 저장 ↓ 백엔드에서 조회 이 과정이 데이터 파이프라인이다. 예를 들어 최근 5년 통계를 보여줄 때마다 원본부터 전부 계산하면 화면이 느릴 수밖에 없다. 미리 월별로 집계해 두면 백엔드는 작은 결과만 읽으면 된다. 빠른 API 뒤에 미리 계산해 둔 데이터가 있을 수 있다는 것. 오늘 이해한 내용 중 특히 기억해 두고 싶은 부분이다. 3. 앞의 두 흐름을 실행하고 지켜보는 흐름 작업이 매일 정해진 시간에 실행돼야 하고, 수집에 성공했을 때만 정제를 시작해야 한다면 작업의 일정과 순서를 관리해야 한다. 서버가 여러 대라면 프로그램을 어디에 배치할지도 정해야 한다. 실행 중에 오류가 나면 알아차릴 방법도 있어야 한다. 여기에 Airflow, YARN, Kubernetes, 모니터링 도구가 등장한다. 도구 주로 관리하는 것 Airflow 작업의 일정, 순서, 의존 관계, 재시도 YARN 데이터 처리 애플리케이션의 실행 자원 Kubernetes 컨테이너의 배치, 개수, 실행 상태 Prometheus 시스템과 애플리케이션의 수치 지표 수집 Grafana 지표 등을 대시보드로 시각화 Loki 로그 수집·저장·조회 Airflow가 직접 Spark의 집계 연산을 대신하는 것은 아니다. 예를 들면 이런 관계다. 매일 새벽 Airflow가 Spark 작업을 시작한다. Spark는 YARN에서 실행 자원을 확보한다. executor들이 계산을 마치면 Airflow가 다음 결과 반영 작업을 시작한다. 전부 “관리 도구”처럼 들렸는데, 무엇을 관리하는지 나누니 차이가 보였다. 실시간과 분산도 따로 생각해야 했다 두 개를 자꾸 한 덩어리로 생각해서 함께 정리했다. 구분 질문 배치·스트리밍 데이터를 모아서 작업 단위로 처리할까, 계속 들어오는 데이터를 지속적으로 처리할까? 실시간성 들어온 데이터가 결과에 반영되기까지 얼마나 걸릴까? 단일·분산 한 컴퓨터에서 실행할까, 여러 컴퓨터가 나눠 실행할까? 과거 10년치 데이터를 여러 서버에서 계산하면 분산 배치 처리 다. 실시간으로 들어오는 데이터라도 양이 적으면 한 서버에서 처리할 수 있다. Spark와 Flink도 각각 배치 전용, 실시간 전용으로 외우면 안 된다. 둘 다 배치와 스트리밍을 지원하며, 어떤 처리 방식과 지연 요구에 맞는지를 봐야 한다. 이름이 너무 많아서 역할별로 놓아봤다 새로 알게 된 이름을 전부 깊게 파기보다는, 일단 어느 위치에 있는지 정리했다. 같은 줄에 있다고 완전히 같은 도구라는 뜻은 아니다. 역할 대표 기술 외부 시스템 연결·변경 데이터 수집 Kafka Connect, Debezium 이벤트 전달·작업 큐 Kafka, RabbitMQ 대량 원본 보관 HDFS, Amazon S3 데이터 계산 Spark, Flink 작업 순서·일정 관리 Airflow, Dagster SQL 중심 분석 데이터 변환 dbt 분석용 데이터 저장·조회 BigQuery, Snowflake, ClickHouse 여러 저장소 통합 SQL 조회 Trino 서버·네트워크 같은 인프라 생성 Terraform 패키지 설치·서버 설정 자동화 Ansible 빌드·테스트·배포 자동화 Jenkins, GitHub Actions Kubernetes 배포 상태를 Git 설정과 동기화 Argo CD HDFS는 분산 파일 시스템이고 S3는 객체 저장소다. Kafka와 RabbitMQ도 메시지를 전달한다는 공통점이 있지만, 이벤트 보관·재처리와 작업 큐·라우팅 등에서 주로 활용하는 방식이 다르다. 이 표는 도입 후보를 바로 정하는 비교표보다는, 공부할 때 길을 찾기 위한 지도에 가깝다. 그렇다고 전부 넣어야 하는 건 아니다 이름을 이렇게 늘어놓고 보니 “서비스 하나 만들려면 이걸 다 알아야 하나?” 싶은 생각도 든다. 하지만 실제로 필요한 구성은 서비스의 요구와 문제에 따라 달라진다. 처음에는 서버 한 대에 프론트엔드, 백엔드, DB를 두고 기본적인 배포·백업·모니터링을 갖추는 것으로 충분할 수 있다. 데이터가 커져서 계산을 나눠야 할 때 분산 처리를 검토하고, 여러 후속 작업을 분리해야 할 때 메시지 전달 구조를 검토하고, 실행할 컨테이너와 서버가 많아질 때 관리 방식을 고민하는 것이다. 운영에서는 “떠 있다”와 “정상이다”도 다르다. API가 살아 있어도 응답이 너무 느릴 수 있고, 화면은 멀쩡해도 파이프라인이 실패해서 어제 데이터가 보일 수 있다. 서버 자원뿐 아니라 응답 시간, 오류율, 데이터의 마지막 갱신 시각도 봐야 한다. 오늘 바뀐 질문 오늘 대화가 끝날 때 이런 말을 했다. “지금까지 백엔드, 프론트엔드가 중요하다고 생각했는데, 지금 완전 그 뒤쪽 이면 구조를 파악해 가는 과정인 것 같아.” 화면을 만들고 API를 연결하는 일이 서비스의 큰 부분인 건 여전하다. 이제는 그 코드가 어디에서 실행되고, 화면에 나올 데이터가 어떻게 준비되며, 그 과정이 계속 돌아가도록 무엇이 받쳐 주는지도 함께 보인다. 다음에 새로운 기술 이름을 만나면 먼저 세 가지를 물어보려고 한다. 무엇을 입력받고, 무엇을 내보낼까? 데이터를 저장·전달·계산할까, 프로그램의 실행을 관리할까? 지금 우리 서비스의 어떤 문제를 해결해 줄까? Kafka와 YARN 중 뭘 고르는지 묻던 데서 시작했는데, 이제는 각 기술이 들어갈 자리를 먼저 찾아볼 수 있을 것 같다. 참고 자료 Apache Kafka 소개 Spark 클러스터 구조 Kubernetes 개념 Airflow 소개 Prometheus 시작하기