国内Cloud spanner初事例！「迎車料金無し！新感覚タクシーアフ?リ「フルクル」」
- 2. 自己紹介 @ExistMikan 経歴 ?会津大学卒(ヅ大) ?ヅ大発某ベンチャー企業に就職 → モバイルアプリメイン ?現職場にJOIN → GCP中心の開発へ 伊藤勇斗 (Hayato Ito) 吉積情報株式会社所属 ?フルクルのサーバ/モバイル担当
- 5. フルクルとは
- 6. フルクルとは
- 7. システム構成 API系 App Engine Batch系 App Engine wordpress App Engine 管理系 App Engine BigQueryLogging Cloud SQL Cloud Spanner Cloud DatastoreiOS Android Clients manager Task Queues Memcache Monitoring
- 8. 想定リクエスト数 Android/iOS 約3300台 : 各車約10秒に1回継続的にリクエスト ?人 : 起動中に約5秒に1回リクエスト ほぼタクシーのリクエストが占める形 毎秒300リクエスト来る前提で構える
- 9. モニタリング ?SpannerのCPU使用率 → ノード数の基準になるので超大事 ?GAEインスタンス数 → おかしなスパイクが発生していないかとか ?APIのレイテンシ → 健康なシステムかどうか ?APIのエラー →予想しない出来事が起きているか 他にも色々なグラフをダッシュボードで管理 何かがおかしいとき、同じ時間軸の他の指標を 見れることで色々推測できてGOOD
- 12. Spanner利用の経緯 メイン機能 ?タクシーの近くにいるユーザ、およびユーザの近くにいるタクシーを割り出す 当初想定 Cloud Datastore 不等号フィルタが複数の プロパティに適用できない制限 できない！ 35.0000 < lat < 36.000 && 138.0000 < lon < 139.000 && 2017/12/13 00:00:00 < modificationDate < 2017/12/13 00:01:00 35.0000 < lat < 36.000 && 138.0000 < lon < 139.0000 時間でも絞りたいけど、もっとできない！
- 14. Spanner利用の経緯 このままだとどうなるか？ データストアから大量に取ってきてJava側でどうにかする → どうにかはなる → データ量多い → 共有memcacheぶっ壊れる (でも使わないとDataStore Read料金がスゴい) → 処理量多い=APIのレイテンシ増加 → GAEインスタンス数の増加 → 料金が(ry 読み込みはいいとしても書き込みの料金も結構行く
- 15. Spanner利用の経緯 2017/02/14 ベータ発表 2017/05/16 GA 2017/06/16 東京リージョン選択可 ! 僥倖???！いざ検証へ CloudSQLについてはコネクション速度の懸念など あったためspanner優先とした。。
- 16. Spanner検証 App Engine 今回のAppEngineは Standard Environment Java 7 (!) (goでは動作した様子) java 8, Flex, GCEにする？ → 時間的余裕無し → RESTで検証
- 17. Spanner検証:REST Cloud Spanner API Client Library https://developers.google.com/api-client-library/java/apis/spanner/v1?hl=ja RESTをラッパしたいつものGoogleライブラリは提供されている
- 21. インスタンスを作成する:REST APIリファレンス REST APIのリファレンス GCP ProjectのID が入る
- 27. データの書き込み:即席関数 Spannerが認識する型のオブジェクトに適宜変換。 INT64にはIntegerでは入れられないなどがあった。 (実質Longだから? しかしLongも文字列..)
- 34. セッション管理 読み書きするために必ず必要になる、Cloud Spanner データベース サービスとの通信チャネル。 Client Libraryには、Channnelという概念があり、そこでセッションプールのような管理がされているようだが RESTでは該当する概念無し。 生成のためのレイテンシがそれなりにかかる(100ms~1000msくらい？） → リクエストするたびに生成/削除をやるのはコストが高い 毎回やりたくな い！ そうだ、 キャッシュしよう
- 36. セッション管理:キャッシュ場所 ?簡単そうだが、インスタンス間で共有できない → インスタンス数の増加によっては、 セッション数の上限に達してしまうのでは？ → コワイ インスタンス セッション セッション セッション インスタンス セッション セッション セッション ?インスタンス毎にメモリに持つ ?Memcache/DataStoreに入れる インスタンス セッション セッション インスタンス セッション セッション ?全インスタンス間で共有できる ?状態をもたせるのはつらそう(atomicに更新が厳しい) ?max値を決めておけば、上限を超えることはない → 負荷が高まった時は、1つのセッションを同時に使うリクエストが増える → 読み込みは快速だが、書き込みが1つのセッションに集中するとロックがかかるの でその分遅くなる ?併用しているのは毎回DataStoreにreadしにいくとread entitiy分の料金が発生する ため。 管理しやすそう
- 37. セッション管理:フローチャート ランダムなキーでセッションを取って、なければ作り、あればそのまま利用する形で Try (簡単化のため毎回セッション有効判定を実施 ) 多量のリクエストを素早く捌けた
- 39. ベストプラクティスとは? 主キーの選択 → 値が単調に増加する列を最初のキー部分に選択すると、キー空間の最後にすべての挿入が実行されるため、 誤ってホットスポットが作成される可能性がある Cloud Spanner は分散データベースなので、データベースが 大きくなると、Cloud Spanner は「スプリット」と呼ばれる塊に データを分割します。各スプリットは、相互に独立して移動で き、異なるサーバーに割り当てることができます。サーバーは異 なる物理的なロケーションに存在することもあります。 連続しているデータは別のスプリットに分割されにくい 挿入が同じスプリット =同じDBになるので、負荷が集中する
- 41. ホットスポットの検証 ?タイムスタンプをキーにしたテーブルと、UUIDをキーにしたテーブルを用意し、負荷を掛けて比較 ?ノード数1の場合と、ノード数3の場合で検証する ?GCEから秒間リクエスト500になるように、GAEにデプロイしたAPIを叩く → 30分継続実行 ?APIでは、リクエストを受けたら新しい行をテーブルに追加するREST APIを実行する ?30分の実施後、DBは一回DB毎削除する→世代管理されているので中身をカラにするだけではダメ ちゃんと分散されるほう ベストプラクティスに沿わないヤツ
- 44. 検証まとめ ?高い処理効率を維持するには、ベストプラクティス準拠 & ノード数を3以上にするのが良い → キー選択以外にも多くのベストプラクティスがある → 想定リクエスト数で、 CPU使用率が75%を下回っているなら、ノード数は 1でも問題にはならない
- 45. Quotaについて REST Libraryを使用した場合(UrlFetch版) 1日のリミット : 864,657,084 Client Libraryを使用した場合(gRPC版) 1日のリミット : 3,456,000 フルクルの1日のcall数 120,960,000
- 46. 実際のリクエスト数とCPU使用率(1ヶ月) 容量/リクエスト数 変わらずで上昇。 これは無駄な不要 過去データを削除し たら落ち着いた 基本的にデータは消去しないが、 Storageは上げ下げする
- 52. 負荷試験について:苦しいところ はじめに要件があって、それを満たせるかどうかという観点では検証できたが、 最大のパフォーマンスを引き出せているかの確認が難しい???！ コンソールか何かで確認したいこと ?各ノードのCPU使用率 → 高いやつがあればHotSpotが発生しているとわかる ?Storageの内訳 → どれくらい過去のものまで保持しているのかとか 料金 → お高い。。負荷試験はしょうがないとしてもtry&errorなこ とやってるとき苦しかった
- 54. そういえばシステムの料金は？ ?Cloud Spanner 3台分なのでベースとしてはそれなりにかかる → ざっくり30万近く ?DataStoreと比べると、多少DataStoreの方が安くなるがCloud Spannerの レイテンシが無さ過ぎたので、その分のGAEインスタンス代が浮いている形！ ※1リクエストで3回くらいspannerをコールしてこれ。 パフォーマンスも向上しているので フルクルには合っていると感じる
- 55. 今後について ?Java1.8 (もしくは別言語)へのリプレース！ → そろそろか？と思っていたところに昨日、java1.7 deprecate扱い+2019年1月で終了 のお達しメールが届く！ ?gRPC版にして再度同検証を行い、同じようなCPU使用率になるのか とかを見てみたい → 今は都合でREST APIで扱っているが、REST APIに優位性があるのなら使い続けるのもあり ? ?効率の良いテーブル構造/Indexになっているか等細かいチューニング
- 56. 超実践 Cloud Spanner 設計講座 /HammoudiSamir/cloud-spanner-78081604 Spannerユーザ必読。ノードやスプリットの関係についても言及されています。 普通のエンジニアが【Cloud Spanner】使ってみた /ssuserc49633/20170822-cloud-spanner こちらも参考情報盛りだくさんです。 Cloud Spanner参考資料