LASSIC Media らしくメディア

データベースは、構築して動き始めたあとも、そのまま放っておくと少しずつ性能が落ちていきます。削除した行の跡地がたまって容量が膨らみ、統計情報が古くなって効率の悪い処理が選ばれ、索引（インデックス）が断片化して検索が遅くなる——こうした劣化は、日々の更新を続けるかぎり避けられません。だからこそ、定期的に手入れをする運用が欠かせないのです。

ところが、この定期メンテナンスは「遅いクエリを直す作業」や「バージョン移行」としばしば同じ話にまとめられがちです。担う中身は別物で、混同したまま体制を組むと、日々の手入れが抜け落ちてしまいます。本記事では、自社のデータベースを守る立場の情報システム部門やインフラ担当者に向けて、定期メンテナンスとは何か、遅いクエリの改善や移行とどう違うのか、そして進め方と外注の勘所を整理します。

データベースの定期メンテナンスとは——クエリ改善・移行との違い

データベースの定期メンテナンスとは、稼働中のデータベースの性能と健全さを保つために、不要になった領域の回収や統計情報の更新、索引の整理といった手入れを、決めた周期で続ける運用を指します。一度やって終わりではなく、日々の更新で生じる劣化を、こまめに打ち消していく取り組みです。似た文脈で語られる2つの作業と並べると、役割の違いがはっきりします。

遅いクエリ（スロークエリ）の改善は、特定の重い処理を見つけて速くする、いわば「その場の困りごとを直す」作業です。またデータベースのバージョン移行は、古くなった版を新しい版へ入れ替える、一度きりの取り組みです。これらに対して定期メンテナンスは、特定のクエリでも、版の入れ替えでもなく、データベース全体の状態を日常的に整え続ける部分を受け持ちます。

その場の改善でも、一度きりの移行でもなく、性能と健全さを保つ手入れを回し続ける——ここに違いがあります。なお、こうした日々の手入れを含めて運用そのものを任せたい場合に向くのが、クラウド運用代行（マネージドサービス）という選択肢です。自社が何を解決したいのか、目の前の遅さなのか、版の古さなのか、日常の状態維持なのかを見極めておくと、取り組みの範囲を絞りやすくなります。

なぜ放っておくと遅くなるのか

データベースは、使い込むほどに内部が乱れていきます。代表的な劣化は3つです。一つ目は、不要領域の蓄積です。多くのデータベースでは、行を削除しても、その場所がすぐに空くわけではありません。更新や削除を繰り返すと使われない跡地がたまり、容量が膨らんで読み書きの効率が落ちていきます。

二つ目は、統計情報の陳腐化です。データベースは、どのデータがどれくらいあるかという統計をもとに、処理の進め方を決めています。データが増減しても統計が古いままだと、効率の悪い進め方が選ばれ、同じ処理でも遅くなってしまいます。三つ目は、索引の断片化です。検索を速くするための索引も、更新を重ねるうちに配置が乱れ、本来の速さを出せなくなることがあります。これらはいずれも、特定のクエリが悪いわけではなく、放置による全体の劣化です。だからこそ、遅くなってから慌てて直すより、周期を決めて手入れを続けるほうが、性能を保ちやすくなります。

定期メンテナンスでやること

定期メンテナンスは、思いつきで実行するだけでは効果が安定しません。おおまかには次のような工程を、決めた周期で繰り返します。自社でどこまで回せているかと照らし合わせてみてください。

まず、データベースの状態を観測します。容量の膨らみや断片化の度合い、統計情報の古さを見て、手入れが必要な箇所を把握する工程です。次に、対象とする表や実行する時間帯を決めて計画を立てます。そのうえで、不要になった領域の回収（PostgreSQLでいうVACUUMなど）で削除行の跡地を整理し、統計情報を更新して効率のよい進め方を選べるようにします。断片化した索引は、必要に応じて作り直して整える対象です。最後に、性能やサイズがどう変わったかを確認し、記録して次回の計画へ反映します。多くの作業は自動化の仕組みに任せられますが、どこまで自動に任せ、どこを人が見るかの線引きは欠かせません。この一連の流れを図にすると次のとおりです。

