MySQL on IaaSの運用あれやこれや

2020/12/03 dbts2020
https://www.db-tech-showcase.com/dbts/2020/online/schedule

Transcript

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

8. 7/44
   

   View Slide

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

   View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

15. 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
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

45. Any Questions
    and/or
    Suggestions?
    44/44
    

    View Slide