Amazon Aurora の v1 が EOL になるので 10 クラスタアップグレードして出てきたノウハウ

Slide 1

Slide 1 text

Amazon Aurora の v1 が EOL になるので 10クラスタアップグレードして出てきたノウハウ id:dekokun / @dekokun 2022/06/07 Hatena Engineer Seminar #20 「AWS Renovation 編」 1

Slide 2

Slide 2 text

dekokun ● SRE ● 1児の父 2

Slide 3

Slide 3 text

話すこと ● 背景 ● アップグレードの方法 ● 罠たち(本題) 3

Slide 4

Slide 4 text

4 背景

Slide 5

Slide 5 text

Aurora MySQL のv1 EOL ● 2023年2月28日にサポートを終了 ○ 2022年9月27日以降作成できなくなる ○ 2022年2月28日以降自動的にアップグレードされる 5

Slide 6

Slide 6 text

私の所属するチーム ● 名称：サービスプラットフォームチーム ● はてなの基盤となる多数のサービスを扱うチーム 6

Slide 7

Slide 7 text

チームの持つ多数のサービス ● はてなスターや人力検索はてな等、ユーザに直接触ってもらうサービス ● はてなのシステム内部から使われるマイクロサービス的なもの ● 完全に社内向けの小規模Webサービス 7

Slide 8

Slide 8 text

多数のサービス・多数のDB ● 多数のAurora ○ 計24クラスタ ○ v1(アップグレード対象)：今年頭時点で計20クラスタ 8

Slide 9

Slide 9 text

多数のサービス・多数のDB ● 現在、20クラスタ中12クラスタのアップグレードが完了 ● 今日は、これまでのアップグレードでハマった事象をメインにノウハウを紹介します 9

Slide 10

Slide 10 text

10 アップグレードの方法

Slide 11

Slide 11 text

インプレース vs Blue/Green ● インプレース ○ 既存のクラスタをAWSがアップグレードしてくれる ● Blue/Green ○ バージョンの新しいクラスタを作って古いクラスタからレプリケーションをしつつアプリケーションの参照するクラスタを切り替える 11

Slide 12

Slide 12 text

