RDS Serverless のバージョンアップ作業の懺悔

RDS Serverless のバージョンアップ作業の懺悔ハッカーズチャンプルー2023

わたし知花　司(ちばな　つかさ) @chibana_555 趣味: 全く効果のでない筋トレダイエット BP: 105kg, SQ: 160k, DL:
160kg 放送大学学生: 心理学や法学なども勉強中。仕事は今は大阪の会社でテックリードしてます。

いつドラが鳴ってもいいように、最初にまとめの共有。 • ポスグレ(PostgreSQL)をメンテナンスしたらANALYZEを実行しましょう(ドキュメント読みましょう) • IaCで環境作っていても全く同じ環境を再現できるとは限らないので、環境は常に２つ以上作りましょう

ポスグレをメンテナンスしたらANALYZEを実行しましょう(ドキュメント読みましょう)っていう話

当初の構成普通のJamStackな構成

今リリースから一年がたち、RDSの用途が多様化 RDSのリードレプリカが欲しくなってきた RDSがAurora Serverless v1 でした。

Aurora Serverless v1をv2の違い Aurora Serverless v1 リードレプリカ対応してない論理レプリケーションも非対応

Aurora Serverless v1をv2にあげるためには 1. ポスグレをv2対応のバージョンに上げる 2. サーバーレスクラスターを通常のクラスターに変換する 3. Serverless v2インスタンスを追加してフェールオーバーさせる
4. クラスター変換で作成されたインスタンスを削除する

まずはポスグレのバージョンを上げないといけない

ポスグレをv2対応のバージョンへアップグレード実行クエリの検証: ユニットテストの環境のDBをアップグレードして検証済み性能: スロークエリのしきい値2秒をクリアしているので多少はおっけーアップグレードをどうやって実施するか？開発環境でやってみよー

ポスグレをv2対応の13.9にアップグレードマネコンでめっちゃカジュアルに実行できる開発環境だし、ということでぽちぽちっと数分で無事完了念の為1ヶ月ほど様子見したが問題なし

ポスグレをv2対応の13.9にアップグレード建築現場向け2Bのサービスなので夜間に利用している人はほぼいない数分だったらRDSのメンテナンス機能で夜間にやってしまえ。えいやー

翌朝

本番環境が仮死状態に早朝からスロークエリーのアラートが飛びまくり 30秒以上かかるクエリが多発 api gatewayのtime outでリクエストが切られてサービス停止状態に

原因と対応テーブルの統計情報が全部飛んでた手動でANALYZEを実行して解消

統計情報引き継がれないの？統計情報はデータベースエンジンに格納されるのでメジャーアップグレードしたら引き継がれないポスグレをメンテナンスしたら手動でANALYZEしましょう AWSのマネコン操作だけではそこまではやってくれない

ドキュメントを読みましょう以上の内容はすべてawsのドキュメントに書いてました。ドキュメント読みましょう(自戒) https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/USER_ UpgradeDBInstance.PostgreSQL.html#USER_UpgradeDBInstance.PostgreSQL. MajorVersion

環境は常に２つ以上作ろうっていう話ドキュメント読んでもわかんないこともあるよ

Aurora Serverless v1をv2にあげるためには 1. ポスグレをv2対応のバージョンに上げる 2. サーバーレスクラスターを通常のクラスターに変換する 3. Serverless v2インスタンスを追加してフェールオーバーさせる
4. クラスター変換で作成されたインスタンスを削除する 1の作業は実施済み

1の作業は実施済み 2 3 4

ポスグレ仮死状態の失敗を活かし・・・ドキュメントは読みました。 cdkで環境管理しているので、検証用に環境を複製しました。複製した環境で手順を検証しました。ダウンタイムはフェールオーバーのタイミングで5秒程度。利用者が急激に減る20時以降なら無視できると判断開発環境でリハーサルを実施してみたら。。。

最初のクラスター変換で失敗したクラスター変換が実行できないインスタンスの名前が長すぎるってエラーになるこのステップでコケた

最初のクラスター変換で失敗したクラスターの変換プロセスの中でふつうのRDS インスタンスが作成される RDSインスタンスは `{クラスター ID}-instance1` という名前が付与されるインスタンス名コントロールできなくて詰んだ cdkで複製した環境での検証で気づけなかったのはなぜ？

稼働中の環境のクラスターIDが長いプロダクションの環境はcdk v1で構築されていたサービスロンチ後にcdk v2にアップグレードしていた複製はcdk v2で構築しているので、全く同じ環境ではなかった
検証のために複製した環境稼働中の環境

cdkで複製した環境での検証で気づけなかったのはなぜ？プロダクションの環境はcdk v1で構築されていたサービス公開後にcdkをv2にアップグレードしていた複製はcdk v2で構築しているので、全く同じ環境ではなかった cdk v1で構築したクラスターIDが長すぎた

じゃ、どうするの？クラスターの変換プロセスの中でRDSインスタンスが作成されるインスタンス名はコントロールできない、クラスターIDは変更できる開発環境だし、やってみるかw えいやー (嫌な予感しかしないw)

クラスターID変更したらエンドポイントが変わったでしょうねw

開発環境のRDSにアクセスしているサービスが全壊プロジェクト関係者の皆さん、ごめんなさいw

さすがに計画停止が必要影響を受けるすべてのサービスのconfigの修正が必要影響をうけるサービスが10以上ある各サービスのconfig修正して動作検証まで1時間はかかるサービス停止時間が長くなると休日深夜にやれって話になる(やりたくない) サービス停止は短いほうが良いよね

クラスター変換を無停止作業と計画停止作業に分割事前準備(無停止、日中作業) RDSのエンドポイントにCNAMEを設定事前準備で各サービスのDBアクセスをCNAME経由に変更サービス停止作業日クラスターID変更、CNAME張り替え、クラスター変換サーバーレスインスタンス追加、フェールオーバー、クリーンアップ

RDSのアクセスを事前にDNS経由にしましたよ

サービス停止は10分程度で済みました。サービス停止クラスターID変更、CNAME張り替え、(CNAMEのTTLの時間待機) サービス再開 (とは言っても夜間なのでアクセスは非常に少ない) クラスター変換 (5秒程度の接続断) サーバーレスインスタンス追加フェールオーバー (5秒程度の接続断)
不要インスタンスの削除

最後にもう一回まとめ • ポスグレ(PostgreSQL)をメンテナンスしたらANALYZEを実行しましょう • ドキュメント読みましょう • ドキュメント読んでも想定外は起きるので、環境は常に２つ以上作りましょう

ご清聴ありがとうございました。 (たぶん、途中で時間切れでここまで辿り着けない)

参考文献 Aurora PostgreSQL の PostgreSQL DB エンジンのアップグレード https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2.upgrade.html Aurora Serverless
v2 の開始方法 https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2.upgrade.html よくお世話になっている某ブログ https://dev.classmethod.jp/articles/moving-from-aurora-serverless-v1-tov2/

RDS Serverless のバージョンアップ作業の懺悔

RDS Serverless のバージョンアップ作業の懺悔

tchibana

More Decks by tchibana

Other Decks in Technology

Featured

Transcript