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

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

yoku0825
PRO
December 03, 2020

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

yoku0825
PRO

December 03, 2020
Tweet

More Decks by yoku0825

Other Decks in Technology

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