Cloud SQL フェイルオーバーのテスト: 何から始めるべきか
Google Cloud Japan Team
※この投稿は米国時間 2021 年 3 月 9 日に、Google Cloud blog に投稿されたものの抄訳です。
Cloud SQL の高可用性セットアップにおける重要な考慮事項として、プライマリ インスタンスが応答不能になった場合に、プライマリ インスタンスからスタンバイ インスタンスにフェイルオーバーする機能が挙げられます。意図的にフェイルオーバーを開始して挙動を観察しようという考えは、パラダイム シフトと言えるかもしれません。しかし、データベースに対してこの類のテストを実施して、ゾーン フェイルオーバーの場合にアプリケーションが復元できるかを確認することは大いに有効です。目的が一般的なパフォーマンス テストやピークイベントの特定の準備のいずれであってもかまいません。さらに、Cloud SQL インスタンスで使用されるリージョン永続ディスク（RePD）は、リージョン内の 2 つのゾーン間でデータをブロックレベルで同期的に複製します。つまり、すべての書き込みは、プライマリ インスタンスに加えてスタンバイ インスタンスに対しても自動的に行われます。これにより、ダウンタイムが減り可用性が向上しますが、フェイルオーバーの復旧時間と復元力をテストして、アプリケーションがバックアップ インスタンスにできる限りスムーズに接続できるようにする必要もあります。フェイルオーバーをテストしてアプリケーションのパフォーマンスを最適化する際に、モニタリングする主な指標をいくつか確認してみましょう。たとえば、データベースの接続数、秒間クエリ数、インスタンスの CPU とメモリの使用率、読み取り / 書き込み IOPS、ピーク時のレプリケーション ラグなどを調べます。
Cloud SQL インスタンスを実際にフェイルオーバー テストする方法
ステップ 1: テスト用のインスタンスを選択する
Cloud SQL インスタンスのインベントリを確認し、平均的なワークロードを反映するインスタンスから始めます。はじめから最大規模のインスタンスをテストしないでください。代わりに、テーブルやレコードの数など、環境で最も一般的なマシンのサイズと仕様を表したインスタンスを選択します。
本番環境の負荷をシミュレートできるインスタンスを使用し、テスト結果が有意義になるようにします。
インスタンスのリージョン ロケーションにも配慮します。すべての主要リージョンでフェイルオーバー テストプロセスを繰り返すことをおすすめします。
ステップ 2: テストの実施方法を決定する
フェイルオーバー時にテストする特定のデータ入力とシナリオを理解することが重要です。たとえば、さまざまな負荷サイズでフェイルオーバーをテストし、動作の変化を理解することをおすすめします。
T シャツのサイズの観点でとらえるとわかりやすいかもしれません。平均的なワークロードを考慮し、それに比べて小、中、大の規模の負荷でフェイルオーバーをテストします。フェイルオーバー テストは負荷テストとは違い、さまざまな負荷の下でフェイルオーバーの動作を確認することが重要です。
フェイルオーバー テストのバリエーションの例:
非ピーク時の負荷
ピーク時の負荷
異なるリージョンのインスタンス
さまざまなマシンサイズ
さまざまなワークロード（各種の読み取り、書き込み、挿入、更新など）
ステップ 3: フェイルオーバー テストを実施し、監視の準備をする
フェイルオーバー テストを最初から最後まで実施し、結果を観察するのに十分な時間を確保します。フェイルオーバー テストの前後や最中の重要な動作とその結果の指標を完全にキャプチャするには、数時間余裕を見ておくことがおすすめです。
フェイルオーバーをテストする前に、主な指標のベースラインをキャプチャして、比較対象を把握します。
手動フェイルオーバーは GCP Console またはコマンドラインから開始できます。
キャプチャする指標の例:
全般:
データベースの接続数 - フェイルオーバーを開始する前に特定のプロセスを自動的にシャットダウンするなどして、接続数を制御できます（database/network/connections など）。
秒間クエリ数（QPS）
インスタンスの CPU 使用率（database/cpu/utilization など）
インスタンスのメモリ使用率（database/memory/utilization など）
読み取り / 書き込み IOPS（database/disk/read_ops_count、database/disk/write_ops_count など）
ピーク時のレプリケーション ラグ（MySQL Seconds_Behind_Master 指標や Postgres replica_byte_lag など）
MySQL:
MySQL グローバル統計情報
MySQL の Undo スペース
InnoDB ダーティページ（database/mysql/innodb_buffer_pool_pages_dirty など）
InnoDB フリーページ（database/mysql/innodb_buffer_pool_pages_free など）
MySQL スロー クエリログの数
Postgres:
パーティション分割テーブル、テーブルスペース
共有ブロックのキャッシュ アクセス（database/postgresql/insights/aggregate/shared_blk_access_coun など）
有効なキャッシュ サイズ
VACUUM オペレーション
全体の結果:
フェイルオーバーの時間
復旧時間
データベース / アプリケーションの全体的なパフォーマンス（フェイルオーバーとフェイルバックの両方など）
ステップ 4: 確認できた内容を検討する
どのログや指標が役立ちましたか。Google Cloud のオペレーション スイートに設定して、データベース インスタンスやアプリケーションの動作の理解を深められる追加のログや指標はありますか。
リードレプリカはフェイルオーバー トラフィックのオーバーフローをどのように処理しましたか。追加のリードレプリカを作成して、プライマリ インスタンスからの負荷を処理できますか。
自動フェイルオーバーと手動フェイルオーバーでアプリケーションの動作に違いはありますか。
高可用性インスタンスにおけるプライマリ インスタンスからスタンバイ インスタンスへのゾーン フェイルオーバーは、リージョン間の障害復旧とは異なります。DR 戦略の一環として、リージョン フェイルオーバーのテストもご検討ください。
一般的なパフォーマンスに関するその他のヒント
データベースの内部キャッシュは、読み取りパフォーマンスに不可欠な場合があります。Cloud SQL for MySQL と Postgres のいずれを使用する場合でも、どのようにインスタンスがデータをキャッシュし、キャッシュしたデータから読み取っているかを理解するようにしてください。たとえば、MySQL の InnoDB エンジンがバッファプールをキャッシュする方法を把握します。
一般には CPU、RAM、ディスクに十分な余裕のあるインスタンス サイズを選択します。ディスクサイズが大きいほど、IOPS の能力が高くなります。
同様に、並べ替えや正規表現など、CPU 使用率が非常に高いクエリをインスタンスで実行する場合は、利用するマシンサイズを増やす必要があります。
接続が失われた場合にアプリケーションがどのように応答するかを理解します。インスタンスを再起動してこのテストを行うこともできます。
コンソールの Cloud SQL でお試しになるか、Cloud SQL Insights のドキュメントをご覧になり、このようなシナリオでパフォーマンスの問題が生じたときのトラブルシューティングにお役立てください。
-Google Cloud カスタマー エンジニア Whitley Talmadge
