본문 바로가기
Develop/etc

[백엔드 실무 스터디] 2장. 느려진 서비스 살펴보기

by 연로그 2025. 7. 5.
반응형

서론

이 글은 '주니어 백엔드 개발자가 반드시 알아야 할 실무 지식' 책을 읽고 진행하는 스터디 내용을 정리한다. 책을 읽고 학습하는 게 아니라, 책의 내용을 주제로 경험을 공유하는 스터디이기 때문에 포스팅 내용은 책과 관련이 없다. 이번 글은 '2장 느려진 서비스, 어디부터 봐야 할까'를 읽고 진행한 스터디 내용을 정리했다. 

 

 

2장. 느려진 서비스, 어디부터 봐야 할까

수직 확장 & 수평 확장 (26p)

  • CPU 수치에 따라 스케일인/아웃되는 auto scaling group 설정
  • 사용자 적은 시간대는 스케일인을 해둔다던가 다양한 조건으로도 설정 가능
  • DB 스케일은 직접 다룰 일이 없다 (DBA에게 요청해서 수행)

 

 

로드밸랜서 (27p)

트래픽 분산 방식 알아보기

  • EC2 > Target Groups > 상세 > Attributes > Traffic configuration

 

 

커넥션 풀 (28p)

옵션 (HikariCP 기준) 설명 디폴트 값 (5.1.0 기준)
maximum-pool-size 최대 커넥션 수 10
minimum-idle 최소 유휴 커넥션 수 10
connection-timeout 커넥션 할당까지의 대기 시간 30000 (30초)
idle-timeout 최대 유휴 시간 - 노는 커넥션을 풀에 유지하는 시간 600000 (10분)
connection-test-query 유효성 검사 - 커넥션 유효성을 테스트하기 위한 쿼리 null
max-lifetime 최대 유지 시간 - 커넥션 연결 유지 시간 1800000 (30분)
connection-timeout과 동일하게 사용 연결 시도 최대 대기 시간 30000 (30초)
  • 대기 시간, 최대 유휴 시간, 최대 유지 시간 등을 커스텀해서 사용 중
    • 회사 내부에 '최소 품질 체크 리스트'라는 권장 설정값 존재 - 장애가 발생하거나 보안 위험성 등이 발견될 때마다 꾸준히 갱신
    • API 응답 시간에 맞춰 커스텀
  • DB HikariCP는 maximum-pool-size와 minimum-idle 값을 동일하게 세팅하도록 권장
    • 트래픽 점진적 증가할 경우: DB 연결 시간이 성능에 큰 영향이 없음
    • 트래픽 급증할 경우: DB 연결 시간도 성능 저하의 주요 원인
  • 커넥션 풀 크기를 늘리면 처리량을 높일 수 있다
    • 단, DB 자체의 최대 커넥션 수가 있다
    • show variables like ‘max_connections’

 

 

캐시 (34p)

  • 로컬 캐시를 리모트 캐시로 옮겼던 사례
    • 새로고침할 때마다 화면이 변경되는 현상
    • 인스턴스별로 다른 데이터 캐싱 -> 호출되는 인스턴스에 따라 다른 데이터를 응답
  • 로컬 캐시 vs 리모트 캐시
    • 어떤 게 더 적합한지는 서비스별, 상황별로 다르다
  • 로컬 캐시 사용 소감
    • 활용하기 굉장히 편하다
    • 갱신이 불편한 문제는 Redis pub/sub 기능으로 어느 정도 개선이 가능
    • EC2 메모리량에 한계가 있으니 엄청 크고 많은 데이터를 다 넣기는 힘들다
  • 캐시 무효화 수단
    • 굉장히 긴 시간 캐싱하는 데이터의 경우, key에 버전을 넣음 (ex: v1, v2나 250630 같은 날짜)
    • 무효화를 위한 API, 배치 등 생성

 

 

웜업

  • 배포 직후 인스턴스 CPU 치는 현상 완화 가능
  • 외부 API에 의존성이 큰 API보다 로직 수행 자체가 오래 걸리는 코드 웜업이 효율적
  • ObjectMapper 사용도 웜업 가능
  • 스프링 애플리케이션의 웜업 방식
    • @EventListener(ApplicationReadyEvent.class) 사용
    • CommandLineRunner 또는 ApplicationRunner 구현
    • ping API 생성 및 활용
  • Kafka 프로듀서는 웜업의 여지가 있으나, 컨슈머는 힘들다

 

 

CDN (46p)

CloudFront vs Cloudflare

  • CloudFront
    • 짧은 지연 시간과 빠른 전송 속도로 안전하게 콘텐츠 전송 (AWS의 서비스)
    • (스터디원들 경험) 서버 개발에서 활용할 일이 없음. 이미지 합성 로직을 서버에서 직접 제어할 때 활용한 적 있음
  • Cloudflare
    • 웹 사이트, 애플리케이션, 네트워크를 더 빠르고 안전하게 구축 (Cloudflare의 서비스)
    • DDoS 방어와 같은 다양한 보안 기능 제공

 

Cloudflare vs AWS WAF

  • AWS WAF
    • AWS에서 제공해 주는 WAF(Web Application Firewall; 웹 애플리케이션 방화벽)
    • http header에 삽입되어 있는 악성 문자열을 탐지/차단하는 등의 보안 기능 제공
  • Cloudflare
    • 일부 WAF의 기능을 포함하나, 운영되는 룰이 달라 이중 보안 관점에서 적용
    • DDoS 자동방어, bot management 등 추가적인 보안 기능 제공

 

반응형