Tweet
Tweet

Slide 1

Slide 1 text

MySQL on IaaSの運用あれやこれや マネージドでないことを楽しむ 2020/12/03 yoku0825 db tech showcase ONLINE 2020

Slide 2

Slide 2 text

セッション概要(これ登録した人は見えたのかな…) - IaaS上でMySQLを運用して上手く行ったことやハマったことを紹介します - オンプレに比べて便利なこと不便なこと - マネージドに比べて便利なこと不便なこと - 「IaaSに適したMySQL」の話ではなく、「組み合わせて、上手くやりたい」経験談です 大事なことはだいたい @ts4th の資料に書いてある さいきんの InnoDB Adaptive Flushing （仮） ‐ さいきんのMySQLに関する取り組み（仮） ‐ 1/44

Slide 3

Slide 3 text

＼こんにちは／ yoku0825＠とある企業のDBA オラクれない ‐ ポスグれない ‐ マイエスキューエる ‐ 生息域 Twitter: @yoku0825 ‐ Blog: 日々の覚書 ‐ 日本MySQLユーザ会 ‐ MySQL Casual ‐ 2/44

Slide 4

Slide 4 text

MySQL on IaaS IaaSの定義とかよく知らないんですけど、このセッションの中では「OSより下(だ け)を提供してくれる何か」のつもりでいます 3/44

Slide 5

Slide 5 text

vs. マネージド 主に名前解決ベースのHAが提供される 秒単位のPITRが提供される 少なくともこれらが自前で提供できないなら、 MySQL on IaaS は「楽しめない」 えっこれらが提供されてないマネージドMySQLがあるんですか！？ ‐ 4/44

Slide 6

Slide 6 text

vs. 物理マシン CPUバウンドなワークロードでは熱とか電源がちゃんとしてればオーバークロック が有効 ローカルストレージの書き込みに失敗すれば綺麗にmysqldがアボートしたり綺麗 にOSリブートかかったりする 書き込みに失敗したことが返らないストレージというものはかなり厄介 5/44

Slide 7

Slide 7 text

IaaSのいいところ だいたいLANが速い だいたいインターネットへの送信は帯域幅ではなくデータ量で線形に課金 だいたいストレージは1GB～100GB単位で増やせる だいたい「野良インスタンス」があれば気付く 6/44

Slide 8

Slide 8 text

7/44

Slide 9

Slide 9 text

(･∀･)ゞ あんまり データベースとして 面白味はない… 8/44

Slide 10

Slide 10 text

