AWS Mainframe Modernization Service (マネージドランタイム環境エクスペリエンス) は、新規のお客様に公開されなくなりました。 AWS Mainframe Modernization Service (マネージドランタイム環境エクスペリエンス) と同様の機能については、 AWS Mainframe Modernization Service (セルフマネージドエクスペリエンス) をご覧ください。既存のお客様は、通常どおりサービスを引き続き使用できます。詳細については、AWS 「 Mainframe Modernization の可用性の変更」を参照してください。
翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
AWS Blu Age ランタイムのレート制限を設定する
AWS Blu Age ランタイムには、過剰なリクエストや不正使用から gapwalk アプリケーションを保護するためのレート制限機能が組み込まれています。レート制限システムは、トークンバケットアルゴリズムを使用して、バースト容量と持続的なレート制限の両方を提供します。
レート制限の概要
レート制限システムには以下の機能があります。
- トークンバケットアルゴリズム
-
設定されたバースト容量までのバーストトラフィックを許可する
1 分あたりのリクエスト数に基づいてトークンを一定の割合で補充します
正当なトラフィックスパイクをブロックすることなく、スムーズなレート制限を提供
- クライアント ID
-
プロキシをサポートする IP アドレスでクライアントを識別します
X-Forwarded-For ヘッダーと X-Real-IP ヘッダーをサポート
ロードバランサーとリバースプロキシのシナリオを処理します
- 自動メモリ管理
-
期限切れレート制限バケットを自動的にクリーンアップする
設定可能なクリーンアップ間隔と有効期限
長時間実行されるアプリケーションでのメモリリークの防止
- HTTP 統合
-
制限を超えたときに HTTP 429 (リクエストが多すぎます) を返します
レスポンスに標準レート制限ヘッダーを含める
クライアントに再試行情報を提供します。
設定プロパティ
application-main.yaml ファイルでレート制限を設定します。
gapwalk: ratelimiting: enabled: true # Enable/disable rate limiting requestsPerMinute: 1000 # Sustained rate limit per minute burstCapacity: 1500 # Maximum burst requests allowed includeHeaders: true # Include X-RateLimit-* headers cleanupIntervalMinutes: 5 # Cleanup interval for expired buckets bucketExpiryHours: 1 # Hours after which unused buckets expire errorMessage: "Too many requests. Try again later." # Custom error message whitelistIps: "" # Comma-separated IPs to bypass limiting perEndpointLimiting: false # Apply limits per endpoint (not implemented)
プロパティの説明
- 有効
-
レート制限機能を有効または無効にするマスタースイッチ。デフォルト:
false - requestsPerMinute
-
持続的なレート制限で 1 分あたりに許可されるリクエストの数。これはトークンリフィルレートを表します。デフォルト:
1000 - burstCapacity
-
レート制限が適用される前にバーストで許可されるリクエストの最大数。トラフィックの急増を許可する
requestsPerMinuteには、 よりも高くする必要があります。デフォルト:1500 - includeHeaders
-
HTTP レスポンスに標準レート制限ヘッダー (
X-RateLimit-Limit、X-RateLimit-Remaining、X-RateLimit-Reset) を含めるかどうか。デフォルト:true - cleanupIntervalMinutes
-
期限切れのレート制限バケットの自動クリーンアップの分単位の間隔。メモリリークの防止に役立ちます。デフォルト:
5 - bucketExpiryHours
-
未使用のレート制限バケットが期限切れと見なされ、クリーンアップの対象となる時間。デフォルト:
1 - errorMessage
-
レート制限を超えたときに JSON レスポンスで返されるカスタムエラーメッセージ。デフォルト:
"Too many requests. Try again later." - whitelistIps
-
レート制限を完全にバイパスする IP アドレスのカンマ区切りリスト。ヘルスチェックや信頼できるシステムに役立ちます。デフォルト:
empty - perEndpointLimiting
-
クライアントのみではなくエンドポイントごとに個別のレート制限を適用するかどうか。現在実装されていません。デフォルト:
false
レート制限を有効にする
デフォルト設定でレート制限を有効にするには:
gapwalk: ratelimiting: enabled: true
クライアント ID
レート制限システムは、次の優先順位を使用してクライアントを識別します。
X-Forwarded-For ヘッダー (カンマ区切りの場合は最初の IP)
X-Real-IP ヘッダー
HTTP リクエストからのリモートアドレス
これにより、アプリケーションの背後にある場合の適切なクライアント識別が保証されます。
ロードバランサー
リバースプロキシ
CDNs
API ゲートウェイ
クライアント ID の例
# Direct connection Client IP: 192.168.1.100 # Behind load balancer with X-Forwarded-For X-Forwarded-For: 203.0.113.45, 192.168.1.100 Client IP: 203.0.113.45 (first IP used) # Behind reverse proxy with X-Real-IP X-Real-IP: 203.0.113.45 Client IP: 203.0.113.45
レート制限ヘッダー
includeHeaders を有効にすると、次のヘッダーが HTTP レスポンスに追加されます。
- X-RateLimit-Limit
-
クライアントのレート制限の上限 (1 分あたりのリクエスト数)
- X-RateLimit-Remaining
-
現在のレート制限ウィンドウに残っているリクエストの数
- X-RateLimit-Reset
-
レート制限ウィンドウがリセットされる時刻 (Unix タイムスタンプ)
レスポンスヘッダーの例
X-RateLimit-Limit: 1000 X-RateLimit-Remaining: 847 X-RateLimit-Reset: 1640995200
レート制限がレスポンスを超えました
レート制限を超えると、システムは以下を返します。
- HTTP ステータス
429 Too Many Requests
- Content-Type
application/json
- 再試行後
再試行するまでの待機秒数
{ "error": "Rate limit exceeded", "message": "Too many requests. Try again later.", "retryAfter": 60, "timestamp": 1640995140000 }
メモリ管理
レート制限システムは、長時間実行されるアプリケーションのリークを防ぐためにメモリを自動的に管理します。
- 自動クリーンアップ
-
cleanupIntervalMinutes分ごとに実行bucketExpiryHours時間未使用のバケットを削除しますモニタリングのクリーンアップアクティビティを記録します。
- メモリ効率
-
スレッドの安全性のために同時データ構造を使用する
遅延バケットの作成 (必要な場合のみ)
効率的なトークンバケットの実装
クリーンアップアクティビティのモニタリング
クリーンアップメッセージのログを確認します。
INFO RateLimitingService - Cleaned up 15 expired rate limiting buckets