Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Amazon Aurora の v1 が EOL になるので 10 クラスタアップグレードし...
Search
dekokun
June 08, 2022
Programming
0
2.4k
Amazon Aurora の v1 が EOL になるので 10 クラスタアップグレードして出てきたノウハウ
Hatena Engineer Seminar #20 AWS Renovation 編
https://hatena.connpass.com/event/249039/
の発表資料です
dekokun
June 08, 2022
Tweet
Share
More Decks by dekokun
See All by dekokun
フルCDNアーキテクチャ実験 / Minami Aoyama Night #1
dekokun
5
18k
東京にいながら仕事のほとんどを京都のエンジニアと一緒にしている私のリモートワークの話 / Hatena Engineer Seminar #6
dekokun
3
11k
はてなでの サービス信頼性向上のための 取り組み事例
dekokun
15
5.8k
Other Decks in Programming
See All in Programming
Hack Claude Code with Claude Code
choplin
4
2.1k
RailsGirls IZUMO スポンサーLT
16bitidol
0
190
レベル1の開発生産性向上に取り組む − 日々の作業の効率化・自動化を通じた改善活動
kesoji
0
220
Composerが「依存解決」のためにどんな工夫をしているか #phpcon
o0h
PRO
1
260
20250704_教育事業におけるアジャイルなデータ基盤構築
hanon52_
5
790
ふつうの技術スタックでアート作品を作ってみる
akira888
1
850
プロダクト志向なエンジニアがもう一歩先の価値を目指すために意識したこと
nealle
0
130
Porting a visionOS App to Android XR
akkeylab
0
460
初学者でも今すぐできる、Claude Codeの生産性を10倍上げるTips
s4yuba
16
11k
ソフトウェア品質を数字で捉える技術。事業成長を支えるシステム品質の マネジメント
takuya542
1
13k
AI駆動のマルチエージェントによる業務フロー自動化の設計と実践
h_okkah
0
150
なぜ適用するか、移行して理解するClean Architecture 〜構造を超えて設計を継承する〜 / Why Apply, Migrate and Understand Clean Architecture - Inherit Design Beyond Structure
seike460
PRO
3
770
Featured
See All Featured
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
281
13k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
53
2.9k
jQuery: Nuts, Bolts and Bling
dougneiner
63
7.8k
The MySQL Ecosystem @ GitHub 2015
samlambert
251
13k
RailsConf 2023
tenderlove
30
1.1k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
126
53k
Being A Developer After 40
akosma
90
590k
The Power of CSS Pseudo Elements
geoffreycrofte
77
5.9k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
31
2.4k
BBQ
matthewcrist
89
9.7k
How to Ace a Technical Interview
jacobian
278
23k
GraphQLの誤解/rethinking-graphql
sonatard
71
11k
Transcript
Amazon Aurora の v1 が EOL になるので 10クラスタアップグレードして 出てきたノウハウ id:dekokun
/ @dekokun 2022/06/07 Hatena Engineer Seminar #20 「AWS Renovation 編」 1
dekokun • SRE • 1児の父 2
話すこと • 背景 • アップグレード の方法 • 罠たち(本題) 3
4 背景
Aurora MySQL のv1 EOL • 2023年2月28日にサポートを終了 ◦ 2022年9月27日以降作成できなくなる ◦ 2022年2月28日以降自動的にアップグレードされる
5
私の所属するチーム • 名称:サービスプラットフォームチーム • はてなの基盤となる多数のサービスを扱う チーム 6
チームの持つ多数のサービス • はてなスターや人力検索はてな等、ユーザに 直接触ってもらうサービス • はてなのシステム内部から使われるマイクロ サービス的なもの • 完全に社内向けの小規模Webサービス 7
多数のサービス・多数のDB • 多数のAurora ◦ 計24クラスタ ◦ v1(アップグレード対象):今年頭時点で計20クラスタ 8
多数のサービス・多数のDB • 現在、20クラスタ中12クラスタのアップグ レードが完了 • 今日は、これまでのアップグレードでハマっ た事象をメインにノウハウを紹介します 9
10 アップグレードの方法
インプレース vs Blue/Green • インプレース ◦ 既存のクラスタをAWSがアップグレードしてくれる • Blue/Green ◦
バージョンの新しいクラスタを作って古いクラスタか らレプリケーションをしつつアプリケーションの参照 するクラスタを切り替える 11
• ボタンポチでアップグレードが完了するので 手順がシンプル • データの量などでダウンタイムが決まる ◦ ダウンタイムはだいたい10分〜(すごく時間がかかる ことあり。後述 12 インプレース
• 新クラスタを旧クラスタからcloneして生成 • 旧クラスタから変更をレプリケーションしつ つ新クラスタをアップグレード • アプリケーションのDBの接続先を新クラスタ に向ける 13 Blue/Green
https://aws.amazon.com/jp/blogs/database/performing-major-version-upgrades-for-a mazon-aurora-mysql-with-minimum-downtime/ より 14 Blue/Green
• ダウンタイムはアプリケーションのデプロイ にかかる時間 + α ◦ データ量その他にあまり依存しない 15 Blue/Green
インプレース vs Blue/Green • 社内向け等で求める可用性が低いサービスの DBはコンソールからポチポチするだけのイン プレース方式を採用しようと思ったが ◦ 後述の罠により面倒になりすべてブルーグリーンに 16
インプレース vs Blue/Green • ブルーグリーンの面倒なところはコマンド一 発に自動化した ◦ DBをcloneしてアップグレードしてeventからポジ ションを取得しレプリケーションをはるところ 17
18 罠たち(本題)
たくさんの罠たち • インプレース方式では再起動が必須 • インプレースなアップグレードに数時間 • レプリケーションのポジションが不明 • show innodb
statusの出力が欠けてる • binlog出力のためのF/O ◦ F/O時にローカルストレージ枯渇の危険 19
20 インプレース方式では 再起動が必須
インプレース方式では再起動が必須 • インプレースアップグレード完了後はパラ メータグループが適用されていない状態に ◦ 手動で再起動が必要 21
インプレース方式では再起動が必須 • “アップグレードプロセス中にカスタムパラ メータグループを指定した場合は、アップグ レード終了後にクラスターを手動で再起動す る必要があります。” 22 https://docs.aws.amazon.com/ja_ jp/AmazonRDS/latest/AuroraUserGuide/Au roraMySQL.Updates.MajorVersionUpgrade.html
より
インプレース方式では再起動が必須 • このDBは“可用性が低くてもいいから”と何も 考えずにポチッとupgradeしてから、手動で 再起動するまでの書き込みでデータがおかし くなるかも? 23
インプレース方式では再起動が必須 ◦ アップグレード前後でアプリケーションを 止めてアップグレード後に再起動すれば良 い、が 24
インプレース方式では再起動が必須 ◦ ボタンポチで済む(はずだった)のがインプ レースのいいところだったのに… ◦ 後述の”インプレースなアップグレードに 数時間”も含めて面倒になってインプレー ス方式はやめた 25
26 インプレースな アップグレードに数時間
インプレースなアップグレードに数時間 27 ◦ Blue/GreenでDBをcloneした直後にイン プレースなアップグレードを行うと2回に1 回くらい、数時間かかる
インプレースなアップグレードに数時間 28 https://aws.amazon.com/jp/blogs/database/performing-major-version-upgrades-for-a mazon-aurora-mysql-with-minimum-downtime/ より
インプレースなアップグレードに数時間 29 ◦ snapshotに時間がかかっている様子 ◦ アップグレードの時間は保証されていない
インプレースなアップグレードに数時間 30 ◦ Blue/Green方式中にアップグレードに時 間がかかってもユーザ影響はないですし ゆったり待ちましょう
31 レプリケーションの ポジションが不明
レプリケーションのポジションが不明 32 ◦ https://aws.amazon.com/jp/blogs/database/performing-major-version-upgrades-for-a mazon-aurora-mysql-with-minimum-downtime/ より
レプリケーションのポジションが不明 33 ◦ cloneするとDBのeventとしてレプリケー ションのポジションが出力される ◦ そのポジションに対して以下打つ ▪ ”call mysql.rds_set_external_master”
レプリケーションのポジションが不明 34 ◦ たまにこのイベントが出力されない… ▪ 当然レプリケーションが設定できない ◦ 諦めてcloneし直しましょう
レプリケーションのポジションが不明 35 ◦ こういうことがあるので、是非一通りの流 れを自動化しておきましょう
36 binlog出力のためのF/O
binlog出力のためのF/O 37 https://aws.amazon.com/jp/blogs/database/performing-major-version-upgrades-for-a mazon-aurora-mysql-with-minimum-downtime/ より
binlog出力のためのF/O 38 ◦ レプリケーションを行うということは binlogの出力が必要 ◦ そのためにはDBの再起動が必要
binlog出力のためのF/O 39 ◦ 直前にやろうとして慌てないように ◦ 久しぶりのfailoverの際に注意すべきこと がある
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/ より
F/O時にローカルストレージ枯渇の危険 41 ◦ readerインスタンスにてローカルストレー ジが枯渇することがあるとのこと ◦ ローカルストレージが枯渇すると一時テー ブルを作るようなクエリが失敗する
F/O時にローカルストレージ枯渇の危険 42 ◦ ローカルストレージを監視しておこう ▪ CloudWatchのFreeLocalStorage ▪ Mackerelのrds.aurora.storage.free
43 show innodb statusの 出力が欠けてる
show innodb statusの出力が欠けてる 44 ◦ 構築したAurora V2クラスタにMackerelの mysql pluginを向けてメトリックを取得し ようとしたらpanicした
◦ 調査したところ、show innodb statusの 出力が一部想定外
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] ,”
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] ,”
47 なんか足りないっすね
show innodb statusの出力が欠けてる 48 ◦ v2の最近のバージョンで起きてるっぽい ◦ AWSのサポートに伝えた ◦ aio
readsが空でもpluginがpanicしないよ うにmackerelチームに修正してもらった ▪ 当然ながら値は取れてない ▪ AWSの修正を応援しています
49 もうこれ以上 罠は無いと信じたい! 残り8クラスタ やっていくぞ!
50 みなさまも 楽しい Aurora アップグレードライフを!