つまずきやすい難所

定期メンテナンスを回すうえで、あらかじめ想定しておきたい難所がいくつかあります。着手前に押さえておくと、思わぬ停止を避けやすくなります。

一つ目は、処理中のロックや停止時間です。索引の作り直しなどは、やり方によっては対象の表への読み書きを止めてしまうことがあります。業務への影響が小さい時間帯を選び、止めずに進められる方法を検討する必要があります。二つ目は、自動化に任せる範囲です。多くのデータベースには自動で手入れをする仕組みがありますが、更新の多い大きな表では追いつかないこともあり、任せきりだと劣化が進みます。三つ目は、製品ごとの違いです。不要領域の回収や統計更新のやり方、索引の整え方は、PostgreSQL・MySQL・SQL Serverなどで異なります。使っている製品に合わせた手順が要ります。四つ目は、状態の見える化です。何をもって手入れが必要と判断するかの目安がないと、過不足が生じます。これらは、放置するほど絡み合って難しくなります。だからこそ、周期を決めてこまめに回す運用が現実的なのです。

どれくらいの頻度でやるか

定期メンテナンスは、作業の種類によって向く頻度が異なります。すべてを同じ間隔で行う必要はなく、狙いに応じてめりはりを付けるのが現実的です。目安を整理しました。

頻度は、更新の多さやデータ量、そのシステムの重要度によって変わります。更新が激しく止められない仕組みほど、自動の手入れをこまめに働かせつつ、影響の大きい作業は計画的に行う組み立てが現実的です。大きなデータ移行やまとめての取り込みがあったあとは、周期を待たずに一度手入れをしておくと、劣化の後追いを避けられます。

外注時に確認しておきたい点

定期メンテナンスを外部に委託する場合は、次の点を事前にすり合わせておくと、認識のずれを防ぎやすくなります。まず、対象とするデータベースの製品と規模、そして更新の多さです。使っている製品や、止められない度合いによって、進め方が変わってきます。次に、どこまでを任せるか。状態の観測だけなのか、実際の手入れの実施や、自動化の仕組みづくりまで含めるのかで、契約の形が変わります。

さらに、作業を行う時間帯（メンテナンスの窓）と、停止時間をどこまで許容できるか、問題が起きたときの切り戻しの考え方も、あらかじめ決めておきたいところです。そして忘れずに確認したいのが、状態の見える化と報告のしかた、手順書の整備です。定期メンテナンスは続いていく運用なので、いずれ自社で回せるように記録を残してもらえるかどうかは、後々の助けになります。手入れの実施だけを頼むのか、監視や見直しまで含めて依頼するのかを明確にしておくと、任せたあとのつまずきを抑えやすくなります。

まとめ：定期メンテナンスで押さえる3つの視点

データベースの定期メンテナンスは、目の前の遅いクエリを直す改善や、版を入れ替える移行とは役割の異なる、「性能と健全さを日常的に保ち続ける」運用です。検討するうえで押さえたい視点は3つに整理できます。第一に、遅いクエリの改善・バージョン移行・定期メンテナンスを切り分け、自社が解決したいのがどれなのかを見極めること。第二に、削除行の跡地・統計の陳腐化・索引の断片化という劣化を前提に、周期を決めて手入れを続けること。第三に、自動化に任せる範囲と人が見る範囲を線引きし、停止時間と効果を確認しながら回すことです。この3点を踏まえておけば、「気づいたら重くなっていて、原因も切り分けられない」という事態を避けやすくなります。自社だけで回しきるのが難しいと感じたら、状態の見える化や手順づくりから外部の手を借りるのも一つの選択肢です。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：PostgreSQL公式ドキュメント「Routine Database Maintenance Tasks」（https://www.postgresql.org/docs/current/maintenance.html）

Tweet