freeeの開発情報ポータルサイト

トップ > Advent Calendar 2023 > 安全なデータベース削除オペレーションの自動化事例

安全なデータベース削除オペレーションの自動化事例

Advent Calendar 2023 ピックアップ DBRE

この記事は freee 基盤チーム Advent Calendar 2023 の 20 日目の記事です。

こんにちは、freee の Database Reliability Engineering（DBRE）チームでエンジニアをしている清水と申します。今回は freee のデータベース運用業務の自動化事例について紹介します。

データベース削除に関する課題

頻繁に作成・削除されるデータベース

freee では RDBMS として Amazon Relational Database Service のうち、Amazon Aurora MySQL 互換エディション（以降 Aurora とよぶ） と RDS for MySQL（以降 RDS とよぶ）を主に利用しています。これらのクラスタやインスタンス（以降まとめてデータベースとよぶ）は、サービスのリリースやクローズ以外にも日常的に作成や削除が頻繁に行われています。

例えば freee では以下のような運用でデータベースの作成が発生します。

  • 本番データのマスキングやコピーで使う一時的なデータベースの構築
  • アップグレードで切り替え先になる新バージョンのデータベースの用意1

作成されたデータベースと入れ替えられる元のデータベースは、コストや管理などの観点で削除する必要があります。

削除作業の内容

本来残しておくべきデータベースを誤って削除した場合は損害が大きいため、慎重に削除を行う必要があります。また削除にあたって必要な作業としては、時系列順に以下のようなものが挙げられます。

  1. 過去一定期間コネクションがないことの確認
  2. 余計なアラートを上げないための監視ダウンタイム設定2
  3. スナップショットの取得
  4. 削除保護の無効化
  5. レプリカ、プライマリの順でインスタンスを削除
  6. 自動バックアップ有効化してクラスタ削除

作業手順が多いことに加え、操作後にデータベースの状態変更が完了するのを待たなければならない場面も多いです。また Aurora と RDS の仕様の違いによる手順の分岐もあります。人間による操作ミスが入る余地が多いため、特に本番環境では安全を期して DBRE のメンバーがペアで作業を行っていました。

新規サービスの開発や既存サービスのマイクロサービス化などによりデータベースの数は増加し、削除の発生頻度は上がってきており、定型作業にもかかわらず工数を取られるオペレーションになりつつありました。

データベース削除ツール

ツールの実装

先述のようなデータベース削除に関する課題を解決するため、現在では削除のためのツールを作成して利用しています。ツールでは手動で行われていた作業の自動化に加えて、削除開始前などのタイミングで Slack への通知なども行われます。

実装方法としては AWS Step Functions（以降 Step Functions とよぶ）のステートマシンから、各ステップごとに実装された AWS Lambda の関数を呼び出す形になっています。Aurora と RDS の差分は関数で実行されるスクリプトで吸収しています。

ステートマシンの実行例
ステートマシンの実行例（ステップが多いので一部抜粋）

Step Functions を利用することで、各ステップの実行順序の制御や進捗状況の可視化、データベースの状態変化完了までの待機の実装のしやすさなどに加え、ステートマシンをエンドポイントとして使えることで以下のメリットがあります。

  • 人間（CLI またはマネジメントコンソール）とツール（SDK）の両方から実行できる
  • AWS IAM（以降 IAM とよぶ）を使った実行権限の制御ができる（権限管理の仕組みを独自に作る必要がない）
  • 対象クラスタやオプションなどを実行時にパラメータで指定できる

導入した所感と今後について

現在のところ、以前から手動でのデータベース削除を許可している IAM Role にのみツールの実行権限を渡していますが、作業時間の削減効果を感じています。今後はこのツールをデータベース削除の基本コンポーネントとして、他の運用ツールからも呼び出してさらに自動化を進めていく予定です。

ツールからデータベースを削除する場合、通常は直接 AWS API を呼び出すことになります。IAM では設定やタグなどでしか対象リソースの絞り込みが行えず、実際にそのデータベースがどのような状態になっているかは判断できません。そのため各ツールで事前のチェック処理を実装する必要がありますが、今回紹介したステートマシンを呼び出すことにより「このような状態であればデータベースを削除してもよい」という認識をコード化して必ずそれを保証できるようになります。また様々なツールに同じような実装が重複することも防ぐことができます。

誤った操作が防がれ安全なプロセスでデータベースを削除できるようになったので、ツールを介せば削除操作を DBRE からプロダクトチーム側に委譲することもやりやすくなる可能性もあります。

おわりに

freee の DBRE チームでは、サービスのパフォーマンス改善や安定稼働に向けた取り組みに加えて、データベースが増えてもスケールするような運用業務の効率化にも取り組んでいます。今回はその一部である、データベースの削除オペレーションの自動化について紹介しました。

21 日目の明日は、同じくDBRE チームの shinta さんの記事です。お楽しみに！

  1. アップグレードの詳細については RDS Proxyを用いたオンラインスイッチオーバーによるMySQLのアップグレードについて - freee Developers Hub をご参照ください↩
  2. 監視に使っている Datadog が対象リソースからメトリクスを取得できなくなると No Data アラートが通知されるため、通知を無効化してノイズにならないようにする必要があります。↩