개발블로그, 숲

Apache AirflowApache Airflow는 워크플로우를 자동화하고 관리하기 위한 오픈 소스 플랫폼입니다. DAG(Directed Acyclic Graph)를 기반으로 작업(Task)을 정의하고 실행하며, 다양한 Operator를 활용해 여러 유형의 작업을 수행할 수 있습니다. DAG (Directed Acyclic Graph)DAG는 작업의 실행 순서를 정의하는 그래프로, 각 작업(Task)의 종속성을 표현합니다. Airflow에서는 DAG를 통해 복잡한 워크플로우를 쉽게 정의할 수 있습니다. 주요 특징작업 간의 실행 순서를 정의합니다.반복 실행이 가능하며 스케줄링을 지원합니다.DAG 내 모든 Task는 서로 연결되어야 합니다. DAG 실행 (DAG Run)DAG 실행(DAG Run)은 특정 ..

Kubernetes(K8s)는 애플리케이션의 여러 구성 요소를 파드(Pod) 형태로 모델링하여 관리합니다. 파드는 하나 이상의 컨테이너를 포함하며, K8s는 이를 클러스터 내에서 동적으로 배치하고 관리합니다. 하지만 파드는 재배포될 때마다 IP 주소가 변경되므로, K8s는 이를 해결하기 위해 서비스(Service) 리소스를 제공합니다. 서비스(Service)란? 서비스는 파드 간 통신을 안정적으로 제공하기 위한 K8s의 핵심 리소스입니다. 클러스터 내부와 외부 간의 트래픽을 원활하게 처리할 수 있도록 다음과 같은 주요 기능을 수행합니다.주요 기능어드레스 디스커버리(Address Discovery)Kubernetes의 서비스는 파드의 IP가 변경될 때마다 이를 자동으로 추적하고, 클러스터 내 DNS를 통해..

파드(Pod)Kubernetes(K8s)가 하나 이상의 컨테이너를 효과적으로 관리하고 애플리케이션을 더 잘 분리하고 배포하기 위해 사용하는 가장 작은 배포 단위로, 컴퓨팅의 단위 역할을 합니다.이는 애플리케이션의 실행 환경을 제공하며, 클러스터를 이루는 노드 중 하나에서 실행됩니다.노드 간 이동이나 복구 작업 시에도 Kubernetes가 이를 자동으로 관리합니다. 주요 특징자체 복구(Self-Healing) 애플리케이션 관리 기능과 원하는 상태(desired state) 관리Kubernetes는 파드의 상태를 지속적으로 모니터링하며, 문제가 발생하거나 파드가 실패할 경우 비정상적으로 종료된 파드를 재시작하거나, 정의된 개수만큼 파드를 유지하기 위해 새로운 파드를 생성하는 등 자동으로 복구하거나 대체합니다..

3년 동안 4번의 글또를 마치며 블로그와 노션, 그리고 옵시디언을 통해 글을 정리하고 작성할 수 있었다. 매번 글또에 참여할 때마다 조금씩 더 나아지고 꾸준히 글을 작성하게 되었고, 이제는 그 과정이 습관처럼 자리 잡았다. 만약 내가 글또에 참여하지 않았더라면, 이 글들은 작성되지 않았을 것이고, 나의 생각과 학습 내용을 기록으로 남기지도 못했을 것이다.또한 다양한 분들의 글을 읽으며 생각의 폭을 넓힐 수 있었고 좋은 분들을 많이 만날 수 있어 감사했다.그래서 이번 기수에도 주저 없이 참여하게 되었다. 글또가 나에게 얼마나 큰 동기부여가 되었는지 알기에, 내가 배운 것들을 이번 기수에도 계속 정리하고자 한다. 어떤 글감으로 진행할지쿠버네티스 이해하기 몇 개월 전, "쿠버네티스 교과서"라는 책을 완독하기 ..

