728x90 Project11 K6 & Grafana를 활용하여 병목 해결 & 스레드풀, 커넥션풀 조절기 배경현재 간단한 게임 친구 매칭 및 커뮤니티 앱을 운영하고 있다.초기에는 사용자 수가 많지 않아서 EC2 t2.micro 단일 인스턴스와 RDS만으로도 큰 문제 없이 서비스를 운영할 수 있었다.그런데 최근 들어 유저 수가 빠르게 늘어나면서 어느덧 100명을 넘기게 되었고, 지금은 약 120명 정도까지 증가한 상태다. 아직까지는 서비스가 크게 느려지거나 장애가 발생한 적은 없지만, 이 상태로 계속 유저가 늘어나면 언젠가는 문제가 생길 것 같다는 불안이 들기 시작했다. 이전에 부하 테스트를 간단히 해본 적은 있다. 특정 API를 하나 정해서 요청을 계속 보내보고, TPS가 어느 정도 나오는지 확인하는 식이었다. 하지만 지금 돌아보면 실제 사용자 흐름과는 거리가 있는 테스트였고, 단순히 수치만 보는 수준에 그.. 2026. 5. 11. [Project] 분산환경에서 캐시는 어떻게 적용해야할까? 우리가 보통 어플리케이션 레벨 기준으로 캐시를 적용한다고 하면 2가지로 나뉜다. 왼쪽 그림과 같은 로컬 캐시와 오른쪽 그림과 같은 글로벌 캐시로 나뉜다. 로컬 캐시와 글로벌 캐시는 각각 장, 단점을 가진다. 구분로컬 캐시 장점로컬 캐시 단점분산 캐시 장점분산 캐시 단점응답속도JVM 메모리 직접 접근으로 초저지연인스턴스 당 메모리 제한 (수백 MB~수 GB)네트워크 홉이 있지만 여전히 빠른 조회 (ms 단위)네트워크 비용·레이턴시(수십~수백 μs) 발생일관성단일 인스턴스 내 강력 일관성노드 간 데이터 불일치 가능단일 소스(클러스터)에서 일관성 관리 가능클러스터 복제 지연 시 일시적 불일치확장성애플리케이션 인스턴스 늘리면 캐시 미스 증가스케일아웃해도 캐시 데이터 공유되지 않음노드 추가로 무제한 수평 확장 .. 2025. 4. 23. [Project] 인스턴스 서버에 너무 많은 부하가 쏠리다면? 지금부터 우리 서비스의 아키텍쳐를 우선 설명하겟다. 초기 아키텍쳐고 서버에선 jwt을 엑세스토큰과 리프레쉬토큰로 검증해서 사용하고 있는데 문제점이 발생했다.토큰이 유효한지 확인하려면 아래와 같이 계속해서 데이터베이스를 조회하는 과정이 있었다. 이렇게 계속해서 데이터베이스를 거치는 과정은 비용이 클 뿐만 아니라 사용자에게 안좋은 영향을 끼치고 있었다.이러한 문제점을 데이터베이스를 거치는 대신 아래와 같이 Redis를 사용하여 서비스 로직을 단축시키는 아이디어 적용해 우리 서비스에 적용할 수 있었다. 그래서 그다음 아키텍쳐 구조는 아래와 같이 진화할 수 있었다. 우리 서버에서는 자주 조회되는 데이터에 대해서 로컬캐시로 저장하고 있었다. 캐싱전략은 Cash Aside 전략을 사용해 아래와 같은 흐름으로 동.. 2025. 4. 17. [Project] 적절한 풀 사이즈 설정하기 우선적으로 풀이란 무엇이고 왜 해야되는가?? 우선 풀(Pool)이라는 것은 수영장 풀이라고 생각해도 될 것 같다. (유튜브에서 봤었던거같은? 이해가 잘 되었다) 한마디로 우리가 수영장 풀에다 물을 미리 부어놓고 재미있게 놀 듯이 프로그램에서 자원을 미리 생성해두고 관리하는 것을 의미한다.보통 백엔드 관점에서는 2가지로 나뉘는 것 같다. 첫번째는 데이터베이스 커넥션 풀과 쓰레드 풀로 나뉜다. 데이터베이스 커넥션 풀: DB에 연결할 때마다 새 커넥션을 맺는 대신, 일정 수의 커넥션을 미리 만들어 두고 필요할 때 꺼내 쓰는 방식쓰레드 풀: 요청 혹은 작업을 처리할 쓰레드를 매번 새로 생성하지 않고 일정 수의 쓰레드를 유지하며 돌아가게 하는 방식 둘 다 하는 역할은 자원을 미리 생성해두는 건 똑같다. 근데 왜 .. 2025. 3. 26. 이전 1 2 3 다음 728x90
