フォント変更版：「DBAが夜間メンテをしなくなった日」発表資料

1. AWS RDS(MySQL)をオンサービスのまま
スキーマモデル変更する運⽤を
１年間続けた所感
DBAが夜間メンテをしなくなった⽇

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

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.最終的なコマンドサンプル
アジェンダ

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

5. 4.終わりに
4-1.メリット
4.2.デメリット
4.3.所感
4.4.免責事項
アジェンダ

6. 1-1.⾃⼰紹介
⽒名：益⼦ 徹
経歴：
・2002年 新卒で中堅SIerに⼊社、テキストマイニングツールの
パッケージソフト開発から⼤⼿製造業、サービス業向けの受託開発
に従事。
・2013年 株式会社ビズリーチに⼊社、弊社サービスのDBA,インフ
ラからスマートフォンアプリケーションの製造・運⽤、開発部隊の
マネジメントまで幅広く担当。
1.はじめに

7. 1­2.本⽇お話すること
アクセス頻度の⾼いWebサービスにて、MySQL(InnoDB)を利⽤し
た場合に於いても、サービスを運⽤したまま、スキーマ変更を実施
する運⽤経験についてお話します。
1.はじめに

8. 補⾜：
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.はじめに

9. 2­1.克服すべき運⽤課題
弊社のいくつかのサービスでは、AWS RDS(MySQL)を利⽤したサービス開発が⾏
われております。
データモデルの整合性を保つ為、MySQLのテーブル間に外部キー制約を貼ることを
基本ルールとしておりました。
MySQLでテーブルへのカラム追加やテーブルの再編成などを⾏うと、その間テーブ
ルと関連テーブルに共有ロックが発⽣致しますが、サービスが成⻑する(各テーブル
のデータ量、起点テーブルに紐づく関連テーブルの数、特定テーブルに対するアク
セス頻度が増加)に連れ、オンサービス中における共有ロックの発⽣時間の増加や、
共有ロックが原因で発⽣するシステム停⽌障害がリスクとなりました。
2.導⼊検討フェーズ

10. 2­1.克服すべき運⽤課題
弊社はベンチャー企業、スピード感を⼤切にしている為、システムの開発リリース
サイクルは、短いスプリントで実施致します。
その間に発⽣したデータモデルの変更要求は、可能な限り、サービスを停⽌するこ
となく実施する必要がありました。
DBAとしては、成果とリスクの狭間で苛まれる情けない課題を抱えておりました。
2.導⼊検討フェーズ

11. 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.導⼊検討フェーズ

12. 2-2-2.InnoDBとオンライン DDL について
(1).MySQL5.1以前のバージョン
「1­2.本⽇お話すること」の補⾜ 事項で記述した動作仕様となります。
2.導⼊検討フェーズ

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

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

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

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

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

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

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

20. 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.導⼊検討フェーズ

21. 2-4-3.AWS RDS(MySQL) パラメータグループの変更内容
運⽤中のAWS RDS(MySQL)に対して、pt-online-schema-changeを適⽤するにあ
たり、以下のパラメータグループの変更とインスタンスの再起動を実施いたしまし
た。
2.導⼊検討フェーズ

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

23. 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.導⼊検討フェーズ

24. 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.運⽤フェーズ

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

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

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

28. 4-1.メリット
1.共有ロック不要でスキーマ変更可能
2.実⾏中に進⾏割合を確認可能
3.ツールの処理中にデットロックエラーが発⽣し、処理が落ちても、エラーメッ
セージを返し、ロールバックされる
4.ツールの処理中に強制停⽌した場合、ツール実⾏時に作成されたトリガーと⼀時
テーブルを洗い出して削除することでリラン可能
4.終わりに

29. 4.2.デメリット
1.テーブルコピーを伴う為、若⼲のIOとCPU（最⼤で使⽤率30％上積み）を消費す
る
2.直接 ALTER TABLEを実⾏するよりは、150%以上の所要時間が必要
3.⼀時的なテーブルコピーに際して、余分なディスク容量が必要
4.ツールのバージョンによっては、困った不具合を抱えている為、運⽤回避を前提
に事前検証が必要
5.トリガー作成・削除時にメタデータロックダウンする可能性を抱えている
4.終わりに

30. 4.3.所感
冒頭で述べました、「可能な限り、サービスを停⽌することなく、システムの開発
サイクルに合わせて、データモデルを変更する」という⽬的に対して、pt-online-
schema-change の導⼊は確実に成果がありました。
RDS(MySQL)⾃体のパラメータ変更や本当に⼤規模なデータ移⾏を除いて、システ
ム停⽌を伴うメンテナンスの頻度が⼤きく減少しました。
但し、運⽤するシステムのRDS(MySQL)への参照・更新頻度が本当に⾼い場合は、
このツールを使⽤しても解決できないケースが発⽣するのも確かです。
このツールの使⽤に際しては、⼗分な検証作業と利⽤⽅針を定めた上で活⽤するこ
とをお勧めします。
4.終わりに

31. 4.4.免責事項
最後になりますが、本⽇の発表に含まれる情報もしくは内容を利⽤することで直
接・間接的に⽣じた損失に関し、弊社(株式会社ビズリーチ)と発表者は⼀切の責任を
負わないものとします。オンラインスキーマチェンジを実⾏する際には、細⼼の注
意を⼼掛けて下さい。
本⽇は、ご清聴ありがとうございました。
4.終わりに