Google Cloud Next 2018 Extended App & Infra Dayに参加しました!
今日もgcpugにやってきました。いやーいい勉強会だった。
特にkumaさんの発表の、マイクロサービスの導入周りの話は、自戒含めてすごくためになった。
個人的なまとめは別途書くとして、いったん公開。
https://gcpug-tokyo.connpass.com/event/94417/
GCP Database の世代交代,Firestore :Datastore Mode & Datastore Automatic Upgrade to Firestore by sinmetal
Speaker
twitter.com
- firestoreがGoogleCloudFirestoreとして提供された(六角形アイコンも登場!)
- GCP Databaseの世代交代 Bigtable -> Datastore,Spanner -> FireStore
- FireStore内でSpanner,Bigtableの要素を活用しており、
SpannerはBigtableの要素を活用している。
つまりBigtableからSpannerに移行していくことを宣言しているようなもの - Google提供のDBの住み分けは下記に集約される
- まとめ
https://docs.google.com/presentation/d/11Jp1gt-n8LxVgrHBRy1ym6iJMsKww-mit1A00IS-oHk/edit#slide=id.g407b87bf62_0_10
Cloud Bigtable
- ハイパースケーリングな純粋KVS
- トランザクション機能は無し、APで要考慮
- ColossusというGoogle作成のファイルシステムを利用
- 行キーの辞書順(a~e:1,f~j:2,,,,,,,)で配置先のTablet(Storage nodeみたいな概念)を決定
- 一つのtabletが大きくなったり負荷が高くなると、Tabletが増えていく
- 行キーの偏りがあると、Tabletにhotspotができてしまう
- uuidなどを使って管理すると分散する
→ただし範囲指定して取得することができない
- uuidなどを使って管理すると分散する
- 分散について、キーの範囲が重要なわけではなく、挿入データの順番がバラバラであることが望ましい
★設計の考慮ポイント
500/50/5ルール:https://cloud.google.com/datastore/docs/best-practices#ramping_up_traffic - 行キーの戦略
- ユーザを元にデータを取りたい場合、キーにユーザIDを入れるとごそっとデータを取ることができる(キーを知らなくてもいい)
- Key Visualizerがリリースされ、どのようにキーが分散されているか確認できるようになった
Cloud Datastore
- BigTableと同じく分散型KVSのDB、アプリケーション開発向け
- プロパティに対するクエリに対応
- 10万回のreadで30円くらい
- Datastoreは3層構成
- DataStoreはBigtable上に、indexテーブルを一度作成したうえでrawテーブルからデータを取得している、つまりindexがないとクエリは実行されず、失敗となる(full scanはできない、みたいな)
- Indexは非同期で作成されるので注意,今登録したデータが一覧に出ないことがある
- Ancestor QueryというStrong Consistencyを持った機能が存在する
- Entity Groupは、Entity間で親子関係を組むことができる機能
Keyのprefixに親のKeyを入れることで、Bigtableインフラ上で連続して配置されるようになる - QueryがEventual Consistency
Spanner
「SpannerをMySQLと思って使うと即死」
- 分散型RDB,実際には分散KVSにRDBの機能を付属しているような感じ
- Bigtable,DataStoreの後継なので、それぞれの課題を解決している
- 構造的にはBigtableとほぼ同じ(Colossus,Split,Node)
PKの辞書順でデータの保存先splitを決める - PKにシーケンシャルIDを使うと死亡、やはりuuidなどを使う
- created_atなどをキーにしたい場合はソルト的なものを設定する必要がある
PK戦略をちゃんと考えないと、偏りが発生するので、Insert性能が極端に劣化したりする
Shardingをちゃんと考える - TimeStampベースのTransactionを利用している
- そのうちQuery Statsが提供されるようになる
Cloud FireStore
これまでFirebase側にあったが、ついにGCP側で提供されるようになった
- NativeMode
- Datastore model
- ダウンタイム無し、これまでの互換性をサポート
- FireStoreはSpannerをみんなで共用するようなイメージ
- Cloud DataStoreはすべてFireStore Datastore modelに移行することになる
- GoogleはこれからのデータレイヤはすべてSpannerに寄せていくイメージ(MegaStoreはそのうち消滅する)
Application and Infra by kuma
Speaker
- Nextに行った人も、他の報告会に行った人もそれほどいないから、報告会をするのが正しいw
- ハードウェアが水冷!
「俺のコードはここで動いている!」ができる - Real Service meshの写真w
- Youtubeにビデオがたくさんあがっている。
昨日の酔いどれGCPUGでおすすめされていたビデオはこちら。
IoT:https://t.co/Lkxme34Gs4
test:https://t.co/MQhezN1417 - サービスが拡大してくるとどんどんPodsが増える、メッシュも肥大化する
「マイクロサービスというやつがいいんじゃない?」と近年言われているし、誰かが言い出す- 本当にそうなの?Netflixを見てみた。
- めちゃめちゃ複雑、podsある方がシンプルなのでは、、
- 各サービスがどう繋がっていて、どう監視すればいいかとか難しい
- マイクロサービスでもモノリシックでも、サービスがでかくなると複雑になる
- 運用管理のワークフローを自動化していくことが大事
- Istio難しい、、。Kubenetesも難しい、、。開発スピードも速い、、。
- 最終的なROIを考えたら、Kubenetes+Istio使うよりも、マネージドフル活用+モノリシックの方がいいかも、、?
- CI/CD、例えば1メソッド1マイクロサービスにすると、デプロイスピードは上がるが、週に何百回デプロイせなあかんねん、、ってなる
- 何をモニタリングするの?ログを全部収集したり、監視をガッツリやっても、何をどう見ればいいの?
- CloudServicesPlatformがリリースされた話
- Googleが考える現状の最適解をパッケージ化して提供しているもの、と思う。
SRE的なアプローチで、昨今のサービスこうした方がいいんじゃない?を提案してくれている - ところでこれは誰向け?
- Googleが考える現状の最適解をパッケージ化して提供しているもの、と思う。
- 本当にそうなの?Netflixを見てみた。