최근 스파크를 이용하여 스트리밍 데이터를 델타레이크로 저장할 때 발생한 문제를 소개하고자 한다. 현재 작업 중인 환경에서는 스파크 스트리밍의 마이크로 배치 처리시간이 평균적으로 일반적인 쓰기 작업은 10 초 내외이고, 10 번의 쓰기 작업마다 새로운 체크포인트 파일을

스파크를 이용하여 스트리밍 데이터를 델타레이크로 저장할 때 체크포인트가 성능에 어떠한 영향을 미치는지 살펴보고, 이를 개선할 수 있는 멀티파트 체크포인트 기능에 대해 알아보도록 하자.(아래의 실험 환경은 모두 마이크로 배치 간격이 1 분으로 설정되어 있다.)위의 그래프

델타레이크는 효율적인 읽기 작업을 위해 여러 가지 최적화 기법을 제공한다. 최적화 기법은 크게 델타로그를 이용해서 데이터 파일을 필터링하는 방식과 파케이(Parquet)가 제공하는 필터링 기능을 이용하는 방식으로 나뉜다. 오늘은 아래 예제를 이용해서 필수적인 최적화 기

델타레이크는 쓰기 작업이나 여러 최적화 과정(Compaction, Z-Order, ...)이 반복될수록 로그가 쌓여간다. 이렇게 로그가 지속적으로 쌓여가면 마지막 상태 정보를 담고 있는 스냅샷을 만드는 작업이 점점 더 오래 걸릴 수 밖에 없어진다. 이 문제를 개선하기

스파크로 유명한 데이터브릭스에서 몇 년전에 공개한 델타레이크(DeltaLake)라는 기술은 데이터레이크와 데이터웨어하우스의 장점을 합친 레이크하우스 아키텍처의 핵심 기술이다. 이는 기존에 (기술적인/비용적인 한계로 인해) 원시 데이터는 데이터레이크에, 가공 데이터는 데

Cilium 이 최근 공개한 eBPF 기반의 서비스 메쉬에서 중요하게 언급하고 있는 것 중에 하나는 Pod 마다 사이드카 형태로 프록시를 추가하지 말고 노드별로 하나씩만 설치해서 사용하자는 것이다. 이는 특히 대규모의 클러스터에서 많은 사이드카 프록시로 인해 발생하는

오늘은 최근 회사에서 GitOps 를 적용하기 위해 ArgoCD 를 설치하던 중 발생했던 네트워크 정책(NetworkPolicy) 관련된 문제에 대해 살펴보고자 한다.Helm 을 이용하여 ArgoCD 를 설치하였는데 아래와 같이 두 개의 Pod 만 동작하지 않는 문제가

쿠버네티스처럼 다양한 워크로드를 제한된 자원을 이용하여 효율적으로 실행해야하는 플랫폼에서는 QoS 의 역할과 보장이 매우 중요하다. 특히 성능에 큰 영향을 주는 메모리 관리는 무엇보다 중요하며, 최근 CGroupV2 와 스왑 지원으로 메모리 관리 기능이 점점 더 강화되

리눅스는 패킷의 출발지 주소를 마음대로 조작해서 공격하는 IP 스푸핑 공격을 막기위해 RPFilter (Reverse Path Filter) 라는 기능을 제공한다. 이 기능은 간단히 소개하면 특정 네트워크 장치로 들어온 패킷이 동일한 네트워크 장치로 나갈 수 있는지를

최근 공개된 우분투 21.10 은 컨테이너와 관련된 상당히 큰 부분이 변경되었다. 마침내 CGroupV2 가 적용되었고, 도커도 업그레이드되면서 CGroup 네임스페이스의 기본값이 Private 으로 설정되었다. 오늘은 이로 인해 발생한 문제에 대해 자세히 살펴보도록

오늘은 지난 글에서 소개했던 NAT 루프백 문제에 대해 다시 소개하고자 한다. 이유는 몇 개 국가의 IDC 혹은 클라우드에서 NAT 루프백 문제를 해결하기 위해 라우터에 필요한 설정을 추가했음에도 불구하고 원인을 정확히 알 수 없는 이유로 동작하지 않는 문제가 발생해서

BPF 파일을 컴파일하면 BPF 코드가 생성된다. 이 BPF 코드는 자바 바이트코드처럼 특정 CPU 에 종속적이지 않은 일종의 중간코드이고, 리눅스 커널은 런타임에 몇 가지 방법으로 이 BPF 코드를 실행한다. 오늘은 리눅스 커널이 BPF 코드를 실행하는 방식에 대해

BPF 는 일반적으로 하나의 함수(메인함수)가 하나의 섹션이 되고, 하나의 섹션이 하나의 프로그램이 된다. 그래서 커널에서 해당 프로그램을 실행할 때는 프로그램의 시작 위치가 메인함수의 시작 위치이기 때문에 간단히 처음부터 실행하면 된다. 하지만 아래와 같이 메인함수에

BPF 는 일반적인 프로그램과 유사한 방식으로 개발하기 때문에 유사한 실행파일 및 메모리 구조를 가지고 있지만, 커널 안에서 제한된 환경으로 실행되기 때문에 로딩(loading)하는 과정은 상당히 다르다. 오늘은 BPF 의 실행파일 및 메모리 구조에 대해 간단히 살펴본

최근 몇 년간 리눅스 커널 커뮤니티에서 가장 주목받고 있는 기술은 누가 뭐래도 eBPF 일 것이다. 리눅스 커널에 안정성과 확장성, 그리고 생산성을 동시에 부여하는 혁신적인 기술로, 대표적인 쿠버네티스의 CNI 인 Cilium과 Falco, Pixie 등 다양한 오픈소

쿠버네티스는 기본적으로 메모리 스와핑을 지원하지 않는다. 20년 넘는 시간동안 운영체제 관련 연구/개발을 수행하면서 메모리 스와핑이 만들어내는 다양한 문제들에 대한 연구를 많이 봤었고, 이러한 문제들때문에 메모리 스와핑을 강제로 막는 경우도 많이 봤었기 때문에 딱히 이

오늘은 Cilium 에서 소켓 기반 로드밸런싱을 이용할 때 발생하는 EnvoyProxy 사이드카 우회 문제에 대해 살펴보고자 한다. 이는 현재 모든 서비스 메쉬(Istio, Linkerd, ...)에서 서비스 IP 기반으로 동작하는 모든 필터를 우회하는 심각한 문제를

오늘은 어떤 국가의 지역 클라우드 서비스를 이용하여 쿠버네티스 클러스터를 구축하던 중 발생했던 NAT 루프백 문제(Hairpin NAT)를 파악하고 해결했던 과정에 대해 간단히 소개하고자 한다. 일반적으로는 크게 신경쓰지 않아도 되는 문제인데, 해당 국가의 클라우드 서

우리 회사에서는 주로 의료데이터를 다루다보니 개인정보보호법에 의해 서비스를 운영하는 국가 외부로 데이터가 유출되면 안 된다. 그래서 한국이나 미국 같이 AWS 나 GCP 리전이 있는 국가들은 해당 서비스를 이용하여 운영할 수 있지만, 해당 국가에 리전이 없는 경우에는

Cilium 에서 ClusterIP 서비스로 통신할때 로드밸런싱이 이루어지는 과정은 아래 그림과 같다. 왼쪽 그림은 네트워크 기반 로드밸런싱 방식이고, 오른쪽 그림은 소켓 기반 로드밸런싱 방식이다. 간단한 설명을 위해 백엔드가 같은 노드에 있는 경우만 살펴보자.cili