쿼카러버의 기술 블로그

이번에 회사에서 대량의 데이터와 이미지에 대한 분석 정보를 추출하고 분석하기 위해 LLM API를 호출해야 했다. 구체적인 내용은 회사와 관련 돼 있어 언급하기 어렵지만 설명, 특성, 리뷰, 이미지 등의 데이터를 LLM에 전달하고, 구조화된 정보나 개선된 콘텐츠를 생성받아야 한다. 이런 대규모 작업에서는 데이터 관리부터 API 호출, 결과 저장까지 효율적으로 처리할 수 있는 아키텍처가 필요하다. 여기서 한 가지 분명히 짚고 넘어가고 싶은 점이 있다. 이 글은 "Spark와 Hive로 데이터를 어떻게 분석하고 처리하는가"에 초점을 맞춘 글이 아니다. 나는 데이터 엔지니어도 아니고 Spark를 활용해본 경험이 많지 않다. 다만 우리 회사에는 이미 Spark와 Hive 인프라가 갖춰져 있었고, 나는 이 기존 ..

지난 글에서 Airflow에서 온보딩하기 위한 학습순서, 그리고 왜 그 개념들을 공부해야 하는지 간단하게 다뤄보았다. 아직 Airflow에 온보딩하기 전에 이 문서를 봤다면 아래 글을 먼저 한번 보고 오는 것을 강력 추천한다!! Airflow를 처음 접하게 될 경우 봐야 할 정보가 너무 많다 보니, 실질적으로 온보딩할 때 뭐에 집중해야 하는지 감을 잡는데 도움이 되기 위해 작성한 글이다.Airflow 온보딩 가이드: 뭐부터 배워야할지 학습 순서만 다룸 무튼 온보딩 가이드에 이어서, 이왕 공부한거 나중에 복습할겸 글을 적어보고자 한다. 복잡해 보이는 Airflow를 시스템 구성 요소(웹 서버, 스케줄러, Executor 등)와 워크플로우 구성 요소(DAG, Operator, Task 등)로 나누어 설명하고..

이 글을 적는 목적 :사실 Airflow 개념 설명이나 이런 건 이미 너무 잘 정리되어 있고, 공식 Docs + GPT 활용하면 개념 학습은 훨씬 더 쉬울 거라고 생각한다.다만 처음 접하게 될 경우 봐야 할 정보가 너무 많다 보니, 실질적으로 온보딩할 때 뭐에 집중해야 하는지 감을 잡는데 도움이 되기 위해 글을 작성했다. 이 글을 읽으면, 뭐부터 봐야하는지, 그리고 그 개념들을 왜 봐야하는지 간단하게 설명했으니 온보딩하기전에 한번쯤 참고해보는 것을 추천한다. 보고나서 마음에 들었다면 내가 개인적으로 이왕 공부한거 나중에 보기 위해 정리한 개념 정리 문서도 있으니.. 봐주시면..Airflow 개념 중요한 것들만 골라서 정리 Airflow의 본질: 데이터 워크플로우 자동화Airflow는 시간에 맞춰 여러..

리더 선출이란 여러 대의 동일한 코드로 동작하는 어플리케이션 인스턴스들 중에서 특정 인스턴스를 '대표'로 선정하는 과정을 말한다. 리더 선출의 주된 목적은 시스템 내에서 중요한 결정이나 작업을 담당할 ‘리더’를 선정하는 것이다. 이 과정은 특히 분산 시스템이나 클러스터 환경에서 중요하다. 본 글에서는 그 중에서도 쿠버네티스에서의 리더 선출에 대해 다룬다. 다시 말해 쿠버네티스에 의해 조정되고 관리되는 리더 선출 메커니즘에 대해 다루려고 한다. 쿠버네티스는 Distributed Lock을 활용해 다수의 인스턴스 중 한 인스턴스를 리더로 선출할 수 있게 하여, 오직 그 인스턴스만이 특정 작업을 수행할 수 있도록 보장한다. 참고로 블록체인에서도 리더를 선출한다. 하지만 이 글에서 말할 리더 선출과는 다른 개념..

