내가 만든 백엔드 서버를 숫자로 자랑하는 법 | 신뢰성, 성능, 가용성 지표

최근에 개발자가 된지 만 2년이 되어 경력기술서를 업데이트하게 되었다. 

근데 작성하다보니 성과에 대한 정량적인 데이터가 매우 부족하다는 것을 깨달았다. 

여태까지 성능을 측정하고 개선하는 것이 아닌 그저 기능 구현에 초점을 맞춰왔던 것이다. 

 

개발자로서의 가치를 높이기 위해서는 그저 기능 구현만 하는 것이 아닌, 

내가 만든 기능을 어떻게 안정적이고 빠르게 동작할 수 있도록 만들 수 있는지에 대해 고민하여야 한다. 

그리고 이러한 고민은 정량적인 수치를 바탕으로 이루어져야 한다. 

 

그래서 이번 포스팅에서는 백엔드 개발자로서 어떤 것에 집중하여야 하고

어떻게 백엔드 서버의 성능을 측정할 수 있는가에 대해 정리해보려 한다. 

---

백엔드 서버의 주요 목표

백엔드 서버는 클라이언트의 요청에 따라 비즈니스 로직을 처리하고

보이지 않는 곳에서 서비스가 원활하게 작동하도록 만드는 역할을 한다. 

 

백엔드 서버의 주요 목표는 다음과 같다. 

1. 신뢰성

2. 성능

3. 가용성

---

신뢰성

사용자의 예상대로 매번 정확하고 일관적으로 동작하는가?
예상치 못한 상황에서도 안정적으로 동작하는가?

 

금융 서비스, 커머스와 같은 서비스는 높은 신뢰성을 요구한다. 

 

신뢰성을 높이는 방법

• API 응답/에러의 일관성
• 트랜잭션, 롤백
• DB 복제 및 데이터 백업
• 멱등성을 고려한 설계
• 장애상황을 고려한 설계

 

신뢰성 측정 지표

• MTBF(Mean Time Between Failures) : 장애와 장애 사이의 평균 시간
• MTTR(Mean Time to Recovery) : 장애가 복구되는데 걸리는 평균시간
• 에러율 : 전체 요청 중 오류 비율
• 데이터 무결성 검사 : 실제 데이터와 저장된 데이터의 무결성 검사

---

성능

클라이언트의 요청을 얼마나 효율적이고 신속하게 처리할 수 있는가?
주어진 자원 내에서 얼마나 시스템이 빠르고 효율적으로 동작하는가?

 

스트리밍 서비스, 검색 엔진, 온라인 게임과 같은 서비스는 높은 성능을 요구한다. 

 

성능을 높이는 방법

• 캐싱
  • Redis, 캐싱 라이브러리, CDN, ...
• 비동기 처리
• DB 최적화
  • 쿼리 최적화, 인덱스 추가, 레플리케이션, 샤딩
• 아키텍쳐 개선
  • CQRS, 이벤트 기반 아키텍쳐, MSA 구조 요청 횟수 줄이기

 

성능 지표

• 응답 시간(Response Time) : 요청 후 응답이 반환될때까지 걸리는 시간
• 지연 : 요청 후 서버에서 처리되기 전까지 기다리는 시간
• 처리량(Throughput)
  • TPS(Transactions Per Second) : 총 트랜잭션 수/ 총 소요시간
  • RPS(Requests Per Second) : 총 요청수 / 총 소요시간
• 자원 사용률 : CPU, 메모리, 네트워크 자원 사용량

---

가용성

사용자가 필요할 때 언제든지 사용할 수 있는 상태인가? 

 

클라우드 서비스, 응급 서비스와 같은 서비스는 높은 가용성을 요구한다. 

 

가용성을 높이는 법

• 단일 장애 지점(SPOF, Single Point of Failure) 제거
• 이중화, 데이터 백업 및 복구
• 장애 감지 및 모니터링
• 부하 분산, 지리적 분산

 

가용성 지표

• 가동 시간 : (총 운영시간 - 장애 시간)/총 운영시간

---

이번 포스팅에서는 백엔드 개발자가 고려해야하는 점과 

신뢰성/성능/가용성의 측정 지표에 대해 알아보았다. 

 

앞으로는 이러한 지표들을 측정하고 이를 기반으로 개선하는 경험을 늘려보고자 한다.