들어가며 지난 글에서 Spark RDD에 대해서 알아보았다. 이번 글에서는 DataFrame에 대해서 알아보겠다. RDD의 문제점 DataFrame이 등장한 이유는 기존 RDD에 문제점이 있었기 때문일 것이다. 그렇다면 왜 RDD가 있었음에도 불구하고 DataFrame이라는 새로운 데이터 구조가 생긴 것일까? 여러가지 이유가 있었는데, 주된 내용은 성능 이슈였다. 메모리 사용 및 디스크 I/O RDD는 디스크에서 데이터를 읽고 쓸 수 있으며, RDD의 메모리 사용은 비효율적이다. 또한 메모리나 디스크에 용량이 충분하지 않으면 제대로 동작하지 않는다. 데이터 처리의 효율성이 떨어짐 스키마 개념이 없어, 구조화된 데이터와 비구조화 데이터를 함께 저장하여 효율성이 떨어진다. 객체 직렬화 오버헤드 RDD는 자바..
들어가며 이번 글에서는 Spark의 데이터 구조인 RDD를 알아볼 것이다. 최근에는 DataFrame과 DataSet을 주로 사용하지만 이는 다음글에서 다루겠다. RDD를 살펴보기에 앞서 하둡과 스파크의 관계를 간단하게 짚고 넘어가겠다. HDFS와 Map Reduce 하둡은 HDFS(Hadoop Distributed File System)라고 불리는 분산 파일 시스템을 기반으로 동작한다. 이를 통해 굉장히 방대한 양의 데이터를 저장/관리할 수 있게 되었고, MapReduce라고 불리는 데이터셋 병렬 처리 방식으로 데이터를 처리했다. 하지만 HDFS도 치명적인 문제점이 있었는데, 바로 HDFS가 Distk I/O를 기반으로 동작하는 것이었다. 또한 실시간(Realtime)에 대한 니즈가 크게 증가하기 시작..
들어가며 카프카의 내부 동작 원리와 구현에서 가장 중요한 부분 중 하나는 리플리케이션 동작이다. 카프카는 물론이고 일반적인 분산 시스템에서는 애플리케이션의 고가용성을 위해 내부적으로 리플리케이션 동작을 하게 되는데, 이러한 리플리케이션 동작의 구현은 매우 어려운 부분일 뿐만 아니라 애플리케이션의 성능 저하도 불러오게 된다. 이를 보완하기 위해 카프카는 안정성을 높임과 동시에 최대한 성능에 영향을 주지 않도록 설계되었다. 이번 글에서는 이러한 카프카 내부 동작을 살펴본다. 카프카 리플리케이션 카프카는 스스로를 고가용성 분산 스트리밍 플랫폼이라고 정의하는 만큼 무수히 많은 데이터 파이프라인의 정중앙에 위치하는 메인 허브 역할을 한다. 이렇게 중앙에서 메인 허브 역할을 하는 카프카 클러스터가 만약 하드웨어의 ..
들어가며 이번 글에서는 카프카의 큰 구성 요소인 프로듀서(Producer), 브로커(Broker), 컨슈머(Consumer)와 전달받은 메시지가 어떻게 관리되는지를 알아본다. Producer Producer는 메시지를 생성해서 카프카의 토픽으로 메시지를 보내는 애플리케이션이다. 여기서 Producer가 카프카에게 메시지를 전달하게 되면 카프카는 ACK/NACK로 응답을 반환한다. Brokers Kafka는 Producer와 Consumer 사이에서 메시지를 중계한다. Producer와 Consumer는 별도의 애플리케이션으로 만들어진 반면, Broker는 Kafka 그 자체이기 때문에 Kafka Broker는 일반적으로 Kafka라고 불리는 시스템을 의미한다. 따라서 Kafka와 Kafka Broker는..
도전 2023년 2월 4일 이른 새벽에 서울로 올라와 잠실 새내의 작은 자취방에 짐을 풀던 날, 2월 7일 우아한테크코스 첫날 출입증을 받던 날이 엊그제 같은데 얼마 전 그 출입증을 반납하고 왔습니다. 2022년 12월 26일 학교에서 진행하는 겨울방학 캠프 수업을 듣고 있었습니다. 우아한테크코스의 국룰 시간이라고 불리는 오후 3시가 되었고, 이메일이 도착했습니다. 전 아직도 그날 우아한테크코스에 최종 합격했던 순간이 기억납니다. 이메일을 받자마자 소리를 지르며 전교에 자랑하고 다니기도 했던 것 같습니다. 물론 다른 회사에 인턴도 같이 합격한 상태라 우아한테크코스로 인한 자퇴는 학교와 선생님들 입장에서는 그리 달가워하지 않았지만요. 저는 인생에 반드시 타야 할 기차는 단 한 번 밖에 오지 않는다고 생각합..
들어가며 현재 사이드 프로젝트 겸 플레이 그라운드 프로젝트에 랭킹 기능을 도입하려고 합니다. 해당 랭킹 기능은 미션 별 step 내림차순입니다. 위 기능을 구현하는 도중 레디스의 Sorted-Set 자료구조를 이용하면 key-value 중복 제거 기능으로 간편하게 구현할 수 있으며, 조회 성능은 폭발적으로 증가시킬 수 있을 것 같았습니다. 참고로 미리 구현한 기능의 응답 시간입니다. 유저 한 명의 요청을 처리하는 데 389ms의 시간이 걸리는 상황입니다. Redis Sorted Set(Zset) 레디스는 다양한 형태의 자료 구조를 제공합니다. 기본적으로 key-value 형태의 구조를 띄며, value가 사용하는 자료 구조에 따라 기능을 사용할 수 있습니다. Sorted Set은 이름에서 알 수 있듯이 ..
들어가며 이번 글에서는 자바 진영의 서킷 브레이커(CircuitBreaker) 라이브러리인 Resilience4j를 사용하여 외부 서버 통신에 대한 장애를 처리하는 방법을 살펴보겠습니다. 서킷 브레이커 패턴에 대한 내용은 이 글을 참고해 주세요. Resilience4j Resilience4j에는 여러 가지 코어 모듈이 존재합니다. 이 중에서 CircuitBreaker를 활용할 것이기 때문에 이 부분만 자세히 살펴보도록 하겠습니다. CircuitBreaker Resilience4j의 CircuitBreaker는 CLOSED, OPEN, HALF OPEN으로 이루어진 일반적으로 3가지의 일반 상태와 DISABLED 및 FORCED OPEN으로 이루어진 2가지의 특수 상태를 제공합니다. CircuitBreak..
분산 환경에서의 장애 전파 문제 분산 환경에서 개발을 하다 보면 외부 API를 호출해야 하는 경우가 있을 것입니다. 특히나 아키텍처가 MSA로 구성되어 있다면 다른 서비스 호출이 매우 빈번합니다. 하지만, 다른 서비스에 문제가 생겼을 때 장애가 전파되기가 매우 쉽습니다. 즉 A 서비스가 B 서비스를 호출하는 상황일 때 B 서비스에 장애가 발생한다면 A 서비스까지 정상적으로 동작하지 않게 되는 것이죠. 이런 상황에서는 장애가 발생한 서비스를 탐색하고 요청을 차단할 필요가 있습니다. 그렇지 않으면 하나의 서비스에 생긴 장애가 전체 서비스의 장애로까지 이어지기 때문입니다. 재시도(Retry) 패턴 만약 네트워크가 일시적으로 끊겨 요청이 처리되지 않는 경우는 간단한 재시도로 해결할 수 있습니다. 재시도 패턴(R..
들어가며 서비스를 개발하다 보면 클라이언트의 요청이 없어도 서버에서 자체적으로 데이터를 전달해줘야 할 때가 있습니다. 대표적으로 알림과 같은 기능이 있는데요, 사이드 프로젝트를 진행하면서 비슷한 요구사항을 만났습니다. PR 수동 동기화 기능을 개발하였는데, 이때 동기화된 PR을 다른 유저들도 실시간으로 볼 수 있어야 하기 때문에 화면을 보고 있는 모든 클라이언트에게 변경 사항을 전달해줘야 합니다. 여기서 Server Sent Event(SSE)라는 것을 사용하여 이 문제를 해결할 수 있습니다. 이번 글에서는 Spring에서 SSE를 활용하여 클라이언트에게 직접 데이터를 전송하는 방법을 알아보겠습니다. SSE란? SSE(Server-Sent Events)는 웹 애플리케이션에서 서버로부터 비동기적으로 전송받..
들어가며 집사의 고민 서비스의 기능 개발이 거의 마무리되면서 기존 코드 또는 기능의 퀄리티를 올리기 위한 작업 중 캐시를 적용하자는 의견이 나왔습니다. 이번 글에서는 집사의 고민 팀에서 사용하는 캐시와 분석한 내용을 공유하려고 합니다. 캐시는 웹사이트, 브라우저, 앱이 더 빠르게 로드되도록 돕기 위해 데이터를 임시로 저장해 놓은 공간입니다. 요청한 데이터를 캐시에서 찾을 수 있으면 Cache Hit, 찾을 수 없다면 Cache Miss가 발생합니다. 글로벌 캐시 vs 로컬 캐시 글로벌 캐시(Global Cache) 서버가 여러대로 분산되어 있는 분산 환경에서 적합한 캐시 전략입니다. 당연하게도 별도의 캐시 서버를 두고 공유하여 사용하기 때문에 서버 간 데이터 공유가 쉽다는 장점이 있습니다. 반면, 로컬캐..