API 게이트웨이는 클라이언트와 내부 백엔드 서비스 사이에 있는 서비스의 아키텍처 모델입니다.
게이트웨이는 모든 클라이언트의 요청을 받아들여 정확한 서비스로 에이전트하고 어떤 경우에는 여러 서비스로 에이전트합니다.
중앙 집중식 솔루션으로 요청, 속도 제한, 통계 정보 수집 및 단일 포털 지점으로 공공 액세스를 제한하는 데 사용됩니다.

찬성 의견

인증

하나의 입구점이 있다는 것은 요청을 내부(때로는 민감한) 백엔드 서비스에 에이전트하기 전에 인증할 수 있다는 것을 의미한다.인증 논리는 서로 다른 서비스 주위에서 반복할 필요가 없고 API 게이트웨이에만 유지됩니다.

속도 제한

사용자가 서버에 생성한 요청 수량을 제한해서 부하를 줄이기를 원할 수도 있습니다.API 게이트웨이에서 이 메커니즘을 각 서비스에서 구현하는 것이 아니라 한 번만 구현할 수 있습니다.그것은 DDoS 공격이나 악성 사용자가 시스템을 파괴하려고 시도하는 것을 매우 편리하게 방지할 수 있습니다.

단일 입구

안전성에 있어서 이 점은 매우 중요하다.만약 당신이 엄격한 기업 표준을 따른다면, 시스템에 들어가는 데이터를 감시해야 할 수도 있습니다.시스템에 들어가는 입구가 하나만 있으면 이 임무를 더욱 쉽게 할 수 있다.서비스 하나만 감시하면 돼.
더 많은 장점이 있지만, 이러한 사실, 즉 하나의 입구점에 의존하기 때문에, 당신은 한 번만 원하는 논리를 실현할 수 있습니다.다른 서비스로 옮길 필요가 없습니다.

속이다

공연

클라이언트와 요청을 만족시키는 실제 서비스 사이에 중개인을 도입할 때 성능 비용이 항상 발생한다.요청은 클라이언트에서 API 게이트웨이로 전송되어야 합니다.거기서 서비스를 계속하고 API 게이트웨이로 돌아가고 클라이언트로 돌아갑니다.스트림 전송 요청을 통해 API 게이트웨이와 서비스가 같은 지역(클라우드 공급업체)에 있는지 확인하면 왕복 시간을 줄일 수 있다.그러나 성능 비용은 항상 존재합니다.

단일 장애 지점

단점 진입도 단점 고장을 의미한다.API 게이트웨이가 닫히면 모든 클라이언트가 시스템을 사용할 수 없습니다.이러한 상황이 발생하지 않도록 하고 API 게이트웨이를 엄격히 모니터링해야 합니다.그렇지 않으면, 너의 시스템에 시한폭탄이 하나 있을 것이다.

나의 결정

daily.dev을 더 작은 서비스로 분해하기 시작했을 때 사용자 정의 API 스위치를 추가했습니다.나의 주요 원인은 집중적인 방식으로 신분 검증을 처리하는 것이다.
이것은 한동안 좋았지만, 하루가 끝날 때, 나는 그것이 나의 시스템 성능에 영향을 끼치는 것을 참을 수 없었다.나는 이미 적당한 곳에서 추적을 나누어 주었기 때문에 나는 이 점을 확신한다.
지난주에 나는 API 게이트웨이 모델을 깨고 다른 서비스를 공개하기로 결정했다.공연 원가가 너무 높아 감당할 수 없다.결과는 매우 좋았다. 문장의 마지막에 나는 약간의 데이터를 공유했다.
중요한 것은 모든 용례에 대해 다른 해결 방안이 있을 수 있다는 것을 강조해야 한다. 나는 단지 이곳에서 나의 이야기를 나눌 뿐이다.API 게이트웨이를 삭제해야 하는 것은 아닙니다.

게이트웨이 분리

