AWS Lambda におけるバースト耐性

token bucket algorithm が本稿のテーマになるのでまずはその意味を wikipedia から拾ってみたいと思います。

概要
トークンバケットは、バケット内のトークンの存在に基づいてトラフィックの転送をいつ行うかを指示する制御機構である。バケットには複数のトークンがあり、それぞれがあるバイト列単位に対応したり、事前に設定した大きさの1つのパケットに対応している。バケット内のトークンはパケットを送信する際に削除される。ネットワーク管理者は何バイトの転送に何個のトークンを対応させるかを設定する。トークンがあるとき、トラフィックを転送できる。バケット内にトークンがないとき、パケットを転送することはできない。従って、個別のフローに十分なトークンが割り当てられていて、バーストしきい値が適切に設定されていれば、そのフローはバースト的に転送可能である。

- Wikipedia より

あるシステムに requests per second (rps) の Quota 設定がされている場合を考えます。例えば 10 rps を Quota 設定されている API エンドポイントがあった場合、200 rps がクライアントから送信されたときに期待としては およそ 190 requests が throttle します。

200 rps 全て処理させたい場合、考えうる対処は 200 rps の Quota に API を設定変更するか、クライアント側で exponential backoff retry させるなどが思い付くでしょうか。

もちろん、これらの対処でも十分である場合も多いですが、クライアントが定常的に 200 rps 送信するのではなく、あるタイミングで一気に送信がスパイクして 200 rps になるが、ほとんどの時間帯では 0 〜 10 rps 程度であるようなシステム特性を持つワークロードも多いと思います。

スパイクに対応するようにシステムにバースト耐性を持たせておくことで、rps の Quota 設定は定常時に合わせて低く設定しておくことができるようになります。

上の例だと、10 rps を API の Quota 設定としておきながらも、200 rps まで バーストさせれるように設定できれば良いと思いませんか ?

そのようなシステム設計に対処するためのアルゴリズムの一つが token bucket algorithm になります。

考え方としては、また上記のスパイクするシステムを例にとって話すと、200 token が入る bucket (バケツのこと / S3 bucket とは何の関係もありません) を用意しておきます。API に 1 回のリクエストが来るたびに bucket から 1 token を払い出します (消費します)。リクエストのたびに token は消費していくので、bucket の中身はどんどん減っていきます。bucket の中身が枯渇した時点で throttle となります。

token bucket algorithm が本稿のテーマになるのでまずはその意味を wikipedia から拾ってみたいと思います。

概要
トークンバケットは、バケット内のトークンの存在に基づいてトラフィックの転送をいつ行うかを指示する制御機構である。バケットには複数のトークンがあり、それぞれがあるバイト列単位に対応したり、事前に設定した大きさの1つのパケットに対応している。バケット内のトークンはパケットを送信する際に削除される。ネットワーク管理者は何バイトの転送に何個のトークンを対応させるかを設定する。トークンがあるとき、トラフィックを転送できる。バケット内にトークンがないとき、パケットを転送することはできない。従って、個別のフローに十分なトークンが割り当てられていて、バーストしきい値が適切に設定されていれば、そのフローはバースト的に転送可能である。

- Wikipedia より

あるシステムに requests per second (rps) の Quota 設定がされている場合を考えます。例えば 10 rps を Quota 設定されている API エンドポイントがあった場合、200 rps がクライアントから送信されたときに期待としては およそ 190 requests が throttle します。

200 rps 全て処理させたい場合、考えうる対処は 200 rps の Quota に API を設定変更するか、クライアント側で exponential backoff retry させるなどが思い付くでしょうか。

もちろん、これらの対処でも十分である場合も多いですが、クライアントが定常的に 200 rps 送信するのではなく、あるタイミングで一気に送信がスパイクして 200 rps になるが、ほとんどの時間帯では 0 〜 10 rps 程度であるようなシステム特性を持つワークロードも多いと思います。

スパイクに対応するようにシステムにバースト耐性を持たせておくことで、rps の Quota 設定は定常時に合わせて低く設定しておくことができるようになります。

上の例だと、10 rps を API の Quota 設定としておきながらも、200 rps まで バーストさせれるように設定できれば良いと思いませんか ?

そのようなシステム設計に対処するためのアルゴリズムの一つが token bucket algorithm になります。

考え方としては、また上記のスパイクするシステムを例にとって話すと、200 token が入る bucket (バケツのこと / S3 bucket とは何の関係もありません) を用意しておきます。API に 1 回のリクエストが来るたびに bucket から 1 token を払い出します (消費します)。リクエストのたびに token は消費していくので、bucket の中身はどんどん減っていきます。bucket の中身が枯渇した時点で throttle となります。

ここまで見てきた通り、AWS Lambda の同時実行数の上限緩和をしても、Lambda のバースト性の制約から一気に同時実行数上限までバーストするわけでは無いと言うことがわかりました。

同時実行数のバースト性を高めるには Provisioned Concurrency を利用する方法があります。 Provisioned Concurrency を使うと 5000 同時実行でも 10000 同時実行でも暖めたインスタンスの数だけバーストします。(詳しくは、Lambda の Provisioned Concurrency と 1 年付き合ってみて思ったこと。を参照ください)

ただ、よく考えると何も同時実行数のバースト性に頼らずに、リクエストハンドリングのバースト性を向上させれば良いと言うことに気がつきます。Lambda 関数の 1 インスタンスは同時にリクエストを受けれる数は 1 ですが、処理が終われば次のリクエストを受け付けることができます。先ほどの例ではあえて、900s の sleep を入れて実験したため、1 インスタンスが再利用され無いように組んでいました。

例えば、100ms の Lambda Handler 実行時間の関数だとすると 1 インスタンスで 1 秒間におよそ 10 tps 処理することができます。ですので、先ほどの例の 5000トランザクションであれば 500 同時実行程度で捌けることになります。(詳しくは、「AWS Lambdaの実行モデルについて考えてみる」を参照ください)

よって、

同時実行数のバースト性 << リクエストハンドリングのバースト性

を意識して、同時実行数によるスケールを考えるより、Lambda handler の処理時間チューニングを考えていく方がよりスケーラブルなシステムになります。