どうも佐野です。トレタのインフラはEngineyardでワオワオやってたんですが、あの、なんていうのAurora？それを使いたかったわけです。
さて、私が書いた前々回の記事にて、「コア機能のAWS化」を今後のTODOとして挙げていましたが、5/9にEngineyardからAWSへの移設が完了していました。EngineyardはRailsやnodejsなどのWEB-DB環境を簡単に構築できるPaaSです。Herokuとの違いはサーバにsshしたり、chefを利用してFluentdなどのミドルウェアを入れたり、既存のコンフィグレーションをカスタマイズしたりすることができる点が挙げられます。比較的自由度の高いPaaSと言えるでしょう。トレタでは創業〜先月までお世話になりました。
今回は移設とAuroraの運用に関するTipsの紹介になります。なお、本記事に示す設計・運用方針はAWSのソリューションアーキテクトの支援を得て決定したものではなく、私の見解で決定したものなのでご了承ください。ベストプラクティスではないかもしれません。
以下、目次になります。
- 移設
- Auroraのコンフィグレーション
- 基本、マスターのみを使う
- スロークエリの検出
- フェイルオーバするとき
- スケールアップするとき
- Auroraのメンテナンスをするとき
- リストアするとき
- MySQL on EC2からレプリケーションを行う場合
- 失敗したこと
1. 移設
運用エンジニアを長らくやっていると移設は慣れっこなのですが、弊社エンジニアに移設経験者が私しかいませんでした。MTGで「なるほどー」という空気になったので書いてみます。システムの移設をやったことがない、これからやる、という方がいらっしゃいましたら参考にしてみてください。
移設は往々にしてデータをどのようにして新環境に移すか？というのが技術的な課題になります。トレタの場合、MySQL, Redisといったレプリケーション可能なよく知られたデータストアを使っていたので、技術的な難しさはほとんどなく、どちらかというと社外を含む関係各所へのメンテナンスの日程の調整の方が骨が折れました。このあたりはセールスチームなどの協力を得て今回はスムースに調整を進めることができました。
技術的な移設手順は下記の通り。
1.1. これを
Engineyardで稼働している状態です。AWSに新環境を作っておきます。
1.2.こうして
データストアは新環境からレプリケーションを張っておきます。Engineyardはsshポートがグローバルに開放されているので、sshトンネルを張ってトンネル経由でレプリケーションを行いました(Engineyardのサポートに連絡すれば3306ポートをIP制限掛けてグローバルに開放してくれたかもしれない)。またsshプロセスはmonitで監視し、もし落ちた際は自動再起動するようにしておきます。Redisについても同様、sshトンネル経由で6379ポートに接続してデータの同期を行います。
Auroraから外部のMySQLにレプリケーションを行う場合(Auroraがスレーブ、MySQLがマスタ)は、 call mysql.rds_set_external_master のようなストアドで行います。このあたりはRDSのマニュアルを参照してください。で、今回はEngineyardのMySQLにsshトンネル経由でレプリケーションを行う必要があるため、AWS上に踏み台のMySQLを用意し、カスケード接続でAuroraにデータを同期させます。図の通り、Engineyard MySQL <- (sshトンネル) <- EC2 MySQL <-(ストアド利用) <- Auroraというレプリケーションチェーンになります。
1.3. こうやって
これはメンテナンス時間中に行います。まずシステムをメンテナンス状態にします。そしてデータストアのレプリケーション遅延がゼロになっていることを確認して、ウェブアプリケーションのデータストアの接続先が新環境に向くようにします。終わったらメンテナンスを解除します。トレタではメンテナンス時間は1時間設けました(実作業時間は確認を含めて30分程度でした)。
蛇足ですが、Auroraなどのデータストアはパブリックアクセス可能な状態にし、旧環境であるEngineyardのAppサーバからのアクセスを許可しておく必要があります。
1.4. こう
あとは日中帯に落ち着いて新環境にデプロイを行い、DNSを新環境に向けて終わりです。
2. Auroraのコンフィグレーション
長らくMySQL運用おじさんをやっていた身としてはやはりコンフィグが気になります。私が気にした箇所についていくつか抜粋します。総括すると、大抵のものはデフォルトで良さそうな印象を受けました。
クラスタパラメータグループ
* 文字コード
character_set_client = utf8
character_set_server = utf8
character_set_connection = utf8
character_set_database = utf8
character_set_results = utf8
skip-character-set-client-handshake = 1
* バイナリログ
binlog_format = MIXED
log_slave_updates = 1(デフォルト)
sync_bin_log = 1(デフォルト)
* InnoDB
innodb_commit_concurrency = 0(デフォルト)
innodb_purge_threads = 1(デフォルト)
innodb_file_per_table = 1(デフォルト)
innodb_flush_log_at_trx_commit = 1(デフォルト)
innodb_support_xa = ON(デフォルト)
文字コード周りとバイナリログの有効化を設定してあります。移設の段階でカスケード接続させるのでlog_slave_updatesは1にします。sync_bin_logは1で良いでしょう。またバイナリログの保持期間を設定する expire_logs_days は無く、 call mysql.rds_set_configuration('binlog retention hours', 24); などとしてストアドでバイナリログの保持期間を設定する必要があります。InnoDB関連でいくつか気になるものがありますが、デフォルトで納得できる値になっていました。
DBパラメータグループ
* 接続周り
max_connections = 自動計算(デフォルト)
thread_cache_size = 自動計算(デフォルト)
max_allowed_packet = 134217728(128M)
* スローログ
slow_query_log = 1
long_query_time = 2
log_queries_not_using_indexes = 1
log_output = TABLE(デフォルト)
* 各種バッファ
tmp_table_size = 67108864(64M)
max_heap_table_size = 67108864(64M)
sort_buffer_size = 8388608(8M)
join_buffer_size = 131072(128K)
innodb_sort_buffer_size = 1M(デフォルト)
innodb_log_buffer_size = 8M(デフォルト)
* InnoDB
innodb_buffer_pool_size = 自動計算(デフォルト)
innodb_flush_method = O_DIRECT(デフォルト)
innodb_buffer_pool_dump_at_shutdown = 1(デフォルト)
innodb_buffer_pool_load_at_startup = 1(デフォルト)
* 分離レベル
tx_isolation = REPEATABLE-READ(デフォルト)
* クエリキャッシュ
query_cache_size = 自動計算(デフォルト)
query_cache_type = 1(デフォルト)
接続周りの設定、スローログ、各種バッファ、InnoDB関連、トランザクション分離レベル、クエリキャッシュあたりをケアしました。
thread_cache_size、max_connectionsが自動計算されるようになっていて、計算後の値も適切だったのでAuroraの自動計算に任せました。max_allowed_packetは自分のMySQLの秘伝のタレの値をそのまま転用。
スローログについては閾値を2秒とします。RDSの場合、log_outputはTABLEとなり、これはmysql.slow_logにログが蓄積されることを意味します。
バッファの数値はちょいちょいいじりました。とはいえこれらの数値の根拠はなくて、私の経験的にデフォルトではちょっと小さいのではないか？と思ってこのような数値にしてあります。
クラスタパラメータグループだけでなくDBパラメータグループにもInnoDB周りの設定があります。性能面において最も重要な設定の一つであるinnodb_buffer_pool_sizeはこちらにあり、これもAuroraによって自動計算されるようになっています。innodb_flush_methodもO_DIRECTになっており、これらは適切な値だったのでとくにいじりませんでした。
確認したところ、tx_isolation = REPEATABLE-READがデフォルトで設定されていたので特に変更せず。
デフォルトで有効になっており、キャッシュサイズは自動計算されていました。実はこれが個人的にちょっと悩ましくて、私の経験上、過去にクエリキャッシュが効果を発揮したことはあまりなかったです(根拠のあるデータを出すことができずすみませんが...)。インデックスが効いていれば十分高速ですし。無効にしたいところだが、Auroraの推奨？と判断して特に変更せずこのままとしました。
3. 基本、マスターのみを使う
現状のトレタのトラフィックでは1DBで十分です。1DBでの運用を行います。(スレーブは深夜のバッチ処理で使うようにしてありますが)基本的にスレーブは昇格用のスタンバイです。
4. スロークエリの検出
上の方に書いた通り log_output = TABLE のためスロークエリは mysql.slow_log テーブルに出力されるようになります。監視用に立てたインスタンスから次のようなクエリを定期的に投げて、スロークエリを検出しています。
select * from mysql.slow_log where start_time > '%s' order by start_time
トレタでは次の様にしてSQL警察がslackに通知するようにしています。
5. フェイルオーバするとき
フェイルオーバーボタンをポチります。数十秒〜1分程度です。
6. スケールアップするとき
インスタンスサイズの大きいreader*1を優先度tier-0(優先度-0)*2で作成し、フェイルオーバーを行います。
7. Auroraのメンテナンスをするとき
Auroraも他のRDSがサポートしているエンジン同様、Aurora自体のメンテナンス(OSアップグレード、バージョンアップetc)が必要なケースがあります。トレタではAuroraのメンテナンスはフェイルオーバーで行う方針です。つまり先にスレーブをupgradeしてそれをマスタに昇格させます。このリンクのようにAuroraのメンテナンス時はフェイルオーバーじゃなくて再起動の方が早い、つまり無下に「upgrade now」を実行してもよいと言及されている場合もありますが、私が実験した結果では、upgrade nowの停止時間は短い時は短いが遅長い時もある、フェイルオーバは安定して1分程度の停止時間、という結果になったので停止時間が安定している方を採択する方針です。upgrade nowの停止時間はAuroraのメンテナンスの内容、インスタンスサイズ、実施時の負荷などに依存するのかもしれません。
- db.r3.largeをupgrade now: 16秒停止
- db.r3.largeをフェイルオーバ: 60秒停止
- db.r3.xlargeをupgrade now: 1分59秒停止
- db.r3.xlargeをフェイルオーバ: 55秒停止
なお、ここでいう停止時間とは、インターネット経由でシステムのエンドポイントを叩き、オフラインになった時間を計測しています。なのでAurora自体の停止時間に加えて、ヘルスチェックなどで切り離されてしまった時間から復活する時間も含まれています。
8. リストアするとき
任意の時刻でのpoint-in-timeリカバリが可能です。もし時刻ではなく、たとえばオペミスでdrop tableしちゃってdrop tableの直前まで戻したい場合などは、バイナリログを活用することになるでしょう。
9. MySQL on EC2からレプリケーションを行う場合
AuroraをマスタとしてEC2など外部のMySQLをスレーブにするパターンです。移設のときと逆ですね。こちらについてはいつもどおりAuroraにレプリ用のユーザを作成して 外部のMySQLから change master すればよいです。
10. 失敗したこと
リザーブドインスタンスにし忘れた...:(；ﾞﾟ'ωﾟ'):
うーむ...。RDSってあとからリザーブドにできなかったよね...？？？
(追記)各所よりあとからリザーブにできると教えていただきました
おわり
