Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

[Cloud OnAir] Google Cloud における RDBMS の運用パターン 2020年11月19日 放送

データベースはシステム構築に必須のコンポーネントです。一方で、その構築および運用作業でやらなければいけないことは多岐にわたり、複雑なことを求められるケースも多いかと思います。今回の放送では、特にリレーショナル データベースにフォーカスし、Google Cloud のソリューションがどのように課題解決に役立つかを解説いたします。

  • Login to see the comments

  • Be the first to like this

[Cloud OnAir] Google Cloud における RDBMS の運用パターン 2020年11月19日 放送

  1. 1. Cloud Onr Cloud OnAir Cloud OnAir Google Cloud における RDBMS 運用 2020 年 11 月 19 日 放送
  2. 2. 写真を配置後 角丸六角形くり抜きの図形を 被せてください https://goo.gl/NcsiAz Speaker Cloud OnAir Data Management Specialist Daichi Egawa Google Cloud Japan にてデータベース関連の サービスの技術支援に従事。
  3. 3. Agenda Cloud OnAir 1 3 2 4 RDBMS 運用における課題 Google Cloud のデータベース ソリューション Cloud SQL による課題の解決とその特徴 Cloud Spanner による課題の解決とその特徴
  4. 4. Cloud OnAir Cloud OnAir RDBMS 運用における課題
  5. 5. Cloud OnAir 現代のビジネス状況 予測可能・連続的 予測不可能・非連続的 (コロナ、デジタル化による産業の変化 etc.)
  6. 6. Cloud OnAir 不確実性の時代におけるデータベース運用の課題 導入・保守コスト 俊敏性・拡張性 機会損失の防止・可用性
  7. 7. Cloud OnAir 導入・保守コスト ● 初期投資はなるべく避けたい ● 固定費は削減したい ● データベースの運用、保守には多額の費用がかかる
  8. 8. Cloud OnAir データベース運用に関わるタスク ● データベース運用には 多くのタスクが発生 ● 組織によっては、 それぞれのタスクの 担当者が異なる ○ タスクの依頼や連携にも課 題があるケースも アプリの最適化 電源 / HVAC / ネットワーク DB バックアップ & 監視 スケーラビリティ ホスト メンテナンス OS / DB インストール& パッチ ラックの 導入と管理 高可用性構成 典型的なデータベース管理
  9. 9. Cloud OnAir 俊敏性・拡張性 ● ハードウェアの導入、データベース構築に 時間がかかる ● サイジングやキャパシティ プランニングが困難である ● CPU、メモリ、ストレージの追加などのイベントが 長時間かかる。場合によってはトラブルにつながる。
  10. 10. Cloud OnAir 機会損失の防止・可用性 ● 機会損失防止のために、ダウンタイムは避けたい ● 可用性向上のための高度な設定を行うことができる 人材が不足している ● 本来、冗長化が必要なシステムであるにも関わらず、単一 障害点を許容する構成になっていることがある
  11. 11. Cloud OnAir Cloud OnAir クラウド データベースによる 課題へのアプローチ
  12. 12. データベース管理戦略の進化に合わせて自社の戦略を変更 Gartner, Inc.* によると、2022 年までに、すべての データベースの 75 % はクラウド プラットフォームに デプロイまたは移行されると予測され、これまでに クラウドからオンプレミスに戻すことを検討された データベースは 5 % にすぎません。 *Gartner のプレスリリース 出典: 「Gartner Says the Future of the Database Market is in the Cloud」、2019 年 7 月 1 日 詳細: https://cloud.google.com/solutions/data-management?hl=ja
  13. 13. Cloud OnAir 近年のデータベース利用におけるトレンド ● コスト低減に向けた取り組み ○ クラウド コンピューティングへの移行 ● データベース運用の省力化に向けた取り組み ○ マネージドサービス(Database as a Service (DBaaS) Cloud Native DB) への移行
  14. 14. Cloud OnAir データベース構築の選択肢 クラウド オンプレミス上に構築 IaaS 上に構築 DBaaS (*) を 利用 Cloud Native DB (**) を利用 (*)既存 RDBMS との強い互換性を保持するサービス (**)DBaaS の中でもクラウドで動かすことを前提に作られた新しいアーキテクチャをもつサービス
  15. 15. Cloud OnAir クラウドコンピューティング利用によるコスト削減 ● 規模の経済 ○ データセンター、HW は大量に 一括調達したものを利用可能 ● 従量課金 ○ 開発工程が終わったら、開発環境を 停止してコスト削減 ○ 検証サーバは土日など停止可能 ○ 減価償却などのオペレーションが不要 ● データセンターでの物理的な作業が不要 ○ オペレーションを改善し、より開発スピードUP コスト削減↓
  16. 16. Cloud OnAir データベース構築の選択肢 クラウド オンプレミス上に構築 IaaS 上に構築 DBaaS (*) を 利用 Cloud Native DB (**) を利用 (*)既存 RDBMS との強い互換性を保持するサービス (**)DBaaS の中でもクラウドで動かすことを前提に作られた新しいアーキテクチャをもつサービス
  17. 17. Cloud OnAir DBaaS, Cloud Native DB 選択の背景 ● DBaaS, Cloud Native DB は、マネージドサービス ○ データベース運用に必要な作業をクラウド プロバイダーにオフロード ● 俊敏性、拡張性のための機能 ○ データベース プロビジョニングは自動化され、即座に起動可能 ○ ストレージ容量の管理、スケール アップ が容易に可能 ○ Cloud Native DB ではストレージなどのサイジングが不要になることが多い (ユーザーが意識しなくても自動で拡張する) ● 高可用性のための機能 ○ 冗長構成を簡単に構築 (DBA が工数を費やす作業をそのまま利用可能) ○ Cloud Native DB では高可用性がビルトインされた設計になっていることが多い (ユーザーが意識しなくても冗長構成が保たれている)
  18. 18. なぜマネージド データベースを活用すべきか アプリの最適化 電源 / HVAC / ネットワーク DB バックアップ & 監視 スケーラビリティ ホスト メンテナンス OS / DB インストール& パッチ ラックの 導入と管理 高可用性構成 典型的なデータベース管理 ● マネージド DB の活用により優秀なエンジニアの生産性を向上 Cloud OnAir
  19. 19. なぜマネージド データベースを活用すべきか アプリの最適化 電源 / HVAC / ネットワーク DB バックアップ & 監視 スケーラビリティ ホスト メンテナンス OS / DB インストール& パッチ ラックの 導入と管理 高可用性構成 典型的なデータベース管理 ● マネージド DB の活用により優秀なエンジニアの生産性を向上 Cloud OnAir IaaS 上にデータベースを構築した場合でも これらの作業の負荷軽減が可能
  20. 20. なぜマネージド データベースを活用すべきか アプリの最適化 電源 / HVAC / ネットワーク DB バックアップ & 監視 スケーラビリティ ホスト メンテナンス OS / DB インストール& パッチ ラックの 導入と管理 高可用性構成 典型的なデータベース管理 ● マネージド DB の活用により優秀なエンジニアの生産性を向上 Cloud OnAir DBaaS, Cloud Native DB での データベース管理 プログラミング アプリの最適化/ チューニング サーバ管理、スケーリングやバッ ク アップはサービスの 一部として提供
  21. 21. Cloud OnAir 即座に起動、削除、よりスムーズに拡張 ● 即座に起動、削除 ○ GUI により数クリックの操作で起動 ○ CLI により作成作業の自動化も可能 ○ 削除も同様にできるので、 不要になったら即座に削除 ● 拡張 ○ ワークロードに合わせて柔軟に変更可能 ○ 拡張作業も GUI, CUI で即座に実施可能
  22. 22. 可用性、耐障害性の向上もより簡単に Cloud OnAir ● データベース管理者が時間を費やす 高度な設定がビルトイン ○ レプリケーション、 自動フェイル オーバー ○ 自動バック アップ ○ 数クリックでのデータベース復元 ゾーンA ゾーンB 永続ディスク 永続ディスク リージョン IPアドレス プライマリDB スタンバイDB リージョン 永続ディスク レプリケーションの例
  23. 23. Cloud OnAir Cloud Native DB によるさらなる運用省力化 ● Cloud Native DB では、DBaaS 以上に インフラストラクチャレイヤーが抽象化(ユーザー が意識しなくて良い) され、 運用負荷軽減に繋がる ● 以下のような機能がビルトインされているケース が多い ○ 自動シャーディング ○ ストレージの自動スケーリング ○ 計画的なメンテナンスによる ダウンタイムがない 自動スケーリングの例
  24. 24. Cloud OnAir Cloud OnAir Google Cloud の データベース ソリューション
  25. 25. Cloud OnAir Google Cloud のデータベース ソリューション Cloud Memorystore BigQuery Cloud Datastore / Cloud Firestore Cloud Bigtable Cloud SQL Cloud Spanner ● すべてマネージドサービスとして 前述の課題へのアプローチが可能 ○ 導入・保守コストの軽減 ○ 即座に利用可能、ワークロードに合わせた拡張 ○ 高い可用性をもつための機能、設計 ● 多様な選択肢 ○ ユースケース、ワークロードに合わせて 最適なサービス選択が可能 ○ 複数のサービスを組み合わせて実施可能 ○ 必要に応じて Compute Engine (IaaS) 上に 構築することも可能
  26. 26. Google Cloud のデータベース関連サービス Cloud OnAir 移行に適した OSS および 商用 DB モダナイズに適した クラウドネイティブ DB データ ウェアハウスキャッシュ Cloud Memorystore BigQuery マネージド Redis & memcached Cloud Firestore (Native / Datastore Mode) サーバーレスで スケーラブルな ドキュメントストア Cloud Bigtable 低レイテンシで スケーラブルな ワイドカラムストア Cloud SQL マネージド MySQL & PostgreSQL & SQL Server Cloud Spanner スケーラブルで 可用性の高い ミッション クリティカル RDBMS サーバーレスで スケーラブルな エンタープライズ DWH 今回のテーマ
  27. 27. Cloud OnAir Compute Engine (IaaS) 上に DB 構築するという選択肢 ● Compute Engine 上ではより自由度の高い選択やデータベース運用が可能 ● 以下のようなケースでは、Compute Engine 上での DB 構築が必要 ○ マネージド サービスでは対応していないRDBMS, バージョンを利用したい ○ マネージド サービスで提供されるCPU、メモリ サイズでは不足する ○ OS への設定が必須である ■ OS パラメータをチューニングしたい ■ データベースと同じ OS 上に監視エージェントなどを インストールしたい ○ データベースの管理者権限が必要な処理がある
  28. 28. Cloud OnAir Cloud OnAir Cloud SQL
  29. 29. Cloud OnAir Cloud SQL とは? フルマネージドなリレーショナル データベース サービス高可用 性、バックアップ、暗号化、パッチ適用、 容量増加などが組み込まれた RDBMS の マネージド サービス MySQL PostgreSQL SQL Server Google Cloud の各種サービスとの容易な統合 クライアントやドライバーを用いた接続だけでなく GCP の各種サービスと容易に連携可能
  30. 30. Cloud OnAir Cloud SQL の特徴 導入・保守コスト 俊敏性・拡張性 機会損失の防止・可用性 ● 規模の経済 ● 従量課金 ● フルマネージド サービスによる 保守コストの削減 ● すぐに簡単に作成可能 ● 容易なスケールアップ ● ストレージの 自動スケーリング ● リード レプリカによる 参照スケールアウト ● 高可用性設定 (同期レプリケーション+ 自動フェイル オーバー) ● 自動バックアップ
  31. 31. Cloud SQL (高可用性構成) のアーキテクチャ イメージ Cloud OnAir ゾーン A ゾーン B 永続ディスク 永続ディスク 東京リージョン IPアドレス プライマリDB スタンバイDB リージョン 永続ディスク 同期レプリケーション リードレプリカ リードレプリカ 非同期レプリケーション
  32. 32. Cloud OnAir 各種 DB インスタンスを簡単に作成 数ステップで DB インスタンスを作成 ● 最低限の情報を入れるだけで作成可能 ● 必要に応じて設定オプションを追加 柔軟に選択可能なマシンタイプ ● CPU 最大 96 コア ● RAM 最大 624 GB
  33. 33. Cloud OnAir 自動拡張するスケーラブルなストレージ 容量に応じた性能をプロビジョニング ● 容量は最小 10 GB から最大 30 TB ● SSD または HDD を選択可能 ● 最大 60,000 IOPS 必要に応じて自動拡張 ● ストレージのサイジングが不要で 拡張に伴う停止も無し
  34. 34. リードレプリカによる性能向上 ゾーン A ゾーン B 東京リージョン IP アドレス X プライマリDB リードレプリカ リードレプリカ IP アドレス Y IP アドレス Z 非同期レプリケーション ● プライマリ インスタンスより 非同期レプリケーションにより データを複製 ● 読み取りの負荷分散が可能 ● 注意 ○ 本機能は PostgreSQL, MySQL エンジンで提供 ○ 接続先となる IP アドレスは プライマリ インスタンスのものとは 異なる ○ リードレプリカは性能向上のための 機能。高可用性を備えたものではなく、 それを提供するものではない。
  35. 35. Cloud OnAir 自動バックアップにより容易に実現できる高可用性 自動取得される日時バックアップ ● 時間帯を選択するだけで自動取得 ● 任意時間でオンデマンド取得も可能 ● 最大 7 世代まで保持
  36. 36. HA 構成による高可用性 - ゾーン間でのリアルタイム データ同期 ゾーンA ゾーンB 永続ディスク 永続ディスク 東京リージョン IPアドレス プライマリDB スタンバイDB リージョン 永続ディスク リージョン永続ディスクによる同期 プライマリ DB への書き込みは、 リージョン永続ディスク(Regional PD)を通 じ、スタンバイ DB が配置されたゾーンの永 続ディスクへも 同期書き込みが行われる これによりレプリケーション遅延が なくなり、フェイルオーバーにかかる 時間を大幅に短縮
  37. 37. Cloud OnAir Cloud OnAir Cloud SQL アップデート
  38. 38. Cloud OnAir 主な新機能 (1 / 2) ● Cloud SQL 共通 ○ Cloud SQL インスタンスのメンテナンス事前通知とスケジュール変更 ○ メンテナンス拒否期間の設定 ○ リージョン間の Private IP 接続 ○ クロス リージョン レプリカのサポート (PostgreSQL、MySQL エンジンでサポート) ○ サーバーレス エクスポートをサポート (PostgreSQL、MySQL エンジンでサポート) ○ Cloud VPN 経由の接続をサポート ○ VPC サービス コントロールのサポート ○ 顧客管理の暗号鍵 (CMEK) のサポート ○ 確約利用割引 (CUD) をサポート その他、新しいマシンタイプの登場なども! 詳細: https://cloud.google.com/sql/docs/release-notes
  39. 39. Cloud OnAir 主な新機能 (2 / 2) ● For MySQL ○ MySQL 8.0 をサポート ○ データベースフラグを 80 までサポート ● For PostgreSQL ○ PostgreSQL 12 をサポート ○ PostgreSQL 13 をサポート ○ PostgreSQL にて新たに 8 つの拡張機能をサポート ○ Cloud SQL IAM データベースの認証をサポート ○ pgAudit (監査に利用可能な拡張機能 )をサポート ● For SQL Server ○ SQL Server エンジンをサポート ○ デフォルトの照合順序を設定をサポート 詳細: https://cloud.google.com/sql/docs/release-notes
  40. 40. ● 96 コア マシンタイプの登場 ● MySQL 8.0 のサポート ● PostgreSQL 10, 12, 13 のサポート ● SQL Server 2017 のサポート 最新 DB バージョンへの追従は常に行っているため、最新情報を確認のこと 新たに追加されたマシンタイプと DB バージョンUpdates Cloud OnAir
  41. 41. メンテナンス通知の受信 ● 実施予定日の 1 週間前までにコンソール上で通 知を確認できる ● メール通知を受け取るには、コンソールの 設定よりメンテナンスの時間枠の通知を 有効化 メンテナンス期間の拒否 ● メンテナンス 1 回につき、1度の 拒否期間 (1 ~ 90 日)を設定可能 ○ 繁忙期のメンテナンス実施を回避可能 Cloud SQL インスタンスのメンテナンス事前通知Updates Cloud OnAir
  42. 42. 1. pg_repack  オンラインでのテーブル及び  インデックスの再編成が可能 2. postgres_fdw  リモートの PostgreSQL に接続し  テーブルを参照することが可能 ● PostgreSQL は機能拡張が可能で、さまざまなモジュールが提供されている ● Cloud SQL for PostgreSQL でサポートされてきた PostGIS もその 1 つ PostgreSQL の拡張機能の追加Updates 3. pageinspect 4. pgfincore 5. pg_freespacemap 6. pg_visibility 7. PL/Proxy 8. postgresql-hll 2020年に追加された拡張機能 9. pgAudit  より柔軟なデータ ベースの監査が可能 Cloud OnAir
  43. 43. マスターと異なるリージョンにリードレプリカを 配置することが可能になった クロスリージョンレプリカの利点 ● アプリに近いリージョンにレプリカを 配置することで読み取り性能の向上 ● レプリカはマスターへ昇格可能であり DR サイトの構築が可能 クロスリージョン レプリカUpdates Cloud OnAir
  44. 44. Cloud SQL において、 異なるリージョン間での プライベート IP による通信が できるようになった そのため、利便性や可用性が さらに向上した リージョン間のプライベート IP 接続Updates Cloud SQL の専用 VPC 東京リージョン 10.35.32.0/24 master-db 10.35.32.3 大阪リージョン 10.35.33.0/24 replica-db1 10.35.33.3 ユーザーの VPC 東京リージョン 10.146.0.0/20 client-vm 10.146.0.6 Private IP 通信 北米リージョン 10.35.34.0/24 replica-db2 10.35.34.3 クロスリージョン レプリケーション 東京リージョンから、 大阪リージョンや 北米リージョンなど、 異なるリージョンの Cloud SQL へプライベートIP 通信 が可能
  45. 45. ● 確約利用割引 (CUD) とは ○ データベース インスタンスを、 継続使用することと引き換えに 適用される割引料金 ● 特徴 ○ 1 年間 (25% 割引) or 3 年間 (52% 割引) ○ リージョン内の Cloud SQL インスタンスの 使用量の合計に自動的に適用 (適用する インスタンス、エンジンの選択の必要なし) ● 注意点 ○ 特定のリージョンを選択してのコミットメント ○ 共有 CPU マシンタイプ (db-f1-micro、db-g1-small な ど) は対象外 確約利用割引 (CUD) をサポートUpdates Cloud OnAir
  46. 46. Cloud OnAir Cloud OnAir Cloud Spanner
  47. 47. Cloud OnAir Cloud Spanner 概要 フルマネージドなデータベースで容易に構成可能、パッチ適用なども全自動 テーブル構造に対してSQL でのクエリや、ACID トランザクションをサポート DR 構成も可能で 99.999 % の可用性を提供、メンテナンスによるダウンタイムも無し テーブルは自動シャーディングされ、スケール アウト / インが実施可能 クラウド ネイティブのリレーショナルデータベース リレーショナル データベースのようテーブル構造に対してSQL と トランザクションをサポートし、NoSQL のようなスケーラビリティを持つ
  48. 48. Cloud OnAir Cloud Spanner の特徴 導入・保守コスト 俊敏性・拡張性 機会損失の防止・可用性 ● 規模の経済 ● 従量課金 ● フルマネージド サービスによる 保守コストの削減 ● すぐに簡単に作成可能 ● ノード追加による スケール アウト ● ストレージの 自動スケーリング ● デフォルトで冗長化 ● 最大 99.999 % の可用性 ● マルチリージョン 構成による災害対策 ● ダウンタイムなしで 様々なオペレーションが可能
  49. 49. Cloud OnAir Cloud Spanner の設定項目 インスタンス名 / ID 任意の名前を入力 構成 どこのリージョンに インスタンスを 構築するかを選択 ノード数 必要なスループット性能に 応じてノード数を入力 必要な入力項目は わずか 3 種類
  50. 50. Cloud OnAir Cloud Spanner の設定項目 インスタンス名 / ID 任意の名前を入力 構成 どこのリージョンに インスタンスを 構築するかを選択 ノード数 必要なスループット性能に 応じてノード数を入力 必要な入力項目は わずか 3 種類 可用性に影響を与える 設定項目 性能 (スループット) に 影響を与える設定項目
  51. 51. Cloud OnAir Cloud OnAir 可用性の仕組み - 構成の選択とレプリケーション
  52. 52. Cloud OnAir Cloud Spanner の設定項目 インスタンス名 / ID 任意の名前を入力 構成 どこのリージョンに インスタンスを 構築するかを選択 ノード数 必要なスループット性能に 応じてノード数を入力 必要な入力項目は わずか 3 種類
  53. 53. 53 東京リージョン(asia-northeast1) 内部は a, b, c の 3 つのゾーンに 分かれている。 大阪リージョン(asia-northeast2) 内部は a, b, c の 3 つのゾーンに 分かれている。 リージョン 独立した地理的地域のこと。 各リージョンには少なくとも 3 つのゾーン があり、同一リージョン内のネットワーク レイテンシは 95 % tile で 1 ms 未満になるように 設計されている。 ゾーン 同一リージョン内の各ゾーンは 独立されて設計されており、電源、 冷却、ネットワーク、コントロール プレーンなどは、他のゾーンから 切り離されている。 https://cloud.google.com/solutions/best-practices-compute-engine-region-selection?hl=ja a b c a b c Google Cloud のリージョンとゾーン
  54. 54. 54 東京リージョン 大阪リージョン シングル リージョン構成 日本国内には東京と大阪の 2 リージョンから選 択。もちろんその他海外のリージョンも 選択可能。可用性は 99.99 % マルチ リージョン構成 複数のリージョンを同時に利用することにより、可用 性を 99.999 % に向上させ、またリージョン障害や災 害など地理位置に依存した障害にも 耐えることができる。 日本では、東京及び大阪 (及びソウル*1 ) を同時に利 用することで実現 *1) ソウルには実際のデータを保存しないが、 リージョン障害発生時においてもデータの 整合性担保ができるよう通信を行う。 Cloud Spanner の構成 Cloud OnAir
  55. 55. Cloud OnAir Cloud Spanner インスタンスの作成画面 インスタンス名 / ID 任意の名前を入力 構成 どこのリージョンに インスタンスを 構築するかを選択 ノード数 必要なスループット性能に 応じてノード数を入力 必要な入力項目は わずか 3 種類 構成: (シングル) リージョン ノード数:1
  56. 56. Cloud Spanner のアーキテクチャ イメージ Cloud OnAir 東京リージョン (asia-northeast1) ゾーン a ゾーン b ゾーン c Cloud Spanner インスタンス 1 ノード node1 node1 node1 分散ストレージ 分散ストレージ 分散ストレージ ● ノード数に関係なく裏側で冗長化(ノード数 1 でも単一障害点のない構成) ● データはノードとは分離された分散ストレージに保存 ● コンピュートとストレージは切り離されており、それぞれ独立して性能と可用性を担保 コンピュート ストレージ コンピュート ストレージ
  57. 57. Cloud Spanner は強整合性をもったレプリカを持つ Cloud OnAir 東京リージョン (asia-northeast1) ゾーン a ゾーン b ゾーン c node1 node1 node1 データはゾーンごとにレプリカが作成される。1 つがリーダー(代表者) となり、 分散合意アルゴリズムとしてのPaxos アルゴリズムを用いた同期レプリケーションにより、 強整合性を持った複製を持っている。 コンピュート ストレージ 分散ストレージ 分散ストレージ 分散ストレージ 強整合性を持った レプリケーション レプリカ レプリカ レプリカ (Leader)
  58. 58. 強整合性をもったレプリケーションをするための条件 Cloud OnAir Google Cloud 東京リージョン ゾーン a ゾーン b ゾーン c 強整合性を持ったレプリケーション レプリカのうち 1 つがリーダー(Leader)となり、 書き込みリクエストはリーダーが受け付ける。 書き込みを commit する際、リーダーは他のレプリカに 更新内容を転送しつつ、この内容で書き込みを行っても 問題ないか採決を行う。 全体のレプリカのうち 過半数から同 意が得られたら、書き込みが成功となる。 障害があっても、レプリカの過半数が生き残れば 処理を継続できる。 commit しても良いか? commit ok ok リーダー(Leader) 書き込みリクエストを 受け付ける。 リーダー自身も 採決に参加する。 遠くのレプリカからの返事 リーダー含めて過半数 (3 分の 2) からの応答を 待てばよいので、地理位置が離れており、遠くにある レプリカの応答は、障害時以外では通常待たずに 書き込み成功とみなされる。 レプリカ レプリカ (Leader) レプリカ
  59. 59. ゾーン障害時は他のレプリカがリーダーに昇格 東京リージョン (asia-northeast1) ゾーン a ゾーン b ゾーン c Cloud Spanner インスタンス 1 ノード node1 node1 node1 分散ストレージ 分散ストレージ 分散ストレージ 59 ゾーン障害時は他のレプリカがLeader となり、ダウンタイムなく処理を継続することができる。 レプリカ レプリカ (Leader) 障害 昇格 Cloud OnAir
  60. 60. 60 東京大阪マルチリージョン構成 (asis1) Cloud OnAir 正常時 マルチ リージョン構成では 5 つレプリカがあるので、 過半数である 3 つから返事がくれば良い。 正常時は、まず東京リージョンに書き込みが行き、 東京で 2 つ、大阪から 1 つ応答があった時点で、 書き込みが成功する。東京ソウル間のレイテンシは 無視できる。 障害時 東京リージョン障害時の場合、大阪リージョンが リーダーになる。その場合であっても、大阪 2 つ、 ソウル 1 つで過半数を満たせるため、レプリカ間の 整合性を保ちながら、処理を継続できる。 DR を含め様々な障害に自動対応可能 これらが全てフルマネージドで提供され、 稼働率として SLA 99.999 % を提供。 ウィットネス レプリカ (データを保持しない) リーダー レプリカ レプリカ
  61. 61. Cloud Spanner マルチ リージョン構成におけるレプリカ構成 東京リージョン (asia-northeast1) node1 node1 分散ストレージ 分散ストレージ マルチ リージョン構成であっても、シングル リージョンの仕組みの 延長で構築できる。リージョン障害時であっても 過半数のレプリカを残すためには、3 つのリージョンで 構築する必要がある。 レプリカ レプリカ (Leader) 大阪リージョン (asia-northeast2) node1 node1 分散ストレージ 分散ストレージ レプリカレプリカ ソウルリージョン (asia-northeast3) node1 ウィットネス レプリカ レプリカ間の整合性を保つための投票には 参加するが、データを保存しないレプリカ。 合意に必要な情報は受け取るが、それを 取得可能なデータとしては保存せずに捨てる。 Cloud OnAir
  62. 62. Google Cloud 東京リージョン ゾーン a (参考) 障害発生時に過半数のレプリカが保てない構成 62 データ ゾーン b データ Google Cloud 大阪リージョン ゾーン a データ ゾーン b データ 例 1 - 東京 2, 大阪 2 単一リージョンだけで 過半数を満たせないので、リー ジョン障害に 耐えられない。 Google Cloud 東京リージョン ゾーン a データ ゾーン b データ Google Cloud 大阪リージョン ゾーン a データ ゾーン bゾーン c データ データ 例 2 - 東京 3, 大阪 2 東京リージョン障害時に、 大阪リージョンだけで 過半数を満たせないので、リー ジョン障害に 耐えられない。 4 つのうち 2 つしか 残らないため NG 5 つのうち 2 つしか 残らないため NG 障害 障害 Cloud OnAir
  63. 63. Cloud OnAir Cloud OnAir スループット向上 (拡張性) のしくみ - ノードの追加と自動シャーディング
  64. 64. Cloud OnAir Cloud Spanner の設定項目 インスタンス名 / ID 任意の名前を入力 構成 どこのリージョンに インスタンスを 構築するかを選択 ノード数 必要なスループット性能に 応じてノード数を入力 必要な入力項目は わずか 3 種類
  65. 65. コンピュートとストレージの分離 Cloud OnAir 東京リージョン (asia-northeast1) ゾーン a ゾーン b ゾーン c Cloud Spanner インスタンス 1 ノード node1 node1 node1 分散ストレージ 分散ストレージ 分散ストレージ コンピュート ストレージ コンピュート ストレージ コンピュートとストレージは切り離されており、 それぞれ独立して性能と可用性を担保。
  66. 66. node1 ゾーン a ゾーン b ゾーン c node2 node1 node2 node1 node2 2 ノード目追加 数秒で起動完了 Cloud Spanner インスタンス 2 ノード 東京リージョン (asia-northeast1) 分散ストレージ 分散ストレージ分散ストレージ コンピュート ストレージ 66Cloud OnAir ノード追加によるコンピュートの水平スケール ノード追加とは、新たなコンテナの起動する。データ自体は分散ストレージ経由で共有されて いるため、ノードの追加と削除は速やかに完了する。
  67. 67. ノード数の数だけ処理能力が向上する node1 ゾーン a ゾーン b ゾーン c node2 node1 node2 node1 node2 Cloud Spanner インスタンス 4 ノード 東京リージョン (asia-northeast1) 分散ストレージ 分散ストレージ分散ストレージ node3 node4 node3 node4 node3 node4 ストレージ コンピュート Cloud Spanner 1 ノードの性能 読み込みでは最大 10,000 qps 書き込みでは2,000 qps を処理可能 (*) (*)パフォーマンス値は推定値であり、ワークロード、スキーマ設計、データセットの特性によって大きく変わります。 参考:https://cloud.google.com/spanner/docs/instances?hl=ja#regional-performance
  68. 68. コンピュートとストレージの分離 Cloud OnAir 東京リージョン (asia-northeast1) ゾーン a ゾーン b ゾーン c Cloud Spanner インスタンス 1 ノード node1 node1 node1 分散ストレージ 分散ストレージ 分散ストレージ コンピュート ストレージ コンピュート ストレージ コンピュートとストレージは切り離されており、 それぞれ独立して性能と可用性を担保。
  69. 69. ストレージのスケール (自動シャーディング) ゾーン a node1 分散ストレージ 69 ● Cloud Spanner テーブルのデータは、内部で一定の単位で分割 ○ 主キー (PK) のレンジで、自動的に分割 ○ 分割単位を「スプリット」と呼ぶ 自動分割 テーブル スプリット スプリット スプリット Cloud OnAir
  70. 70. ストレージのスケール (自動シャーディング) ゾーン a node1 分散ストレージ 70 スプリットは分散ストレージに保存されているため、 コンピュートノードが増えると担当するスプリットを変更することによって、 性能がスケールするようになっている。 自動分割 テーブル スプリット スプリット スプリット node2 node3 Cloud OnAir
  71. 71. 自在にスケール可能な Cloud Spanner node1 分散ストレージ 71 このようにして Cloud Spanner は、1 ノードの小規模構成から、数百ノードもの 大規模構成まで、柔軟にスケールさせることが可能。 分散ストレージ内のスプリットは、データサイズや負荷状況に応じて分割や結合が行われる。 node2 Node X・・・ ・・・ Cloud OnAir
  72. 72. Cloud OnAir Cloud OnAir Cloud Spanner アップデート
  73. 73. Cloud OnAir 主な新機能 ● チェック制約のサポート ● Generated columns のサポート ● Numeric 型のサポート ● 最も古いアクティブなクエリ (ロングランニングクエリ) の監視をサポート ● Cloud Spanner エミュレータをサポート ● 統計情報を SQL で取得可能に ● バックアップとリストアをサポート ● 外部キー制約をサポート 詳細: https://cloud.google.com/spanner/docs/release-notes
  74. 74.      外部キー制約 (Foreign Keys) が 追加 特徴 ● 外部キー制約が DDL で定義できるようになった ● 非キー列や複数テーブル間で外部キー制約を実現 ○ 補足:これまでは Cloud Spanner のインターリーブ機能を 利用して、外部キー制約に似たことを実現していた FEATURE player_items PK player_id STRING(32) PK, FK item_id INT64 quantity INT64 items PK item_id INT64 name STRING(255) price INT64 Cloud OnAir
  75. 75.      マネージド バックアップ リストア 特徴 ● インスタンス内の DB 単位で バックアップ取得可能 ● バックアップは、インスタンスに紐付いた専用領 域に保管され、最大 1 年間保持可能 ● 同一インスタンス及び、同一リージョンの別の インスタンスに対してリストア可能 ● リストア時間は非常に高速 FEATURE Cloud OnAir
  76. 76.      Cloud Spanner エミュレータ がリリース 特徴 ● 任意の環境で動作可能なエミュレータを、バイナリ及びコンテナで提供 ● 開発者のローカル環境はもちろん、CI / CD に組み込んでの利用も可能 ● 開発コストの削減、開発効率の向上 エミュレータと実機との動作の違いに注意 ● Cloud Spanner エミュレーターでは内部的なロックの取り方が異なるため、 トランザクションの競合をテストするような用途には向かない ● エラーメッセージの出方が異なる場合がある $ gcloud beta emulators spanner start Executing: docker run -p 127.0.0.1:9010:9010 -p 127.0.0.1:9020:9020 gcr.io/cloud-spanner-emulator/emulator:0.7.3 [cloud-spanner-emulator] 2020/04/19 14:15:10 gateway.go:135: Cloud Spanner emulator running. [cloud-spanner-emulator] 2020/04/19 14:15:10 gateway.go:136: REST server listening at 0.0.0.0:9020 [cloud-spanner-emulator] 2020/04/19 14:15:10 gateway.go:137: gRPC server listening at 0.0.0.0:9010 $ gcloud spanner instances create emu-instance --config=emu-config --description="Dev Instance" --nodes=1 FEATURE
  77. 77. Cloud OnAir Cloud OnAir まとめ
  78. 78. Cloud OnAir まとめ ● クラウド データベースを利用することで、不確実性の時代における データベース運用の課題に対応 ○ コスト、俊敏性・拡張性、可用性に関わる課題へのアプローチ ● マネージド サービスを活用し、データベース エンジニアの生産性を向上 ○ Cloud SQL を利用して、高可用性、バックアップ、暗号化、 パッチ適用、容量増加などの作業を効率的に実施 ○ Cloud Spanner を利用して、ダウンタイムのより 短いデータベース運用を実施

×