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

こちらの記事は，[Firebase.yebisu #1](https://connpass.com/event/69238/)のLTに補足解説を加えたものになります．
[発表スライド](https://speakerdeck.com/yatima/firebase-dot-yebisu-number-1)
当日お話できなかった，実施する際の注意などもありますので，ごさしゅーください．

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

#背景
##動機
Firebaseの新しいデータベース，Firestoreは安価，安定，既存より柔軟で非常に魅力的です（詳細は[過去記事](https://qiita.com/Yatima/items/54ea22d0cea1acc6cbcb)参照）．

しかし，ドキュメント内の制限事項に気になる表記がありました．
ある条件[^1]では，書き込み頻度に上限があるという内容です．
[^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](https://rocro.com/loadroid)を利用します．
![Screenshot 2017-11-21 at 17.18.33.png](https://qiita-image-store.s3.amazonaws.com/0/17440/13ea65ee-92e5-03b0-759a-48e6bea11330.png)

ROCROというSONYグループで生まれたベンチャーのサービスになります．
裏側ではGCPが利用されているようです（[Googleの記事](https://developers-jp.googleblog.com/2017/10/gcp-use-case-rocro.html)，[活用事例スライド](https://speakerdeck.com/yoshiyukimineo/rocroniokerugcphuo-yong-shi-li)）．
現在クローズドアルファです．

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

##費用確認

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

###Loadroid使用料
公式サイトで非公開なので，一応非公開とさせていただきます．
お問い合わせください．

##Loadroidの実際

###準備
####連携
GitHub/Bitbucketと連携します．
![Screenshot 2017-11-21 at 17.50.47.png](https://qiita-image-store.s3.amazonaws.com/0/17440/98ceb764-e5a8-8be7-1890-360e8d1bf4e0.png)

####ホスト所持確認
jsonをアップロードし，Loadroidに確認してもらいます．
![Screenshot 2017-11-21 at 16.48.45 - Edited.png](https://qiita-image-store.s3.amazonaws.com/0/17440/a97a52a4-e791-792b-e061-25aa4acc1bb3.png)
ここで注意したいのは，Firestoreから（望む形での）**jsonが返せない**，ということです．
そのため，Firebase Hostingからリダイレクトするという形にします．
ただし普通のリダイレクトではPOSTがGETとなってしまいますので，**307でのリダイレクト**とします．


####各種設定
どんな条件で実行するかを`rocro.yml`に書き，連携したリポジトリにpushします．
詳細は，本サービスアクセス権限付与時にサンプルやドキュメントをいただけますので，ご参照ください．
容易と思われます（詳細は後日書く，かもしれません）．
![Screenshot 2017-11-21 at 16.40.34 - Edited.png](https://qiita-image-store.s3.amazonaws.com/0/17440/57443588-008a-3652-eb03-2663085ae9cf.png)
*タスクバーがChromeOSであることをちゃっかりアピールしている*

###実行
ウェブUIより，ポチっとします．じゃじゃーん（英語で言うとTa-da!）．

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


#結果
想像通りですが，500/secの壁を超えることは可能でした．
![Screenshot 2017-11-21 at 16.41.58 - Edited.png](https://qiita-image-store.s3.amazonaws.com/0/17440/37422065-a3d7-08ee-0f9f-d71b80176488.png)

しかし序盤に大量の503が発生する事態となっていました．
![Screenshot 2017-11-21 at 16.43.26.png](https://qiita-image-store.s3.amazonaws.com/0/17440/fa23fc9d-6b61-5bdb-de40-7c65b5c98f96.png)

Firestoreが急激なアクセス増加にびっくりしてしまい[^2]，対応できなかったようです（1秒で0→7万仮想ユーザ[^3]としていました）．
[^2]: Firestoreの裏側ではGoogleによる[Datastore](https://cloud.google.com/datastore/?hl=ja)が動いています．こちらについての知見もあると，Firestoreの挙動も理解が深まります．
[^3]: Loadroidにおける現在の上限です．
10秒ほどかけて7万仮想ユーザに増加させることで，503はなくなりました．
![Screenshot 2017-11-21 at 18.16.28.png](https://qiita-image-store.s3.amazonaws.com/0/17440/88121f30-3198-f90c-47da-58a6a92752db.png)

めでたしめでたし．

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

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

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

#ついでにこちらもどうぞ（自分が以前書いたFirebase関連記事）
[Firebase Dev Summit 2017 で発表された新機能ざっくり，これまでとの違いも](https://qiita.com/Yatima/items/1b2af3094874c4a6bb77)
[結局Firebaseのdbでは何に気をつけるべきか？少しマニアックな内容も含め，わかりやすく説明する(realtime database)](https://qiita.com/Yatima/items/8a54acc8fda3e5fce741)
[Firebase RTDB + GCP datastore = Firestoreについて第一印象](https://qiita.com/Yatima/items/54ea22d0cea1acc6cbcb)

#ついでにコミュニティも紹介
誕生したての，Firebaseの日本ユーザグループ
https://firebase.asia/

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