2024-03-29 SRETT9 Cloud SQLの可用性について

Transcript

1. Cloud SQLの可用性について Copyright © 3-shake, Inc. All Rights Reserved. 株式会社スリーシェイクSreake事業部 鈴木勝史
2. Copyright © 3-shake, Inc. All Rights Reserved. おまえだれよ 2 • すずきまさし • 株式会社スリーシェイク Sreake事業部所属 • クラウドインフラなんでも屋さんしてます ◦ 設計支援、運用支援、構築支援、支援以外も実作業もする • AWSちょっとわかる ◦ AWS Community Builder 2024 • Google Cloudなにもわからない • Terraformちょっとわかる
3. Copyright © 3-shake, Inc. All Rights Reserved. シナリオ 3 あなたはGoogle Cloud上で稼働するWebアプリケーションのインフラ運用を任されたエンジニアです。 グローバルに展開するアプリケーションであるため、リージョンに障害が起きた際にもアプリケーションを稼働させ続ける必要 があります。 さしあたってアプリケーションで使用している Cloud SQL をゾーン障害、リージョン障害に備えた構成にしてほしいと言われ ています。 ここからどのような方策が取れるかを考えていきます。
4. Copyright © 3-shake, Inc. All Rights Reserved. 目次 4 1. Cloud SQLについて 2. ゾーン障害に備える 3. リージョン障害に備える 4. ダウンタイムをさらに少なくする 5. まとめ
5. Copyright © 3-shake, Inc. All Rights Reserved. Cloud SQL 01 5
6. • Google CloudのマネージドRDBサービス • MySQL、PostgreSQL、SQL Server対応 • EnterpriseとEnterprise Plusのエディションがある • Enterprise Plusの方がSLAが高く、パフォーマンスに優れる ◦ Enterprise 99.95% ◦ Enterprise Plus 99.99% ◦ MySQLとPostgreSQL対応 ◦ 取りうるDBのバージョンに制限あり ▪ MySQL 8.0 ▪ PostgreSQL14, 15 • 参考: Cloud SQL の各エディションの概要 | Cloud SQL ドキュメント | Google Cloud Copyright © 3-shake, Inc. All Rights Reserved. Cloud SQL 6
7. Copyright © 3-shake, Inc. All Rights Reserved. ゾーン障害に備える HA構成 02 7
8. Copyright © 3-shake, Inc. All Rights Reserved. HA構成 8 • プライマリゾーンとセカンダリゾーンにインスタンスを構成する ◦ AWSのRDSでいうところのMulti AZと考えてもらえると ◦ スタンバイのインスタンスを起動させておくので料金は 2倍 ◦ ゾーン障害に備えることができる • 高可用性構成を適用した場合に完全な SLAが適用される ◦ 参考: Cloud SQL Service Level Agreement SLA | Google Cloud • クライアントから見えるDBエンドポイントは一つ ◦ フェイルオーバー時に自動で IPの向け先が変わるので クライアント側で切り替える必要がない • DBへの書き込みはリージョン永続ディスクにされる • ハートビートは1秒間隔 • フェイルオーバー時のダウンタイムは 60秒ほどの想定 • 参考: 高可用性について | Cloud SQL for PostgreSQL | Google Cloud
9. Copyright © 3-shake, Inc. All Rights Reserved. リージョン障害に備える クロスリージョンレプリカ 03 9
10. Copyright © 3-shake, Inc. All Rights Reserved. リードレプリカ 10 • それぞれのRDMSのレプリケーションの仕組みをマネージドで利用できる • 読み込みクエリはリードレプリカに差し替えることで負荷分散をすることができる • 読み込み負荷が高い場合は、リードレプリカを複数台立てることもできる ◦ ワークロードごとに発行するクエリを分けて影響を抑える方法も ▪ ex: Webアプリと分析でクエリを分割等 • 非同期レプリケーションを使用するのでレプリカラグには注意
11. Copyright © 3-shake, Inc. All Rights Reserved. クロスリージョンレプリカ 11 • 別リージョンにリードレプリカを作ることができる • プライマリとは別のリージョンにリードレプリカを構築することによりリージョン障害に備える • リージョン障害時にクロスリージョンレプリカを昇格させる • クライアント側のエンドポイント設定を変更する。
12. Copyright © 3-shake, Inc. All Rights Reserved. クロスリージョンレプリカの課題 12 • マネージドでフェイルオーバーする仕組みがない ◦ 自前で障害検知して、レプリカを昇格する必要がある ◦ クライアント側でエンドポイントを切り替える必要がある ▪ 高可用性構成のようにエンドポイントが共通のものではなく、別々になっている ▪ マネージドなDBプロキシが用意されていないので何かしら切り替える仕組みが必要
13. Copyright © 3-shake, Inc. All Rights Reserved. ダウンタイムをさらに少なくしたい Spanner 04 13
14. Copyright © 3-shake, Inc. All Rights Reserved. Spannerという選択肢 14 • マネージドな分散RDBサービス • 高い可用性 ◦ マルチリージョン99.999% ◦ シングルリージョン 99.99% • コンピュートとストレージが分離 ◦ クラウド向けに設計されている • PostgreSQLとGoogleSQLをサポート ◦ DB作成時にSQL方言を選択する • ノード、プロセッシングユニットを増やすことで水平スケール可能 ◦ 1000プロセッシングユニット = 1ノード • マルチリージョン構成を取ることでリーション障害時にも可用性を維持可能 • ダウンタイム無しで構成変更することが可能
15. Copyright © 3-shake, Inc. All Rights Reserved. Spannerも銀の弾丸ではない 15 • PostgreSQLと完全互換ではない ◦ 参考: Spanner 向け PostgreSQL Interface | Google Cloud PostgreSQL と完全な互換性はありません。ストアド プロシージャ、トリガー、拡張機能、構成可能な隔離レベ ルなど、PostgreSQL の機能に依存する既存のアプリケーションでは、 Spanner で実行する再作業が必要に なります。ただし、Spanner がサポートする SQL 構文はセマンティックに同等な PostgreSQL である • 接続方法 ◦ Spannerクライアントライブラリ ▪ 既存のアプリケーションのライブラリを差し替える必要がある ◦ PGAdapterプロキシ経由で接続する ▪ Cloud Runアプリケーションから接続する際はサイドカーで PGAadaperを立てる必要がある ▪ 参考: PGAdapter を起動する | Spanner | Google Cloud • Cloud SQLの最小構成と比べるとコスト高になる。 ◦ 開発環境で使うには工夫が必要となる
16. Copyright © 3-shake, Inc. All Rights Reserved. まとめ 05 16
17. Copyright © 3-shake, Inc. All Rights Reserved. まとめ 17 • 今回はリージョン障害に備えた構成を考えてきました。 • サービスの特性により求める可用性が異なります。それぞれの特性にそった構成を選択してください。 ◦ 使い捨てのサービスであれば、 1台ぽんとてれば良いし ◦ リージョン障害に備えるならクロスリージョンレプリカも選択肢に上がるでしょう ◦ 予算が許し、移行コスト払えるなら Spannerを使うという選択肢もあるでしょう • 今回はCloud SQLを例にしましたが、AWSでもAzureでも求められる可用性に対してどのような選択肢が取れるのか 把握してきましょう。 • それでは良いDBライフを!