Session Day 2 のセッションの参加レポートです。この日は別件の用事もあり、参加できるセッション数が少なくなってしまいました。
Percona Server for MySQL 8.0
MySQL8.0 のGAリリース（2018-04-19）から約8か月後、Percona Server for MySQL（以下、Percona Server）もGAリリース（2018-12-21）されました。本セッションでは、そんなPercona Server8.0の特徴（変更点）について述べられました。
ちなみにスピーカーのLaurynas氏は、Percona Server のテクニカルリードを務め、時おりバグレポートなどでも名前を見たことがあります。
まず、Percona Server8.0は「MySQL8.0 + enhancements」と表現される通り、MySQL8.0との互換性を保ちつつ、独自の改良を加えられている点が大きな特徴となります。
具体的な例として、以下の4点が挙げられました。
Write optimized Storage Engine
Session Day 1 の Keynote でも説明された「MyRocks」が、Percona Serverにはバンドルされています。
MySQL および Percona Server で主要な InnoDB ストレージエンジンは「READ最適化」されたものであるため、「WRITE最適化」されたMyRocksストレージエンジンはユースケースによってはかなり有効であるため、Perconaでは今後連携を強化していくそうです。
また、その他にもMySQL8.0でも実装された native partitioning についても触れられていました。さらに異なるストレージエンジンが混在した環境でも整合性のとれた物理バックアップ（XtraBackup）が取得できるような改善も施されているようです。
一方で、ビッグデータ向けのストレージエンジンとして注目されていた「TokuDB」に関して、Percona Serverではサポートを終了するとのことでした。もし利用中のユーザがいたら注意が必要です。
Data encryption
近年のセキュリティ意識の高まりに合わせ、Percona Server8.0も「暗号化」にかなり注力しているようです。上記の表は、細かな暗号化機能の実装状況についてですが、MySQLでは未実装の「一時テーブルスペース」や「システムテーブルスペース」の暗号化にも挑戦していることが分かります。
多くはまだGA前（pre-GA）の状態なので、本格的なリリースが今から楽しみです。
enterprise Features
Percona Serverでは、MySQLにおいて「商用版」でのみ提供されている機能もオープンソースで実装しています。代表的なものでは “Thread pool”, “Audit Plugin”, “PAM認証プラグイン” などです。
これらの機能は 8.0 でも引き続き強化、改善していくとのことでした。
Flexbility & Management
その他にも、Percona Server8.0 では操作性や運用面での改善が施されています。
以下、細かな内容となるため箇条書きで列挙します。
- MEMORYストレージエンジンで VARCHAR/BLOB 型をサポート
- 大量の小さなJSONデータを効率よく格納するため、カラム圧縮機能を強化
→ JSON カラムの定義に”COLUMN_FORMAT COMPRESSED”オプションを付ける - LOCK TABLES FOR BACKUPステートメントのロックを削減、MyRocks向けの拡張
- /* SET_VAR */ コメントの実装
- information_schema.USER_STATISTICS テーブルの CPU_TIME カラムなどが、INT型からDOUBLE型に変更
→ 1秒未満の数値も小数ありで表示できるようになった - binlog_space_limit 変数の実装
→ バイナリログの保存領域の管理が簡単になった
最後に、8.0 で削除される機能について述べられました。スライドに載っている以外にも、Scalability metrics plugin（誰も使ってないらしいです）やクエリキャッシュ、innodb_flush_method=O_DIRECT なども言及されていました。
また、ただ単に削除されるだけでなく Performance_schema に置き換わる Query Response Time plugin のような例もあります。
まだGAリリースがされたばかりの Percona Server8.0ですが、今後も様々な新機能が追加される可能性が高いです。弊社でも問い合わせが増えることが予想されるので、情報を追いかけつつ調査・検証を継続していきたいと思いました。
From Scheduled Downtime to Self-Healing in Less Than a Year
スピーカーのKaroly氏は、booking.com → DropBox → Salesforce と名だたるTECH企業を渡り歩いてきたインフラエンジニアで、特にDBの可用性向上を得意としているそうです。
本セッションでは、DBのダウンタイムを最大限に短くするための「DB自動修復システム」について解説してくれました。
「自動修復」に必要な要素は、以下の6点です。
- Provisioning
- Bootstrapping
- Traffic control / Connection management
- Maintenance
- Monitoring
- Decommission
また、4. Maintenance は更に以下の5つに細分化できます。
4-1. Configuration management
4-2. Access management
4-3. Failure detection
4-4. Patching
4-5. Migrations
とはいえ、これら全てを備えるシステムを簡単に作ることはできません。特に「自動」という部分は非常に複雑です。その理由は、修復のために必要な処理の件数が膨大になるからです。
分かりやすく言うと、以下のような計算式が参考になります。
「タスク数」（ex. backup, build new server, failtover）×「ホスト数」×「横入り処理」（これが意外と多い…）
これを全て解決してくれるツールは残念ながら存在しません。そのため、同氏が担当してきたどの企業でも、複数のツールを組み合わせてシステムを実現させていたそうです。以下のスライドがその参考資料となります。
Configuration management ツールである Chef や Ansible は日本国内でも人気を集めています。またレプリケーション管理ツールとしては、Orchestratorがお気に入りのようです。ただ、スライドの中に既にサポートが終了している MySQL Fabric が含まれていた点が気になりました…。
上記で設定した自動修復がいつ必要になるかと言うと、例えば「設定のミスマッチ」「マスタがダウン」「バックアップが古すぎる」など様々なケースが想定されます。
また、何らかの問題（障害）が発生したケース以外でも、例えばMySQLのバージョンアップをしたい場合などでもこの自動修復システムが役立ちます。
このセッションでは、具体的な設定手順などには余り触れられませんでしたが、恐らく大量のサーバを運用している企業では必ず必要となる情報かと思います。
余談ですが、セッションの冒頭でSalesforceが運用しているDBサーバに関する話があり、現在は600～700台ほどのサーバが稼働しているそうです。やはりそれなりに大規模ですね。
Immutable Database Infrastructure with Percona XtraDB Cluster
※発表されたスライド資料も上記で公開されています
長いようで短かったPercona Live 2019の最後を飾るのは、日本企業から唯一、スピーカーとして参加されたヤフー三谷氏のセッションです。日本でも度々お話されていますが、同社が運用されているPercona XtraDB Cluster（以下、PXC）環境は世界的にも大規模であり、参加者の注目を集めていました。
セッションの内容としては「Immutable」（不変）なDBとして、なぜPXCを選択したのかという理由と、その可用性、運用容易性を活かすためにどのようなツールを採用しているか、というものでした。
以前のヤフー様の環境では、可用性の面では問題ないものの、複数バージョンのソフトを並列させることができないという課題がありました。
特にヤフー様の場合、そのサービスの数が膨大であり様々なバージョンの組み合わせでテストが実施できないというのは運用上のリスクになってしまいます。
そこでPXCであれば、サーバの追加・更新・削除をフレキシブルに操作できるため、各バージョンの組み合わせを試しては消す、試しては消すといった方法が可能となります。
PXCの柔軟なスケーラビリティがまさに要件に合致していたことが、採用の決め手となったそうです。
また、DB環境を取り巻くインフラの構成についても説明がありました。GitHub（Chef）からスタートしてVMのイメージを作成し、それをOpenStackを利用したIaaS環境で展開することで、自由にサーバをリビルドできる環境を用意しているとのことでした。
ヤフー社内のメンテナンス作業に求められるのは、「ダウンタイムゼロ」かつ「事前準備無しでいつでも実施」できることです。それを満たすことができるPXCは優れたソリューションですが、一方で不満点もあるとのことでした。
特に大きいのがSSTの制限（仕様）の部分で、以下の点が指摘されていました。
- 5.7.21 / 5.7.22 の間でSSTの互換性が失われている（エラーになる）
- TDEおよびテーブル圧縮が有効なテーブルがある場合、SSTがエラーになる
- SST実行中はDDLがブロックされる（–lock-ddl オプションがついているため）
- テーブルデータが大きいと、その分SSTの時間が長くなる
→ 緊急デプロイなどで足かせに…
実際にPXCを運用している立場から見える、実践的なノウハウが多く詰まったセッションでした。これで参加者の中からPXCに興味を持って、各々の本番環境に導入してくれたらとても素晴らしいですね。
※ 最後に宣伝となりますが、弊社ブログにてヤフー様の事例を紹介しております。もし興味がございましたら、こちらも参照してみてください。
Percona XtraDB Clusterで「運用」「構築」「パフォーマンス」に関わる課題をまとめて解決（ヤフー株式会社様）
