Spannerをrestでつかってみた
- 2. 自己紹介 @ExistMikan ・会津大学卒 (2012年) → IT系の猛者が集う大学 ・上記大学発ベンチャー企業に就職 → スマートフォンアプリ(Android/iOS)の開発に従事 ・現職場(吉積情報株式会社)に転職 (今年) → GCP中心の開発へ ・先週、パパエンジニアと化す 寝不足多幸感 VS 大分前から放置気味の アカウント(´・ω・`)
- 5. 提供状況 ・2017/02/14 ベータ発表 ・2017/05/16 GA ・2017/06/16 東京リージョン選択可 こりゃ使うしかな い！
- 7. Spanner Consoleで出来ること ・インスタンスの作成 /削除 ・データベースの作成 /削除 ・テーブルの作成/削除 ・インデックスの作成 /削除 ・クエリ 出来無さそうなこと。。。 ・データの追加/削除 → クエリ入力欄にINSERT文を入れても反応せず。。
- 12. RESTでアクセス！ なぜREST? → GAE + SE(Java)の環境で、DBをDataStoreからSpannerに切り替えたくなった → しかし、GAE + SEではgRPC系ライブラリが提供されていない → RESTでやるしかない GoではGAE + SEでもライブラリが 動作するらしい。。 Goのライブラリでは Socket APIを裏で使っているため、 OverQuotaに注意 つらい RESTでやる場合はURL Fetchの OverQuotaに注意。
- 13. RESTライブラリ for JAVA Cloud Spanner API Client Library https://developers.google.com/api-client-library/java/apis/spanner/v1?hl=ja RESTをラッパしたいつもの Googleライブラリは提供されている Eclipseでの導入方法 (プロジェクトを右クリック →Google→Google APIの追加) ※Google Plugin for Eclipseの場合。Cloud Tool for Eclipseのパターンは未検証。。。
- 17. インスタンスを作成する:REST API リファレンス REST APIのリファレンス GCP ProjectのIDが入る
- 24. データの書き込み:即席関数 Spannerが認識する型のオブジェクトに適宜変換。 INT64にはIntegerでは入れられないなどがあった。 (実質Longだから? しかしLongも文字列..)
- 31. セッション管理 読み書きするために必ず必要になる、Cloud Spanner データベース サービスとの通信チャネル。 Client Libraryには、Channnelという概念があり、そこでセッションプールのような管理がされているようだが RESTでは該当する概念無し。 生成のためのレイテンシがそれなりにかかる(100ms~1000msくらい？） → リクエストするたびに生成/削除をやるのはコストが高い 毎回やりたくな い！ そうだ、 キャッシュしよう
- 34. セッション管理:キャッシュ場所 ・簡単そうだが、インスタンス間で共有できない → インスタンス数の増加によっては、 セッション数の上限に達してしまうのでは？ → コワイ インスタンス セッション セッション セッション インスタンス セッション セッション セッション ・インスタンス毎にメモリに持つ ・Memcache/DataStoreに入れる インスタンス セッション セッション インスタンス セッション セッション ・全インスタンス間で共有できる ・状態をもたせるのはつらそう(atomicに更新が厳しい) ・max値を決めておけば、上限を超えることはない → 負荷が高まった時は、1つのセッションを同時に使うリクエストが増える → 読み込みは快速だが、書き込みが1つのセッションに集中するとロックがかかるの でその分遅くなる ・併用しているのは毎回DataStoreにreadしにいくとread entitiy分の料金が発生する ため。 管理しやすそう
- 35. セッション管理:フローチャート ランダムなキーでセッションを取って、なければ作り、あればそのまま利用する形で Try (簡単化のため毎回セッション有効判定を実施 ) 多量のリクエストを捌けた (・∇・）
- 37. ベストプラクティスとは? 主キーの選択 → 値が単調に増加する列を最初のキー部分に選択すると、キー空間の最後にすべての挿入が実行されるため、 誤ってホットスポットが作成される可能性がある Cloud Spanner は分散データベースなので、データベースが 大きくなると、Cloud Spanner は「スプリット」と呼ばれる塊に データを分割します。各スプリットは、相互に独立して移動で き、異なるサーバーに割り当てることができます。サーバーは異 なる物理的なロケーションに存在することもあります。 連続しているデータは別のスプリットに分割されにくい 挿入が同じスプリット =同じDBになるので、負荷が集中する
- 40. ・タイムスタンプをキーにしたテーブルと、UUIDをキーにしたテーブルを用意し、負荷を掛けて比較 ・ノード数1の場合と、ノード数3の場合で検証する ・GCEから秒間リクエスト500になるように、GAEにデプロイしたAPIを叩く → 30分継続実行 ・APIでは、リクエストを受けたら新しい行をテーブルに追加するREST APIを実行する ・30分の実施後、DBは一回DB毎削除する→世代管理されているので中身をカラにするだけではダメ ホットスポット検証 ちゃんと分散されるほう ベストプラクティスに沿わないヤツ
- 43. 検証まとめ ・高い処理効率を維持するには、ベストプラクティス準拠 & ノード数を3以上にするのが良い → キー選択以外にも多くのベストプラクティスがある → 想定リクエスト数で、 CPU使用率が75%を下回っているなら、ノード数は 1でも問題にはならない
- 44. 超実践 Cloud Spanner 設計講座 https://www.slideshare.net/HammoudiSamir/cloud-spanner-78081604 Spannerユーザ必読。ノードやスプリットの関係についても言及されています。 普通のエンジニアが【Cloud Spanner】使ってみた https://www.slideshare.net/ssuserc49633/20170822-cloud-spanner こちらも参考情報盛りだくさんです。 参考資料