분류 전체보기

테스팅 개요 위와 같은 서버 구조에서 알림 시스템을 구축하고 알림 전송 시스템의 생산자서버인 Main Server에 K6로 부하테스트를 수행했습니다. 테스트 목적1. 본 테스트는 서버의 자원을 최대한으로 사용하여 알림 전송이 어느 정도의 TPS를 달성하는지를 측정하는 것 입니다. 2. 테스트를 통해 각종 지표를 분석하고 코드 수정이나 설정 변경을 통해  더 높은 TPS를 달성할 수 있는 지 탐색해보는 것 입니다. 3. 마지막으로 서버의 자원을 최대한으로 활용하지 않고 평이한 트래픽은 어느 정도로 처리가 가능한 지 측정하려 합니다. K6 스크립트30초 간 100명의 가상유저1분 간 300명의 가상유저1분 간 500명의 가상유저개별 가상 사용자의 요청의 간격 2초import http from "k6/http..

들어가기알림 시스템을 구축했으니 이제 RabbitMQ가 감당할 수 있는 메세지 양을 측정해보고 Prefetch Size와 Concurrent Consumer의 관계와 해당 값들이 성능에 미치는 영향을 알아보려합니다. 서버 구조서버 구조는 위처럼 구성돼있습니다. 각 Compute Engine 인스턴스를 모니터링하기 위해 Prometheus, Grafana를 위한 인스턴스를 별도로 구성했습니다. Grafana, Prometheus를 제외한 Spring Boot, RabbitMQ는 도커로 실행중입니다. 이번 글에서는 RabbitMQ의 지표를 살펴볼 예정입니다. RabbitMQ 인스턴스 스펙GCP E2-SmallvCPU 2코어 1RAM 2GBUbuntu 20.04 LTSK6 Script부하는 K6를 이용해 생성..

들어가기 GitHub - AmorGakCo/Backend: 모두 모여 각자 코딩 플랫폼 [Backend]모두 모여 각자 코딩 플랫폼 [Backend]. Contribute to AmorGakCo/Backend development by creating an account on GitHub.github.com 모각코 모집 플랫폼을 개발하면서 FCM을 이용한 WebPush와 SMS 알림 발송을 구현했습니다. 알림전송의 딜레이를 줄이기 위해 비동기 프로세스가 필요했고 안전한 비동기 프로세스 구축을 위해 RabbitMQ를 선택했습니다. 이 글에서는 알림 발송에 실패한 경우 재시도 전략과 데드레터 처리 과정을 정리해보려 합니다. AMQPRabbitMQ의 특징으로는 가장 먼저 AMQP기반의 메세징 미들웨어라고 할 ..

들어가기난생 처음으로 오픈소스에 기여를 해보게 됐습니다. 비록 코드가 아닌 문서화 관련이지만 나름 뿌듯한 경험이었고 과정을 기록해놓고 싶습니다. 배경 GitHub - TUK-SPORTIFY/sportify-backend: 2024년 국민체육진흥공단 공공데이터 활용 경진대회 수상작[장려상2024년 국민체육진흥공단 공공데이터 활용 경진대회 수상작[장려상]. Contribute to TUK-SPORTIFY/sportify-backend development by creating an account on GitHub.github.com 공모전에 출품한 Sportify 서비스는 위/경도 위치연산을 통해 사용자 주변 위치의 스포츠 이용권 강좌를 제공해야했습니다. 데이터 베이스를 선택할 때 MySQL이 위치연산도 제..

TCP의 큰 특징을 꼽으라하면 신뢰성 있는 프로토콜, 연결지향 프로토콜 그리고 네트워크 혼잡 제어이다. 이번엔 TCP가 혼잡을 제어하는 방식을 알아보자. 전통적인 혼잡 제어 앞선 글에서 살펴봤 듯이 전통적인 TCP는 네트워크의 지원없이 종단 간에(송신자와 수신자 끼리) 혼잡을 제어한다. 기본적으로 TCP는 혼잡이 발생하면 송신율을 낮추고, 혼잡이 없다면 송신율을 높인다. 혼잡 제어는 TCP의 흐름 제어와 유사하게 Congestion Window(혼잡 윈도우) 크기를 조절해가며 전송속도를 조절한다. 여기서 흐름제어는 수신 측 버퍼에서 패킷이 버려지지 않도록 송신자와 수신자가 속도를 맞추는 것이고 혼잡 제어는 네트워크 혼잡 비용을 줄이기 위한 것이다. 네트워크 혼잡 비용은 앞선 글에서 상세히 다뤘다. 혼잡을..

혼잡의 원인과 비용네트워크에 혼잡이 발생하게되면 어떤 일이 벌어지는 지를 시나리오 별로 살펴본다. 시나리오 1단일 라우터라우터 버퍼 크기는 무한 (패킷이 버려지지 않음)재전송, 흐름 제어, 혼잡 제어를 수행하지 않는다.2개의 송신자 2개의 수신자  단일 라우터를 공유하는 4개의 호스트가 존재한다. 이 때 송신자(Host A,B)는 링크 용량의 절반인 R/2 아래로 전송하면 수신률은 좌측 그림처럼 선형 증가한다. R/2를 초과하게되면 라우터의 버퍼는 무한하기에 패킷은 버려지지 않고 딱 R/2만큼 전송된다. 하지만 전송률이 아닌 지연의 관점에선 R/2에 근접할 수록 지연은 무한대가 된다. 여기서 지연은 큐잉 지연을 뜻한다. 예를 들어 버퍼에 10개의 패킷이 도착한 경우 첫 패킷은 지연없이 바로 전송되지만 뒤..

들어가기 AWS VPC + ELB 구축하기들어가기클라우드 컴퓨팅 수업을 듣게 되면서 평소에 써보고 싶었던 AWS 서비스를 마음껏 써볼 수 있게 됐습니다. 저번 주 수업 내용은 Public Subnet과 Private Subnet을 구축해 보는 것이었고 이번 주curiosity-s.tistory.com  지난번 VPC + ELB 구성에 이어서 이번엔 Auto Scaling을 구성해보려합니다. Scale-Out 말로만 들었지 직접 해본 적은 없었기 때문에 매우 설레입니다... ELB + VPC지난 포스팅에 그대로 이어서 추가로 구성을 해주면 됩니다. 지난 포스팅은 딱 위 그림까지 였습니다. 이제 부하가 일정 수준 쌓이면 설정한 최대 EC2 개수만큼 늘어나고, 최소 개수 만큼 늘어나게끔 Auto Scaling..

들어가기클라우드 컴퓨팅 수업을 듣게 되면서 평소에 써보고 싶었던 AWS 서비스를 마음껏 써볼 수 있게 됐습니다. 저번 주 수업 내용은 Public Subnet과 Private Subnet을 구축해 보는 것이었고 이번 주 수업 내용은 Private Subnet에 EC2 3대를 배치하고 ELB로 로드밸런싱을 해보는 것이었습니다. 수업 복습도 할 겸 차례대로 다시 한 번 구축해보려합니다. VPCVPC는 Virtual Private Cloud의 약자로 한 리전의 여러 가용영역(AZ)에 걸쳐서 가상의 네트워크를 만드는 AWS 서비스입니다.  VPC는 CIDR로 자체 IP범위를 지정해 줄 수 있습니다. 예를 들어 10.0.0.0/16 를 VPC의 IP범위로 설정하게 되면 10.0 구간까진 고정돼고 뒤에 0.0은 F..