確定申告を乗り越えるDBパフォーマンス改善 - Aurora 移行の舞台裏

アプリケーション基盤開発エンジニアの Nayuta です。私が先日登壇した freee Tech Night Online #9 の様子を簡単にご紹介したいと思います。「確定申告を乗り越える DB パフォーマンス改善」をテーマとし、会計 freee のデータベース移行 (MySQL→ Aurora) についてお話しました。

登壇者達の写真

Nayuta (@NayutaYanagisaw)

  • アプリケーション基盤開発エンジニア、2019年6月に中途入社(写真左上)。
  • ストレージミドルウェアに関する仕組み作りや運用改善を担当。趣味的に MariaDB Server にコントリビュートしている。

Terasawa (@terakoya76)

  • SRE、2017年10月に新卒入社(写真右上)。
  • 人事労務 freee の開発に参画した後、SRE チームでインフラの運用・改善を担当。サービスの運用、開発者のサポート、DB の改善がミッション。

のぶじゃす (@noblejasper)

  • ラジオパーソナリティ、2017年に中途入社(写真右下)。
  • mixi、ソーシャルゲーム企業でソフトウェアエンジニアを経験し freee に。入社後はエンジニア→エンジニア採用担当→エンジニアと DevBranding を担当。
  • しゃべりたがり。声が大きい。

レプリケーション遅延が小さな Aurora を選択

nayuta が考え込んでいる写真
大変だったことを思い出しながら話しました

1年で最も負荷の高まる確定申告に向けて、どのような対策を行ったか教えてください。

Nayuta: 様々な対策を行ってきましたが、最も大きいのはデータベースを MySQL から Aurora に移行したことです。

なぜ Aurora に移行したのでしょうか?

Nayuta: Read をスケールアウトできるようにし、負荷を下げたいというのが一番のモチベーションでした。

会計 freee は、freee が提供する中では最大規模のサービスなのですが、サービスの特性上 write がとても多いんです。そのため、Aurora に移行する前はレプリケーション遅延のコントロールが難しく、レプリカをほとんど使えていない状態でした。

いままでは MySQL をスケールアップすることで負荷の増大に対応していたのですが、最近では最大に近いインスタンスタイプを使っていて、後がない状態でした。そこで、仕組み上レプリケーション遅延が小さく、read のスケールアウトが容易な Amazon Aurora への移行を決断しました。

Aurora 以外の選択肢は検討しましたか?

Nayuta: Spanner や TiDB などのいわゆる NewSQL は検討の俎上に上がりました。と言うのも、NewSQL を使えば read だけでなく write もスケールアウトできる可能性があるからです。

しかし、MySQL から NewSQL への移行は構成の変更があまりに大きく、確定申告に間に合わせるのは難しいと考えました。そこで、直近では MySQL と高い互換性を持ち、read のスケールアウトが可能な Aurora に移行することにしたんです。

もっとも、厳密な計測は行っていませんが、write 性能についても Aurora の方が MySQL よりは高いはずです。

いかにして Aurora の性能検証を行ったのか

移行前にどのような検証を行いましたか?

Nayuta: 主眼に据えたのは、本番クエリのリプレイによる性能検証です。会計 freee はかなりのトラフィックがあるサービスで、かつワークロードも非常に多様です。なので、人工的なシナリオに基づいた負荷試験をやるよりは、実際のクエリをリプレイする方がより正確に性能を見積もることができると考えました。

ちなみに、クエリのリプレイには Percona 社製の pt-upgrade というツールを改造して使ったのですが、今思えば独自にツールを開発した方が柔軟性が高かったかなと思います。これは反省点ですね。

どのような試行錯誤がありました?

Nayuta: 一部のクエリで Aurora の方が数倍レイテンシーが高くなるという現象が観測されました。IO が大量に発生しそうなクエリが多かったと記憶しています。このときは一瞬「もう移行は無理かも…」と思いましたね。

それは焦りますね。どのように対処したんでしょうか?

Nayuta: いやー、本当に焦りました。実はその後の調査で、buffer pool size を十分に大きくすれば上の問題は緩和されることがわかったんです。負荷試験のために本番より小さなインスタンスサイズを使っていたので、本番と比べて沢山の IO が発生する状態だったのが原因と推測しています。

