SRGについてこれまでの取り組み技術記事採用情報
SRGについてこれまでの取り組み技術記事採用情報
HOME/技術記事/Aurora MySQL Version3への切り替えをもっと安全に進める方法

Aurora MySQL Version3への切り替えをもっと安全に進める方法

メディア統括本部 サービスリライアビリティグループ（SRG）の鬼海雄太（@fat47）です。
#SRG（Service Reliability Group）は、主に弊社メディアサービスのインフラ周りを横断的にサポートしており、既存サービスの改善や新規立ち上げ、OSS貢献などを行っているグループです。
本記事は、より慎重にAurora MySQL Version3へ切り替えを行っていく方法について説明しています。
 

Aurora MySQL v3への移行順調ですか

みなさん、Aurora MySQL v3への移行順調でしょうか。標準サポート終了までいよいよあと5ヶ月を切ったところですね。
私は順調だと思っていたんですが、ここにきてトラブルに遭遇したのでちょっと遅延しています。

今までのv3への切り替えの流れ

今までのv3への切り替えは概ね下記のような流れで実行していました。
  • 開発環境,ステージング環境でB/G Deployments作成して動作確認と切り替え
  • 本番環境でB/G Deployments作成
  • 本番アプリケーションの参照クエリ向き先をGreenリーダーエンドポイントへ変更して確認
  • 元のリーダーエンドポイントに戻す
  • B/G切り替え実行

v3へ参照向き先変更後トラブル発生

参照をv3に向けてから、とあるクエリのパフォーマンスが100倍以上悪くなり、
サービスが継続できないレベルになったので切り戻しを行いました。
 
詳しい話はまた別の記事でご紹介しようと思いますが、
v2クラスタで実行していた時と異なるインデックスが選択され、
v3クラスタでのクエリ実行がフルスキャンになっていたことが根本原因でした。
幸い、今回はアプリケーションの向き先変更だけでしたのですぐに切り戻すことができました。

トラブル後の切り替えの流れ

今回の切り替えの流れで良かった点とまずかった点は以下のとおりです。

よかった点

  • B/G切り替えは実施せず、まずはアプリケーションの参照だけ向き先変更して動作確認していた点

まずかった点

  • いきなり 全ての参照クエリをAurora MySQL Version3のエンドポイントに向けた点
  • ステージング環境で動作確認はしていたが、本番環境データでのv2クラスタとv3クラスタの実行計画比較ができていなかった点
 
これらのことを考慮して、特にユーザー影響が大きそうなクラスタに関しては、
次のような流れで切り替えを行っていくことにしました。
 
  1. v2クラスタのslow logのlong_query_timeを0か0.1に変更
  1. v2クラスタをクローン機能で複製したクラスタA,Bを作成して、クラスタBをv3にアップグレード
  1. percona-toolkitに含まれるpt-upgradeをクラスタAとクラスタBで実行
    1. 実行時は(1)で取得したスローログ元にクエリ実行させる
  1. B/G Deploymentsの作成
  1. (※) Route53で加重ルーティングするためのレコード作成
    1. BlueのリーダーエンドポイントとGreenのリーダーエンドポイントを10:1などの加重で登録
  1. アプリケーションの参照向き先を(5) で作成したレコードに向ける
    1. (※)Driverや実装の関係で加重レコードが利用できない場合は、アプリケーションサーバの一部のみクエリ向き先をGreenリーダーエンドポイントに変更するなどで対応する
  1. 参照先を元のリーダーエンドポイントに戻して、B/Gの切り替えを実行する
 

1) v2クラスタのslow logのlong_query_timeを0か0.1に変更

これは既存の環境でできるだけ多くのサンプルとなるクエリを集めるためです。
データ量がとても多くなってしまうので、数時間などある程度時間を決めて変更します。
 

2) v2クラスタをクローン機能で複製しクラスタA,Bを作成して、クラスタBをv3にアップグレード

後述のpt-upgradeをつかって検証するための環境を作成します。クラスタBのアップグレードはインプレースで行います。
B/G Deployments機能をまだ使わない理由は、pt-upgradeの実行は本番環境への実行は非推奨ですので、B/Gで作成した環境へ実行してしまうと本番のBlue環境へ検証クエリが飛んでしまう為です。
 

3) percona-toolkitに含まれるpt-upgradeをクラスタAとクラスタBで実行

pt-upgradeについての説明は、インターン生の方が記事にしてくれているのでそちらをご参照ください。
 
ざっくり説明しますと、2つのクラスタに対して同じクエリを実行してその実効速度を比較することができます。
実行するクエリもスローログから生成させることができます。
このツールを使って、(1)で取得した既存本番環境のクエリログからクエリを生成し、クラスタA,Bに同時に投げていきます。
そこで大幅に速度が低下したクエリがないかを確認していきます。
 

4) B/G Deploymentsの作成

速度低下したクエリがなかったり、改善することができたらB/G機能をつかってGreenクラスタを作成していきます。
 

5) ※ Route53で加重ルーティングするためのレコード作成

今回の失敗ですべての参照クエリをGreenクラスタに向けたことで、より影響が広範囲に出てしまいました。
できるだけユーザー影響の範囲を小さくするためにRoute53の加重ルーティングを使っていきます。
Blueのリーダーエンドポイントを加重10 、Greenのリーダーエンドポイントを加重1のように10:1の比率でCNAMEでレコードを登録していきます。
※がついている理由は、Driverや実装の関係で加重レコード経由だとクラスタエンドポイントにアクセスができない場合がある為です。
 

6) アプリケーションの参照向き先を(5) で作成したレコードに向ける

アプリケーションの向き先を変更します。
この時なにかの理由で加重ルーティングのレコードが利用できない場合は、一部のアプリケーションサーバのみをGreenエンドポイントに向けるなどの代替案でもOKです。
問題がなければ加重比率を徐々に上げていき、最終的にすべての参照クエリがGreenリーダーエンドポイントに向くようにします。
 

7) 参照先を元のリーダーエンドポイントに戻して、B/Gの切り替えを実行する

上記の確認を行いすべて問題がないことが確認できたら、アプリケーションの参照先を元のエンドポイントに戻し、B/G切り替えを実行して終了です。

終わりに

今回の事象はデータ量の少ない開発環境、ステージング環境では発生しなかった問題だったので、
本番のデータ量で確認を進めることの大切さを改めて認識しました。
手間は増えてしまいますが、より安全な方法でこれからもアップグレードを進めていきたいですね。
 
SRG では一緒に働く仲間を募集しています。 ご興味ありましたらぜひこちらからご連絡ください。
 
このエントリーをはてなブックマークに追加