7.2. 기본 캐싱


캐시되지 않은 요청의 경우 이러한 이벤트는 다음과 같습니다.

  1. APIcast는 일치하는 매핑 규칙에서 사용 지표를 추출합니다.
  2. APIcast는 메트릭과 애플리케이션 인증 정보를 3scale 백엔드 서버로 보냅니다.
  3. 3scale 백엔드 서버는 다음을 수행합니다.

    1. 애플리케이션 키를 확인하고 보고된 메트릭 사용이 정의된 제한 내에 있는지 확인합니다.
    2. 보고된 지표의 사용을 늘리기 위해 백그라운드 작업을 대기열에 넣습니다.
    3. 요청이 승인되어야 하는지 여부를 APIcast에 응답합니다.
  4. 요청이 승인된 경우 업스트림으로 이동합니다.

이 경우 3scale 백엔드 서버가 응답할 때까지 요청은 업스트림에 도달하지 않습니다.

다른 한편으로는 기본적으로 활성화된 캐싱 메커니즘을 사용하여 다음을 수행합니다.

  • APIcast는 권한이 부여된 경우 3scale 백엔드 서버에 대한 권한 부여 호출 결과를 캐시에 저장합니다.
  • 동일한 인증 정보 및 메트릭이 있는 다음 요청은 3scale 백엔드 서버로 이동하는 대신 캐시된 권한 부여를 사용합니다.
  • 요청이 승인되지 않았거나 APIcast가 인증 정보를 처음 수신하는 경우 APIcast는 위에서 설명한 대로 3scale 백엔드 서버를 동기적으로 호출합니다.

인증이 캐시되면 APIcast는 먼저 업스트림을 호출한 다음 post action 이라는 단계에서 3scale 백엔드 서버를 호출하고 다음 요청을 준비하도록 캐시에 권한 부여를 저장합니다. 3scale 백엔드 서버에 대한 호출은 요청 시간에 발생하지 않기 때문에 대기 시간이 발생하지 않습니다. 그러나 동일한 연결로 전송된 요청은 post 작업 단계가 완료될 때까지 기다려야 합니다.

클라이언트가 keep-alive 를 사용하고 있는 시나리오를 가정하고 매초마다 요청을 보냅니다. 업스트림 응답 시간이 100ms이고 3scale 백엔드 서버의 대기 시간이 500 ms인 경우 클라이언트는 100ms로 마다 응답을 받습니다. 전체 업스트림 응답 및 보고에는 600 ms가 필요합니다. 이는 다음 요청이 시작되기 전에 400 ms를 추가로 제공합니다.

아래 다이어그램은 기본 캐싱 동작을 보여줍니다. 캐싱 메커니즘의 동작은 캐싱 정책을 사용하여 변경할 수 있습니다.

기본 캐싱 동작
Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

© 2024 Red Hat, Inc.