また、この問題は本番環境では起きていないようです。実際、本番環境の DB を Aurora に入れ替えた後、主要な API のレイテンシーを監視していたのですが、大きな変動はありませんでした。

運用課題の対策としてクラスター切り替えの仕組みを用意

terasawa が神妙な顔をしている写真
神妙な面持ちで語るTerasawaさん

運用面での検証で苦労したことはありましたか?

Terasawa : マスター昇格のオペレーションの準備が大変でした。会計 freee は、サイズが非常に大きいテーブルが多く、マイグレーションの対象によっては完了までに1日近くかかってしまうものもあるんです。

そういった長時間のマイグレーションに対して、これまでは事前にマイグレーションを掛け終えた DB を別途用意しておき、定期メンテナンス時にアプリケーションからの向け先を入れ替えるマスター昇格を活用していました。

RDS for MySQL ではマスター昇格機能が Managed Service の一部として提供されていましたが、Aurora では内部的な仕組みが違うこともあり、そういったオペレーションをサポートする機能が提供されていません。そのため、こちら側でそこの仕組みを整備する必要がありました。

Nayuta: Percona の pt-online-schema-change を使うという手もあったと思いますが、何でマスター昇格の仕組みを作ったんでしたっけ?

Terasawa : 今回は性能特性の異なる Database Engine への移行ということもあり、移行直後に何かしらの問題が発生した場合、直ぐに切り戻したいと考えていたんですよね。そのため、移行時および移行後の運用双方で利用できるクラスター切り替えによる仕組みを整備することに決めました。

具体的には新旧マスター間で双方向レプリケーションを張って、データの書き込みを同期し、その上で実際に書込み可能なマスターは常に1つのみに制限します。あとは切り替えのタイミングで書き込み可能状態とトラフィックの向け先の切り替えを行うという仕組みを用意しました。

Nayuta: そういえば、3-4年前にの Aurora に移行する目論見はあったらしいんですが、当時はいま言った問題を乗り越えられず中止になったようです。

Terasawa: 我々が入社する前の話ですが、そう考えると3年越しの悲願が達成されたと言ってもよさそうですね(笑)

移行の判断から約2ヶ月で移行を完了

具体的に移行はどのように行いましたか?

Nayuta: あまりに大変すぎて移行時の記憶が飛んでいます…

そこを何とか、思い出してください。お願いします!

Nayuta: そうですね…、2020年の11月に経営陣の GO が出て、12月の中旬に移行したのですが、移行後問題が生じた場合に切り戻すための仕組みや手順の整備がとにかく大変だったと思います。そのあたりは主に Terasawa さんが頑張ってくれました。

Terasawa : 前提として、マスターの負荷が非常に高いので、レプリケーション遅延を考慮した移行手順および切り戻しのシナリオを整えるのに苦労した記憶がありますね。

移行作業自体は無事に済みましたか?

Nayuta: MySQL に戻せる状態を2〜3週間維持して、無事に年末年始も超えられたので、1月頭に移行完了となりました。様々なトラブルを想定して作業に臨みましたが、実際は割とスムーズに行きましたね。

移行してみてどのようなメリットがありましたか?

Nayuta: やはりレプリケーション遅延が小さいのが良いですね。今後負荷が高まった際には、クエリをレプリカに逃がすという選択肢が取りやすくなりました。Write 性能も高く DB 関連のアラートが激減したと思います。Terasawa さんからも何かありますか?

Terasawa : レプリカへクエリを逃がすのもそうですし、Parallel Query の利用など、アプリケーション開発者からも負荷を和らげる取り組みがしやすくなったのはとても大きいと思います。何より無事に移行が完了して、ホッとしています。

のぶじゃす: ぜひ、確定申告の際には『会計freee』を使ってみてください。安定していますよ!

イベントの本編はここまでです。この後は「アフタートーク」でより深いな技術談議が繰り広げられました。

▶freee Tech Night 次回は4月23日に

「freee Tech Night Online #10 人事労務freee、EKS移行」を開催!

freee-tech-night.connpass.com

▶今回のイベントのアーカイブ(録画)

youtu.be