( ｰ`дｰ´) だがDBA としては嬉しい 9/44

Slide 11

Slide 11 text

の前に俺が好 んで作る構成 10/44

Slide 12

Slide 12 text

俺が好んで作る構成 11/44

Slide 13

Slide 13 text

俺が好んで作る構成 サービス用のインスタンスとは別にバックアップ専用のレプリカを作る 大体「セグメントごとに1つ」くらいのペース ‐ バックアップレプリカは好きな時に止めたり止めなかったりして好きにバックアッ プが取れる サービス用のレプリカを増設する時も、時間によらず「バックアップレプリカを止めてデータ を転送するだけ」で構築できる ‐ かつてはここからファイルサーバーやテープドライブに転送していた。今は某オブ ジェクトストレージに送るのが主流 12/44

Slide 14

Slide 14 text

俺が好んで作る構成 サービス用のインスタンスとは別にバックアップ専用のレプリカを作る 大体「セグメントごとに1つ」くらいのペース ‐ バックアップレプリカは好きな時に止めたり止めなかったりして好きにバックアッ プが取れる サービス用のレプリカを増設する時も、時間によらず「バックアップレプリカを止めてデータ を転送するだけ」で構築できる ‐ かつてはここからファイルサーバーやテープドライブに転送していた。今は某オブ ジェクトストレージに送るのが主流 13/44

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

LANが速くて嬉しいケース 地味に pt-online-schema-change や gh-ost は大容量のバイナリログを吐く 特に gh-ost は binlog_row_image = FULL を要求するので「もとのテーブルの倍近く」のバイナ リログを(既存のトラフィックに追加で)サクッと吐く ‐ 非同期レプリケーションの転送を律速するパラメーターは特に存在しないので、ツール側でも sleepするけど心配がないくらいまで帯域が大きいと嬉しい ‐ 15/44

Slide 17

Slide 17 text

俺が好んで作る構成 16/44

Slide 18

Slide 18 text

俺が好んで作る構成 サービス用のインスタンスとは別にバックアップ専用のレプリカを作る 大体「セグメントごとに1つ」くらいのペース ‐ バックアップレプリカは好きな時に止めたり止めなかったりして好きにバックアッ プが取れる サービス用のレプリカを増設する時も、時間によらず「バックアップレプリカを止めてデータ を転送するだけ」で構築できる ‐ かつてはここからファイルサーバーやテープドライブに転送していた。 今は某オ ブジェクトストレージに送るのが主流 17/44

Slide 19

Slide 19 text

インターネットへの送信がデータ量に線形に課金で嬉しいケース 帯域幅95%ile方式の課金だと「バックアップ＆外部転送」を特定の時間に重ねる とバンと跳ね上がる可能性がある 転送バイト数よりも転送に使う帯域に気を使わないといけないのがストレス ‐ 複数のバックアップレプリカから同時に転送が走らないようにしたり ‐ 転送帯域に制限をかけたらかけたでバックアップが長引いたり ‐ 最初から「どんな速度で送ろうと、100GBは100GBぶんの料金」なので余計な駆 け引き(?)が要らない あとは「だいたい線形」なので、95%ileみたいに桁が一つ変わることはない ‐ 18/44

Slide 20

Slide 20 text

オブジェクトストレージ vs. ブロックストレージ 前者の方が幾分お安くつく イメージ的には物理マシンの HDD vs. SSD くらい？ ‐ 長期保管用にはオブジェクトストレージ, 短期保管(数日ぶんを保持する用途)には ブロックストレージ(あるいは物理マシンのHDD)とやっていたけど、それもオブ ジェクトストレージに載せた方が安くつく？ ⇒安くつきました ‐ 19/44

Slide 21

Slide 21 text

俺が好んで作る構成 20/44

Slide 22

Slide 22 text

俺が好んで作る構成 サービス用のインスタンスとは別にバックアップ専用のレプリカを作る 大体「セグメントごとに1つ」くらいのペース ‐ バックアップレプリカは好きな時に止めたり止めなかったりして好きにバックアッ プが取れる サービス用のレプリカを増設する時も、時間によらず「バックアップレプリカを止めてデータ を転送するだけ」で構築できる ‐ かつてはここからファイルサーバーやテープドライブに転送していた。今は某オブ ジェクトストレージに送るのが主流 21/44

Slide 23

Slide 23 text

ストレージが小単位で増やせるのが嬉しいケース バックアップレプリカはサービストラフィックを一切受け付けないので、サービス 用mysqldに比べて小さいマシンパワーで動かせる 1サーバーに複数のmysqldを起動させて集約を図る ‐ そのぶんdatadir用の領域がいっぱいほしい ‐ 物理マシンだといつか「ベイに空きがないからここから先は再構築しかない」タイ ミングにぶつかることがあるけれど、基本的にそんなこともない それを恐れて無駄に数TB余らせてしまうこともない ‐ 22/44

Slide 24

Slide 24 text

俺が好んで作る構成 23/44

Slide 25

Slide 25 text

IaaSのいいところ だいたいLANが速い だいたいインターネットへの送信は帯域幅ではなくデータ量で線形に課金 だいたいストレージは1GB～100GB単位で増やせる だいたい「野良インスタンス」があれば気付く 24/44

Slide 26

Slide 26 text

野良インスタンス XXXサービスのセグメントに何故か1つだけポツンとYYYサービスのインスタンス が… 開発環境のwebapが何故か本番のDBに接続している… 25/44

Slide 27

Slide 27 text

野良インスタンス 事故を防ぐためにIPアドレス決め打ちでアカウントを作っていた MySQLの「アカウント」は (User, Host) で1つのアカウント ‐ webap増えるたびに CREATE USER, GRANT .. MySQL 8.0でロールが出来たので幾分楽になったけれど ‐ 26/44

Slide 28

Slide 28 text

野良インスタンス vs. ファイアウォール MySQL側の認証機構に頼るよりも、IaaS側のネットワークACLに任せる方がいい MySQL上では CREATE USER hoge@'%' で作るということ ‐ ManagedなDBMSだとこれが定石らしいし ‐ ネットワークACLは(DBMSのアカウント管理よりはよほど頻繁に)よくコード化さ れる Terraform, AWS Cloudformation, etc.. ‐ そもそも請求書に直結するので、自前データセンターよりよほど野良インスタンス が少ない（） 27/44

Slide 29

Slide 29 text

クラウドっぽいなと思ったところ ブロックストレージが綺麗に死なない インスタンスガチャは健在 インプレースではなく「増やして減らす」が定石 28/44

Slide 30

Slide 30 text

datadirに刺さってるス トレージを黙って引っこ 抜いたことはあります か？ [はい/イエス] 29/44

Slide 31

Slide 31 text

ブロックストレージが綺麗に死なない datadirに刺さってるストレージを黙って引っこ抜くとフツーのmysqldは死にます 厳密にはInnoDBログファイルへのwriteにOSがエラーを返してくれるとちゃんとAssertする ‐ NFSとかNASとかそうなんですけど、引っこ抜いても死なない(writeがエラーを返 さずに何故かずっと待つ)環境もあって プラットフォームによるんでしょうけどIaaSは待つことが多い気がする ‐ RAIDカードがぶっ壊れた時とか死にかけのHDDみたいな感じ ‐ 30/44

Slide 32

Slide 32 text

ブロックストレージが綺麗に死なない mysqldが落ちてくれないということはTCPの3306は開きっぱなし フェイルオーバーがトリガーされない ‐ コネクションプールで繋ぎっぱなしのコネクションが切断されない ‐ あっ刺さってると思ってフェイルオーバーしたら、元のマスターが何故か活動を再 開した (少なくとも切り替えた時点では) SET GLOBAL read_only = 1 的なクエリーを叩き込もうとして もタイムアウトしていた ‐ 仕方がないので残ったマシンだけでレプリケーション構成を再構築する、Dead promotionと 言ったりするらしい ‐ コネクションプールで繋ぎっぱなしになっていたコネクションが運悪く活動を再開 してデュアルマスターであばばばば 30分ぶんのデータの辻褄を合わせるのに8時間くらいがんばった… ‐ 31/44

Slide 33

Slide 33 text

ノードフェン シングだいじ 32/44

Slide 34

Slide 34 text

ノードフェンシングだいじ 今までは物理マシンのH/Wウォッチドッグが頑張ってOSを叩き落としてくれてい た そのことを忘れたままIaaSに行っちゃったのでこれからの人は思い出しておいてく ださい 言われてみりゃアレはLinuxの機能じゃない方のウォッチドッグだった… ‐ 33/44

Slide 35

Slide 35 text

同じEXPLAIN、同じmy.cnfな のに1台だけ%userが高くてレ スポンスタイムが20msくらい 遅い…原因パッと思いつきます か？ 34/44

Slide 36

Slide 36 text

インスタンスガチャは健在 「噂には聞いていたけどこれがそれか…！」と思った ホントにインスタンス停止/起動したら綺麗に他のマシンと同じくらいになった 理屈としても噂としても理解はできるけど、物理マシン脳すぎて辿りつけなかった うわぁクラウドっぽいと思った 35/44

Slide 37

Slide 37 text

インプレースよりも「増やして減らす」 「バックアップ取ってレプリカ切り離してALTER流して、検証終わったらリストア してレプリケーションつなぎ直しましょうか」 「スナップショット取って復元した方を検証に使えばいいのでは？」 「( ﾟдﾟ)ﾊｯ!」 36/44

Slide 38

Slide 38 text

インプレースよりも「増やして減らす」 「トータルの台数は変えられない」という錯覚 ちゃっと上げてパッと使ってサクッと消す、クラウドだ！ ‐ もともとMySQLのレプリケーションによくマッチした使い方ではある だがこの使い方と非常に相性の悪い構成管理ツールがあってだな 37/44

Slide 39

Slide 39 text

あんまり変わらないところ サーバーは落ちるものだと考える バックアップはポータブルな形で取る バージョンアップはサボらない MySQLのレプリケーションの柔軟度高杉 38/44

Slide 40

Slide 40 text

あんまり変わらないところ サーバーは落ちるものだと考える まあ物理マシンでも落ちたよね ‐ インスタンスリタイアの通知を見過ごすと冷汗が流れる ‐ バックアップはポータブルな形で取る バージョンアップはサボらない MySQLのレプリケーションの柔軟度高杉 39/44

Slide 41

Slide 41 text

あんまり変わらないところ サーバーは落ちるものだと考える バックアップはポータブルな形で取る あんまりプラットフォームに密結合なスナップショットとかで取ると取り回しが効かない DC ⇔ クラウド間を行ったり来たりとか、クロスリージョンとか ‐ バージョンアップはサボらない MySQLのレプリケーションの柔軟度高杉 40/44

Slide 42

Slide 42 text

あんまり変わらないところ サーバーは落ちるものだと考える バックアップはポータブルな形で取る バージョンアップはサボらない はやくMySQLはLTSを出してください ‐ MySQLのレプリケーションの柔軟度高杉 41/44

Slide 43

Slide 43 text

あんまり変わらないところ サーバーは落ちるものだと考える バックアップはポータブルな形で取る バージョンアップはサボらない MySQLのレプリケーションの柔軟度高杉 DC ⇔ クラウド間を行ったり来たりとか、クロスリージョンとか ‐ 42/44

Slide 44

Slide 44 text

まとめ IaaSそのものもそうだけど、IaaSについてくるその他の機能を使って、組み合わ せて楽しくやる 大事なことはだいたい @ts4th の資料に書いてある さいきんの InnoDB Adaptive Flushing （仮） ‐ さいきんのMySQLに関する取り組み（仮） ‐ 43/44

Slide 45

Slide 45 text

Any Questions and/or Suggestions? 44/44