AWS RDS(MySQL) をオンサービスのままスキーマモデル変更する運用を

１年間続けた所感

DBA が夜間メンテをしなくなった日

アジェンダ

1. はじめに 1-1. 自己紹介 1-2. 本日お話すること2. 導入検討フェーズ 2-1. 克服すべき運用課題 2-2. 達成するにあたって検討したこと 2-2-1. オンラインスキーマチェンジする為の方法 2-2-2.InnoDB とオンライン DDL について 2-2-3. 最初に考えたこと 2-2-4. オンラインスキーマチェンジする為の方法

2-3. ツール選定 2-3-1. 選定したツール 2-3-2. 実際のツールの挙動 2-4. ツールの運用環境 2-4-1.AWS RDS(MySQL) の運用環境 2-4-2.Percona Toolkit の運用環境 2-4-3.AWS RDS(MySQL) パラメータグループの変更内容 2-4-4.pt-online-schema-change コマンド発行時に 発生した課題と回避オプション 2-4-5. 最終的なコマンドサンプル

アジェンダ

3. 運用フェーズ 3-1. 運用実績 3-1-1. 達成できたこと 3-1-2. アプリケーションリリース時にスキーマ変更が 必要な場合の実績 3-1-3. バッチ処理で OPTIMIZE TABLE を実行する場合の実績 3-2. 運用実績 ( 障害例 ) 3-2-1. トリガー使用時のロックダウンについて

アジェンダ

4. 終わりに 4-1. メリット 4.2. デメリット 4.3. 所感 4.4. 免責事項

アジェンダ

1-1. 自己紹介

氏名：益子 徹

経歴：・ 2002 年 新卒で中堅 SIer に入社、テキストマイニングツールのパッケージソフト開発から大手製造業、サービス業向けの受託開発に従事。・ 2013 年 株式会社ビズリーチに入社、弊社サービスの DBA, インフラからスマートフォンアプリケーションの製造・運用、開発部隊のマネジメントまで幅広く担当。

1. はじめに

1−2. 本日お話すること

アクセス頻度の高い Web サービスにて、 MySQL(InnoDB) を利用した場合に於いても、サービスを運用したまま、スキーマ変更を実施する運用経験についてお話します。

1. はじめに

補足：MySQL(InnoDB) は、スキーマ変更 ( カラム追加やテーブルの再編成など ) を行うと、その間、テーブルに共有ロックがかかる仕様となっています。 (※ 注 1)

ALTER TABLE 構文を実行すると、ユーザからは見えないテンポラリーテーブルを新しい定義で作成し、構文適用前のテーブルからデータをすべてコピーし、コピーが完了すると既存のテーブルとテンポラリーテーブルのテーブル名をリネームするという処理が行われます。この処理中は、ユーザーはテーブルに対して、ノンロッキングリードのみ許可されており、他の処理はブロックされます。更新やロッキングリードが必要なアプリケーションでは、処理が停止します。加えて、最後のテーブルリネーム時は、アクセスが排他的になります。

※注 1 MySQL のバージョンによって、設定値の変更と実施したスキーマ変更の種類により、共有ロックを回避できるものもございます。"14.11.1 オンライン DDL の概要 ". MySQL 公式サイト . https://dev.mysql.com/doc/refman/5.6/ja/innodb-create-index-overview.html, ( 参照 2017-03-26)

1. はじめに

2−1. 克服すべき運用課題

弊社のいくつかのサービスでは、 AWS RDS(MySQL) を利用したサービス開発が行われております。

データモデルの整合性を保つ為、 MySQL のテーブル間に外部キー制約を貼ることを基本ルールとしておりました。MySQL でテーブルへのカラム追加やテーブルの再編成などを行うと、その間テーブルと関連テーブルに共有ロックが発生致しますが、サービスが成長する ( 各テーブルのデータ量、起点テーブルに紐づく関連テーブルの数、特定テーブルに対するアクセス頻度が増加 ) に連れ、オンサービス中における共有ロックの発生時間の増加や、共有ロックが原因で発生するシステム停止障害がリスクとなりました。

2. 導入検討フェーズ

2−1. 克服すべき運用課題

弊社はベンチャー企業、スピード感を大切にしている為、システムの開発リリースサイクルは、短いスプリントで実施致します。その間に発生したデータモデルの変更要求は、可能な限り、サービスを停止することなく実施する必要がありました。

DBA としては、成果とリスクの狭間で苛まれる情けない課題を抱えておりました。

2. 導入検討フェーズ

2−2. 達成するにあたって検討したこと 2-2-1. オンラインスキーマチェンジする為の方法

(1).MySQL の InnoDB 用オンライン DDL を使用する

(2). スキーママイグレーション・ツールを使用する「 Percona Toolkit」 pt-online-schema-change, Facebook OSC, LHM, oak-online-alter-table等。

