자체 개발한 API 게이트웨이 덕분에 제3자 서비스 호출 비용을 38% 절약했지만, 지역 간 호환성 문제로 골치를 앓고 있습니다.

지난주 우리 동남아시아 전자상거래 도구 팀은 Q1의 기술 비용 청구서를 검토한 후, 결제 인터페이스를 담당하는 동료가 깜짝 놀랐습니다. 이전에 사용하던 제3자 게이트웨이를 자체 개발한 게이트웨이로 교체한 후에 월간 API 호출 비용이 38%나 줄었거든요. 하지만 대규모 프로모션 전에 진행된 그레이트컬러 테스트에서 싱가포르 노드의 사용자 결제 성공률이 갑자기 6%포인트 하락했습니다. 원인을 찾기 위해 오랫동안 조사한 끝에, 게이트웨이의 지역 간 브레이킹 규칙이 적절히 조정되지 않았다는 것을 발견했습니다.

먼저 이해해야 할 것은: 자체 개발한 게이트웨이가 도대체 무엇인가 하는 것입니다.

간단히 말해서, 자신만의 트래픽 엔트리 프로그램을 작성하여 모든 외부 API 요청, 제3자 콜백, 서비스 간 호출을 이 프로그램을 통해 처리하도록 하는 것입니다. 이는 이전에 구매한 제3자 게이트웨이 서비스를 대체하는 것입니다. 현재 우리가 사용하는 버전은 4대의 2코어 4G 해외 노드 서버에서 실행되고 있으며, 각 서버는 초당 1200건의 요청을 처리할 수 있어서 하루 평균 180만 건의 결제 및 상품 동기화 요청을 완벽하게 처리할 수 있습니다.

당신이 얻을 수 있는 세 가지 실질적인 이점은 다음과 같습니다:

• 먼저, 비용을 실제로 절감할 수 있습니다. 이전에 사용하던 제3자 게이트웨이는 호출 횟수에 따라 요금이 부과되어 매달 2,100달러가 소요되었는데, 이제 자체적으로 구축한 서버와 모니터링 비용을 합쳐도 매달 1,300달러 미만으로 충분합니다. 게다가 단계적인 요금 인상의 제한도 받지 않습니다.
• 둘째로, 규칙을 완전히 자율적으로 설정할 수 있습니다. 이전에는 제3자 게이트웨이를 통한 제한이 통합되어 있었는데, 대규모 프로모션 기간 동안 결제 인터페이스에 임시로 제한 쿼터를 할당해야 했습니다. 이때마다 3개 작업일이 걸리는 티켓을 제출해야 했습니다. 하지만 이제는 백엔드에서 설정을 변경하는 데 단 10초만 소요되며 즉시 효력이 발생합니다.
• 마지막으로, 데이터를 제3자를 통해 전송할 필요가 없습니다. 우리는 전자상거래 도구를 개발하면서 많은 사용자의 결제 확인 요청을 처리해야 하는데, 이전에는 모든 요청이 제3자 서비스 제공업체의 시스템을 거쳐야 했습니다. 이제는 모든 민감한 데이터가 우리 자체 서버에서 처리되므로 규정 준수 비용이 크게 줄었습니다.

서둘러서 설치하지 마세요. 먼저 우리가 겪었던 문제들을 살펴보세요.

첫 번째 문제는 지역 간 네트워크 적응의 문제였습니다. 처음에는 게이트웨이 메인 노드를 싱가포르에 두었는데, 말레이시아 사이트를 개설할 때 트래픽을 그대로 싱가포르로 전환했습니다. 그 결과로 로컬 사용자의 요청이 싱가포르를 거쳐 다시 돌아오게 되어 네트워크 지연이 200ms 증가했습니다. 많은 사용자들이 이 지연으로 인해 결제 페이지를 포기했습니다. 우리는 말레이시아의 엣지 노드를 설치하는 데 일주일이 걸렸습니다.

