테크리드라면 먼저 ‘사용자 10배’를 예상 사용량, 서비스 목표, 팀이 실행할 수 있는 계획으로 바꾸겠습니다. 등록 계정 수만으로 가장 바쁜 순간의 요청 수는 알 수 없습니다.
주문 플랫폼이 캠페인을 준비한다고 가정합니다. 핵심은 주어진 시간과 예산 안에서 고객이 캠페인 중에도 탐색, 구매, 확인 수신을 할 수 있는지입니다.
사용자가 언제 유입되고 무엇을 할지 제품팀에 묻습니다. 1년간 점진적인 증가와 모두 동시에 접속하는 캠페인은 다릅니다.
예를 들어 계정 10만 개 중 1%가 동시에 활동하면 1천 명, 5%면 5천 명입니다. 예시 가정이지 기본 비율이 아닙니다. 요청 빈도와 요청당 처리량도 추정해야 합니다.
캠페인이 만드는 부하를 나열합니다.
이렇게 해야 서버를 열 배로 늘리라는 막연한 지시 대신 시험할 부하가 생깁니다.
핵심 경로의 허용 응답 시간, 오류율, 완료 기준을 정합니다. 필요한 곳에는 데이터 최신성과 복구 기대치도 정합니다. 보고서 지연은 괜찮아도 구매 실패는 안 될 수 있습니다.
[Campaign assumptions] -> [Expected workload] -> [Service targets]
|
[Acceptance tests]
목표는 기술 작업을 고객 결과와 연결합니다. 개선이 충분한지, 압박 상황에서 어떤 저하를 허용할지 결정할 수 있습니다.
운영 관찰과 대표 부하 시험을 사용합니다. 느린 쿼리, 데이터베이스 연결, CPU, 메모리, 큐 대기 시간, 외부 서비스 한도를 확인합니다. 무작위 요청뿐 아니라 인기 상품으로 쏠리는 트래픽도 포함합니다.
데이터베이스 연결이 한계라면 앱 노드 추가가 경합을 늘릴 수 있습니다. 결제 업체의 할당량이 한계라면 빠른 앱이 그 한도를 높이지는 않습니다.
정상 동작 외에 빈 캐시와 인스턴스 한 개의 장애도 시험합니다. 이상적인 시험에 충분한 용량뿐 아니라 캠페인 중 복구할 여력이 필요합니다.
| 발견 | 검토할 조치 | 필요한 증거 |
|---|---|---|
| 비싼 읽기가 반복됨 | 쿼리 개선 또는 적절한 결과 캐시 | 최신성을 유지하며 DB 작업 감소. |
| 배경 작업이 구매와 경쟁 | 용량 제한 또는 분리 | 배경 부하 중에도 구매가 정상. |
| 의존 서비스 할당량 부족 | 증액 협의 또는 진입 제어 | 확인된 한도와 한계에서의 시험 결과. |
| 작은 개선 뒤에도 용량 부족 | 확장 또는 큰 설계 변경 검토 | 측정한 효과, 이전 계획, 비용. |
각 조치에 담당자, 예산, 의존성, 기한, 수용 시험을 둡니다. 구현뿐 아니라 배포, 운영 교육, 온콜 준비도 포함합니다.
고객 영향과 실행 위험으로 우선순위를 정합니다. 대규모 재작성이나 샤딩에는 입증된 이유와 이전 및 검증을 위한 충분한 시간이 필요합니다.
변경을 관리 가능한 단위로 출시하고 예상 경로를 함께 시험합니다. 트래픽 확대, 확대 중단, 롤백 기준을 정합니다. 데이터 형식 변경은 단순 롤백 대신 앞으로 수정하는 복구가 필요할 수 있습니다.
선택적 내보내기 지연, 배경 작업 제한, 핵심 작업을 보호하면서 초과 요청 거절 등 통제된 저하를 준비합니다. 실제로 부하를 줄이고 고객에게 명확한 결과를 주는지 확인합니다.
목표가 일정이나 예산에 맞지 않으면 제품팀에 구체적 선택지를 제시합니다. 유입을 나누거나, 비싼 기능을 줄이거나, 측정한 병목에 투자할 수 있습니다. 각 선택의 고객 영향과 불확실성을 설명합니다.
기억할 점: 성장 가정 → 서비스 목표 → 측정한 한계 → 담당자가 있는 계획 → 연습한 출시. 테크리드는 사람, 비용, 복구까지 포함한 용량 계획을 만듭니다.
주니어부터 시니어까지 상세한 답변이 포함된 IT 면접 질문 라이브러리.
후원하기