わたしのまわりのニュー・ノーマル3選

吉祥寺.pm25 [Online] 2021/01/19 Talk

Transcript

1. わたしのまわりのニュー・ノーマル（むりやり） 3 選 吉祥寺.pm25【オンライン】 2021/01/19 まつひさ（hmatsu47）
2. 自己紹介 松久裕保（@hmatsu47） https://qiita.com/hmatsu47 名古屋で Web インフラのお守り係をしています MySQL 8.0 の薄い本を作って配っています ◦ Qiita の記事： https://qiita.com/hmatsu47/items/ceb75caf46e3c761095d ◦ GitHub リポジトリの他、印刷版を勉強会などで無料配布していました ◦ 新型コロナウイルスの関係でオフライン勉強会ができなくなったので、 現在は BOOTH でも配布しています（100円＋送料）後の話に続く… https://booth.pm/ja/items/2524481 2
3. 吉祥寺.pm 初トーク参加です • 一般参加：過去 1 回 ◦ 設計ナイトを含めても過去 2 回 • 「一句」が浮かばず一週間悩む ◦ これ↓を見て「聞きたかった」と思いつつ 3
4. 本日のネタ（むりやり 3 選） • 継続的デリバリーモデル • OLTP + OLAP = HTAP • レガシーなシステムでのクラウドとの付き合い方 4
5. [1] 継続的デリバリーモデル • 2020/12/08、CentOS 8 終了のお知らせ ◦ https://blog.centos.org/2020/12/future-is-centos-stream/ ◦ 2021/末終了 ◦ 今後は CentOS Stream に注力 • CentOS Stream : 継続的デリバリー ◦ 赤帽エンジニアブログ https://rheb.hatenablog.com/entry/centos_stream 5
6. ところで、継続的デリバリーモデルといえば（強引） • MySQL Innovation Day（2018/05）の講演にて ◦ MySQL 8.0 は継続的デリバリーモデルによって、GA となった後 も機能を継続的に追加していくことに https://gihyo.jp/dev/serial/01/oss-db-various-news/0034 • 四半期毎にマイナーバージョンアップ ◦ それにあわせて新機能追加・改良 6
7. 継続的デリバリーモデル : 使用上の注意 • アップデートで突然、挙動が変わる ◦ 例）NLJ Only だった MySQL、8.0.18 にて Hash Join を採用 ▪ なぜか同じ SQL（文）によるデータの取得結果が違ったり…?? ◦ 例）予約語の追加が命取りに https://dev.mysql.com/doc/mysqld-version-reference/en/keywords.html →メジャーバージョン間の差異 https://dev.mysql.com/doc/refman/8.0/en/keywords.html →8.0 マイナーバージョンでの追加・削除・変更 7
8. 「変わる」ことを前提に付き合っていく • 変わっても良いようにしておく ◦ 例）自動アップデートは OFF に（確認後にアップデート） ◦ 例）DB・テーブル・列名などはバッククォート（`）で挟む • 変化を積極的に追い続ける ◦ メジャーバージョンアップまでの間「塩漬け」しない ▪ 一度に大きな変化に対応する必要があり、かえって大変になる ▪ セキュリティパッチを当てられないリスクが大きい 8
9. 【余談】MySQL 8.0 の薄い本も • 四半期毎のマイナーバージョンアップに追従 ◦ 継続的デリバリー中 ▪ 正直しんどい • 2021/01 は MySQL 8.0.23 リリース見込み ◦ そろそろ出る？昨日（2021/01/18）出てた ◦ 薄い本も 8.0.23 対応版の改訂時期 9
10. ところで、MySQL といえば • 集計・分析用の重たいクエリを投げると ◦ 数時間結果が返ってこないことも • 集計・分析をするなら ◦ ETL 経由で分析・OLAP 用の環境にデータを流して処理 10
11. MySQL の旧ノーマル : 集計・分析が苦手な子 （後述 URL の PDF 資料「20201223_MySQL_MDS_HeatWave_jp.pdf」より引用） 11
12. [2] OLTP + OLAP = HTAP • Oracle Cloud の MySQL Database Service（MDS）に HeatWave 機能が追加！ ◦ https://www.mysql.com/jp/why-mysql/presentations/business-benefits-of- using-mds-and-heatwave-202012-doc-jp/ （サービス説明 PDF 資料） ※要 Oracle シングル・サインオンアカウント（無料） • 分析クエリが自動的に HeatWave へ ◦ https://qiita.com/sugimount/items/9ecf8800cd59ba2a635c 12
13. MySQL のニュー・ノーマル : MDS で HeatWave （前述 URL の PDF 資料「20201223_MySQL_MDS_HeatWave_jp.pdf」より引用） 13
14. MySQL が「集計・分析できる子」に！（MDS 限定ですが ） https://dev.mysql.com/doc/ （MDS・HeatWave が先頭に） 14
15. [3] クラウドとの付き合い方 • とあるサービスの話 : 約 3 年半前、自社サービス （15 年モノのレガシー Web システム）を AWS へ移行 ◦ https://qiita.com/hmatsu47/items/23e2f0b36ab46234b9db （ほか、計 3 記事） ◦ LB を ALB、DB（MySQL）を Aurora へ ◦ ほぼ AWS に「載せただけ」（でも大変だった） • 2020/12、サービス別に AWS アカウントを分離 ◦ メインのサービスを別アカウントへ移行 15
16. ALB の仕組み • 複数の AZ にある複数のインスタンスがターゲットサーバ にリクエストを振り分ける ◦ （1AZ で使わないかぎり）単一インスタンスではない • 負荷に応じて自動的にスケールアウト／スケールイン→ スケールアップ／スケールダウン ◦ インスタンスの数やサイズが動的に変わる 16
17. ある日の ALB（事情によりメトリクスグラフは出せませんが） • 突然、スパイクアクセスを受ける ◦ 調査＋サポートに問い合わせ ▪ 瞬間的に大量のリクエストがあった ▪ その後は元のリクエスト数に戻った（継続はしていない） • ALB 関連のメトリクスグラフは異常なまま ◦ コネクション数が倍増（ずっと戻らない） ◦ 他は元に戻っていた（分間 リクエスト数・平均 レスポンス時間など） 17
18. そのとき、ターゲットサーバでは • コネクション数が 3 倍に（ずっと戻らない） ◦ アイドルタイムアウト設定など何も変えていないのに • Web サーバの設定が「昔のまま」だったので ◦ コネクション増→メモリ使用量がダイレクトに増加 ◦ 一部（設定上の）コネクション上限に達する ▪ アカウント移行作業時、サーバソフトウェア類のバージョンは上げていた のに、設定内容が一部古いままだった 18
19. スパイク前のイメージ 19 ALB Web
20. スパイク後のイメージ 20 ALB Web
21. ALB の中身はブラックボックス • 日々進化している ◦ 例えば、スケールアップ時の応答性の向上とか ▪ 暖機がほぼ不要になった • 「昨日と同じ動きをする」とは限らない ◦ 使う側も、クラウドの流儀（Elastic）に合わせてスケール対応 する構成に変えていかないといけない （問題のコネクション数は年が明けたところで元の水準に戻っていた） 21
22. 時を戻して…ここで、突然の一句。 年の瀬に ひやり Aurora 再起動 22
23. サポートに問い合わせてみて原因が判明 先読みが コケて Aurora 再起動 • 再起動後のエラーログに↑を見つけたら AWS サポートへ ◦ 決して bugs.mysql.com にバグレポートを上げてはいけません （ちなみに、オーロラは冬の季語ではないらしい） 23 yyyy-mm-dd hh:mm:ss XXXXXXXXXXXX InnoDB: Assertion failure in thread nnnnnnnnnnnnnn in file ut0boundedqueue.cc line 123 InnoDB: Failing assertion: oldVersion != EMPTY_ENTRY && oldVersion != SUPERSEDED_ENTRY InnoDB: We intentionally generate a memory trap. InnoDB: Submit a detailed bug report to http://bugs.mysql.com. （後略）
24. その後、DB の性能問題が発生 • ワークアラウンド対応（先読み無効化）の影響？ ◦ あったとしても軽微 ▪ 普段から利用状況を見ていたので概ね判断が付いた • 原因を見つけて対応 ◦ 無事、解決 • 念のため別の対応策も準備 ◦ 構成を変えると DB 負荷がどう変わるか何度か検証していた 24
25. 本日のネタ（むりやり 3 選）のまとめ • 継続的デリバリーモデル ◦ 「変わる」ことを前提に付き合っていく • OLTP + OLAP = HTAP ◦ MySQL が「集計・分析できる子」に！（ただし MDS に限る） • レガシーなシステムでのクラウドとの付き合い方 ◦ レガシーでも Elastic を意識してスケール対応（設定） ◦ 可観測性と「平常時」の把握が大事（構成変更時の変化の検証も） 25
26. 【振り返り】変わったもの・変わっていないもの • ニュー・ノーマルで変わったもの ◦ 使うツール／ツールの使い方 ◦ 手段・手順 • ニュー・ノーマルでも変わっていないもの ◦ ベースとなる考え方 ◦ 目的 26