20170329 D3 DBAが夜間メンテをしなくなった日発表資料

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-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 1.− 克服すべき運用課題
弊社はベンチャー企業、スピード感を大切にしている為、システムの開発リリースサ
イクルは、短いスプリントで実施致します。
その間に発生したデータモデルの変更要求は、可能な限り、サービスを停止すること
なく実施する必要がありました。
DBA としては、成果とリスクの狭間で苛まれる情けない課題を抱えておりました。

2 2.− 達成するにあたって検討したこと
(1).MySQL の InnoDB 用オンライン DDL を使用する
(2). スキーママイグレーション・ツールを使用する
「 Percona Toolkit 」 pt-online-schema-change, Facebook OSC, LHM, oak-online-alter-table 等。
(3). スキーマをマイグレーション用レプリカに移行、リファクタリングしたレプリカ
を新しいマスターとして使用する

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

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

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

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

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

2-2.4. オンラインスキーマチェンジする為の方法
(1).MySQL の InnoDB 用オンライン DDL を使用する。
→ カラム追加や Optimize Table 等、実施したいことに対して実現できないケースが
ある
(2). スキーママイグレーション・ツールを使用する。
→ 「 Percona Toolkit 」 pt-online-schema-change の動作内容を調べたところ、自身が最初
に考えた内容と近かった為、深掘り調査を実施。
(3). スキーマをマイグレーション用レプリカに移行、リファクタリングしたレプリカ
を新しいマスターとして登用する。
→ レプリカ遅延状況をオンライン状態で追いかけることは、現実的ではない。
また、レプリカのマスター昇格時にオンラインではなくなるタイミングが発生
する。

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

2-3-2. 実際のツールの挙動手順
1. 対象テーブルと同じ構造をした作業用テーブルを作成
2. 作業用テーブルに変更する ALTER 文を適用
3. 3 つトリガーを作成して、対象テーブルへの挿入・削除・更新が作業用テーブルに
反映されるよう設定
4. 対象テーブルから作業用テーブルへトリガー経由でデータをコピー
• 5. RENAME して対象テーブルと作業用テーブルを入れ替える
• 6. 入れ替え後の古いテーブルとトリガーを削除する

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

• 2-4-4.pt-online-schema-change コマンド発行時に発生した課題と回避オプション
• pt-online-schema-change コマンドの検証を実施する過程でいくつかの課題が発生。
• その中でオプション値を設定することで回避できたことについて触れます。

• 2-4-5. 最終的なコマンドサンプル
• pt-online-schema-change
• --alter "ADD カラム追加構文 "
• --alter-foreign-keys-method "rebuild_constraints"
• --charset "utf8mb4"
• --recursion-method none
• --execute t=table_name

• 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-1-2. アプリケーションリリース時にスキーマ変更が必要な場合の実績
• 本番運用中の RDS(MySQL) のアクセス頻度の高い主要テーブルを対象としたカラムと
インデックス追加処理を pt-online-schema-change を使用して実行しました。 10 回以上の
運用実績がございますが、代表的な成功例を提示いたします。

• 3-1-3. バッチ処理で OPTIMIZE TABLE を実行する場合の実績
• 本番運用中の RDS(MySQL) に対して日次バッチとして pt-online-schema-change を定期実行
しました。
• 日次で全行の洗い替えが発生する集計テーブルを対象とし、データーファイルのデフ
ラグ処理を目的に 5 ヶ月以上の連続運用実績がございます。

• 3-2. 運用実績 ( 障害例 )
• 3-2-1. トリガー使用時のロックダウンについて
• 本番運用中の RDS(MySQL) に対して pt-online-schema-change を定期実行した際に、完全な
ロックダウンを経験したことが一度だけございます。
• トリガー作成時のロック競合に起因して、テーブルまたはデータベース全体がアクセ
ス不能になりました。
• トリガーの生成または削除時に要求されるロックはメタデータロックである為、マイ
グレーション対象のテーブルもしくは、関連テーブルへのアクセス頻度が高すぎる場
合は、トリガーの作成、削除の僅かなタイミングでロックダウンするリスクがござい
ます。

• 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. 終わりに

20170329 D3 DBAが夜間メンテをしなくなった日発表資料

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to 20170329 D3 DBAが夜間メンテをしなくなった日発表資料 (20)

More from dcubeio (20)