핵심 정리
- REST는 브라우저, 서버리스 함수, 관리 도구, 중저빈도 호출에서 가장 간단한 선택입니다.
- gRPC는 연결을 재사용하는 서버 간 지속 호출과 타입이 명확한 클라이언트에 적합합니다.
- 같은 리전의 대상 지연시간과 공용 인터넷을 거친 고객의 종단 지연시간을 구분해 측정합니다.
REST가 실용적인 기본값인 경우
REST는 표준 HTTP 도구로 확인하기 쉽고 일반적인 게이트웨이와 기업 네트워크를 통과하기 편합니다. 호출이 간헐적이거나 클라이언트가 다양하거나 curl과 일반 SDK로 빠르게 시작해야 할 때 적합합니다.
REST도 연결 재사용이 중요합니다. 요청마다 새 TLS 연결을 만드는 벤치마크는 API 처리보다 핸드셰이크 비용을 크게 측정합니다. 운영 클라이언트는 keep-alive, 제한된 연결 풀, 요청 제한시간, 구조화된 오류 처리를 사용해야 합니다.
gRPC의 운영 비용을 감수할 가치가 있는 경우
gRPC는 타입이 있는 계약, 압축된 바이너리 프레이밍, HTTP/2 다중화, 효율적인 연결 재사용을 제공합니다. 지속적으로 요청을 보내는 백엔드 서비스와 지원되는 gRPC 클라이언트를 통제할 수 있는 환경에 적합합니다.
재연결, 제한시간, 상태 점검, 로드밸런서 호환성은 별도로 설계해야 합니다. 장기 연결 채널은 요청마다 만들지 말고 재사용합니다. 코어 처리 시간이 짧아도 네트워크, 인증, 속도 제한, 스케일링 이벤트를 포함한 p95가 같은 수준이라는 뜻은 아닙니다.
재시도는 업무 결과를 바꿀 수 있습니다
시간 초과가 발생했다고 서버가 아무 일도 하지 않았다고 단정할 수 없습니다. 업무 멱등성 없이 추첨이나 섞기를 다시 호출하면 두 번째로 유효한 난수 결과가 만들어질 수 있습니다. 하나의 업무 이벤트는 자체 연산 식별자를 가지고 전송 재시도와 새로운 업무 요청을 구분해야 합니다.
출시 전에 쓸 수 있는 시험 조합
고객이 사용할 AWS 리전이나 네트워크에서 클라이언트를 실행하고 전송 설정을 고정합니다. 요청 속도와 API 키 수를 각각 늘린 뒤 영수증 사용 비율을 바꿔 반복합니다. 지속 부하, 짧은 버스트, 스케일링 이벤트를 포함해야 용량과 회복을 추정이 아니라 결과로 확인할 수 있습니다.