LoginSignup
2
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

@gatchan0807

Cloud Spannerのことをﾁｮｯﾄ理解できる記事（GKE & Cloud Spanner入門勉強会 参加レポート）

Last updated at Posted at 2020-01-22

ご挨拶

はじめましての人ははじめまして。がっちゃんです
今回は2年ぶりぐらいにQiitaに記事を投稿します

記事の内容としては、昨日参加したGoogle主催の勉強会のレポートで、GKE（k8s）とCloud Spannerの仕組みについての話を自分なりにまとめたものです

もし間違いや誤字脱字などございましたらご連絡いただけますと幸いです！🙏

勉強会情報

  • 開催日：2020/01/21
  • 《 プログラム 》

　16:30 受付開始
　17:00 開場
　17:00 – 17:55 セッション 1 : GKE 入門
　18:00 – 18:55 セッション 2 : Cloud Spanner の技術概要
　19:00 – 19:20 セッション 3 : お客様事例紹介
　19:25 – 20:00 個別相談会 (希望者のみ)

アジェンダ

  • GKE 入門
  • Cloud Spanner の技術概要
  • お客様事例紹介

GKE 入門

スライド

https://www.slideshare.net/GoogleCloudPlatformJP/gke-spanner-gke

内容

コンテナとKubernetesとは

  • コンテナの歴史

    • Googleでは10年以上、検索やGmailなどを無料でユーザーに届けるために、サーバーリソースを限界まで効率的に使うことができるようにコンテナを使ってきた。
    • 今ではGoogle内では毎週40億以上のコンテナが立ち上がっている
    • コンテナは運用を楽にする。運用チームの人数の増加の10倍の速度でアプリケーションの規模を大きくしてきた。

  • コンテナとは？

    • アプリケーショコードとインフラを疎結合にするシステム
    • インフラを抽象化し、アプリケーションから呼び出す部分をラップしているのがContainer Engine
    • VMとは違い、Container EngineがOSとのつなぎこみを行い、GuestOSの部分を立ち上げない分、軽量でポータブルで効率的になる

  • 1つのアプリケーションに必要なコンテナを複数まとめてNodeと呼ぶ

    • 冗長化のために必要な台数をまとめてClusterと呼ぶ
      • 複数のNodeにどうやってコンテナをデプロイする？
      • コンテナが何らかの原因で落ちた時に検知や復旧はどうする？
      • 一つ一つリリースしていくの？大変じゃない？
      • コンテナ間の通信はどうするの？
      • => それらの課題に対応するために Kubernetes を使う

  • Kubernetesの特徴

Kubernetesのアーキテクチャ

  • MasterとNode
    • Master側（Kubernetes全体を管理する役割）
      • API Server / Scheduler / Controller / etcd を内包する、Kubernetesの全体管理を担当する
        • etcd => クラスタの全データを格納するデータストア
      • これをどう冗長化するか？が難しい。なのでGKEなどを使うのをおすすめする理由
    • Node側（アプリケーションが動く場所）
      • kubelet / kube-proxy を内包する、Kubernetesのアプリケーションに近い部分を担当する
        • kubelet : Masterとのやり取りを担当するエージェント
        • kube-proxy : IPアドレスのやり取りや、外部Podへのアクセス時のエラー処理などを担当する

Kubernetesにおける基本リソース（一部）

  • Pod
    • 1つ以上のコンテナをまとめた、Kubernetes上で管理する最小の単位
  • Deployment
    • Podに対して、新しいアプリケーションのデプロイ・起動しておくPod数の適用などを管轄するためのリソース
    • あるべき状態を実現するためのコントロールを担保する
  • Service
    • Podをクラスタの内部/外部に公開するためのリソース
      • アプリケーションのエンドポイントを提供する
        • クラスタ内のIPを提供する
        • L4でロードバランスする場合もここで設定をする
  • Ingress
    • L7でロードバランスするためのリソース
    • アプリケーションのエンドポイントを提供する

Google Kubernetes Engine vs Kubernetes

【GKEを使うメリット】

  • GCP上の各サービスとインテグレーション
    • Network service（IngressでのLBやNetwork Routeなどの利用）
    • CI / CD（Cloud build）
    • Logging / Monitoring（StackDriver）
  • Master部分はGoogleのSREチームによって管理
    • Masterのバージョン更新をGoogleが管理
      • 今後MasterとNodeのKubernetesのバージョン差異もNode側を自動アップデートすることで対応できるようになる予定
    • etcdの自動バックアップ
  • Kubernetesの40%をコントリビュートをしているGKEチームなので、Kubernetesが使いやすい方法（UIや管理方法）を提供しやすい
  • Container-Optimized OSを使える

質疑応答

Cloud Spanner の技術概要

スライド

内容

Spannerって何？

  • NewSQL（Spanner） = RDB（リレーショナル・データベース構造） + NoSQL（水平方向のスケーラビリティ）
    • どちらの要素もいいとこ取りをしたアーキテクチャ
      • YouTubeを扱うのに、MySQLだけでは辛くなったので、Spannerを開発した。
    • メリットのOverView https://cloud.google.com/spanner/?hl=ja#cloud-spanner-
      • Google Adwords / Google Playで 7年以上の運用実績

