チームに最適なデータベース復旧戦略の選び方
データベースマイグレーションを本番環境にデプロイした直後、モニタリングダッシュボードに障害クエリの急増が表示されました。あなたのチームは今、よくある状況に直面しています。それを迅速に修正する必要があります。しかし、修正方法は技術的な能力だけに依存するわけではありません。それは、あなたが誰であるか、どのくらいの頻度でデプロイするか、そしてどのような種類のアプリケーションを実行しているかによって異なります。
データベース復旧に万能の答えはありません。週に一度リリースする小規模チームに有効な戦略は、1日に10回デプロイするチームでは失敗します。重要なのは完璧な戦略を見つけることではなく、プレッシャーがかかっても一貫して実行できる戦略を見つけることです。
チーム規模とデプロイ頻度が重要
週に一度デプロイする3人チームの復旧課題は、1日に複数回デプロイする20人チームとは大きく異なります。
デプロイ頻度が低い場合、何が変更されたかを正確に把握できます。先週のマイグレーションは数件だけで、チーム全員が覚えています。問題が発生した場合、ダウンマイグレーションを実行してスキーマ変更を元に戻すことを検討できます。他のチームメンバーの作業と衝突するリスクは低いです。なぜなら、同時にデプロイしている人が他にいないからです。
では、数時間おきにデプロイするチームを想像してみてください。あなたのマイグレーションに問題があることに気づく頃には、他の3人の開発者があなたのマイグレーションの上に新しいマイグレーションをプッシュしているかもしれません。この環境でダウンマイグレーションを実行するのは危険です。あなたの変更は元に戻せますが、問題のない他の誰かのマイグレーションも消してしまう可能性があります。衝突リスクは高く、その結果は厄介です。
高頻度デプロイチームにとって、ダウンマイグレーションは責任負担になります。理論上は機能しますが、実際には混乱を引き起こします。これらのチームは、自分たちだけが変更を行っていると仮定しない復旧戦略を必要としています。
ダウンタイム許容度が選択肢を左右する
すべてのアプリケーションが、データベース問題を修正している間にダウンできるわけではありません。ダウンタイムの許容度は、どの復旧戦略が利用可能かを直接決定します。
営業時間中に50人が使用する社内アプリケーションを実行している場合、5分間システムを停止できるかもしれません。これにより、バックアップからの復元や、完了までに時間がかかるダウンマイグレーションの実行が可能になります。ユーザーは不満を感じるでしょうが、ビジネスへの影響は限定的です。
次に、毎秒数千のリクエストを処理する公開アプリケーションを考えてみてください。1分のダウンタイムが収益を損失し、ユーザーの信頼を損なう可能性があります。バックアップからの復元には20分以上かかる可能性があります。それは許容できません。このシナリオでは、ロールフォワードがほぼ必須です。問題を修正する新しいマイグレーションを作成し、デプロイして、先に進みます。修正は数分ではなく数秒で適用されます。
同じロジックが補償スクリプトにも適用されます。リスクの高い変更に取り組んでいることがわかっている場合は、元のマイグレーションをデプロイする前に補償スクリプトを準備してください。何かが壊れるまで待ってはいけません。プレッシャーがかかると、締め切りの中で正しいSQLを書く能力は大幅に低下します。事前に作成されたスクリプトは、その認知的負荷を取り除きます。
変更の種類がリスクレベルを決定する
すべてのデータベース変更が同じリスクを伴うわけではありません。NULL可能なカラムの追加や新しいテーブルの作成は低リスクです。これらの変更は既存のクエリを壊さないため、ロールフォワードが容易です。カラムを追加し、それを使用するアプリケーションコードをデプロイすれば、すべてが機能します。
しかし、カラムの削除、データ型の変更、テーブル間のデータ移行は高リスクです。これらの変更は、本番環境でまだ実行中のクエリを壊す可能性があります。テーブルを数分または数時間ロックする可能性があります。マイグレーションロジックにバグがある場合、データを破損する可能性があります。
高リスクの変更については、事後対応的な復旧に依存すべきではありません。マイグレーションを実行する前に復旧パスを計画する必要があります。つまり、事前に補償スクリプトを作成し、ステージング環境でロールフォワードパスをテストし、マイグレーションが予想より長くかかった場合や成功したが誤ったデータを生成した場合に何を行うかを正確に把握しておく必要があります。
デフォルト戦略：まずロールフォワード
多くのチームと協力してきた結果、明確なパターンが浮かび上がります。成熟したチームはデフォルトでロールフォワードを採用します。ダウンマイグレーションはステージング環境または非常に初期の開発段階に限定されます。バックアップは壊滅的な障害に対するセーフティネットとして扱われ、日常的なロールバックメカニズムとしては使用されません。補償スクリプトは、スキーマを変更せずにデータを修復する必要がある場合に使用されます。
このパターンが機能する理由は一貫性です。常にロールフォワードを使用すると、復旧を容易にする習慣が身につきます。より小さく、より頻繁なマイグレーションを作成するようになります。毎回ロールフォワードパスをテストします。問題を修正することは、最後の変更を元に戻すことではなく、別の変更をデプロイすることを意味するという考え方に慣れてきます。
戦略を混在させるチームはしばしば苦労します。ある週はダウンマイグレーションを使用し、次の週はバックアップから復元し、その次の週はその場で補償スクリプトを作成します。インシデントが発生するたびに、プレッシャーの中で新しい決定を下す必要があります。そこでミスが発生します。
復旧戦略選択のための実践的チェックリスト
- チームのデプロイ頻度はどのくらいですか？1日1回以上の場合は、本番環境でのダウンマイグレーションを避けてください。
上記のチェックリストは良い出発点ですが、視覚的な判断ツリーがあれば、プレッシャーがかかった状況でも選択がより明確になります。以下は、チームの復旧戦略選択をガイドするシンプルなフローチャートです。
- アプリケーションは5分間のダウンタイムに耐えられますか？耐えられない場合、ロールフォワードをデフォルトにすべきです。
- マイグレーションはカラムを追加していますか、それとも削除していますか？高リスクの変更には、事前に作成された補償スクリプトが必要です。
- 本番環境をミラーリングしたステージング環境はありますか？そこで最初に復旧パスをテストしてください。
- チームはデフォルト戦略に合意していますか？完璧さよりも一貫性が重要です。
まとめ
データベース復旧戦略は技術的な決定ではありません。それは、チームの働き方、リリース頻度、ユーザーの許容度によって形作られるチームの決定です。最善の戦略とは、問題が発生したときにチームがためらわずに実行できる戦略です。1つを選び、練習し、デフォルトにしてください。その一貫性は、どんなツールやスクリプトよりも多くの時間を節約してくれます。