솔직히 말하면, 이것은 결코 실현하기 어렵지 않지만, 틀림없이 무서운 여정일 것이다.API 게이트웨이에는 프록시 요청과 검증 요청을 제외하고는 많은 논리가 없습니다.그래서 나는 단지 이 두 가지 문제를 해결하고 싶다.GraphQL 서비스에서 이 개념 검증을 했습니다.

인증

우리의 인증 시스템은 쿠키에 저장된 JWT 영패를 기반으로 한다.JWT의 주요 장점은 무상태 영패라는 것이다.영패를 검증하기 위해 데이터베이스가 필요하지 않습니다. 서명된 키만 필요합니다.게이트웨이의 JWT 영패 검증 함수를 GraphQL 서비스에 복사해서 인증서를 스스로 처리할 수 있도록 합니다.이 부분은 간단명료하다.

에이전트 요청

이제 무서운 부분을 보자.클라이언트를 변경하거나 다운타임을 도입할 필요 없이 GraphQL 서비스를 대중에게 공개해야 합니다.저는 Kubernetes에서 인프라 시설을 관리하기 때문에 서비스 즉 입구를 공개할 수 있는 방법밖에 없습니다.포털 리소스는 내부 서비스 간에 외부 트래픽을 라우팅하는 방법을 정의합니다.막후에서, 그것은 구글 클라우드 부하 평형기를 만들었다.Ingress는 경로 기반 라우팅을 지원하기 때문에 매우 적합합니다.
내가 아는 것은 입구 설정을 바꾸는 데 몇 분이 걸릴 수도 있고 정지될 수도 있다는 것이다.그래서 생산 입구를 바꾸는 것은 범위를 넘어섰다.나는 새 입구를 만들고 그것을 테스트한 후에 전환하기로 결정했다.
이것은 새로운 입구 설정입니다. 범위를 초과했기 때문에 자세히 소개하고 싶지 않지만, 경로를 기반으로 하는 경로를 볼 수 있습니다.기본적으로 요청은 게이트웨이로 프록시되지만 GraphQL 요청은 API 서비스로 프록시됩니다.

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
    kubernetes.io/ingress.global-static-ip-name: daily-ingress-ip
  labels:
    app: daily
  name: daily-ingress
  namespace: daily
spec:
  rules:
    - http:
        paths:
          - path: /*
            backend:
              serviceName: daily-gateway
              servicePort: http
          - path: /graphql
            backend:
              serviceName: daily-api-v2
              servicePort: http
  tls:
    - hosts:
        - app.dailynow.co
      secretName: app-dailynow-co-tls
    - hosts:
        - api.daily.dev
      secretName: api-daily-dev-tls

새 입구를 배치한 후, 로컬 호스트 파일을 점api로 설정합니다.매일의내가 현지에서 그것을 테스트할 수 있도록 새로운 입구를 개발하다.나는 신분 검증을 포함한 새로운 설정이 작동할 수 있는지 확인하기 위해 수동 검사를 했다.
그런 다음 DNS를 새 포털의 IP로 계속 변경합니다.며칠 후, 나는 낡은 입구를 제거하기로 결정했다.생산 인프라를 바꾸는 데는 시간과 인내심이 필요하니 조급해하지 마라.
나 성공했어!스위치 다운은 없나요?🚀

데이터 보여줘!

네가 이렇게 하는 것은 단지 통계 데이터를 보기 위해서일 뿐, 나는 안다.이어서 나는 세 가지 다른 비교를 했다.

우리의 익명 요약 성능, 이것은 비등록 사용자의 가장 흔히 볼 수 있는 요청

등록 사용자가 제시한 성능, 이것은 시스템

중 가장 복잡한 조회

GraphQL 라우팅의 성능이것은 비교로 이 변화의 전체적인 추세를 나타냈다.

도표는 일주일 동안 같은 시간에 변화한 후의 표현과 변화 전의 표현을 비교했다.



Looking forward to hearing your thoughts ✨
Daily은 새로운 라벨을 내놓을 때마다 최고의 프로그램 뉴스를 제공할 수 있다.우리는 당신이 미래를 해독할 수 있도록 수백 개의 합격원을 배열할 것입니다.