【한글자막】 Java 멀티스레딩, 병행성 및 성능 최적화 - 전문가 되기 강의는 Java 멀티스레딩에 대한 체계적이고 포괄적인 이해를 제공하는데, 이를 바탕으로 실제 실무에서 개발시 많은 도움을 얻을 수 있었습니다. 강의는 초보자부터 중급자까지 폭넓게 다루고 있어, 멀티스레딩의 핵심 개념부터 고급 기술까지 이해하기 쉽게 설명하고 있습니다. 강의의 첫 부분에서는 Java의 스레드 모델 및 멀티스레딩의 기본 개념을 다룹니다. 이 부분은 멀티스레딩에 대한 기초를 이해하는 데 큰 도움이 되었습니다. 또한, 스레드의 생성과 제어, 동기화 메커니즘에 대한 설명도 명확하게 제공되어 병행성에 대한 이해를 높일 수 있었습니다. 강의의 중간 부분에서는 멀티스레딩을 활용하여 병렬성을 증가시키고 성능을 최적화하는 방법에 대해..

카프카 리플리케이션 카프카는 많은 데이터 파이프라인의 정중아에 위치하는 메인 허브 역할로 정상 동작 하지 않을시 심각한 문제 → 안정성 확보를 위해 카프카 내부에서 리플리케이션 동작 리플리케이션 동작 개요 replication factor 카프카의 리플리케이션 동작을 위해 토픽 생성시 필수값 리더와 팔로워 리더 리플리케이션 중 하나가 선정되어 모든 읽기 쓰기는 리더를 통해서만 가능 프로듀서는 리더에게만 메시지 전송 / 컨슈머도 오직 리더로 부터 메시지 가져옴 팔로워 리더에 문제가 발생하거나 이슈가 있을 경우를 대비해 언제든지 새로운 리더가 될 준비 컨슈머가 토픽의 메시지를 꺼내 가는 것과 비슷하게 파티션의 리더가 새로운 메시지를 받았는지 확인하고, 새로운 메시지가 있다면 이를 리더로부터 복제 복제 유지와..

카프카 기초 다지기 주요 요소 주피커 카프카의 메타데이터 관리 및 브로커 health check 브로커 카프카가 설치된 서버 / 노드 프로듀서 카프카로 메세지 보내는 클라이언트 컨슈머 카프카에서 메시지를 꺼내가는 클라이언트 토픽 카프카는 메시지 피드들을 토픽으로 구분, 토픽 이름은 카프카 내 고유 파티션 병렬 처리 및 고성능을 위해 여러 토픽을 여러 개로 나눈 것 세그먼트 프로듀서가 전송한 실제 메시지가 브로커의 로컬 디스크에 저장 메시지 / 레코드 프로듀서가 브로커로 전송하거나 컨슈머가 읽어가는 데이터 조각 리플리케이션 메시지들을 여러 개로 복제해서 카프카 클러스터 내 브로커들에 분산하는 동작 → 하나의 브로커가 종료되어도 카프카 안정성 유지 옵션 —replication-factor {숫자} 카프카 내..

안정적인 운영을 위한 주키퍼와 카프카 구성 주키퍼 구성 최근에는 주키퍼의 의존성을 제거하려 하는 움직임 주키퍼는 파티션과 브로커의 메타데이터를 저장, 컨트롤러 서버를 선출하는 동작 수행 주키퍼 서버 수량 쿼럼(과반수) 구성 기반 동작임으로 반드시 홀수 과반수를 충족할 수 있는 수까지만 장애 허용 (3대면 1대만 장애 허용) 일반적 3, 핵심 중앙 데이터 파이프라인이면 5 하드웨어 메모리 4~8GB, 디스크는 240/480G SSD 과도한 물리 메모리는 낭비 트랜잭션이나 스냅샷 로그는 로컬 디스크에 저장함으로 Write 성능 좋은 SSD 추천 네트워크 1G 이더넷 배치 각기 다른 랙에 분산 배치, 전원 / 스위치 이중화 카프카 구성 서버 수량 최소 3개의 브로커 손쉬운 서버 확장 가능함으로 필요한 만큼만 ..