● ボタンポチでアップグレードが完了するので手順がシンプル ● データの量などでダウンタイムが決まる ○ ダウンタイムはだいたい10分〜(すごく時間がかかることあり。後述 12 インプレース

Slide 13

Slide 13 text

● 新クラスタを旧クラスタからcloneして生成 ● 旧クラスタから変更をレプリケーションしつつ新クラスタをアップグレード ● アプリケーションのDBの接続先を新クラスタに向ける 13 Blue/Green

Slide 14

Slide 14 text

https://aws.amazon.com/jp/blogs/database/performing-major-version-upgrades-for-a mazon-aurora-mysql-with-minimum-downtime/ より 14 Blue/Green

Slide 15

Slide 15 text

● ダウンタイムはアプリケーションのデプロイにかかる時間 + α ○ データ量その他にあまり依存しない 15 Blue/Green

Slide 16

Slide 16 text

インプレース vs Blue/Green ● 社内向け等で求める可用性が低いサービスの DBはコンソールからポチポチするだけのインプレース方式を採用しようと思ったが ○ 後述の罠により面倒になりすべてブルーグリーンに 16

Slide 17

Slide 17 text

インプレース vs Blue/Green ● ブルーグリーンの面倒なところはコマンド一発に自動化した ○ DBをcloneしてアップグレードしてeventからポジションを取得しレプリケーションをはるところ 17

Slide 18

Slide 18 text

18 罠たち(本題)

Slide 19

Slide 19 text

たくさんの罠たち ● インプレース方式では再起動が必須 ● インプレースなアップグレードに数時間 ● レプリケーションのポジションが不明 ● show innodb statusの出力が欠けてる ● binlog出力のためのF/O ○ F/O時にローカルストレージ枯渇の危険 19

Slide 20

Slide 20 text

20 インプレース方式では再起動が必須

Slide 21

Slide 21 text

インプレース方式では再起動が必須 ● インプレースアップグレード完了後はパラメータグループが適用されていない状態に ○ 手動で再起動が必要 21

Slide 22

Slide 22 text

インプレース方式では再起動が必須 ● “アップグレードプロセス中にカスタムパラメータグループを指定した場合は、アップグレード終了後にクラスターを手動で再起動する必要があります。” 22 https://docs.aws.amazon.com/ja_ jp/AmazonRDS/latest/AuroraUserGuide/Au roraMySQL.Updates.MajorVersionUpgrade.html より

Slide 23

Slide 23 text

インプレース方式では再起動が必須 ● このDBは“可用性が低くてもいいから”と何も考えずにポチッとupgradeしてから、手動で再起動するまでの書き込みでデータがおかしくなるかも？ 23

Slide 24

Slide 24 text

インプレース方式では再起動が必須 ○ アップグレード前後でアプリケーションを止めてアップグレード後に再起動すれば良い、が 24

Slide 25

Slide 25 text

インプレース方式では再起動が必須 ○ ボタンポチで済む(はずだった)のがインプレースのいいところだったのに… ○ 後述の”インプレースなアップグレードに数時間”も含めて面倒になってインプレース方式はやめた 25

Slide 26

Slide 26 text

26 インプレースなアップグレードに数時間

Slide 27

Slide 27 text

インプレースなアップグレードに数時間 27 ○ Blue/GreenでDBをcloneした直後にインプレースなアップグレードを行うと2回に1 回くらい、数時間かかる

Slide 28

Slide 28 text

インプレースなアップグレードに数時間 28 https://aws.amazon.com/jp/blogs/database/performing-major-version-upgrades-for-a mazon-aurora-mysql-with-minimum-downtime/ より

Slide 29

Slide 29 text

インプレースなアップグレードに数時間 29 ○ snapshotに時間がかかっている様子 ○ アップグレードの時間は保証されていない

Slide 30

Slide 30 text

インプレースなアップグレードに数時間 30 ○ Blue/Green方式中にアップグレードに時間がかかってもユーザ影響はないですしゆったり待ちましょう

Slide 31

Slide 31 text

31 レプリケーションのポジションが不明

Slide 32

Slide 32 text

レプリケーションのポジションが不明 32 ○ https://aws.amazon.com/jp/blogs/database/performing-major-version-upgrades-for-a mazon-aurora-mysql-with-minimum-downtime/ より

Slide 33

Slide 33 text

レプリケーションのポジションが不明 33 ○ cloneするとDBのeventとしてレプリケーションのポジションが出力される ○ そのポジションに対して以下打つ ■ ”call mysql.rds_set_external_master”

Slide 34

Slide 34 text

レプリケーションのポジションが不明 34 ○ たまにこのイベントが出力されない… ■ 当然レプリケーションが設定できない ○ 諦めてcloneし直しましょう

Slide 35

Slide 35 text

レプリケーションのポジションが不明 35 ○ こういうことがあるので、是非一通りの流れを自動化しておきましょう

Slide 36

Slide 36 text

36 binlog出力のためのF/O

Slide 37

Slide 37 text

binlog出力のためのF/O 37 https://aws.amazon.com/jp/blogs/database/performing-major-version-upgrades-for-a mazon-aurora-mysql-with-minimum-downtime/ より

Slide 38

Slide 38 text

binlog出力のためのF/O 38 ○ レプリケーションを行うということは binlogの出力が必要 ○ そのためにはDBの再起動が必要

Slide 39

Slide 39 text

binlog出力のためのF/O 39 ○ 直前にやろうとして慌てないように ○ 久しぶりのfailoverの際に注意すべきことがある

Slide 40

Slide 40 text

F/O時にローカルストレージ枯渇の危険 40 ○ version 2.10.2のchangelog ■ “Fixed an issue which can cause excessive internal logging when attempting zero downtime patching and restart causing local storage to ﬁll up.” https://aws.amazon.com/jp/blogs/database/performing-major-version-upgra des-for-amazon-aurora-mysql-with-minimum-downtime/ より

Slide 41

Slide 41 text

F/O時にローカルストレージ枯渇の危険 41 ○ readerインスタンスにてローカルストレージが枯渇することがあるとのこと ○ ローカルストレージが枯渇すると一時テーブルを作るようなクエリが失敗する

Slide 42

Slide 42 text

F/O時にローカルストレージ枯渇の危険 42 ○ ローカルストレージを監視しておこう ■ CloudWatchのFreeLocalStorage ■ Mackerelのrds.aurora.storage.free

Slide 43

Slide 43 text

43 show innodb statusの出力が欠けてる

Slide 44

Slide 44 text

show innodb statusの出力が欠けてる 44 ○ 構築したAurora V2クラスタにMackerelの mysql pluginを向けてメトリックを取得しようとしたらpanicした ○ 調査したところ、show innodb statusの出力が一部想定外

Slide 45

Slide 45 text

show innodb statusの出力が欠けてる 45 ○ 想定： “Pending normal aio reads: 0 [0, 0, 0, 0] , aio writes: 0 [0, 0, 0, 0] ,” ○ 実際：”Pending normal aio reads:, aio writes: [0, 0, 0, 0] ,”

Slide 46

Slide 46 text

show innodb statusの出力が欠けてる 46 ○ 想定： “Pending normal aio reads: 0 [0, 0, 0, 0] , aio writes: 0 [0, 0, 0, 0] ,” ○ 実際：”Pending normal aio reads:, aio writes: [0, 0, 0, 0] ,”

Slide 47

Slide 47 text

47 なんか足りないっすね

Slide 48

Slide 48 text

show innodb statusの出力が欠けてる 48 ○ v2の最近のバージョンで起きてるっぽい ○ AWSのサポートに伝えた ○ aio readsが空でもpluginがpanicしないようにmackerelチームに修正してもらった ■ 当然ながら値は取れてない ■ AWSの修正を応援しています

Slide 49

Slide 49 text

49 もうこれ以上罠は無いと信じたい！残り8クラスタやっていくぞ！

Slide 50

Slide 50 text

50 みなさまも楽しい Aurora アップグレードライフを！