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
MySQL on IaaSの運用あれやこれや
Search
yoku0825
December 03, 2020
Technology
2
770
MySQL on IaaSの運用あれやこれや
2020/12/03 dbts2020
https://www.db-tech-showcase.com/dbts/2020/online/schedule
yoku0825
December 03, 2020
Tweet
Share
More Decks by yoku0825
See All by yoku0825
HeatWave をオンプレの MySQL と同じように使おうとしてみた!
yoku0825
0
120
MySQLのロックの種類とその競合
yoku0825
10
4.1k
MySQL 8.4 LTS が あらわれた
yoku0825
2
1.8k
ぼくたちはMySQL 8.1とどう生きるか
yoku0825
6
2.6k
2022年のMySQLerが20年前のMySQL 4.0に触ると何が起きるか
yoku0825
0
500
テストデータが偏るということについて
yoku0825
3
8.8k
MySQLが得意なこと、不得意なこと(仮)
yoku0825
12
14k
MySQLとインデックスとPHPer
yoku0825
8
8.2k
MySQLとインデックスと私
yoku0825
82
60k
Other Decks in Technology
See All in Technology
Global Azure2025(GitHub Copilot ハンズオン)
tomokusaba
0
220
DynamoDB のデータを QuickSight で可視化する際につまづいたこと/stumbling-blocks-when-visualising-dynamodb-with-quicksight
emiki
0
100
より良い開発者体験を実現するために~開発初心者が感じた生成AIの可能性~
masakiokuda
0
230
フルカイテン株式会社 エンジニア向け採用資料
fullkaiten
0
5.5k
Mastraに入門してみた ~AWS CDKを添えて~
tsukuboshi
0
380
10分で学ぶ、RAGの仕組みと実践
supermarimobros
0
790
Azure × MCP 入門
ry0y4n
4
690
AI 코딩 에이전트 더 똑똑하게 쓰기
nacyot
0
490
AIでめっちゃ便利になったけど、結局みんなで学ぶよねっていう話
kakehashi
PRO
1
530
読んで学ぶ Amplify Gen2 / Amplify と CDK の関係を紐解く #jawsug_tokyo
tacck
PRO
1
300
勝手に!深堀り!Cloud Run worker pools / Deep dive Cloud Run worker pools
iselegant
4
630
GraphQLを活用したリアーキテクチャに対応するSLI/Oの再設計
coconala_engineer
0
200
Featured
See All Featured
What's in a price? How to price your products and services
michaelherold
245
12k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
507
140k
Testing 201, or: Great Expectations
jmmastey
42
7.5k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
194
16k
How To Stay Up To Date on Web Technology
chriscoyier
790
250k
The Invisible Side of Design
smashingmag
299
50k
Optimizing for Happiness
mojombo
378
70k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
34
2.9k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
227
22k
StorybookのUI Testing Handbookを読んだ
zakiyama
30
5.7k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
3.8k
Build your cross-platform service in a week with App Engine
jlugia
230
18k
Transcript
MySQL on IaaSの運用あれやこれや マネージドでないことを楽しむ 2020/12/03 yoku0825 db tech showcase ONLINE
2020
セッション概要(これ登録した人は見えたのかな…) - IaaS上でMySQLを運用して上手く行ったことやハマったことを紹介します - オンプレに比べて便利なこと不便なこと - マネージドに比べて便利なこと不便なこと - 「IaaSに適したMySQL」の話ではなく、「組み合わせて、上手くやりたい」経験談です 大事なことはだいたい
@ts4th の資料に書いてある さいきんの InnoDB Adaptive Flushing (仮) ‐ さいきんのMySQLに関する取り組み(仮) ‐ 1/44
\こんにちは/ yoku0825@とある企業のDBA オラクれない ‐ ポスグれない ‐ マイエスキューエる ‐ 生息域 Twitter:
@yoku0825 ‐ Blog: 日々の覚書 ‐ 日本MySQLユーザ会 ‐ MySQL Casual ‐ 2/44
MySQL on IaaS IaaSの定義とかよく知らないんですけど、このセッションの中では「OSより下(だ け)を提供してくれる何か」のつもりでいます 3/44
vs. マネージド 主に名前解決ベースのHAが提供される 秒単位のPITRが提供される 少なくともこれらが自前で提供できないなら、 MySQL on IaaS は「楽しめない」 えっこれらが提供されてないマネージドMySQLがあるんですか!?
‐ 4/44
vs. 物理マシン CPUバウンドなワークロードでは熱とか電源がちゃんとしてればオーバークロック が有効 ローカルストレージの書き込みに失敗すれば綺麗にmysqldがアボートしたり綺麗 にOSリブートかかったりする 書き込みに失敗したことが返らないストレージというものはかなり厄介 5/44
IaaSのいいところ だいたいLANが速い だいたいインターネットへの送信は帯域幅ではなくデータ量で線形に課金 だいたいストレージは1GB~100GB単位で増やせる だいたい「野良インスタンス」があれば気付く 6/44
7/44
(・∀・)ゞ あんまり データベースとして 面白味はない… 8/44
( ー`дー´) だがDBA としては嬉しい 9/44
の前に俺が好 んで作る構成 10/44
俺が好んで作る構成 11/44
俺が好んで作る構成 サービス用のインスタンスとは別にバックアップ専用のレプリカを作る 大体「セグメントごとに1つ」くらいのペース ‐ バックアップレプリカは好きな時に止めたり止めなかったりして好きにバックアッ プが取れる サービス用のレプリカを増設する時も、時間によらず「バックアップレプリカを止めてデータ を転送するだけ」で構築できる ‐ かつてはここからファイルサーバーやテープドライブに転送していた。今は某オブ
ジェクトストレージに送るのが主流 12/44
俺が好んで作る構成 サービス用のインスタンスとは別にバックアップ専用のレプリカを作る 大体「セグメントごとに1つ」くらいのペース ‐ バックアップレプリカは好きな時に止めたり止めなかったりして好きにバックアッ プが取れる サービス用のレプリカを増設する時も、時間によらず「バックアップレプリカを止めてデータ を転送するだけ」で構築できる ‐ かつてはここからファイルサーバーやテープドライブに転送していた。今は某オブ
ジェクトストレージに送るのが主流 13/44
LANが速くて嬉しいケース 力勝負の rsync はやっぱりネットワークバウンド 300GBのデータディレクトリを転送するには1Gbpsで40分、10Gbpsなら4分(ワ イヤースピード出ればだけど) 間に pzstd 噛ませて転送の容量を下げるとスピードアップできるけどCPUにもよる dest_machine$
nc -l 0.0.0.0 10000 | pzstd -dc | tar -C /data/mysql -x src_machine$ tar -C /data -c mysql | pv | pzstd -c | nc dest_machine 10000 14/44
LANが速くて嬉しいケース 地味に pt-online-schema-change や gh-ost は大容量のバイナリログを吐く 特に gh-ost は binlog_row_image
= FULL を要求するので「もとのテーブルの倍近く」のバイナ リログを(既存のトラフィックに追加で)サクッと吐く ‐ 非同期レプリケーションの転送を律速するパラメーターは特に存在しないので、ツール側でも sleepするけど心配がないくらいまで帯域が大きいと嬉しい ‐ 15/44
俺が好んで作る構成 16/44
俺が好んで作る構成 サービス用のインスタンスとは別にバックアップ専用のレプリカを作る 大体「セグメントごとに1つ」くらいのペース ‐ バックアップレプリカは好きな時に止めたり止めなかったりして好きにバックアッ プが取れる サービス用のレプリカを増設する時も、時間によらず「バックアップレプリカを止めてデータ を転送するだけ」で構築できる ‐ かつてはここからファイルサーバーやテープドライブに転送していた。
今は某オ ブジェクトストレージに送るのが主流 17/44
インターネットへの送信がデータ量に線形に課金で嬉しいケース 帯域幅95%ile方式の課金だと「バックアップ&外部転送」を特定の時間に重ねる とバンと跳ね上がる可能性がある 転送バイト数よりも転送に使う帯域に気を使わないといけないのがストレス ‐ 複数のバックアップレプリカから同時に転送が走らないようにしたり ‐ 転送帯域に制限をかけたらかけたでバックアップが長引いたり ‐ 最初から「どんな速度で送ろうと、100GBは100GBぶんの料金」なので余計な駆
け引き(?)が要らない あとは「だいたい線形」なので、95%ileみたいに桁が一つ変わることはない ‐ 18/44
オブジェクトストレージ vs. ブロックストレージ 前者の方が幾分お安くつく イメージ的には物理マシンの HDD vs. SSD くらい? ‐
長期保管用にはオブジェクトストレージ, 短期保管(数日ぶんを保持する用途)には ブロックストレージ(あるいは物理マシンのHDD)とやっていたけど、それもオブ ジェクトストレージに載せた方が安くつく? ⇒安くつきました ‐ 19/44
俺が好んで作る構成 20/44
俺が好んで作る構成 サービス用のインスタンスとは別にバックアップ専用のレプリカを作る 大体「セグメントごとに1つ」くらいのペース ‐ バックアップレプリカは好きな時に止めたり止めなかったりして好きにバックアッ プが取れる サービス用のレプリカを増設する時も、時間によらず「バックアップレプリカを止めてデータ を転送するだけ」で構築できる ‐ かつてはここからファイルサーバーやテープドライブに転送していた。今は某オブ
ジェクトストレージに送るのが主流 21/44
ストレージが小単位で増やせるのが嬉しいケース バックアップレプリカはサービストラフィックを一切受け付けないので、サービス 用mysqldに比べて小さいマシンパワーで動かせる 1サーバーに複数のmysqldを起動させて集約を図る ‐ そのぶんdatadir用の領域がいっぱいほしい ‐ 物理マシンだといつか「ベイに空きがないからここから先は再構築しかない」タイ ミングにぶつかることがあるけれど、基本的にそんなこともない それを恐れて無駄に数TB余らせてしまうこともない
‐ 22/44
俺が好んで作る構成 23/44
IaaSのいいところ だいたいLANが速い だいたいインターネットへの送信は帯域幅ではなくデータ量で線形に課金 だいたいストレージは1GB~100GB単位で増やせる だいたい「野良インスタンス」があれば気付く 24/44
野良インスタンス XXXサービスのセグメントに何故か1つだけポツンとYYYサービスのインスタンス が… 開発環境のwebapが何故か本番のDBに接続している… 25/44
野良インスタンス 事故を防ぐためにIPアドレス決め打ちでアカウントを作っていた MySQLの「アカウント」は (User, Host) で1つのアカウント ‐ webap増えるたびに CREATE USER,
GRANT .. MySQL 8.0でロールが出来たので幾分楽になったけれど ‐ 26/44
野良インスタンス vs. ファイアウォール MySQL側の認証機構に頼るよりも、IaaS側のネットワークACLに任せる方がいい MySQL上では CREATE USER hoge@'%' で作るということ ‐
ManagedなDBMSだとこれが定石らしいし ‐ ネットワークACLは(DBMSのアカウント管理よりはよほど頻繁に)よくコード化さ れる Terraform, AWS Cloudformation, etc.. ‐ そもそも請求書に直結するので、自前データセンターよりよほど野良インスタンス が少ない() 27/44
クラウドっぽいなと思ったところ ブロックストレージが綺麗に死なない インスタンスガチャは健在 インプレースではなく「増やして減らす」が定石 28/44
datadirに刺さってるス トレージを黙って引っこ 抜いたことはあります か? [はい/イエス] 29/44
ブロックストレージが綺麗に死なない datadirに刺さってるストレージを黙って引っこ抜くとフツーのmysqldは死にます 厳密にはInnoDBログファイルへのwriteにOSがエラーを返してくれるとちゃんとAssertする ‐ NFSとかNASとかそうなんですけど、引っこ抜いても死なない(writeがエラーを返 さずに何故かずっと待つ)環境もあって プラットフォームによるんでしょうけどIaaSは待つことが多い気がする ‐ RAIDカードがぶっ壊れた時とか死にかけのHDDみたいな感じ ‐
30/44
ブロックストレージが綺麗に死なない mysqldが落ちてくれないということはTCPの3306は開きっぱなし フェイルオーバーがトリガーされない ‐ コネクションプールで繋ぎっぱなしのコネクションが切断されない ‐ あっ刺さってると思ってフェイルオーバーしたら、元のマスターが何故か活動を再 開した (少なくとも切り替えた時点では) SET
GLOBAL read_only = 1 的なクエリーを叩き込もうとして もタイムアウトしていた ‐ 仕方がないので残ったマシンだけでレプリケーション構成を再構築する、Dead promotionと 言ったりするらしい ‐ コネクションプールで繋ぎっぱなしになっていたコネクションが運悪く活動を再開 してデュアルマスターであばばばば 30分ぶんのデータの辻褄を合わせるのに8時間くらいがんばった… ‐ 31/44
ノードフェン シングだいじ 32/44
ノードフェンシングだいじ 今までは物理マシンのH/Wウォッチドッグが頑張ってOSを叩き落としてくれてい た そのことを忘れたままIaaSに行っちゃったのでこれからの人は思い出しておいてく ださい 言われてみりゃアレはLinuxの機能じゃない方のウォッチドッグだった… ‐ 33/44
同じEXPLAIN、同じmy.cnfな のに1台だけ%userが高くてレ スポンスタイムが20msくらい 遅い…原因パッと思いつきます か? 34/44
インスタンスガチャは健在 「噂には聞いていたけどこれがそれか…!」と思った ホントにインスタンス停止/起動したら綺麗に他のマシンと同じくらいになった 理屈としても噂としても理解はできるけど、物理マシン脳すぎて辿りつけなかった うわぁクラウドっぽいと思った 35/44
インプレースよりも「増やして減らす」 「バックアップ取ってレプリカ切り離してALTER流して、検証終わったらリストア してレプリケーションつなぎ直しましょうか」 「スナップショット取って復元した方を検証に使えばいいのでは?」 「( ゚д゚)ハッ!」 36/44
インプレースよりも「増やして減らす」 「トータルの台数は変えられない」という錯覚 ちゃっと上げてパッと使ってサクッと消す、クラウドだ! ‐ もともとMySQLのレプリケーションによくマッチした使い方ではある だがこの使い方と非常に相性の悪い構成管理ツールがあってだな 37/44
あんまり変わらないところ サーバーは落ちるものだと考える バックアップはポータブルな形で取る バージョンアップはサボらない MySQLのレプリケーションの柔軟度高杉 38/44
あんまり変わらないところ サーバーは落ちるものだと考える まあ物理マシンでも落ちたよね ‐ インスタンスリタイアの通知を見過ごすと冷汗が流れる ‐ バックアップはポータブルな形で取る バージョンアップはサボらない MySQLのレプリケーションの柔軟度高杉 39/44
あんまり変わらないところ サーバーは落ちるものだと考える バックアップはポータブルな形で取る あんまりプラットフォームに密結合なスナップショットとかで取ると取り回しが効かない DC ⇔ クラウド間を行ったり来たりとか、クロスリージョンとか ‐ バージョンアップはサボらない MySQLのレプリケーションの柔軟度高杉
40/44
あんまり変わらないところ サーバーは落ちるものだと考える バックアップはポータブルな形で取る バージョンアップはサボらない はやくMySQLはLTSを出してください ‐ MySQLのレプリケーションの柔軟度高杉 41/44
あんまり変わらないところ サーバーは落ちるものだと考える バックアップはポータブルな形で取る バージョンアップはサボらない MySQLのレプリケーションの柔軟度高杉 DC ⇔ クラウド間を行ったり来たりとか、クロスリージョンとか ‐ 42/44
まとめ IaaSそのものもそうだけど、IaaSについてくるその他の機能を使って、組み合わ せて楽しくやる 大事なことはだいたい @ts4th の資料に書いてある さいきんの InnoDB Adaptive Flushing
(仮) ‐ さいきんのMySQLに関する取り組み(仮) ‐ 43/44
Any Questions and/or Suggestions? 44/44