サーバーレスアプリケーションのレート制限

さまざまなレイヤーに複数の代替レート制限ソリューションがあります。簡単な賛否両論の分析とともに3つの主要なものをリストします。

1-同時実行レベルの機能：

クラウドプロバイダーは、サーバーレス関数の実行をスケーリングするために複数のコンテナーを作成します。同時コンテナ/インスタンスの最大数に制限を設定できます。これは同時実行を制限するのに役立ちますが、1秒間に関数が呼び出される回数を制御することはできません。

AWSLambdaとGoogleCloudFunctionsの同時実行を制限する方法は次のとおりです。

長所：

• オーバーヘッドなし
• 設定が簡単

短所：

• 完全な解決策ではありません。同時実行のみを制御します。 1秒あたりの実行回数に制限はありません。

2-APIGatewayのレート制限

API Gatewayを介して機能にアクセスしている場合は、レート制限ポリシーをAPIGatewayに適用できます。 AWSとGCPの両方に、ソリューションの構成方法に関するガイドがあります。

長所：

• オーバーヘッドなし
• 設定が簡単

短所：

• APIGatewayを使用している場合にのみ適用されます。
• ユーザーごとまたはIPごとの割り当てなどのより高度なケースはサポートされていません。

3-Redisによるレート制限

これは最も完全で強力なソリューションです。多くのRedisベースのレート制限ライブラリが利用可能です。 Jeremy Dalyのブログ投稿で、彼は可能な解決策としてElasticacheを拒否し、*this adds a “non-serverless” component and another thing to manage *。ここで、Upstashは、サーバーレスモデルとリクエストごとの価格設定により、非常に優れた代替手段になります。

長所：

• 強力で、ユーザーモデルに合わせてカスタマイズされたロジックを実装できます。
• スケーラブルなソリューション。 Githubがレート制限にRedisをどのように使用しているかをご覧ください
• 豊富なエコシステム、多くのオープンソースライブラリ：redis_rate、redis-cell、node-ratelimiter

短所：

• Redisの使用のオーバーヘッド。

コード：Redisによるレート制限

レート制限ライブラリのおかげで、アプリケーションコードにレート制限を適用するのは非常に簡単です。以下のサンプルコードでは、1秒あたりのIPあたりのAWSLambda関数の実行を制限しています。

const RateLimiter = require("async-ratelimiter");
const Redis = require("ioredis");
const { getClientIp } = require("request-ip");

const rateLimiter = new RateLimiter({
  db: new Redis("YOUR_REDIS_URL"),
  max: 1,
  duration: 5_000,
});

module.exports.hello = async (event) => {
  const clientIp = getClientIp(event) || "NA";
  const limit = await rateLimiter.get({ id: clientIp });
  if (!limit.remaining) {
    return {
      statusCode: 429,
      body: JSON.stringify({
        message: "Sorry, you are rate limited. Wait for 5 seconds",
      }),
    };
  }

  return {
    statusCode: 200,
    body: JSON.stringify({
      message: "hello!",
    }),
  };
};

完全な例については、チュートリアルにアクセスしてください。