大量アクセス対応オプション

Craft Functionsの 大量アクセス対応オプション の内容と、オプションの有無による性能の違いを紹介します。

Craft Functionsはリクエストの増減に応じて自動でスケールしますが、安定して処理できる量は有限です（処理能力についての考え方）。キャンペーン開始直後のアクセス集中や、大量データの一括処理などで処理遅延が気になる場合は、オプション導入の判断材料としてお役立てください。

大量アクセス対応オプションについて

ファンクションのインスタンス（実行環境）の構成を増強し、大量のリクエストが集中したときでも処理を滞りにくくするオプションです。

主に次の2点が強化されます。

強化される点	内容
すぐに処理を始められるインスタンスを常に確保する	リクエストがない間も一定数のインスタンスを起動したままにします。アクセスが急増した直後でも、インスタンスの起動（コールドスタート）を待たずに処理を始められます
同時に起動できるインスタンスの数を増やす	同時に起動できるインスタンスの上限を引き上げます。大量のリクエストが同時に届いたときに、より多くを並行して処理できます

作成したファンクションのインスタンス数は、次のように変わります。

項目	オプションなし	オプションあり
最小インスタンス数（常に起動しておくインスタンスの数）	0	10
最大インスタンス数（同時に起動できるインスタンスの上限）	100	1,000

あわせて、Craft Key-Value Store（KVS）やCraft Counterなどのモジュールを処理する内部のインスタンスも、CPU・メモリと常時起動のインスタンスの数が増強されます。

次のような場合は、大量アクセス対応オプションの導入をご検討ください。

なお、オプションを利用した場合でも、処理できる量には上限があります。Craft KVSなどのモジュールにも、それぞれ安定して処理できる量の目安があります（Key-Value Store の制約と注意点）。大規模な利用が見込まれる場合は、事前にご相談ください。

オプションの有無による性能の違いを確認するために実施した検証の結果を紹介します。

掲載数値はすべて検証環境で計測した参考値であり、実際の性能を保証するものではありません。効果の出方は、処理内容や負荷のかかり方によって異なります。

いずれのケースも、オプションありの方が短い時間で処理が完了しました。

検証したケース	オプションなし	オプションあり
アクセス急増時に、同時1,000件のリクエストを処理し終えるまでの時間	15.7秒	10.9秒
アクセス急増時の、1件あたりの応答時間（中央値）	10.1秒	7.5秒
ジョブフローから一括実行したときの、1実行あたりの処理時間（中央値）	6.2秒	2.5秒

以降で、それぞれの結果を詳しく説明します。

HTTPタイプのファンクションに、同時に1,000件のリクエストを送りました。キャンペーン開始直後に、Webサイトや接客から一斉にファンクションが呼び出されるケースを想定しています。

検証に使用したファンクション

リクエストを受け取るたびに、Craft KVSから約200バイトのデータを1件読み取り（kvs.get）、続けて同じキーへ1件書き込む（kvs.write）HTTPタイプのファンクションです。ユーザーごとの情報を読み書きしながら応答を返す、リアルタイムな処理を想定しています。

結果

オプションありの方が、1,000件すべての処理が完了するまでの時間、1件あたりの応答時間、ファンクション内の処理時間のいずれも短くなりました。

特にファンクション内の処理時間が短くなっているのは、KVSを処理する内部のインスタンスが増強され、大量の読み書きが同時に届いても滞りにくくなったためです。加えて、常に起動しているインスタンスがすぐに処理を始め、同時に起動できるインスタンスの上限も大きいため、急増したリクエストを素早くさばけます。

Datahub Jobflow Connectorから、イベント駆動タイプのファンクションを1,000回実行しました。Datahubのデータを一括でKVSへ同期するケースを想定しています。

検証に使用したファンクション

Datahubのクエリ結果1行ごとに起動するイベント駆動タイプのファンクションです。1回の実行で、Craft KVSへ約200バイトのデータを10件、1件ずつ順番に書き込みます（kvs.write）。1,000行分の実行で、合計10,000件を書き込みます。

結果

オプションありの方が、1実行あたりの処理時間、10,000件すべての書き込みが完了するまでの時間のいずれも短くなりました。