Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

dekokun
June 08, 2022

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

Hatena Engineer Seminar #20 AWS Renovation 編 https://hatena.connpass.com/event/249039/ の発表資料です

dekokun

June 08, 2022
Tweet

More Decks by dekokun

Other Decks in Programming

Transcript

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

    View Slide

  2. dekokun
    ● SRE
    ● 1児の父
    2

    View Slide

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

    View Slide

  4. 4
    背景

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  10. 10
    アップグレードの方法

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  18. 18
    罠たち(本題)

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  36. 36
    binlog出力のためのF/O

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  40. 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 fill up.”
    https://aws.amazon.com/jp/blogs/database/performing-major-version-upgra
    des-for-amazon-aurora-mysql-with-minimum-downtime/ より

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  45. 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] ,”

    View Slide

  46. 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] ,”

    View Slide

  47. 47
    なんか足りないっすね

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide