전체 글

Data Engineering과 Cloud Native 기술에 대해 Dive Deep 하는 플랫폼 엔지니어가 되는 것을 목표로 하고 있습니다. 경험과 공부한 내용을 기록하며 지속가능한 엔지니어가 되는 것이 꿈입니다.
분산 메시지 큐1. 메시지 모델1. point-to-point model : 전통적인 메시지 큐. 큐에 전송된 메시지는 한 소비자만 가져갈 수 있음. 메시지를 가져갔다는 뜻으로 ACK 를 보내면, 큐에서 해당 메시지가 삭제됨. 2. publish-subscribe model : 토픽에 메세지를 보내고 토픽으로부터 메세지를 받음. 메세지는 해당 토픽을 구독하는 모든 소비자들에게 전달됨. 메세지는 토픽에 보관됨. 토픽을 여러 파티션으로 나눠서, 메시지를 균등하게 각각의 파티션에 보내어 분산 배치함. 2. 문제의 설계 요구 조건 메세지 큐의 기본 조건 : 생산자는 메시지를 큐에 보내고, 소비자는 큐에서 메시지를 꺼낼 수 있어야 한다. 기본 기능 외에도 성능, 메시지 전달 방식, 데이터 보관 기간 등을 고려해야..
Intro 비즈니스는 오래 가고, 기술은 자주 바뀐다데이터 엔지니어에서 백엔드 엔지니어로 전향하면서, 코드로 해결해야 하는 문제가 훨씬 더 많아졌다. 지금은 MAU가 꽤 나오는 글로벌 이커머스 백엔드를 만들고 있다. 트래픽도, 요구사항도, 의존하는 외부 시스템도 많다 보니 코드베이스는 빠르게 커지고 복잡도도 함께 증가한다.그래서 단순히 “기능을 구현하는 방법”이 아니라, 유지보수와 확장에 강한 구조를 더 진지하게 공부해야겠다고 느꼈다. 이 글에서는 현재 실무에서 백엔드 개발에서 자주 사용중인 Usecase 패턴을 중심으로, 실제 이커머스 도메인에서 어떻게 적용할 수 있는지 정리해보려 한다. 전통적인 Controller–Service–Repository 구조의 한계전통적인 Backend pattern 은 ..
SI(시스템 통합) 경력을 만 2년 채우고 운 좋게 인하우스 개발 부서로 이동한 지 한 달 만에, 결국 이직을 결심하게 되었습니다. 사실 저는 정말 많이 떨어져 봤고, 이번에 처음으로 최종 합격이라는 결과를 받았습니다. 그동안 스스로를 의심하고, 초조하고 불안해하기도 했지만, 꾸준히 준비해서 원하는 결과를 만들어냈습니다. 이 글은 저의 이직 준비 과정을 회고하며, 같은 고민을 하는 누군가에게 조금이나마 도움이 되었으면 하는 마음으로 작성합니다.1. 이직을 결심한 사유1) (상대적으로) 더 보상체계가 훌륭한 곳을 가고 싶어서2) 서비스 회사에서의 경험을 쌓고 싶어서SI 특성상 너무 빠르게 바뀌는 프로젝트 환경, 사람, 그리고 운영 및 유지보수 경험이 적었습니다.SI 회사에서 서비스 회사로 이직하고 싶다는 ..
정렬 알고리즘이 중요한 이유많은 알고리즘에서 정렬은 필수 전처리 단계로 사용된다. 정렬된 데이터는 이진 탐색처럼 빠른 탐색 알고리즘을 사용할 수 있다. 사람이나 시스템이 데이터를 해석하기 더 쉬워진다. ex. 시간순 , 크기 순, 알파벳 순정렬을 통해서 중복된 값들을 모아 놓을 수 있으므로, 효율적으로 중복 제거를 할 수 있으며 그룹 처리에 유리하다. 버블 정렬 Bubble Sort버블 정렬은 한번 순회할때 정렬되지 않은 값들중에서 가장 큰 값을 찾아서 맨 뒤로 보낸다. 맨 첫번째 정렬 시도에서는 가장 큰 값을 찾아서 배열의 맨 뒤로 보내고, 두번째 정렬시도에서는 두번째로 큰 값을 찾아서 맨 뒤에서 두번째로 보낸다. 1. 공간 복잡도 : O(1)별도의 추가 공간 없이 주어진 배열 안에서 크기 비교와 s..
Intro그동안 ETL 파이프라인 구축 중심의 프로젝트를 해왔는데, 이번에는 처음으로 MLOps 파이프라인을 다뤄보게 되었다. 약 2개월간 진행된 프로젝트를 마치며, 그 과정에서 얻은 기술적인 인사이트와 소프트 스킬에 대한 회고를 남겨본다.MLOps 오케스트레이션 - Data Factory이번 프로젝트에서는 MLOps 파이프라인을 오케스트레이션하기 위해 Azure Data Factory (ADF) 를 사용했다.Azure 공식 문서에 따르면 ADF는 복잡한 하이브리드 ETL, ELT 및 데이터 통합 작업을 위한 완전 관리형 클라우드 서비스다. 일반적으로 Apache Airflow와 비교되곤 하는데, 두 도구 모두 워크플로우 오케스트레이션 도구로서 데이터 이동 및 처리 파이프라인 구축, 배치 파이프라인 스케..
1. Spark Data Skew 란?Spark 클러스터에서, Data Skew 는 특정 키 또는 파티션에 데이터가 쏠려서 불균형이 일어나는 현상이다. 여기서 특정 키 (Key) 라는 의미는 주로 Join, GroupBy, Aggregation 같은 연산에서 특정 키에 과도한 데이터가 집중되는 것을 의미한다. 또한 파티션 (Partition) 이란, Spark 가 데이터를 나누어 저장하고 처리하는 최소 단위이다. Spark 는 각 파티션을 개별 태스크에서 처리하게 된다. Data Skew가 발생하면 다음과 같은 문제가 발생할 수 있다.OOM (Out of Memory) : 특정 파티션에 과도하게 데이터가 몰리게 되면, 해당 파티션을 처리하는 태스크(Task) 가 많은 메모리를 소비하게 된다. Spark ..
전통적인 데이터 레이크는 트랜잭션을 지원하지 않기 때문에, 데이터 정합성을 유지하기 어려운 단점이 있다. 반면, Delta Lake는 트랜잭션을 지원하는 데이터 레이크로, ACID(Atomicity, Consistency, Isolation, Durability) 속성을 보장하며 데이터 무결성을 보다 효과적으로 유지할 수 있다.그러나 Delta Lake에서 주장하는 트랜잭션과 무결성이 RDBMS에서의 트랜잭션과 동일한 수준으로 보장되는지에 대한 의문이 들 수 있다 (우선 내가 그랬다). 이 글에서는 Delta Lake의 트랜잭션 동작 방식과 RDBMS와의 차이점, 그리고 Delta Lake에서 데이터 정합성을 유지하기 위한 전략을 정리해보려 한다.델타 테이블에서의 트랜잭션Delta Table에서 트랜잭션..
오픈 테이블 포맷오픈 테이블 포맷 (Open Table Formats) 는 데이터 레이크(Data Lake) 에 ACID 트랜잭션과, schema 제약조건 강화, time travel 기능 등을 추가한 시스템이다. 기본적으로, 데이터레이크는 빅데이터 패러다임이 등장하면서 확장성, 유연성 그리고 무엇보다 저비용이라는 점에서 장점이 있다. 저렴한 비용으로 정형, 비정형 데이터를 모두 저장할 수 있다는 점에서 널리 쓰인다. 그렇지만 데이터레이크는 데이터베이스와 같은 ACID 트랜잭션을 지원하지 않았다. 데이터 레이크는 csv, json, parquet 과 같은 파일 형식으로 데이터를 저장한다. 따라서 CDC 나 데이터의 일관성 보장에 대해서 처리하기에는 구현하기도 어렵고 파일을 다루다 보니 처리 비용과 시간이..
minjiwoo
minji's engineering note