ScyllaDB는 세계에서 가장 빠른 NoSQL 데이터베이스라고 소개될 만큼 높은 성능을 자랑한다. SycllaDB에 대해 한 줄 요약하자면 C++로 구현된 Cassandra DB다. 실제로 Apache Cassandra와 완벽하게 호환되는 대체품으로 카산드라의 커맨드와 메서드를 그대로 사용할 수 있다. Cassandra의 아키텍처를 기반으로 하되 C++로 재작성되어 성능 최적화에 신경을 쓴 제품이기 때문이다. ScyllaDB가 자랑하는 장점들을 요약해보면 다음과 같다. Cassandra에 비해 5배 빠른 성능 : lower latency, higher throughput Cassandra에 비해 1/10정도의 규모의 클러스터로 동일 성능을 낼 수 있음 GC로 인한 Stop the world 현상 없음 ..

분산 시스템과 블록체인 그리고 데이터 일관성(Consistency) 블록체인은 그 자체로 분산환경 시스템의 한 형태다. 일반적으로 분산 시스템이란 여러 컴퓨터가 네트워크를 통해 연결되어 작동하는 시스템을 말하기 때문이다. 그래서 블록체인과 데이터베이스 분산 처리에 대해 개발자 입장에서 공부하다보면 사실 기술적으로는 공통점이 정말 많을 수 밖에 없다. 누가 데이터를 다루고 보존하고 책임지냐의 문제에서만 차이가 있을뿐, 결국 성능 입장에서 직면하는 문제와 해결해야 하는 문제들 그리고 해결방법들은 서로 밀접하게 연결되어 있다. 탈중앙화 개념을 도입하기 위해 암호학기술, 난수 개념을 활용해서 좀 더 복잡한 메커니즘이 추가되는 정도..? 무튼 본 글은 백엔드 개발자 입장에서 매번 생각만하다 정리해봐야겠다 싶었던 ..

NoSQL을 공부하다보면 가장 많이 접하게 되는 단어 중 하나가 CAP이다. 아무래도 NoSQL 스토리지들이 분산 시스템으로 동작하다보니, 이들을 이해하기 위해서는 꼭 알아두어야 할 개념이기 때문이다. 프로젝트 특성에 따라 데이터베이스 솔루션을 선택해야 하는데, 이 때 이 개념을 잘 이해하고 있으면 프로젝트 특성에 맞는 솔루션을 선택하는데 도움이 된다. 근데 이 CAP Theorem은 매우 심플하게 분산 시스템의 성질을 설명해주는 정리 같으면서도 잘못 읽으면 오히려 오해가 생길 위험이 있다. 따라서 CAP이 의미하는 바가 무엇이고, 이 정리가 진정 무엇을 알려주고자 하는지 좀 제대로 이해해보기 위해 글을 쓴다. 참고로 이번 글은 분산시스템과 데이터베이스에 대한 기본적인 이해가 됐다는 전제하에 쓴 글이다...

데이터베이스를 사용하고 있는 많은 개발자들은 DBMS의 기본 isolation level을 사용하는 경우가 많다. 하지만 지금 내 서비스에 적합한 isolation level을 지정해주지 않으면 여러 요청이 동시에 처리될때 예상치 못한 동작이 발생할 수 있다. 따라서 본 글에서는 Isolation level에 대해 알아볼 것이다. 그치만 그전에, 동시에 트랜잭션이 처리될 때 어떤 이상 현상(Concurrency Problem)들이 발생할 수 있는지에 대해 알아보려고 한다. SQL표준에서 제시한 이상현상 외에도 다른 이상현상들도 알아볼 것이다. 다양한 이상현상들을 공부해두면 트랜잭션을 사용할 때 본인 서비스에 치명적일 수 있는 이상현상(Concurrency Problem)들을 미연에 방지할 수 있고, 문제..