(3). スキーマをマイグレーション用レプリカに移行、リファクタリングしたレプリカを新しいマスターとして使用する

2. 導入検討フェーズ

2-2-2.InnoDB とオンライン DDL について(1).MySQL5.1以前のバージョン「 1−2. 本日お話すること」の補足 事項で記述した動作仕様となります。

2. 導入検討フェーズ

2-2-2.InnoDB とオンライン DDL について(2).MySQL5.1 + InnoDB PlugIn と MySQL5.5 バージョンMySQL5.5 では、 Fast Index Creation という機能が追加されました。この機能により、インデックスを追加する際のみ、新しい定義のテーブルのコピー処理が行われなくなりました。但し、インデックスの作成中は、ノンロッキングリードのみが許可される為、実質的には内部処理の効率だけが改善されました。

2. 導入検討フェーズ

2-2-2.InnoDB とオンライン DDL について(3).MySQL5.6 バージョンInnoDB オンライン DDL機能が追加されました。一部の ALTER TABLE 構文のみ、ノンロッキングリード以外の処理も許可されました。 但し、 ALTER TABLE 構文の開始と終了時点では、排他処理が行われ、行ロックが必要なトランザクションと同時に実行することができない問題を抱えています。

2. 導入検討フェーズ

2-2-2.InnoDB とオンライン DDL について(4).MySQL5.7 バージョンMySQL5.6 で追加されたオンライン DDL機能の制限が一部緩和されました。例として、カラム定義の変更等にて以前は行えなかった VARCHAR型のサイズの増加変更が行えるようになりました。RENAME INDEX という構文が追加されました。

2. 導入検討フェーズ

2-2-3. 最初に考えたこと 手順1. メンテナンス対象の元テーブルをコピーして、作業用の仮テーブルを作成2. 仮テーブルに対して、カラム追加などの変更を実施3. その間、元テーブルに対して行われる更新処理について差分を記録しておく4. 仮テーブルの変更が終わったら、記録しておいた差分データを仮テーブルに反映5. 差分データの反映が終わったら、元テーブルと仮テーブルを入れ替える

2. 導入検討フェーズ

2-2.4. オンラインスキーマチェンジする為の方法(1).MySQL の InnoDB 用オンライン DDL を使用する。 →カラム追加や Optimize Table 等、実施したいことに対して実現できないケースがある

(2). スキーママイグレーション・ツールを使用する。 →「 Percona Toolkit」 pt-online-schema-change の動作内容を調べたところ、自身が最初に考えた内容と近かった為、深掘り調査を実施。

(3). スキーマをマイグレーション用レプリカに移行、リファクタリングしたレプリカを新しいマスターとして登用する。 →レプリカ遅延状況をオンライン状態で追いかけることは、現実的ではない。 また、レプリカのマスター昇格時にオンラインではなくなるタイミングが発生する。

2. 導入検討フェーズ

2-3. ツール選定 2-3-1. 選定したツール

「 Percona Toolkit」 pt-online-schema-change

PERCONA 社が開発した、 MySQL のテーブルをロックをせずに、指定のテーブルのスキーマを変更する事ができるツール。すべて Perl で作成されており、ライセンスは GPL V2 。MySQL と同様、オープンソースで提供され、ユーザは無償で利用することが可能。2017 年 02月に最終更新。更新頻度は数ヶ月単位で実施され、情報源が多い。

2. 導入検討フェーズ

2-3-2. 実際のツールの挙動手順

1. 対象テーブルと同じ構造をした作業用テーブルを作成2. 作業用テーブルに変更する ALTER 文を適用3. 3 つトリガーを作成して、対象テーブルへの挿入・削除・更新が作業用テーブルに反映されるよう設定4. 対象テーブルから作業用テーブルへトリガー経由でデータをコピー

• 5. RENAME して対象テーブルと作業用テーブルを入れ替える• 6. 入れ替え後の古いテーブルとトリガーを削除する

2. 導入検討フェーズ

• 2-4. ツールの運用環境• 2-4-1.AWS RDS(MySQL) の運用環境

• エンジン　　　　　 ： MySQL 5.6.19a• インスタンスクラス ： db.r3.xlarge

• 2-4-2.Percona Toolkit の運用環境• OS ： Amazon Linux version 2015.09• ツール : percona-toolkit-2.2.14-1.noarch.rpm• その他 :システム要件を参照

• ※最新版のツールを使用しない理由： percona-toolkit-2.2.16 を使用して動作検証した際に下記の bug情報と一致する不具合が発生した為、 percona-toolkit-2.2.14 にダウングレードして使用することに致しました。

• 不具合情報• https://bugs.launchpad.net/percona-toolkit/+bug/1498128

2. 導入検討フェーズ

• 2-4-3.AWS RDS(MySQL) パラメータグループの変更内容

• 運用中の AWS RDS(MySQL) に対して、 pt-online-schema-change を適用するにあたり、以下のパラメータグループの変更とインスタンスの再起動を実施いたしました。

