Slackボット作成にあたっては、Event APIや、Slash Command、Interactive Messageなどの
APIを使用することになりますが、いずれも3秒でタイムアウトする仕様であるため、パフォーマンスを
考えることはかなり重要になってきます。
今回は、処理を行うサーバーのロケーションについて、確認してみました。
経緯
今まで、Google App Scriptで運用してきたSlackボットを、Cloud Functionsに移植しましたが、
日本人が使うツールなんだし東京リージョンやろと、深く考えずにデプロイしたことによって、
頻発するタイムアウトに悩まされることになりました。
言語のローカライゼーションや、データレジデンシー機能の実装などで、何となく勘違いしていましたが、
Slackのサービス自体は米国で提供されているんですね。
(すぐに米国内のリージョンにデプロイし直しましたが、データの移行が面倒くさかったです。)
検証
概要
Cloud Functionsに限った話ではありませんが、Slackボットへの応答時間を向上するにあたっては、
以下のような項目があげられると思います。
| # | 項目 | 内容 | 目安 |
|---|---|---|---|
| 1 | ロケーション | 通信時間に影響するため、なるべくSlackに近い地域にデプロイする。 | 数十ms〜数百ms |
| 2 | コールドスタート対応 | FaaSは、必要に応じてインスタンスを立ち上げるので、デプロイ直後や一定時間経過後などに、インスタンス起動やライブラリの読み込み等のオーバーヘッドが発生する | 数百ms |
| 3 | 関数の実行時間 | 関数自体の実行時間(DB処理含む) | なるべく削る |
| 4 | 処理の非同期化 | SlackのAPIは、とりあえずHTTP200を返してあげれば満足するので、本処理は非同期で行うように実装してあげる。 | - |
サーバ環境
ボットの処理を行うサーバは以下のとおりとし、東京とバージニアの2つのリージョンで比較してみます。
- 使用するGCPのサービス
- Cloud Functions: Python3.7
- デプロイするリージョン
- asia-northeast1 (東京)
- us-east4 (北バージニア)
クライアント環境
Slack APIを模してリクエストを送信するクライアントを以下のとおり準備します。
- 使用するGCPのサービス
- Google Compute Engine: Debian9
- デプロイするリージョン
- us-central1 (アイオワ)
測定の仕方
結論を出すにはちょっと乱暴ですが、一旦以下の通りとしました。
日にちや曜日、時間帯といったことにも着目したいところですが、とりあえず。
- 各リージョンごとに100個リクエストを送信する。
- クライアント側で、かかった時間を計測する。
- Functionsの処理時間を 2 から減算する。
結果
以下のような結果となりました。
設計値としては、
東京リージョンにデプロイする場合は約800ms、
バージニアリージョンにデプロイする場合は約200ms、
といったところを見込んでおく必要がありそうです。
| リージョン | 99パーセンタイル | 90パーセンタイル | 50パーセンタイル | 平均値 |
|---|---|---|---|---|
| 東京 | 799ms | 783ms | 751ms | 543ms |
| バージニア | 188ms | 178ms | 55ms | 79ms |
東京
バージニア
結論
現時点では、Slackボットを実装するロケーションは、米国内が無難な選択と思います。
しかしながら、Slackのサービス自体が地域ごとに提供されるようなことになった場合を想定し、
なるべく簡単にボットやデータを移行できるように実装してあげるのが肝要と思われます。