클라우드 네이티브 게이트웨이를 사용하여 트래픽 처리 비용을 38% 절감했지만, 블랙프라이데이에 유럽의 신선식품 배송 체인을 거의 망칠 뻔했습니다.

지난주 블랙프라이데이 대규모 프로모션 회고회가 막 끝났는데, 우리 3명으로 구성된 유럽 신선식품 배송 백엔드 팀은 아직도 떨리고 있습니다. 예약 첫날에 냉동 배송 요청의 17%가 바로 거절되었으며, 사용자 불만 건수가 세 배로 증가하여 3개월 동안 준비해온 연례 대규모 프로모션을 망칠 뻔했습니다.

문제는 2년 동안 사용해 온 기존 API 게이트웨이 때문에 발생했습니다. 주소 해석과 물류 예약이라는 두 가지 핵심 인터페이스에 동일한 제한 설정을 적용했는데, 블랙프라이데이 당일 주소 해석 요청이 폭주하여 게이트웨이의 할당량을 모두 소진시켜 예약 요청들이 전혀 처리되지 못했습니다. 이전에는 게이트웨이를 교체하는 것이 대규모 팀만이 해야 할 일이라고 생각했지만, 이번 경험을 통해 클라우드 네이티브 게이트웨이가 소규모 팀에게도 더 경제적이고 효율적인 선택일 수 있다는 것을 깨달았습니다.

클라우드 네이티브 게이트웨이란 무엇인가요?

한마디로 요약하자면, 이것은 K8s 클러스터에서 실행되는 트래픽 엔트리로, 별도로 서버를 임대하여 배포할 필요가 없습니다.당신은 라우팅 규칙과 제한 전략만 관리하면 되며, 나머지 리소스의 탄력성과 운영 유지보수 업그레이드는 모두 클라우드 제공업체가 처리합니다.현재 사용 중인 버전은 단일 인스턴스로 초당 2만 건의 요청을 처리할 수 있으므로, 사전에 용량 계획을 세울 필요가 없습니다.

변환 후 우리가 얻은 실제 수익은 세 가지입니다.

예약 판매일에 발생한 장애 이후, 우리는 3일 동안 클라우드 네이티브 게이트웨이로 전환하는 작업을 진행했습니다. 블랙프라이데이 본선 경기 당일에는 한 번도 제한 설정으로 인한 오류가 발생하지 않았으며, 예상을 뛰어넘는 세 가지 긍정적인 효과도 있었습니다:

• 비용이 직접적으로 줄었습니다: 이전에는 4코어의 8G 서버 두 대를 별도로 임대하여 기존 게이트웨이를 운영했으며, 추가로 운영 및 유지보수 인력이 매월 8시간을 할애하여 버전 업그레이드를 진행했기 때문에 월 비용이 1200유로였습니다. 하지만 이제는 클라우드 네이티브 게이트웨이를 사용하여 사용량에 따라 비용을 지불하므로 월 비용이 740유로로 줄었습니다.네트워크 트래픽 처리 비용을 38%나 직접 절약했습니다.
• 제한 전략이 마침내 이해되었습니다: 이전에는 게이트웨이에서 전체 인터페이스에 대한 제한 임계값만 설정할 수 있었지만, 이제는 다양한 비즈니스 시나리오에 따라 개별 규칙을 설정할 수 있습니다. 예를 들어, 주소 해석 인터페이스의 경우 초당 최대 5000번의 요청만 허용하도록 설정할 수 있습니다. 이렇게 하면 해당 인터페이스가 과도하게 사용되더라도 결제나 예약과 같은 다른 프로세스에는 영향을 미치지 않습니다.
• HTTPS 핸드셰이크 시간이 절반으로 줄었습니다: 이전에는 SSL 인증서가 우리의 게이트웨이 서버에 저장되어 있어 유럽의 다른 지역 사용자들의 핸드셰이크 지연이 200ms에 달했지만, 이제 클라우드 제공업체가 인증서를 엣지 노드에 캐싱함으로써 대부분의 요청에서 핸드셰이크 지연을 80ms 이내로 줄일 수 있게 되었습니다.

차에 타기 전에 조금만 기다려주세요. 이 두 개의 함정은 이미 우리가 피해봤거든요.

클라우드 네이티브 게이트웨이가 모두 장점만 있는 것은 아니며, 우리가 전환하는 과정에서도 두 가지 문제에 부딪혀 다시 작업을 해야 할 뻔했습니다:

