본문 바로가기

전체 글

 (31)
[회고] 300만 개 뉴스 기사 데이터 처리 성능 개선(kafak pod 분산 처리) 문제:300만 개의 뉴스 기사 데이터를 Spark로 가공하고 Kafka Producer를 통해 토픽에 발행한 뒤, Spring 서버(pod 2개, 최대 4개로 HPA 설정)를 통해 이를 소비하여 데이터베이스에 저장하고자 했습니다. 그러나 메시지 처리 속도가 지나치게 느렸습니다. 원인을 분석한 결과, 하나의 pod만 메시지를 받아 처리하는 현상이 발생하여 시스템의 부하 분산이 제대로 이루어지지 않으며 처리 성능이 저하되었습니다.원인:Kafka의 Consumer 설정으로 인해 여러 pod로 메시지가 분산되지 않고 특정 pod 하나만 모든 메시지를 소비하고 있었습니다. 이로 인해 병렬 처리가 이루어지지 않아 전체적인 처리 속도가 떨어졌습니다.해결 방법:해결 방법은 두 가지입니다.Kafka Consumer Gr..
[회고] API 요청 레이턴시 줄이기 목표: 뉴스 기사에서 제목이나 본문에 특정 키워드가 포함된 기사를 빠르게 조회하고자 했습니다. 문제점: 기존 검색 방식의 속도가 매우 느려 검색 성능이 큰 제약으로 작용했습니다. 초기 접근: 성능 문제를 해결하기 위해 일단은 제목에 특정 주식 이름이 포함된 경우만 검색하도록 제한했습니다. 하지만 이 방식은 주식과 관련된 기사들을 완전히 포괄하지 못하는 한계가 있었습니다. 제약 사항: 프로젝트가 이미 배포된 상태였고, 실제 시연까지 남은 시간이 부족했습니다. Elasticsearch 도입이 검색 성능을 개선할 수 있는 대안으로 떠올랐지만, 새로운 기술을 도입하고 테스트하며 배포하기엔 시간과 자원이 절대적으로 부족했습니다. 이에 따라, 현재 환경과 자원에서 가능한 최적화 방안을 찾는 것이 필요했습니다. 해결..
[회고]Kubernetes 설치 회고 Kubernetes 설치 회고1. 초기 문제와 패키지 저장소 이슈처음에는 Kubernetes를 설치하려고 kubernetes-xenial 저장소를 사용했는데, 계속 404 오류가 발생했다. 알고 보니 kubernetes-xenial이 더 이상 지원되지 않는다는 사실을 알게 되었다. 이때부터 계획을 바꿔야겠다고 생각하게 됐다.2. Kubernetes v1.24 버전과 Docker의 작별Kubernetes v1.23까지는 Docker를 사용할 수 있었지만, v1.24부터는 더 이상 Docker를 지원하지 않게 되면서 예상치 못한 문제가 생겼다. 결국 Docker 대신 containerd로 전환해야 했고, 이때부터 Kubernetes의 변화가 얼마나 큰지를 체감하게 됐다. 기술은 빠르게 발전하고 그 흐름에 맞..
[회고] 09/08 회고 CI와 CD 새로운 프로젝트를 시작하면서 이전 프로젝트에서 진행했던 부분을 자체 피드백하고자 한다.현재 CI/CD를 구축하고자 하는데,이전에 나는 CI/CD를 어떻게 구축했을까?아니, CI/CD에 대해서 어떻게 이해하고 있었을까? 지금의 생각은 이렇다.CI  => 지속적인 통합CD => 지속적인 배달, 지속적인 배포 크게 생각하지 않았고, CI를 통해서 도커 이미지를 빌드하고,CD를 통해서 배포된 이미지를 배포했다. 조금 더 정확하게, 배포된 이미지를 docker-hub에서 다운로드 받아서,이를 docker-compose를 통해서 배포했다. 과연 이게 전부일까? 일부 사실이고, 많이 부족하다고 생각한다.그렇게 생각하는 이유는 목적을 위해서 사용했기 때문이라 생각한다. 조금 더 솔직하게 말하자면 내게 있어 CI/CD는..
[회고] 쿠버네티스 [아쉬운 하루]쿠버네티스의 컨테이너 자동 관리 시스템 및 모니터링에 매료되어 이번 프로젝트는 쿠버네티스를 사용하고자 했다. 또한 한번 경험한 MSA에서의 아쉬운 부분인 테스트 환경(front, backend 테스트)에서 argo를 적극적으로 활용한다면 효과적일 것이라 생각했다.그래서 쿠버네티스를 조금씩 공부하고 있었다.내가 이해한 쿠버네티스는 다음과 같다.쿠버네티스 개요1. 클러스터와 노드쿠버네티스는 하나의 클러스터로 구성됨클러스터는 여러 노드(Node)로 구성되며, 노드는 마스터 노드(Master Node)와 워커 노드(Worker Node)로 나뉨마스터 노드는 클러스터를 제어하고 관리하는 역할을 하며, 여러 개의 마스터 노드가 존재할 수 있음워커 노드는 실제 애플리케이션이 실행되는 Pod를 호스팅함R..
[회고]nginx nginx 애증의 도구이다. nginx를 통해서 간편하게 로드밸런싱, 라우팅, 네트워크 설정... 할 수 있었지만,간편한만큼 문제를 겪은 부분도 많았다. 특히 네트워크 CS 지식이 없었더라면, 문제가 생기더라도 확인하고, 수정할 수 없었을 것이다. nginx에 대해서 간단히 소개하자면 아래와 같은 기능을 한다. Nginx는 경량의 고성능 웹 서버, 리버스 프록시 서버, 메일 프록시 서버로, 주로 다음 기능에 사용된다:HTTP 웹 서버: 정적 파일 제공, 리버스 프록시, 로드 밸런싱 등.리버스 프록시 서버: 클라이언트 요청을 백엔드 서버로 전달하고 그 결과를 반환.로드 밸런서: 여러 서버에 부하를 분산하여 처리.SSL/TLS 처리: HTTPS를 지원하여 보안 통신 가능.나는 4가지 기능을 전부 사용했다. ..
DNS 설정 도메인 구매도메인 등록 서비스(AWS Route 53, GoDaddy 등)에서 원하는 도메인을 구매.도메인 구매 후, 관리 콘솔에서 도메인 상태와 네임서버 정보를 확인.EC2 탄력적 IP 주소 생성AWS 콘솔에서 EC2 인스턴스 선택 후, 탄력적 IP 주소(Elastic IP) 할당.탄력적 IP는 EC2 인스턴스가 재부팅되더라도 IP 주소가 변하지 않음.EC2 인스턴스에 탄력적 IP를 연결.Route 53 설정호스팅 영역 레코드 생성 (유형 SOA)AWS Route 53에서 해당 도메인에 대한 호스팅 영역 생성.SOA(권한 시작) 레코드에 탄력적 IP 주소 입력(SOA 레코드는 권한 있는 DNS 서버를 지정하는 역할)호스팅 영역 레코드 생성 (유형 CNAME)www. 서브도메인용 CNAME 레코드 생성...
Kafka와 RabbitMQ 비교 및 차이점 상황프로젝트에 있어서 메시지 큐를 도입해야 하는 상황이 발생했다.그래서 어떤 기술을 도입할지 고민하면서 해당 두 기술을 비교해봤다.Kafka와 RabbitMQ 비교 및 차이점메시지 브로커 (Message Broker) 정의메시지 브로커는 애플리케이션 간의 통신을 처리하고 메시지를 전달하는 중개자 역할을 합니다. 이를 통해 메시지를 보내는 애플리케이션(프로듀서)과 받는 애플리케이션(컨슈머) 간의 메시지 전송을 관리합니다.메시지 브로커의 주요 기능비동기 통신: 프로듀서와 컨슈머가 독립적으로 작동하여 비동기적으로 메시지를 주고받을 수 있습니다.발행/구독 모델: 메시지를 주제(topic)나 큐(queue)에 발행하고 여러 컨슈머가 이를 구독하여 처리할 수 있습니다.로드 밸런싱: 여러 컨슈머 간 메시지를 균등하게..

티스토리툴바