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

Transcript

1. RDS Serverless のバージョ ンアップ作業の懺悔 ハッカーズチャンプルー2023
2. わたし 知花　司(ちばな　つかさ) @chibana_555 趣味: 全く効果のでない筋トレダイエット BP: 105kg, SQ: 160k, DL: 160kg 放送大学学生: 心理学や法学なども勉強中。 仕事は今は大阪の会社でテックリードしてます。
3. お家がきちんと建っているかな？って見に行くサービ スを提供しております。 3 防湿シートの破れ 土台アンカーボルトの芯ずれ Copyright© 2021 NEXT STAGE Co., Ltd. All Rights Reserved.
4. いつドラが鳴ってもいいように、最初にまとめの共有。 • ポスグレ(PostgreSQL)をメンテナンスしたらANALYZEを実行 しましょう(ドキュメント読みましょう) • IaCで環境作っていても全く同じ環境を再現できるとは限らな いので、環境は常に２つ以上作りましょう
5. ポスグレをメンテナンスしたらANALYZEを実行し ましょう(ドキュメント読みましょう)っていう話
6. 当初の構成 普通のJamStackな構成
7. 今 リリースから一年がたち、RDSの用途が多様化 RDSのリードレプリカが欲しくなってきた RDSがAurora Serverless v1 でした。
8. Aurora Serverless v1をv2の違い Aurora Serverless v1 リードレプリカ対応してない 論理レプリケーションも非対応
9. Aurora Serverless v1をv2にあげるためには 1. ポスグレをv2対応のバージョンに上げる 2. サーバーレスクラスターを通常のクラスターに変換する 3. Serverless v2インスタンスを追加してフェールオーバーさせる 4. クラスター変換で作成されたインスタンスを削除する
10. まずはポスグレのバージョンを上げないといけない
11. ポスグレをv2対応のバージョンへアップグレード 実行クエリの検証: ユニットテストの環境のDBをアップグレードして検証済み 性能: スロークエリのしきい値2秒をクリアしているので多少はおっけー アップグレードをどうやって実施するか？ 開発環境でやってみよー
12. ポスグレをv2対応の13.9にアップグレード マネコンでめっちゃカジュアルに実行できる 開発環境だし、ということでぽちぽちっと 数分で無事完了 念の為1ヶ月ほど様子見したが問題なし
13. ポスグレをv2対応の13.9にアップグレード 建築現場向け2Bのサービスなので夜間に利用している人はほぼ いない 数分だったらRDSのメンテナンス機能で夜間にやってしまえ。 えいやー
14. 翌朝
15. 本番環境が仮死状態に 早朝からスロークエリーのアラートが飛びまくり 30秒以上かかるクエリが多発 api gatewayのtime outでリクエストが切られてサービス停止状態 に
16. 原因と対応 テーブルの統計情報が全部飛んでた 手動でANALYZEを実行して解消
17. 統計情報引き継がれないの？ 統計情報はデータベースエンジンに格納されるのでメジャーアップ グレードしたら引き継がれない ポスグレをメンテナンスしたら手動でANALYZEしましょう AWSのマネコン操作だけではそこまではやってくれない
18. ドキュメントを読みましょう 以上の内容はすべてawsのドキュメントに書いてました。 ドキュメント読みましょう(自戒) https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/USER_ UpgradeDBInstance.PostgreSQL.html#USER_UpgradeDBInstance.PostgreSQL. MajorVersion
19. 環境は常に２つ以上作ろうっていう話 ドキュメント読んでもわかんないこともあるよ
20. Aurora Serverless v1をv2にあげるためには 1. ポスグレをv2対応のバージョンに上げる 2. サーバーレスクラスターを通常のクラスターに変換する 3. Serverless v2インスタンスを追加してフェールオーバーさせる 4. クラスター変換で作成されたインスタンスを削除する 1の作業は実施済み
21. 1の作業は実施済み 2 3 4
22. ポスグレ仮死状態の失敗を活かし・・・ ドキュメントは読みました。 cdkで環境管理しているので、検証用に環境を複製しました。 複製した環境で手順を検証しました。 ダウンタイムはフェールオーバーのタイミングで5秒程度。 利用者が急激に減る20時以降なら無視できると判断 開発環境でリハーサルを実施してみたら。。。
23. 最初のクラスター変換で失敗した クラスター変換が実行できない インスタンスの名前が長すぎるってエラー になる このステップでコケた
24. 最初のクラスター変換で失敗した クラスターの変換プロセスの中でふつうのRDS インスタンスが作成される RDSインスタンスは `{クラスター ID}-instance1` という名前が付与される インスタンス名コントロールできなくて詰んだ cdkで複製した環境での検証で気 づけなかったのはなぜ？
25. 稼働中の環境のクラスターIDが長い プロダクションの環境はcdk v1で構築され ていた サービスロンチ後にcdk v2にアップグレー ドしていた 複製はcdk v2で構築しているので、全く同 じ環境ではなかった 検証のために複製した環境 稼働中の環境
26. cdkで複製した環境での検証で気づけなかったのはなぜ？ プロダクションの環境はcdk v1で構築されていた サービス公開後にcdkをv2にアップグレードしていた 複製はcdk v2で構築しているので、全く同じ環境ではなかった cdk v1で構築したクラスターIDが長すぎた
27. じゃ、どうするの？ クラスターの変換プロセスの中でRDSインスタンスが作成される インスタンス名はコントロールできない、クラスターIDは変更できる 開発環境だし、やってみるかw えいやー (嫌な予感しかしないw)
28. クラスターID変更したらエンドポイントが変わった でしょうねw
29. 開発環境のRDSにアクセスしているサービスが全壊 プロジェクト関係者の皆さん、ごめんなさいw
30. さすがに計画停止が必要 影響を受けるすべてのサービスのconfigの修正が必要 影響をうけるサービスが10以上ある 各サービスのconfig修正して動作検証まで1時間はかかる サービス停止時間が長くなると休日深夜にやれって話になる(やりたくない) サービス停止は短いほうが良いよね
31. クラスター変換を無停止作業と計画停止作業に分割 事前準備(無停止、日中作業) RDSのエンドポイントにCNAMEを設定 事前準備で各サービスのDBアクセスをCNAME経由に変更 サービス停止作業日 クラスターID変更、CNAME張り替え、クラスター変換 サーバーレスインスタンス追加、フェールオーバー、クリーンアップ
32. RDSのアクセスを事前にDNS経由にしましたよ
33. サービス停止は10分程度で済みました。 サービス停止 クラスターID変更、CNAME張り替え、(CNAMEのTTLの時間待機) サービス再開 (とは言っても夜間なのでアクセスは非常に少ない) クラスター変換 (5秒程度の接続断) サーバーレスインスタンス追加 フェールオーバー (5秒程度の接続断) 不要インスタンスの削除
34. 最後にもう一回まとめ • ポスグレ(PostgreSQL)をメンテナンスしたらANALYZEを実行 しましょう • ドキュメント読みましょう • ドキュメント読んでも想定外は起きるので、環境は常に２つ以 上作りましょう
35. ご清聴ありがとうございました。 (たぶん、途中で時間切れでここまで辿り着けない)
36. 参考文献 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/