高可用性とその理由

  • シングルリージョンであっても、リージョンの中のZoneは複数のZoneに対してレプリケーションされているので、通常のSQL Serverよりも可用性は高い。

    • SLAは99.99%

  • マルチリージョン

    • 基本的に3つ以上のリージョンで利用する。
    • Read/Writeができるリージョンが2つ（うち1つがリーダーリージョン、もう1つが役職なしのRead/Writeリージョン）と、ウィットネスリージョン1つの構成で作成する
    • SLAは99.9999%

  • 1つの大陸構成 / 3つの大陸構成を選択できる

  • 3つの大陸構成の場合

    • 上記役割を持つ3つのリージョンの他に読み取り専用リージョンが各大陸に作成される

  • 時刻同期（TrueTime API）が使われており、リージョン間でもTimeStampが信頼できるようになるため、ソートの信頼性を持つ。（それによって、下記のSplitが実現できる => 高いスケーラビリティを実現できる）

書き込み時のルール

RDBのシステムとスケーラビリティを実現する Split の仕組み

  • Spannerを実現する、Splitの仕組み
    • Splitはデータを格納される単位で、Splitを複数のNode（インスタンス）に分割して置くことで、高いスケーラビリティを実現している
  • 基本的に、テーブル内は主キーでソートされている。※Slide 16枚目の図が理解しやすい
    • テーブルはキー範囲で分割される
    • Splitは負荷とサイズに応じて再度分割される
      • 負荷とサイズがしきい値を超えると、再度分割され、レプリケートされる
      • 反対にGCのような形でオプティマイズが走り、負荷とサイズが小さければ結合もされる
  • TIPS: SpannerのプライマリキーはUUIDv4を使おう
    • よくある形でTimeStampやAutoIncrementの連番にすると、すべてのINSERTが一番最後の部分に追記されるので、（Splitの仕組みで考えると）特定のサーバーに対して負荷を与え続けることになってしまう
    • => パフォーマンスが1/5（Node数）しか出せなくなってしまう…

Spanner独特のインターリーブ

  • Spannerには外部キー参照はないが、代わりにインターリーブを使うことで同様のことを実現できる
    • インターリーブ（親子関係）
      • データベースの中に複数のテーブルを定義できる（最大7階層まで）
      • データを物理的にコロケーションできる
        • インターリーブをすることによって、同じNodeに置くように保証することができる
  • TIPS: インデックスをインターリーブすることもできる
    • Spannerではインデックス自体もテーブル
    • => インデックスもインターリーブしておかないと、別のNodeから取得してしまう可能性があり、パフォーマンスを下げてしまうので注意⚠

Spannerのトランザクションについて

  • トランザクションの種類
    • 読み書きトランザクション
      • 読み取り結果に対して書き込みを行う場合に使うトランザクション。
    • 読み取り専用トランザクション
      • 複数のテーブルなどから一貫してデータを取得する時に使うトランザクション
      • ロックは発生しない
  • トランザクションの処理とロックの種類
    • データ読み取りをせずに書き込むトランザクション（ブラインドインサート）
      - ライター共有的ロックと呼ばれる共有的ロックを用いる
      - コミットタイムスタンプの順に順序が決定される
    • 読み書きトランザクション
      • データを読み取るタイミングでは共有的ロック、書き込むタイミングで排他的ロックを取得して書き込みを行う
    • Spannerの特殊な読み取りトランザクション
      • Strong Read
        • 最新のデータを読み取る（一般的なDBはこうで、デフォルト設定もこれ）
      • Steal Read
        • タイムスタンプ指定をすることで、過去のデータを読み取れる読み取りの方法
          • Strong Readの場合、最新版のデータを取得しに行くためにリージョン横断が起きるので、レイテンシが発生するが、Steal Readではローカルリージョンのデータを取得するのでレイテンシを防ぐことができる
          • ただし、古いデータでも許容できる内容でないと問題が起きる可能性はある
        • トランザクションのロックはかからない
  • トランザクション実行時には
  • TIPS: トランザクションは、レコードではなくセルだけをロックする

Spannerにおけるデータ書き込みの方法

  • DML
  • Mutation API
    • insert_or_updateなどのMutetionにしか無いAPIがある
    • 若干こちらのほうがパフォーマンスが良い（ローカルでバッファリングを行っているため）
  • 注意事項：同じトランザクションに対してDML / Mutation APIをどちらも使うのはやめたほうが良い。処理の実行タイミングが異なっていて、DMLが先に実行されるため。

その他デモ内でのTIPS

  • 負荷状況やSlow Queryはコンソールから確認できる
    • Monitoring: QPSやCPU使用率
    • Query Stats: 遅いクエリーの情報を確認できる
  • Spanner自体、空の状態から数件追加された段階ではSplitを使用していない
    • => Warmupしないで使うと、すべてのノードを使われずパフォーマンスが上がっていないのでスピードが落ちてしまう
    • => ダミーデータを入れて、そのデータを消すことで、Warmupを実施できる。Splitはすぐに消されないので。
  • インスタンスのNode数の上げ下げはダウンタイムなしで実行できる

質疑応答

  • splitは結合される？
    • オプティマイズする仕組みがあるので、それによってマージはされる
  • 金額が高いが、どれぐらいの規模から利用すべき？
    • TCOを考えないといけない（落ちたときの機会損失や負荷への対応コスト）
    • 1 Node（月7万円）。見えないコストも含めて計算した時にこれよりも小さいのであればSpannerじゃなくても良いと思う
    • 1 Nodeでも可用性が非常に高いので、SpannerのほうがRDB（Cloud SQL）を使うよりも安心なことも往々にしてある

お客様事例紹介

  • コロプラ
    • DQウォークでの構成
      • ユーザー系DBはすべてCloud Spanner
      • 10,000+ Pods on GKE
  • フルクル（初めてのCloud Spanner国内導入事例）
  • メルペイ（金融系事例）
2
3
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
2
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?