Quota、Spike Arrest、Concurrent Rate Limit ポリシーの比較
  
      
    
  
  
  
  
  
    
  
  
    
    
  Quota ポリシー、Spike Arrest ポリシー、Concurrent Rate Limit ポリシーのうち、レート制限のニーズを最もよく満たすのはどれでしょうか。以下の比較表を参照してください。
  
    
      
        |   | 
        Quota | 
        Spike Arrest | 
        Concurrent Rate Limit | 
      
      
        | 適した用途: | 
        アプリが API プロキシのターゲット バックエンドに対して所定の期間内に作成できる接続数を制限します。 | 
        API プロキシのターゲット バックエンドを、サーバー トラフィックの急増やサービス拒否攻撃から保護します。 | 
        アプリが API プロキシのターゲット バックエンドに対して作成できる同時接続数を制限します。 | 
      
      
        | 適さない用途: | 
        
           API プロキシのターゲット バックエンドをトラフィックの急増から保護する目的では使用しないでください。 
          その目的には、Spike Arrest ポリシーまたは Concurrent Rate Limit ポリシーを使用します。 
         | 
        
           アプリが API プロキシのターゲット バックエンドに対して所定の期間内に作成できる接続数のカウントと制限には使用しないでください。 
          その目的には、Quota ポリシーを使用します。 
         | 
        
           アプリが API プロキシのターゲット バックエンドに対して所定の期間内に作成できる接続数の制限には使用しないでください。 
          その目的には、Quota ポリシーを使用します。 
         | 
      
      
        | カウント格納の可否: | 
        ○ | 
        × | 
        ○ | 
      
      
        | ポリシー接続に関するベスト プラクティス: | 
        
           ProxyEndpoint Request PreFlow に、概してユーザー認証後に接続します。 
          これにより、ポリシーが API プロキシのエントリ ポイントで割り当てカウンタを確認できます。 
         | 
        
           ProxyEndpoint Request PreFlow に、概してフローの一番最初に接続します。 
          これにより、API プロキシのエントリ ポイントで急増から保護できます。 
         | 
        
           このポリシーは以下の 3 か所に添付する必要があります。 
          
            - TargetEndpoint Request PreFlow
 
            - TargetEndpoint Response PreFlow
 
            - TargetEndpoint DefaultFaultRule
 
           
         | 
      
      
        | 制限に達したときの HTTP ステータス コード: | 
        
           500(内部サーバーエラー)* 
         | 
        
           500(内部サーバーエラー)* 
         | 
        503(サービス利用不可) | 
      
      
        | 参考情報: | 
        
          
            - 割り当てカウンタは Cassandra に格納されます。
 
            - カウンタを非同期に同期するようポリシーを構成して、リソースを節約してください。
 
            - 非同期カウンタの同期により、レート制限のレスポンスが遅れることがあり、呼び出しが設定されている制限を少しだけオーバーできる場合があります。
 
           
         | 
        
          
            - 最後のトラフィックが受信された時刻に基づいて調整が実施されます。その時刻はメッセージ プロセッサごとに保存されます。
 
            - レート制限として毎秒 100 呼び出しを指定すると、メッセージ プロセッサには 1/100 秒(10 ms)ごとに 1 回のみ呼び出しが許可されることになります。10 ms 以内に新たに呼び出しをしようとしても、拒否されます。
 
            - 毎秒のレート制限値が大きくても、ほとんど同時のリクエストは拒否されることがあります。
 
           
         | 
        
          
            - メッセージ プロセッサあたりの同時接続の数を保持します。
 
            - 個々の API プロキシが接続を数個しか処理しなくても、全体として、同じバックエンド サービスを参照するレプリケートされた API プロキシの集合に対する接続が、サービスの能力を上回る可能性があります。このポリシーを使用して、このトラフィックを対処できる数の接続にまで制限してください。
 
            - 1 秒あたりのトランザクション数(TPS)が多い API プロキシの場合、このポリシーを使用すると、プロキシのパフォーマンス低下を招くことが確認されています。TPS の高い API プロキシで Concurrent Rate Limit ポリシーを使用してパフォーマンスが著しく低下した場合は、代わりに Spike Arrest ポリシーを試してください。
 
           
         | 
      
      
        | 詳細情報: | 
        Quota ポリシー | 
        Spike Arrest ポリシー | 
        Concurrent Rate Limit ポリシー | 
      
    
  
  * Quota ポリシーと SpikeArrest ポリシーの場合、レート上限を超えていることを表すデフォルトの HTTP ステータス コードは汎用の 500 Internal Server Error になります。このポリシーのステータス コードを 429 Service Unavailable に変更するには、組織レベルのプロパティ(features.isHTTPStatusTooManyRequestEnabled)を追加します。クラウドをご利用のお客様は、Apigee サポートに連絡してプロパティの有効化を依頼してください。
  
  
  
 
  
    
    
      
    
    
  
       
         
  
       
    
    
  
  
  特に記載のない限り、このページのコンテンツはクリエイティブ・コモンズの表示 4.0 ライセンスにより使用許諾されます。コードサンプルは Apache 2.0 ライセンスにより使用許諾されます。詳しくは、Google Developers サイトのポリシーをご覧ください。Java は Oracle および関連会社の登録商標です。
  最終更新日 2020-07-09 UTC。
  
  
    
    
    
      
  
    
  
  
    
      [[["わかりやすい","easyToUnderstand","thumb-up"],["問題の解決に役立った","solvedMyProblem","thumb-up"],["その他","otherUp","thumb-up"]],[["必要な情報がない","missingTheInformationINeed","thumb-down"],["複雑すぎる / 手順が多すぎる","tooComplicatedTooManySteps","thumb-down"],["最新ではない","outOfDate","thumb-down"],["翻訳に関する問題","translationIssue","thumb-down"],["サンプル / コードに問題がある","samplesCodeIssue","thumb-down"],["その他","otherDown","thumb-down"]],["最終更新日 2020-07-09 UTC。"],[],[]]