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

Slide : https://docs.google.com/presentation/d/11Jp1gt-n8LxVgrHBRy1ym6iJMsKww-mit1A00IS-oHk/edit#slide=id.g4049ca1ecb_0_1

Cloud Bigtable

  • ハイパースケーリングな純粋KVS
  • トランザクション機能は無し、APで要考慮
  • ColossusというGoogle作成のファイルシステムを利用
  • 行キーの辞書順(a~e:1,f~j:2,,,,,,,)で配置先のTablet(Storage nodeみたいな概念)を決定
  • 一つのtabletが大きくなったり負荷が高くなると、Tabletが増えていく
  • 行キーの偏りがあると、Tabletにhotspotができてしまう
    • 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層構成
    • 一番下はBigTable、みんなで大きなBigTableを使いましょうという考え方
    • 二番目はMegaStore、ZoneベースのBigTableをうまく使うためのレイヤー
    • 一番上はZoneStore、クエリを処理するためのレイヤー
  • 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
    • MBaaSのためのDB,Android-iOSから直接読み書き可能
  • Datastore model
    • ダウンタイム無し、これまでの互換性をサポート
  • FireStoreはSpannerをみんなで共用するようなイメージ
  • Cloud DataStoreはすべてFireStore Datastore modelに移行することになる
  • GoogleはこれからのデータレイヤはすべてSpannerに寄せていくイメージ(MegaStoreはそのうち消滅する)

Application and Infra by kuma

Speaker

twitter.com

  • 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的なアプローチで、昨今のサービスこうした方がいいんじゃない?を提案してくれている
        • マネージドなIstio
        • Googleがベストプラクティスとして提供しているSREという考え方を元に、システムをモニタリングする機能をStackDriverとして提供している!
        • GKE On-Prem
      • ところでこれは誰向け?
        • KubenetesやIstio,マイクロサービスを構成する要素は技術先行で導入すべきでない
        • googleは"Culture","Infrastructure","Tools","Platform"が必要と言っている
        • アーキテクチャの複雑性を紐解き、
           不便なシステムを自動化し、
           許容できる範囲を明確に定義し、
           事業・システム・ヒトに整合性をつけて全体を無理なく、
           柔軟性を持てるシステムをしたいヒト向け」