GoogleCloudPlatform
Firebase
Rocro
CloudFirestore
Loadroid

Firestoreに負荷試験(Loadroid)してみた+補足

こちらの記事は,Firebase.yebisu #1のLTに補足解説を加えたものになります.
発表スライド
当日お話できなかった,実施する際の注意などもありますので,ごさしゅーください.

tl;dr

高頻度のドキュメント作成(自動ID)で500/secに引っかからないことを確認できた
急激にアクセスが増えると503が出る場合がある(1秒で0→7万仮想ユーザなど)
Loadroidはいいぞ

背景

動機

Firebaseの新しいデータベース,Firestoreは安価,安定,既存より柔軟で非常に魅力的です(詳細は過去記事参照).

しかし,ドキュメント内の制限事項に気になる表記がありました.
ある条件1では,書き込み頻度に上限があるという内容です.
https://firebase.google.com/docs/firestore/quotas

Maximum write rate to a collection in which documents contain sequential values in an indexed field : 500 per second

とりあえず普通の書き込みでは問題ないことを確認するため,負荷試験をした,という経緯になります.
 

手法

負荷試験SaaS, Loadroid

やちまは優秀なハッカーなので怠惰を惜しみません.
簡単に負荷試験ができるサービス,Loadroidを利用します.
Screenshot 2017-11-21 at 17.18.33.png

ROCROというSONYグループで生まれたベンチャーのサービスになります.
裏側ではGCPが利用されているようです(Googleの記事活用事例スライド).
現在クローズドアルファです.

ちなみに,特段宣伝費などはもらっていません.
むしろください

費用確認

Firestoreの書き込み

https://firebase.google.com/pricing/
10M回書き込みしても18ドルです(非常に安いですね).
ネットワーク料金はアップロードのため無料になります.
保存費用は10GBでも2ドル弱なので誤差範囲です.

Loadroid使用料

公式サイトで非公開なので,一応非公開とさせていただきます.
お問い合わせください.

Loadroidの実際

準備

連携

GitHub/Bitbucketと連携します.
Screenshot 2017-11-21 at 17.50.47.png

ホスト所持確認

jsonをアップロードし,Loadroidに確認してもらいます.
Screenshot 2017-11-21 at 16.48.45 - Edited.png
ここで注意したいのは,Firestoreから(望む形での)jsonが返せない,ということです.
そのため,Firebase Hostingからリダイレクトするという形にします.
ただし普通のリダイレクトではPOSTがGETとなってしまいますので,307でのリダイレクトとします.

各種設定

どんな条件で実行するかをrocro.ymlに書き,連携したリポジトリにpushします.
詳細は,本サービスアクセス権限付与時にサンプルやドキュメントをいただけますので,ご参照ください.
容易と思われます(詳細は後日書く,かもしれません).
Screenshot 2017-11-21 at 16.40.34 - Edited.png
タスクバーがChromeOSであることをちゃっかりアピールしている

実行

ウェブUIより,ポチっとします.じゃじゃーん(英語で言うとTa-da!).

連携したリポジトリからrocro.ymlを読み取り,よしなに実行してくれます.
仮想ユーザ数の設定次第で時間がかかる場合もあります.

結果

想像通りですが,500/secの壁を超えることは可能でした.
Screenshot 2017-11-21 at 16.41.58 - Edited.png

しかし序盤に大量の503が発生する事態となっていました.
Screenshot 2017-11-21 at 16.43.26.png

Firestoreが急激なアクセス増加にびっくりしてしまい2,対応できなかったようです(1秒で0→7万仮想ユーザ3としていました).
10秒ほどかけて7万仮想ユーザに増加させることで,503はなくなりました.
Screenshot 2017-11-21 at 18.16.28.png

めでたしめでたし.

やちまの財布もこんな感じにオートスケールしてくれたらいいのに.

まとめ

高頻度のドキュメント作成(自動ID)で500/secに引っかからないことを確認できた
急激にアクセスが増えると503が出る場合がある(1秒で0→7万仮想ユーザなど)
Loadroidはいいぞ
ということでした.

やちまの次回作にご期待ください.
もうネタないけど

ついでにこちらもどうぞ(自分が以前書いたFirebase関連記事)

Firebase Dev Summit 2017 で発表された新機能ざっくり,これまでとの違いも
結局Firebaseのdbでは何に気をつけるべきか?少しマニアックな内容も含め,わかりやすく説明する(realtime database)
Firebase RTDB + GCP datastore = Firestoreについて第一印象

ついでにコミュニティも紹介

誕生したての,Firebaseの日本ユーザグループ
https://firebase.asia/

前からGCPのユーザグループにもたむろっていた(FirebaseはGoogleなので)
http://gcpug.jp/
 

 

 


  1. 正確には,「単一コレクションへのドキュメント書き込みにおいて,インデックスされたフィールドの値が連続的(インクリメントなど)であるとき」です(ちなみに単一フィールドへのインデックスは自動生成されます). 

  2. Firestoreの裏側ではGoogleによるDatastoreが動いています.こちらについての知見もあると,Firestoreの挙動も理解が深まります. 

  3. Loadroidにおける現在の上限です.