두 번째 문제는 보안 규칙의 누락입니다. 이전에 사용하던 제3자 게이트웨이에는 DDoS 방지 및 악성 요청 차단 기능이 기본적으로 포함되어 있었는데, 우리가 직접 시스템을 구축할 때 이 부분을 추가하는 것을 깜빡했습니다. 그 결과 서비스를 온라인으로 올린 지 3일 만에 스파이더에 의해 20만 건의 유효하지 않은 요청이 발생하여 재고 인터페이스가 다운될 뻔했습니다.

세 번째 문제는 운영 및 유지보수 비용이 예상보다 높다는 것입니다. 이전에는 제3자 게이트웨이에 문제가 생기면 고객 서비스에 직접 연락했지만, 이제는 3명의 백엔드 개발자가 번갈아 가며 야간 근무를 하며 게이트웨이 모니터링을 해야 합니다. 지난달에만 게이트웨이 문제 해결에 모두의 작업 시간의 15%가 소요되었습니다.

어떤 팀이 함께 일하기에 적합한지, 어떤 팀은 시간 낭비가 되지 않는지 알아보세요.

만약 여러분의 팀이 하루에 평균 100만 회 이상의 API 호출을 하거나, 민감한 데이터를 많이 처리해야 하거나, 제3자 게이트웨이의 제한과 티켓 처리 절차에 질렸다면, 자체 게이트웨이를 구축하는 것은 분명히 고려할 가치가 있습니다.

하지만 만약 여러분의 팀에 백엔드 개발자가 2명 미만이거나, 비즈니스가 아직 빠르게 시험 단계에 있어서 인터페이스 규칙이 매주 바뀐다면, 굳이 시간을 들여서 이를 구현할 필요는 없습니다. 일단은 제3자 게이트웨이를 사용해서 문제를 해결하면 되며, 비즈니스가 안정되면 그때 다시 바꾸는 것도 늦지 않습니다.

처음으로 조립하는 분들을 위한 3가지 실용적인 팁

1. 먼저 단일 시나리오부터 시작하세요. 처음부터 모든 것을 한 번에 대체하지 마세요. 우리는 처음에 결제 인터페이스의 트래픽만 자체 구축한 게이트웨이로 전환했고, 2주 동안 문제가 없이 잘 작동했습니다. 그 후에 다른 인터페이스들을 점차적으로 마이그레이션했습니다. 문제가 발생하더라도 결제 시나리오에만 영향을 미칠 뿐, 전체 사이트가 다운되지는 않을 것입니다.
2. 꼭 지역 간 스트레스 테스트를 수행해야 합니다. 특히 해외 사업을 하는 경우에는 현지에서만 테스트를 마치고 서비스를 온라인에 올리지 마세요. 목표 시장의 테스트 노드에서 24시간 동안 스트레스 테스트를 실시하여 지연 시간과 패킷 손실률에 문제가 없는지 확인해 보세요.
3. 모니터링 패널은 절대 소홀히 하지 마세요. 적어도 요청량, 성공률, 지연 시간이라는 세 가지 핵심 지표는 꼭 주의 깊게 살펴보고, 알림 임계값을 적절히 설정해 두세요. 사용자들이 불만을 제기하기 전에 게이트웨이가 다운된 것을 발견할 수 있도록 해야 합니다.

흔한 작은 문제들

질문: 반드시 Go나 Rust로만 프로그래밍을 해야 하나요?
아니요, 저희의 첫 번째 버전은 Node.js로 작성되었으며, 그것만으로도 피크 부하를 충분히 견딜 수 있습니다. 여러분 팀이 어떤 언어에 능숙한지에 따라 그 언어를 사용하시면 됩니다. 성능 문제가 생기면 그때 다른 언어로 교체해도 늦지 않습니다.

질문: 클라우드 제공업체의 게이트웨이와 비교했을 때 어느 것이 더 좋나요?
클라우드 제공업체의 게이트웨이는 제3자의 것보다 유연하지만, 자체적으로 구축한 것만큼의 자유도는 떨어집니다. 특정 클라우드 서비스에 얽매이고 싶지 않다면, 직접 구축하는 것이 더 경제적입니다.