첫 번째 문제는 콜드 스타트 지연입니다. 첫날 테스트를 마친 후, 10분 동안 아무 요청도 없었던 후 첫 번째 요청의 응답 시간이 갑자기 300ms 이상으로 증가하는 것을 발견했습니다. 나중에야 클라우드 제공업체의 역동적인 인스턴스가 필요에 따라 시작된다는 것을 알게 되었고, 핵심 인터페이스에 최소 인스턴스를 예약해 두어야 한다는 것을 알았습니다. 그렇지 않으면 여유 시간에 갑자기 트래픽이 증가하면 쉽게 시간 초과가 발생할 수 있습니다.

두 번째는 사용자 정의 플러그인에 대한 제한입니다. 이전에는 우리가 직접 작성한 요청 서명 검증 플러그인을 기존 게이트웨이에서 사용했는데, 새로운 클라우드 네이티브 게이트웨이로 전환할 때 그 플러그인이 WebAssembly 형식만을 지원한다는 것을 알게 되었습니다. 코드를 수정하는 데 이틀이 걸렸습니다. 만약 여러분이 많은 사용자 정의 로직을 사용한다면, 먼저 제조업체가 지원하는 플러그인의 범위를 잘 확인하는 것이 좋습니다.

결국 바꿔야 할지 말지는 어떻게 판단해야 할까요? 이 두 가지 기준을 직접 살펴보세요.

당신이 바꿔야 할 상황은:

• 팀원이 5명 미만이고 전담 운영 및 유지보수 인력도 없어서 게이트웨이 서버의 관리나 업그레이드에 시간을 할애하고 싶지 않습니다.
• 트래픽 변동이 큽니다. 예를 들어, 대규모 프로모션 기간에는 평소의 3배에서 10배까지 트래픽이 증가하는데, 평소에는 사용되지 않는 서버를 미리 대량으로 임대하여 돈을 낭비하고 싶지 않습니다.

당신이 바꾸면 안 되는 상황:

• 컴플라이언스 요구 사항이 매우 엄격해서, 모든 트래픽은 반드시 자신이 제어할 수 있는 서버를 통해 전송되어야 하며, 클라우드 서비스 제공업체의 공용 노드를 사용할 수 없습니다.
• 당신의 게이트웨이에는 매우 많은 사용자 정의된 특수 로직이 포함되어 있어서, 시중에 나와 있는 클라우드 네이티브 게이트웨이들은 이를 지원하지 않습니다. 직접 수정하는 비용이 게이트웨이를 자체적으로 유지보수하는 비용보다도 더 높습니다.

처음 시작하는 분들을 위한 세 가지 작은 팁

• 전체 트래픽을 한 번에 전환할 필요는 없습니다. 먼저 10%의 트래픽을 클라우드 네이티브 게이트웨이로 전환하여 일주일 동안 운영해보고, 이상이 없는지 모니터링한 후에 점차적으로 전환하세요. 저희도 처음에는 주소 해석 인터페이스부터 전환을 시작했으며, 문제가 없어서야 전체 트래픽을 이전했습니다.
• 핵심 인터페이스는 반드시 최소 인스턴스 수를 설정해야 합니다. 그 작은 돈을 아끼지 마세요. 우리는 지금 냉망 유지 관리 예약과 결제라는 두 가지 핵심 인터페이스에 각각 2개의 상시 인스턴스를 배정해 두었고, 이후로 냉시작 지연 문제가 다시는 발생하지 않았습니다.
• 최고 사양의 버전을 구매할 필요는 없습니다. 대부분의 중소기업의 트래픽 규모에는 기본 버전의 기능만으로도 충분합니다. 우리가 현재 사용하고 있는 기본 버전은 QPS가 2만 이하일 때 추가 비용이 전혀 들지 않습니다.

마지막으로 팀 내에서 가장 많이 질문받은 문제에 대한 답변입니다: 클라우드 서비스 제공업체에 의해 종속되지는 않을까요?

우리의 판단은 다음과 같습니다: 10명 미만의 백엔드 팀에게는클라우드 제공업체와의 통합으로 인한 효율성 향상은 모든 구성 요소를 처음부터 직접 구축하는 데 드는 비용보다 훨씬 큽니다.. 정말로 언젠가 클라우드 서비스 제공업체를 바꿔야 할 때가 되면, 그때가 되면 충분한 에너지를 가지고 마이그레이션 작업을 할 수 있을 거예요. 지금은 그 문제에 너무 집착하지 마세요.