Discord API의 비용 귀속 (새 탭에서 열림)

Discord의 API는 1,700개 이상의 엔드포인트와 약 700개의 백그라운드 작업을 포함한 단일 Python 코드베이스로 운영되며, 수백 개의 Kubernetes 배포에 단계적으로 배포된다. 기존 모니터링은 지연 시간·처리량·오류율은 보여주지만, 메시지 전송이나 스트리밍 같은 제품 기능별 호스팅 비용은 충분히 설명하지 못했다. Discord는 배포 구조를 변경하지 않고 애플리케이션 프로파일링 도구를 확장해, 각 기능의 코드 실행 시간에 따라 배포 비용을 배분하는 방식을 도입했다.

대규모 단일 API 코드베이스의 운영

• Discord API는 하나의 Python 코드베이스로 구성되어 있다.
• 1,700개 이상의 API 엔드포인트와 약 700개의 백그라운드 작업을 포함한다.
• 엔지니어들은 매일 공통 코드에 변경을 가한다.
• 변경 사항은 수백 개의 Kubernetes 배포 환경에 단계적 롤아웃 방식으로 지속 배포된다.
• 규모가 크고 변경 빈도가 높기 때문에, 매일 발생하는 변화가 사용자나 시스템에 미치는 영향을 추적하기 어렵다.

기존 관측성의 범위

• Discord는 다음과 같은 운영 지표를 이미 수집하고 있었다.
  • 지연 시간
  • 처리량
  • 오류율
• 이러한 지표는 성능 저하나 오류 증가 같은 회귀(regression)를 감지하는 데 유용하다.
• 그러나 특정 제품 기능이 전체 호스팅 비용에서 차지하는 비중은 파악하기 어려웠다.
• 예를 들어 다음과 같은 질문에 답하기 어려웠다.
  • 메시지 송수신 API 운영 비용은 얼마인가?
  • 스트림 시작 기능에는 얼마가 드는가?
  • Nitro 선물 전송 비용은 얼마인가?
  • 특정 코드 변경이 팀의 호스팅 비용을 얼마나 변화시켰는가?

Kubernetes 배포 단위만으로는 부족한 비용 추적

• 클라우드 제공업체는 일반적으로 Kubernetes 배포별 비용 분류를 제공한다.
• 하지만 Discord의 모든 배포에는 동일한 API 코드베이스가 배포된다.
• 각 배포는 특정 HTTP 트래픽이나 백그라운드 작업의 일부를 처리하지만, 제품 기능 단위로 깔끔하게 분리되어 있지는 않다.
• 비용 추적을 위해 배포를 기능별로 더 세분화하면 운영 복잡성이 지나치게 커진다.
• 따라서 기존 배포 토폴로지를 변경하지 않고 비용을 추적할 방법이 필요했다.

동시 실행 환경에서의 비용 배분

• 하나의 API 워커 프로세스는 여러 작업을 동시에 처리한다.
• 같은 시점에 여러 제품 기능과 관련된 코드를 실행할 수 있다.
• 일부 트래픽은 특정 배포로 격리되어 있지만, 기능별 비용 분석에 충분할 정도로 분리된 것은 아니다.
• 따라서 단순히 배포 단위의 비용을 특정 기능에 모두 할당할 수 없다.
• 정확한 비용 배분을 위해서는 각 배포가 특정 기능의 코드 실행에 얼마나 많은 시간을 사용했는지 측정해야 한다.

프로파일링을 활용한 해결책

• Discord는 기존 애플리케이션 프로파일링 도구를 확장했다.
• 각 기능과 관련된 코드가 실행된 시간을 측정하고, 이를 기반으로 배포 비용을 배분한다.
• 이를 통해 배포 구조를 바꾸지 않고도 다음 단위의 비용을 추정할 수 있다.
  • 개별 API 엔드포인트
  • 여러 엔드포인트로 구성된 제품 기능
• 글에 제시되는 수치와 코드는 실제 운영값이 아닌 설명을 위한 예시다.

실용적인 결론

기능별 인프라 비용을 파악하려면 서비스를 물리적으로 기능별 배포로 나누기보다, 공통 실행 환경에서 각 기능이 소비한 컴퓨팅 시간과 리소스를 측정해 비용을 배분하는 방식이 효과적이다. 특히 대규모 단일 코드베이스에서는 기존 관측성에 비용 귀속 정보를 결합하는 것이 운영 구조를 복잡하게 만들지 않는 현실적인 접근이다.