O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

[db analytics showcase Sapporo 2018] B13 Cloud Spanner の裏側〜解析からベストプラクティスへ〜

235 visualizações

Publicada em

[db analytics showcase Sapporo 2018] B13 Cloud Spanner の裏側〜解析からベストプラクティスへ〜
グーグル・クラウド・ジャパン合同会社 ハムディ サミール 氏

Publicada em: Tecnologia
  • Seja o primeiro a comentar

[db analytics showcase Sapporo 2018] B13 Cloud Spanner の裏側〜解析からベストプラクティスへ〜

  1. 1. Cloud Spanner の裏側 〜解析からベストプラクティスへ〜 Samir Hammoudi (Twitter: @ksimir) Gaming Technical Specialist, Google Cloud
  2. 2. Confidential & Proprietary Cloud Spanner の概要 Cloud Spanner のアーキテクチャ解説 Cloud Spanner ベストプラクティス Agenda
  3. 3. Cloud Spanner の概要
  4. 4. Confidential & Proprietary Cloud Spanner Cloud Spanner は、エンタープライズ クラスで唯一の、 グローバルに分散され、強整合性を備えたデータベース サービスです。リレーショナル データベースの構造と 非リレーショナル データベースの水平スケーラビリティを 兼ね備え、クラウドに特化した設計となっています。 Great apps run on great databases.
  5. 5. Confidential & Proprietary The best of RDBMS + NoSQL
  6. 6. Confidential & Proprietary Cloud Storage Cloud Memorystore (beta) BigQuery RelationalNon-relational Object Warehouse Object storage, data lake Managed Redis Cloud Datastore/ Cloud Firestore (beta) Serverless scalable document store Cloud Bigtable Low latency, scalable wide column store Cloud SQL Managed MySQL & PostgreSQL Cloud Spanner Scalable mission-critical RDBMS Enterprise data warehouse In-memory フルマネージドデータサービスのポートフォリオ
  7. 7. Confidential & Proprietary Relational semantics Schemas, ACID transactions (across rows), SQL query + Horizontal-scale 99.999% SLA, Fully managed, and Easily scalable
  8. 8. Confidential & Proprietary Google のマネージド・スケーラブル・リレーショナルデータベース・サービス 完全マネージドのグローバルスケールで PB スケールの DB サービス1 2 3 4 ゾーン間・リージョン間の自動 synchronous レプリケーション スキーマ、ACID トランザクション、SQL Google内部では、既に5年以上の運用経験 (AdWords, Google Play…) Cloud Spanner とは?
  9. 9. Confidential & Proprietary ● 1ノードごとに3つのレプリカ JP region Cloud Spanner Instance JP zone a JP zone b JP zone c 1 2 3 RW RW RW 展開モデルーシングルリージョン
  10. 10. Confidential & Proprietary 展開モデルーマルチリージョン ● 1ノードごとに9つのレプリカ
  11. 11. Confidential & Proprietary US Datacenter EU Datacenter Time MastersTime Masters 時刻同期 時刻同期 原子時計 原子時計 GPS受信機 GPS受信機 Spanner Node Spanner Node Spanner Node Spanner Node Spanner Node Spanner Node Time Masters Armageddon Masters GPS Masters Cloud Spanner の時刻同期(TrueTime API)
  12. 12. Confidential & Proprietary 可用性とパフォーマンスのために常に複製 Cloud Spanner instance Zone A Zone B Zone C DB 1 DB 2 DB 1 DB 2 DB 1 DB 2
  13. 13. Confidential & Proprietary Data is synchronously replicated using Paxos consensus. Update Cloud Spanner instance Zone A Zone B Zone C DB 1 DB 2 DB 1 DB 2 DB 1 DB 2 Synchronous レプリケーションと高整合性
  14. 14. Cloud Spanner のアーキテクチャ解析
  15. 15. Confidential & Proprietary API Files Node Server API Files Node Server API Files Node Server API Files Node Server API Files Node Server API Files Node Server Client Clients API Server Node Tier Filesystem Zone 1 Zone 2 Zone 3 Cloud Spanner     のアーキテクチャ
  16. 16. Confidential & Proprietary ● Channels ○ Cloud Spanner へ接続する gRPC コネクション数 ○ Default = 4, max = 256. ○ コードの中で定義する必要がある ■ SpannerOptions options = SpannerOptions.newBuilder().setNumChannels(8).build(); ● Sessions ○ Session はトランザクションを実行できるコンテキストです。並列で行われる トランザクションは各自 session を利用する必要がある。例えば、あるアプリが並列に 100トランザクションを行うとしたら、 Session pool を最低100に設定する必要があります。 ○ Default value = Default number of channels * 100 = 400 ○ Recommendations: Number of sessions = number of expected threads ○ データベースごとにセッション数の上限が: 10000 per node. ○ 詳細はこちら:https://cloud.google.com/spanner/docs/sessions?hl=ja Channels と Sessions
  17. 17. Confidential & Proprietary Channels と Sessions Thread Spanner session pool Thread Thread Session in use Idle session Spanner Client application Spanner instance Spanner channel (gRPC connection)
  18. 18. Confidential & ProprietaryZone 1 NS NS NS NS ノード = Node Servers 2TB まで管理できるサーバ Colossus (分散ストレージ) 実データはここに格納される C クライアント Split ノード数:4 各ノードは 複数の Split の オーナー Cloud Spanner のアーキテクチャ
  19. 19. Confidential & Proprietary id (PK) name address gender 101 samir tokyo m 102 hassy tokyo m : 1001 1002 : 2001 2002 Table Data Split 1 Data Split 2 Data Split 3 Key 101~1000 Key 1001~2000 Key 2001~2999 Split とは?
  20. 20. Confidential & Proprietary NS NS NS NS Zone 1 Zone 2 G-NA-F S-ZO-R G-NA-F S-Z O-R Splits Node Servers 100% Key Coverage per Zone Split のレイアウト
  21. 21. Confidential & Proprietary NS NS NS NS Zone 1 Zone 2 G-NA-F S-ZO-R G-NA-F S-Z O-R A-C D-F A-C D-F Split の分割
  22. 22. Confidential & Proprietary NS NS NS NS Zone 1 Zone 2 G-NA-F S-ZO-R G-NA-F S-Z O-R New NS G-N New NS O-R Split の移動
  23. 23. Confidential & Proprietary Paxos プロトコルが利用されるため、 レプリカの大部分が投票したら、コミット は行われる → 例えば、2大陸のMRの構成でレプリカが5台ある場合( 4 x RW + Witness = 5 replicas) → 書き込みのコミットは3台のレプリカが投票してら行われる US regionEU region eu-west1 eu-west1 us-central1 us-central1 us-central2 us-central2 witness RO RO RW RW RW RW W 5レプリカのうち、3レプリカが投票するとコミットが行われる投票しない 書き込みのコミットの仕組み
  24. 24. Confidential & Proprietary プライマリリージョン (Primary region) → リーダーレプリカが配置されるリージョン → 書き込みコミットの投票に利用されるリージョン セカンダリリージョン (Secondary region) → リーダーとして選択可能とされるレプリカが配置されるリージョン → 地理的にプライマリリージョンに近く配置( 1000マイル以下) → 書き込みコミットの投票に利用されるリージョン ウィットネスリージョン(Witness region) → 書き込みコミットの投票のみに利用されるリージョン → セカンダリとプライマリは地域的にウィットネスより近いため、 普段はウィットネスの投票は影響なし リージョタイプ
  25. 25. Confidential & Proprietary Read Write レプリカ → リーダーとして選択可能 → コミットの投票に参加する Read Only レプリカ → リーダーになれない → コミットの投票に参加しない ウィットネスレプリカ → リーダーにはなれない → リーダーの選択には参加 → コミットの投票に参加する リーダーとは? → Split への RW を管理するレプリカ RW RW RW RW Split Split のリーダー レプリカタイプ
  26. 26. Confidential & Proprietary Cloud Spanner には2種類のトランザクション: 1. Locking read-write transaction (mutation) a. 悲観的ロック a. 読み書きするセルのみをロック 2. Read-only transaction a. 3 種類 i. Strong (デフォルト) :最新のデータを読む ii. Bounded staleness:指定した範囲から最新のデータを読む iii. Exact staleness:指定したタイムスタンプのデータを読む b. ロックを行わない トランザクションタイプ
  27. 27. Cloud Spanner のベストプラクティス
  28. 28. Confidential & Proprietary PK のベストプラクティス シナリオ: ● MySQL から Cloud Spanner の移行 ステップ: ● MySQL からデータを CSV として Dump する ● GCS にアップロード ● データロード用のプログラムを GCE インスタンス上で実行 ● Cloud Spanner へデータをロード 問題: ● Auto-increment の PK のスキーマをそのままインポート
  29. 29. Confidential & Proprietary
  30. 30. Confidential & Proprietary 3 ノードから 5 ノードに増加しても、 CPU 使用率が上がらず パフォーマンスも上らない ノード数を増加してら、 CPU 使用率が 35% から 20% に下がった ノード数を増加しても、 パフォーマンスは上らず HOTSPOT の現象 35% 20% 3 5 7000 QPS
  31. 31. Confidential & Proprietary HOTSPOT とは? 同じノードに 書き込みが 集中する問題
  32. 32. Confidential & Proprietary Hotspot の対策 解決策: 1. ランダムの順でデータを Cloud Spanner にインポートする a. PK の順ではホットスポット 2. 新しい PK を作る a. Auto-increment の INT64 の代わりに STRING32 に UUIDv4 を利用する
  33. 33. Confidential & Proprietary
  34. 34. Confidential & Proprietary 5 ノードを設定 スループットが 7000 QPS 程 度から 25000 QPS まで上 がった! CPU 使用率もようやく 100% をヒットした! HOTSPOT 解決! 3 5 100% 25000 QPS
  35. 35. Confidential & Proprietary データのローカリティ 問題: ● Cloud Spanner は分散データベース ● どのデータがどのノードにあるかは想定できない ● JOIN クエリのパフォーマンスが心配 1111 john 1122 paul 1234 bob 1111 001 1111 002 1234 001 Spanserver A Spanserver B SELECT user_name, item_id FROM users INNER JOIN items ON users.user_id = items.user_id WHERE user_id = 1234; user_id user_name 1111 john 1122 paul 1234 bob user_id item_id 1111 001 1111 002 1234 001
  36. 36. Confidential & Proprietary Interleaving Interleaving(インターリービング) ● Cloud Spanner は PK の値によってソートされた順序でレコードを格納し、同じ PK のプレフィック スを共有する親のレコード間に子のレコードを挿入します。 ● 子テーブルは「Interleave Table」と呼ばれる
  37. 37. Confidential & Proprietary Sibling テーブル - 論理的なデータレイアウト CREATE TABLE Singers ( SingerId INT64 NOT NULL, FirstName STRING(1024), LastName STRING(1024), SingerInfo BYTES(MAX), ) PRIMARY KEY (SingerId); CREATE TABLE Albums ( SingerId INT64 NOT NULL, AlbumId INT64 NOT NULL, AlbumTitle STRING(MAX), ) PRIMARY KEY (SingerId, AlbumId);
  38. 38. Confidential & Proprietary Sibling テーブル - 物理的なデータレイアウト
  39. 39. Confidential & Proprietary Interleave テーブル - 論理的なデータレイアウト CREATE TABLE Singers ( SingerId INT64 NOT NULL, FirstName STRING(1024), LastName STRING(1024), SingerInfo BYTES(MAX), ) PRIMARY KEY (SingerId); CREATE TABLE Albums ( SingerId INT64 NOT NULL, AlbumId INT64 NOT NULL, AlbumTitle STRING(MAX), ) PRIMARY KEY (SingerId, AlbumId); INTERLEAVE IN PARENT Singers ON DELETE CASCADE;
  40. 40. Confidential & Proprietary Interleave テーブル - 物理的なデータレイアウト
  41. 41. Confidential & Proprietary Interleave テーブルの階層 - 論理的ビュー CREATE TABLE Singers ( SingerId INT64 NOT NULL, FirstName STRING(1024), LastName STRING(1024), SingerInfo BYTES(MAX), ) PRIMARY KEY (SingerId); CREATE TABLE Albums ( SingerId INT64 NOT NULL, AlbumId INT64 NOT NULL, AlbumTitle STRING(MAX), ) PRIMARY KEY (SingerId, AlbumId), INTERLEAVE IN PARENT Singers ON DELETE CASCADE; CREATE TABLE Songs ( SingerId INT64 NOT NULL, AlbumId INT64 NOT NULL, TrackId INT64 NOT NULL, SongName STRING(MAX), ) PRIMARY KEY (SingerId, AlbumId, TrackId), INTERLEAVE IN PARENT Albums ON DELETE CASCADE;
  42. 42. Confidential & Proprietary Interleave テーブルの階層 - 物理的ビュー
  43. 43. Confidential & Proprietary なぜテーブルを インターリーブするか user_id SELECT user_name, item_id FROM users INNER JOIN items ON users.user_id = items.user_id WHERE user_id = 1234; user_id user_name 1111 john 1122 paul 1234 bob user_id item_id 1111 001 1111 002 1234 001 user_name user_id item_id 1111 john 1122 paul 1234 bob 1111 001 1111 002 1234 001 Spanserver A Spanserver B 1111 john 1111 001 1111 002 1122 paul 1234 bob 1234 001 Spanserver A Logical View Physical View No interleave Physical View With interleave インタリーブをすると、 JOIN   クエリ が2つのサーバにアクセスすることも なく、1サーバで済む
  44. 44. Confidential & Proprietary 負荷試験 シナリオ: ● 負荷試験を行っており、負荷ツールである負荷シナリオを5分間実行する 問題: ● 5分間負荷試験を実行したが、思った通りにパフォーマンスがでない
  45. 45. Confidential & Proprietary 負荷試験は十分長く実行する Cloud Spanner の負荷試験を行う場合、5分ではなく、20〜30分の負荷試験をオススメします。その理由は、データの容量 が多くなることにより、Split がより多く発生して、データが正常に全ノード間に分散されるからです。 テーブルが十分 split されると、全ノードが 活用され、Cloud Spanner の最大の パフォーマンスを出せるようになります。 Split happens
  46. 46. Confidential & Proprietary Cloud Spanner は容量と負荷状況次第、テーブルを split します。 ただし、実際にどのタイミングでテーブルが分割されるかは保証できません。 Cloud Spanner では以下の2つの条件でテーブルが分割されます: ● Size-based splits ○ テーブルの容量が数 GB程度になったら、テーブルを split します ● Load-based splits ○ Cloud Spanner は分散できる負荷だと、テーブルを split します。 分散できない負荷は、例えばシーケンシャルな INSERT 上記は、どれだけ PK の選択肢が重要かを示しています。 テーブルが分割(Split)されるロジック
  47. 47. Confidential & Proprietary 負荷試験を毎回行う際は、Insert したデータを全て削除するのではなく、データベースを Drop するようオススメします。 データの削除+再Insert は、テーブルスキャンのパフォーマンスを劣化します。それは、削除されたデータは Garbage Collector が物理的に削除するまではテーブルに append されるからです。テーブルのクリーンアップまで1週間までかかり ます。 Spanner のストレージは log-structured merge trees (LSM Tree)を使用している。 → Delete のオペレーションは "append a delete mutation" とストレージレベルで見られる。古いデータはデータベースがク リーンアップされるまで削除されない。 → 削除された PK がまだ格納されているので、テーブルスキャンがインパクトされる。 負荷試験間はデータベースをDropする
  48. 48. Confidential & Proprietary パフォーマンス 問題解決 100% 負荷試験完了 すぐにMaxが出る
  49. 49. Confidential & Proprietary
  50. 50. Confidential & Proprietary よく聞かれる2点 ● Index を利用するには、明示的に指定する必要がある FROM MyTable@{FORCE_INDEX=MyTableIndex} ● Index の STORING 機能を利用して、元テーブルにアクセスを避ける CREATE INDEX AlbumsByAlbumTitle2 ON Albums(AlbumTitle) STORING (MarketingBudget)
  51. 51. Confidential & Proprietary Query Plan Cache SQL クエリを Spanner で使用する際に、bound parameters を使用す るのが重要です。 Cloud Spanner のノードは query plan cache の数が限られています。 クエリの中に静的パラメータを使用すると、各クエリが違うものと見られ て、query plan cache を効果的に活用することができません。この問題 を避けるには、以下の例のようにクエリは parameter binding を利用す る必要があります。 Statement statement = Statement .newBuilder("SELECT name WHERE id > @msg_id AND id < @msg_id + 100") .bind("msg_id").to(500) .build(); これ重要!
  52. 52. Confidential & Proprietary Cloud SQL Cloud Spanner Cloud Datastore Cloud Bigtable BigQuery Cloud Firestore on Firebase Is your data structured? Is your workload analytics? Is your data relational? Do you need updates or low-latency? Do you need Mobile SDK’s? Do you need horizontal scalability? No Yes No Yes No Yes YesNo YesNo Yes No Do you need Mobile SDK’s? Firebase Storage YesNo Cloud Storage
  53. 53. Confidential & Proprietary Q&A
  54. 54. Confidential & Proprietary イノベーションのために時間を作ろう! Focus on value add and innovation instead of maintenance. Simplify costing to better understand your app. Ensure your app stays online and more secure - 99.999% SLA.
  55. 55. Confidential & Proprietary Thank you

×