2. 導入検討フェーズ

• 2-4-4.pt-online-schema-change コマンド発行時に発生した課題と回避オプション

• pt-online-schema-change コマンドの検証を実施する過程でいくつかの課題が発生。

• その中でオプション値を設定することで回避できたことについて触れます。

2. 導入検討フェーズ

• 2-4-5. 最終的なコマンドサンプル

• pt-online-schema-change • --alter "ADD カラム追加構文 " • --alter-foreign-keys-method "rebuild_constraints" • --charset "utf8mb4" • --recursion-method none • --execute t=table_name

2. 導入検討フェーズ

• 3−1. 運用実績• 3-1-1. 達成できたこと

• サービスを全く停止すること無く、下記のスキーマ変更を実現することが出来ました。

• ・ ALTER table_name ADD ( カラム追加 Null, Not Null, デフォルト値設定含む )• ・ ALTER table_name MODIFY ( カラム再編成 )• ・ ADD INDEX ( インデックス追加 )• ・ ADD CONSTRAINT FK ( 外部キー制約追加 )• ・ OPTIMIZE TABLE table＿ name ( オプティマイズ )• • ※「 Percona Toolkit」 pt-online-schema-change は上記以外にも多くのスキー

マ変更に対応しておりますが、段階的に適用範囲を広げることにし、採用した内容は上記のみとなります。

3. 運用フェーズ

• 3-1-2. アプリケーションリリース時にスキーマ変更が必要な場合の実績

• 本番運用中の RDS(MySQL) のアクセス頻度の高い主要テーブルを対象としたカラムとインデックス追加処理を pt-online-schema-change を使用して実行しました。 10 回以上の運用実績がございますが、代表的な成功例を提示いたします。

3. 運用フェーズ

• 3-1-3. バッチ処理で OPTIMIZE TABLE を実行する場合の実績

• 本番運用中の RDS(MySQL) に対して日次バッチとして pt-online-schema-change を定期実行しました。

• 日次で全行の洗い替えが発生する集計テーブルを対象とし、データーファイルのデフラグ処理を目的に 5 ヶ月以上の連続運用実績がございます。

3. 運用フェーズ

• 3-2. 運用実績 ( 障害例 )• 3-2-1. トリガー使用時のロックダウンについて

• 本番運用中の RDS(MySQL) に対して pt-online-schema-change を定期実行した際に、完全なロックダウンを経験したことが一度だけございます。

• トリガー作成時のロック競合に起因して、テーブルまたはデータベース全体がアクセス不能になりました。

• トリガーの生成または削除時に要求されるロックはメタデータロックである為、マイグレーション対象のテーブルもしくは、関連テーブルへのアクセス頻度が高すぎる場合は、トリガーの作成、削除の僅かなタイミングでロックダウンするリスクがございます。

3. 運用フェーズ

• 4-1. メリット

• 1. 共有ロック不要でスキーマ変更可能

• 2. 実行中に進行割合を確認可能

• 3. ツールの処理中にデットロックエラーが発生し、処理が落ちても、エラーメッセージを返し、ロールバックされる

• 4. ツールの処理中に強制停止した場合、ツール実行時に作成されたトリガーと一時テーブルを洗い出して削除することでリラン可能

4. 終わりに

• 4.2. デメリット

• 1. テーブルコピーを伴う為、若干の IO と CPU（最大で使用率 30％上積み）を消費する

• 2.直接 ALTER TABLE を実行するよりは、 150%以上の所要時間が必要

• 3.一時的なテーブルコピーに際して、余分なディスク容量が必要

• 4. ツールのバージョンによっては、困った不具合を抱えている為、運用回避を前提に事前検証が必要

• 5. トリガー作成・削除時にメタデータロックダウンする可能性を抱えている

4. 終わりに

• 4.3. 所感

• 冒頭で述べました、「可能な限り、サービスを停止することなく、システムの開発サイクルに合わせて、データモデルを変更する」という目的に対して、 pt-online-schema-change の導入は確実に成果がありました。

• RDS(MySQL) 自体のパラメータ変更や本当に大規模なデータ移行を除いて、システム停止を伴うメンテナンスの頻度が大きく減少しました。

• 但し、運用するシステムの RDS(MySQL)への参照・更新頻度が本当に高い場合は、このツールを使用しても解決できないケースが発生するのも確かです。

• このツールの使用に際しては、十分な検証作業と利用方針を定めた上で活用することをお勧めします。

4. 終わりに

• 4.4.免責事項• 最後になりますが、本日の発表に含まれる情報もしくは内容を利用することで直接・間接的に生じた損失に関し、弊社 ( 株式会社ビズリーチ ) と発表者は一切の責任を負わないものとします。オンラインスキーマチェンジを実行する際には、細心の注意を心掛けて下さい。

• 本日は、ご清聴ありがとうございました。

4. 終わりに