Kubernetes 게이트웨이를 사용하여 429 오류를 해결하여 서버 비용을 30% 절감했습니다.

지난 달 블랙 5 에 우리 팀은 거의 붕괴 될 뻔했다 :13% 의 사용자 주소 분석 요청은 429 에 의해 거부되었습니다.백그라운드에서 반나절을 조사한 후에야 이전에 각 마이크로서비스에 단독으로 배정된 흐름제한규칙이 너무 죽었고 물류조회모두의 흐름량이 3 배로 늘어나고 기타 비어있는 자원은 전혀 과거로 옮길수 없다는것을 발견하였다.

이전에는 Kubernetes 게이트웨이가 대기업에서만 사용되는 복잡한 구성 요소라고 생각했고, 이 구덩이를 밟을 때까지 온라인에 강제로 출시되지 않았으며, 우리가 예상했던 것보다 훨씬 더 나은 효과가 있었다.

Kubernetes 게이트웨이는 무엇입니까?

전체 Kubernetes 클러스터에 대한 통합 트래픽 포털, 모든 외부 요청이 먼저 여기에 도착한 다음 해당 백엔드 서비스로 전달되며, 오픈 소스 버전의 단일 인스턴스는 초당 12, 000 개의 요청을 처리 할 수 있으며, 작은 팀은 성능 병목 현상을 겪을 필요가 없습니다.

우리가 얻은 세 가지 혜택

첫 번째는 가장 직 관 적입니다 : 현재 제한 규칙 은 마침내 각 서비스를 개별 적으로 설정 하지 않습니다 .이전에 우리는 7 ~ 8 개의 마이크로 서비스 의 흐름 제한 임 계 값 을 변경 해야 한다고 크게 촉 구하고 하나 누 락 을 변경 하면 문제가 발생합니다 . 지금은 게 이트 웨 이 층 에서 직접 동 적 흐름 제한 을 하고 비 워 진 서버 자 원은 자동 으로 트 래 픽 이 높은 모듈 에 기울 어 질 수 있습니다 . 이번 크리스마 스는 우리의 42 9 오류 보고 가 직접 0 으로 떨어 졌습니다 .

두 번째는 비용 절감이다.이전에는 피크를 수행하기 위해 3 개의 핵심 서비스에 2 개의 이중화 서버를 추가로 배치했으며 대부분의 시간 리소스 활용률은 20 % 에 불과했으며 이제는 게이트웨이가 자동으로 로드 밸런싱을 수행 할 수 있으며 6 개의 서버를 직접 축소하여 매월 클라우드 비용을 30 % 절감했습니다.

세 번째는 백엔드가 이러한 공통 논리를 도메인 간으로 반복적으로 변경하고 인증하지 않도록하는 것입니다.이전에는 새로운 서비스가 출시 될 때마다 백엔드에서 JWT 검증 코드를 작성해야하며 지금은 게이트웨이 계층에서 규칙을 직접 배치하여 처리합니다. 우리 백엔드 3 명은 매주 적어도 반나절 동안 비즈니스 코드를 작성할 수 있습니다.

좋은 점만 듣지 말고, 이 두 구덩이는 우리가 튼튼히 밟았다.

첫 번째 구덩이는 기본 시간 초과 설정인 Too Pit 입니다.첫날에 우리는 주소 분석 요청의 5 % 가 시간 초과되어 반날을 확인하여 게이트웨이의 기본 시간 초과 시간이 30 s 이라는 것을 발견했지만 주소 분석 서비스 자체는 최대 40 s 를 실행해야하며 규칙을 변경하면 즉시 복구되며 온라인에 오기 전에 반드시 자신의 비즈니스 인터페이스에 대한 시간 초과 임계값을 하나씩 확인해야합니다.

두 번째 구덩이는 처음부터 모든 기능을 쌓지 않는 것입니다.우리는 처음에 로그, 현재 제한, WAF, 회색 스케일 릴리스의 모든 기능을 한 번에 완전히 열고 싶었습니다. 결과 구성이 잘못 작성되어 전체 클러스터 입구가 20 분 동안 끊어졌습니다. 나중에 우리는 먼저 라우팅과 현재 제한만 열고 3 일 동안 안정적으로 실행하고 천천히 다른 기능을 추가하면 문제가 없습니다.

도대체 써야 하나요?우리가 제시한 판단 기준은 간단하다.

사용에 적합한 상황:

• 마이크로 서비스의 수는 이미 5 개 이상이며, 공통 구성을 변경할 때마다 여러 곳을 앞뒤로 변경해야합니다.
• 트래픽 피크가 자주 발생하여 서비스 간에 리소스를 유연하게 예약할 수 없습니다.
• 백엔드 팀은 5 명 미만이며 일반 논리를 반복하는 데 시간을 낭비하고 싶지 않습니다.

삐걱거리지 마세요 :

• 당신은 2 개의 마이크로 서비스를 가지고 있으며, 트래픽은 일년 내내 안정적이며, 현재 nginX 를 사용하여 전달하는 데 아무런 문제가 없습니다.
• 팀 전체가 Kubernetes 의 기초를 이해하지 못합니다. 새로운 기술을 따라 잡기 위해 열심히 노력하지 마십시오.

처음 시작하는 작은 팀에게 두 가지 팁.

모델 선택을 고민하지 않고, 작은 팀은 직접 오픈 소스 APISIX 또는 Kong 을 사용하고, 모든 지원 문서가 있으며, 문제가 발생하면 기본적으로 모든 솔루션이 있으며, 상업용 버전을 구입할 필요가 없으며, 무료 버전의 기능은 완전히 충분합니다.

온라인을 시작하기 전에 10% 의 트래픽을 24 시간 동안 잘라, 초과 시간, 요청이 잘못 차단 된 상황이 있는지에 중점을 두고, 문제가 없으며 다시 전량으로 잘라, 올라오자마자 모든 트래픽을 유도하지 마십시오.

마지막으로 여러분이 자주 묻는 것을 말하십시오 : 우리 3 개의 백엔드 이전에 아무도 게이트웨이를 전문적으로 연구하지 않았으며 공식 문서를 위해 2 일이 걸렸습니다.