サービスのデータベースを、アプリを作ったエンジニアがそのまま面倒を見ている会社は少なくありません。普段は問題なく動いていても、障害が起きたときに誰が何を見るのか、そもそも平常時に何をしておくべきなのかが決まっていないことがよくあります。この記事は専任の DBA (データベース管理者) を置いていない会社の経営者やサービスの責任者に向けて、最低限やることと、それを誰に任せるかの選び方を整理します。
自社に残るのは「見張る」と「直す」
Amazon RDS や Cloud SQL のようなマネージドサービスを使っていれば、バックアップ、ソフトウェアの更新、故障の検知と切り替えといった作業の多くはクラウドの事業者が受け持ちます。一方で、クエリが遅くなっていないか、データが想定どおりに増えているかを見張り、問題が起きたら原因を突き止めて直す作業は、どのマネージドサービスでも利用者の側に残ります。
DBA がいない会社が決めるべきなのは、この残った作業を誰が受け持つかです。
クラウドと自社の受け持ち
Amazon RDS の公式ドキュメントには、自社で動かす場合、EC2 に自分で入れる場合、RDS を使う場合で、誰が何を受け持つかの表があります。要点をまとめると次のとおりです。
| 作業 | 自社のサーバー | EC2 に自分で入れる | Amazon RDS |
|---|---|---|---|
| ハードウェア・電源・ネットワーク | 自社 | AWS | AWS |
| OS とデータベースのインストール・更新 | 自社 | 自社 | AWS |
| バックアップ | 自社 | 自社 | AWS |
| 高可用性 (故障時の切り替え) | 自社 | 自社 | AWS |
| アプリに合わせた最適化 | 自社 | 自社 | 自社 |
同じドキュメントでは、クエリのチューニングは利用者の責任であり、監視とチューニングは環境ごとに異なるため利用者が受け持つ、と書かれています。クエリの速さはテーブルの設計、データの量、アプリの使い方によって変わるため、事業者が一律に面倒を見ることができないからです。
つまり、マネージドサービスに移すことで「サーバーを守る」作業はほぼ無くせますが、「自社のデータとクエリを見張って直す」作業は無くなりません。
最低限やること
DBA がいなくても、次の 6 つは誰かが受け持つ必要があります。
- 接続できない、応答が極端に遅い、ディスクが埋まりそうといった、止まったときや止まりかけたときの状態に通知で気づけるようにします。クラウドの標準の監視 (Amazon CloudWatch、Cloud Monitoring など) で設定できます。
- 遅いクエリやロック待ちが増えていないかを見て、遅くなったときに気づけるようにします。障害は「止まる」前に「遅くなる」形で現れることがよくあります。詳しくは データベース監視とは で説明しています。
- 注文が入らない、決済の失敗が増えた、バッチ処理が溜まっているといった業務の数字の変化に気づけるようにします。こうした変化はサーバーの監視では見えず、売上に直結するのはこちらです。
- バックアップから実際に戻せることを確かめます。バックアップが取れていても、戻せるかは試さないと分かりません。年に一度は別の環境に戻してみることをすすめます。あわせて、何日前まで戻せるか (保存期間) と、本番と同じ場所にしか置いていないかも確かめます。
- 本番の DB に書き込める人と、管理者の権限を持つ人を必要な人だけに絞ります。辞めた人や使わなくなったアプリのユーザーが残っていないかも、定期的に見直します。
- 障害が起きたときに誰に連絡し、誰が判断し、何を記録するかの手順を決めておきます。手順の作り方は 障害対応の流れ にまとめています。
1、4、5 は一度設定すれば、あとは定期的に見直すだけで済みます。負担が大きいのは 2 と 3 で、何を見るか、どこからを異常とするかを決め、通知が来たら原因を調べる、という作業が続きます。兼任のエンジニアの時間を最も取るのもこの部分です。
4 つの任せ方
残った作業の任せ方は大きく 4 つあります。
| 任せ方 | 向いている会社 | 注意点 |
|---|---|---|
| アプリのエンジニアが兼任する | DB が 1 つで、データもまだ小さい | 開発の時間が削られる。担当者が辞めると知識が残らない |
| DB に詳しい人を採用する | DB の設計やチューニングそのものが事業の競争力になる | 採用に時間がかかり、1 人では休みや夜間を埋められない |
| 運用保守の会社に外注する | 24 時間の対応や、定例の報告が必要 | 契約の範囲外の作業は頼めない。自社のデータの意味は伝える必要がある。契約を終えたときに知識が残るよう、手順書の引き渡しを決めておく |
| 監視と調査をツールに任せる | 障害のたびの調査に時間を取られている | 直す判断と作業は自社に残る |
4 つは組み合わせて使えます。たとえば、普段の見張りと最初の調査をツールに任せ、設計の見直しのような大きな作業だけを外部の専門家に頼む、という分け方です。費用の比べ方は DBA の採用・外注・ツールの費用の比べ方 で扱います。
兼任を続けるときに決めておくこと
当面は兼任で続ける場合でも、次の 4 点を決めておくと、担当者が抜けたときや障害が重なったときに困りにくくなります。
- 通知を誰が受けるかを決めます。通知が全員に届いて誰も見ない状態が一番危険です。担当を週替わりで決めるなど、受ける人を 1 人に絞ります。
- 重いクエリを止める、サービスを一時的に止めるといった判断を、担当者が単独でしてよい範囲を決めます。
- 調べたクエリ、分かった原因、次に同じことが起きたときの見方を記録に残すと決めます。記録が無いと、同じ調査を毎回やり直すことになります。
- 設定やパラメータを変えたときは、誰がいつ何のために変えたかを残すと決めます。理由が残っていない設定は、担当者が替わると誰も触れなくなります。
通知の数が多すぎて担当者が見なくなる問題については アラート疲れ で扱っています。
兼任から切り替える目安
次のような状態が続くようになったら、兼任のままでよいかを見直す時期です。
- 障害の調査のために、開発の予定が毎月のようにずれる
- DB の数やサービスの数が増え、担当者が全体を把握しきれなくなった
- 夜間や休日の障害で、同じ人が何度も呼び出されている
- 担当者が休むと、DB について答えられる人がいなくなる
切り替え先の選び方は、上の 4 つの任せ方を参考にしてください。
監視と調査を任せる方法
最低限やることのうち、負担が大きい 2 と 3、つまり「何を見るかを決めて見張り、異常が疑われたら原因を調べる」部分は、AI に任せる方法もあります。Scandock はデータベースの接続文字列を登録すると、AI がテーブルの構成と実データを読んで監視する項目を決め、異常と判断したら読み取り専用のクエリで原因を調べて通知するサービスです。直す判断と作業は自社に残りますが、通知の時点で「何が起きていて、どこを見ればよいか」が分かる状態にできます。AI が監視項目を決める仕組み と 原因の調査 で詳しく説明しています。