[#3][백엔드 최적화]백엔드 최적화 개념과 성능 지표 정리

1. 최적화(Optimization)란 무엇인가?

• 정의: 시스템이 가진 자원(CPU, 메모리, 네트워크, 디스크 I/O)을 효율적으로 사용하면서 성능을 개선하는 과정
• 목적
  1. 성능 향상(Performance) – 응답 속도 단축, 지연 시간(Latency) 감소
  2. 확장성(Scalability) – 더 많은 요청을 안정적으로 처리
  3. 안정성(Stability) – 부하 상황에서도 장애 없이 운영
  4. 비용 효율(Cost Efficiency) – 같은 하드웨어로 더 많은 성능

---

2. 최적화 분류

1. 코드 레벨 최적화 (Code-level)
   • 불필요한 반복 제거, N+1 문제 해결, 캐싱
2. 데이터베이스 최적화 (Database)
   • 인덱스 설계, 정규화/비정규화, 쿼리 튜닝, 커넥션 풀 관리
3. 아키텍처/인프라 최적화 (Architecture/Infra)
   • 로드 밸런싱, 캐시 서버(Redis), 메시지 큐(Kafka), 서버 확장
4. 네트워크/전송 최적화 (Network/Transfer)
   • 압축(Gzip), HTTP/2·HTTP/3, CDN, 응답 데이터 최소화

👉 실제 프로젝트에서는 코드 → DB → 인프라 → 네트워크 순으로 점검하는 경우가 많음.

---

3. 성능 지표(Performance Metrics)

3.1 주요 지표

• Latency (지연 시간): 요청 → 응답까지 걸린 시간
• Throughput (처리량): 단위 시간당 처리 요청 수 (RPS/QPS/TPS)
• TPS/QPS: DB·시스템의 초당 트랜잭션/쿼리 처리량
• Error Rate (에러율): 전체 요청 대비 실패 요청 비율
• P95 / P99 (퍼센타일): 상위 95%, 99% 사용자가 경험하는 응답 시간

3.2 상대값 vs 절대값

• Throughput/TPS/QPS는 “절대 불변 값”이 아님
  • 하드웨어가 정하는 이론적 한계(Absolute Capacity) 존재
  • 하지만 소프트웨어 최적화(쿼리 튜닝, 캐시 등)로 **관측값(Observed Value)**은 개선 가능

---

4. Error Rate(에러율)의 의미

• 정의: “코드 문법 오류”가 아니라, 운영 중 실패 요청 비율
• 발생 원인
  • 서버 과부하 → Timeout
  • DB 커넥션 부족 → 500/502
  • 외부 API 실패 → 502/503
  • 네트워크 단절 → 클라이언트 입장에서 응답 없음
• 중요 포인트
  • 서버가 실행 중이어도 요청 일부 실패 시 Error Rate는 올라감
  • 운영에서 Error Rate가 곧 서비스 신뢰성 지표

---

5. Error Rate ↔ Availability(가용성)

• Availability(가용성) = 정상 응답 비율 = 1 - Error Rate
• SLA(Service Level Agreement) = 서비스 제공자가 보장하는 가용성 목표 (예: 99.9%)
• 허용 다운타임 계산식:
•  
  허용 장애 시간 = 총 시간 × (1 - SLA)
• 예시
  • SLA 99% → 연간 약 3일 15시간 장애 허용
  • SLA 99.9% → 연간 약 8시간 45분 장애 허용
  • SLA 99.99% → 연간 약 52분 장애 허용
  • SLA 99.999% → 연간 약 5분 장애 허용

---

6. 최적화 vs 측정(Measurement)의 차이

• 측정: 지표를 수집해 상태 파악 (Latency, Error Rate, TPS, SLA 계산 등)
• 최적화: 지표를 근거로 설계/코드/DB/인프라를 개선하는 행위
• 검증(Verification): 최적화 전후 지표 비교로 효과 확인

👉 따라서 “측정 로직”은 최적화 자체가 아니라, 최적화가 필요하고 효과 있는지 확인하기 위한 도구임.

---

7. 면접 대비 Q&A

• Q1. 최적화와 모니터링 차이는?
  A1. “모니터링은 성능을 측정하는 행위이고, 최적화는 그 데이터를 근거로 실제 개선을 하는 것입니다. 이후엔 다시 측정으로 효과를 검증합니다.”
• Q2. Error Rate와 Availability 관계는?
  A2. “Availability = 1 - Error Rate입니다. Error Rate 0.1%면 가용성은 99.9%이고, SLA 기준에 따라 허용 장애 시간이 결정됩니다.”
• Q3. Throughput은 절대값인가요?
  A3. “하드웨어가 정한 최대치가 있긴 하지만, 우리가 다루는 관측된 처리량은 소프트웨어 최적화를 통해 개선 가능합니다.”

---

8. Self-Check (자가 검증 요약)

• 정리 포인트
  • 최적화 = 개선 행위, 측정 = 검증 도구
  • 성능 지표: Latency·Throughput·Error Rate·Percentile
  • Throughput/TPS는 절대 한계치가 아니라 상대적 개선 가능 수치
  • Error Rate는 코드 오류가 아닌 운영 실패율
  • Availability = 1 - Error Rate → SLA 계산과 직결
• 자신도: 높음 (실제 SRE/백엔드 운영 기준과 일치)

---

9. 추가 학습 과제 (Next Task)

1. 실습 루프(MAOV):
   • Measure → Analyze → Optimize → Verify
   • 예: Spring Boot API + JMeter로 부하 테스트 → N+1 쿼리 발생 → fetch join으로 최적화 → P95/에러율 개선 확인
2. SLA 실습:
   • 하루·주·년 단위로 SLA 99%, 99.9%, 99.99% 다운타임 직접 계산
   • 운영 캘린더(업무시간만 반영)로 변형
3. APM 툴 학습: Pinpoint, Datadog, New Relic으로 실제 서비스 지표 관찰