ピーク時間帯と定期処理を混ぜない – 業務時間、バッチ、バックアップ、障害対応で考える運用設計

システム運用では、同じ処理でも実行する時間帯によって意味が変わります。業務ピーク中の 1 秒の遅延、夜間バッチ中の CPU 上昇、バックアップ中の I/O 増加、メンテナンス中の一時停止、障害対応中の再起動は、同じ負荷や停止として扱うべきではありません。運用設計では、何を実行するかだけでなく、いつ実行するかを設計対象にする必要があります。

時間帯を見ない運用は、すべての処理を同じ優先度で扱ってしまいます。その結果、業務ピーク中に重い集計を走らせたり、バックアップとバッチを重ねたり、障害対応中に自動再試行や自動スケールが過剰に動いたりします。重要なのは、時間帯を単なるスケジュールではなく、負荷、利用者影響、変更リスク、復旧余力を決める前提として扱うことです。

24 時間稼働でも中身は同じではない

Web サービスや業務システムは 24 時間稼働しているように見えます。しかし、すべての時間帯で同じ負荷、同じ利用者、同じ許容遅延、同じ変更リスクになるわけではありません。平日日中、始業直後、昼休み、月末、夜間バッチ、バックアップ、メンテナンス、障害対応中では、システムが果たすべき役割が変わります。

たとえば業務時間中は、利用者の操作に対する応答が重要です。夜間は、日中に蓄積したデータ処理や連携処理が重要になることがあります。バックアップ時間帯は、処理性能よりも整合性や復旧可能性が重要になります。メンテナンス時間帯は、一時的な停止や性能低下を許容できる一方で、切り戻しできることが重要になります。

時間帯	主な関心	混ぜると起きる問題
業務ピーク	応答時間、エラー率、利用者影響。	重い処理を重ねると、利用者影響が直接出る。
夜間バッチ	処理完了時刻、依存順序、再実行性。	遅延が翌日の業務開始に波及する。
バックアップ	整合性、I/O 負荷、復旧可能性。	バッチや集計と競合し、処理遅延やバックアップ失敗につながる。
メンテナンス	変更範囲、切り戻し、確認手順。	通常運用の監視や自動化が誤反応する。
障害対応中	影響の抑制、暫定復旧、証跡保持。	通常時の自動処理が原因調査や復旧を邪魔する。

業務ピークでは平均負荷より利用者影響を見る

業務ピーク中に重要なのは、平均 CPU 使用率や平均レスポンスだけではありません。実際に利用者が待たされているか、エラーになっているか、重要な業務操作が完了しているかです。ピーク時間帯では、少しの遅延でも問い合わせや作業停止につながることがあります。

そのため、業務ピークに実行してよい処理と、避けるべき処理を分ける必要があります。重い集計、全件スキャン、インデックス再作成、大量エクスポート、キャッシュ全削除、ログの一括圧縮、バックアップのフルスキャンなどは、通常時には問題にならなくても、ピーク時には利用者影響を増やします。

ピーク時間帯の監視も、通常時とは見方を変えるべきです。CPU が高いこと自体より、p95 / p99 レイテンシ、タイムアウト、キュー長、DB 接続待ち、外部 API 待ち、認証基盤の遅延が業務に影響しているかを見ます。

夜間バッチは静かな時間ではない

夜間は利用者が少ないため、処理を詰め込みやすく見えます。しかし、夜間バッチ、データ連携、バックアップ、ウイルススキャン、ログ集計、レポート作成、インデックス更新、クラウドのスナップショットが重なると、夜間はむしろ高負荷帯になります。

夜間バッチで重要なのは、単体の処理時間だけではありません。処理順序、依存関係、再実行性、失敗時の切り戻し、翌営業日への影響です。あるバッチが 30 分遅れるだけなら問題ない場合もありますが、その後続に請求、在庫、レポート、外部連携が続くなら、影響は連鎖します。

設計項目	確認すること
開始条件	前段処理、外部データ、業務締め処理が完了しているか。
終了条件	何時までに終わらなければ翌日の業務へ影響するか。
依存関係	後続処理、外部連携、レポート生成に何が続くか。
再実行性	途中失敗後に安全に再実行できるか。
競合	バックアップ、集計、スキャン、メンテナンスと同じ資源を奪い合わないか。

バックアップ時間帯は性能ではなく復旧可能性を見る

バックアップは、処理性能だけで判断すべきではありません。重要なのは、必要な時点へ戻せること、整合性が取れていること、復旧手順が確認されていることです。バックアップ中は I/O 負荷が増え、アプリケーションやデータベースの性能に影響することがあります。

ここで問題になるのは、バックアップを単なる夜間処理として扱うことです。夜間に実行しているから安全なのではありません。夜間バッチと同じ時間帯に走れば、I/O、CPU、ネットワーク、ストレージ帯域を奪い合います。さらに、バックアップ対象のデータがバッチによって更新中であれば、整合性や復旧時点の意味も確認が必要です。

バックアップ時間帯は、システムを止めないための時間ではなく、止まった後に戻すための時間です。RPO、RTO、スナップショット、レプリケーション、アーカイブ、リストア試験を含めて設計しなければ、バックアップは取れているように見えても復旧できない状態になります。

メンテナンス時間帯は何を許容するかを決める

メンテナンス時間帯は、単に作業してよい時間ではありません。その時間帯に何を許容するのかを決める必要があります。完全停止を許すのか、縮退運転にするのか、一部機能だけ止めるのか、読み取り専用にするのか、性能低下をどこまで許すのかで、作業設計は変わります。

また、メンテナンス中は監視や自動化の扱いも変わります。計画停止を通常障害として通知し続けると、重要なアラートが埋もれます。一方で、メンテナンスだからといって監視を完全に止めると、作業中に起きた想定外の障害を見落とします。抑制するアラートと残すアラートを分けるべきです。

メンテナンス設計では、作業手順だけでなく、事前条件、影響範囲、切り戻し条件、確認項目、監視抑制、関係者連絡、作業後の観測期間を決めます。作業が終わったことと、サービスが正常に戻ったことは同じではありません。

障害対応中は通常時の自動化が逆効果になることがある

障害対応中は、通常時に便利な自動処理が逆効果になることがあります。自動再試行、自動スケール、自動再起動、ジョブの自動再実行、キューの再投入、監視の連続通知は、状況によっては負荷を増やし、原因調査を難しくします。

たとえば外部 API が遅延しているときに、全クライアントが短い間隔で再試行すると、障害は増幅します。Pod が落ち続けているときに自動再起動を繰り返すと、ログが流れ、依存先への接続が増え、原因の切り分けが遅れます。通常時の回復動作は、障害時の負荷増幅装置にもなり得ます。

障害対応中は、まず影響範囲を抑えることが重要です。レート制限、一時的な機能停止、キュー投入の停止、再試行間隔の調整、読み取り専用化、フェイルオーバー、トラフィック遮断などを、通常時とは別の運用モードとして準備しておく必要があります。

時間帯を運用設計に落とす

運用設計では、時間帯をカレンダーや cron の設定だけで終わらせるべきではありません。どの時間帯に、どの処理が、どの資源を使い、どの失敗が、どこへ波及するのかを整理します。

観点	決めること
業務時間	利用者影響を最優先する時間帯と、許容できる遅延。
処理時間	バッチ、集計、連携、バックアップの開始・終了条件。
変更時間	デプロイ、設定変更、メンテナンスを許容する時間帯。
監視条件	時間帯ごとのアラート閾値、抑制、通知先。
競合管理	同じ CPU、I/O、DB、ネットワークを奪い合う処理の整理。
例外運用	障害対応中に止める自動処理、残す自動処理。

この整理があると、負荷の見方も変わります。夜間に CPU が高いことが問題なのか、予定されたバッチの範囲なのか。バックアップ中の I/O 増加が許容範囲なのか、翌朝の処理遅延につながるのか。ピーク中の短い遅延をどこまで許容するのか。時間帯ごとの前提がなければ、同じメトリクスを見ても判断がぶれます。

運用カレンダーとして管理する

時間帯を設計するなら、最終的には運用カレンダーとして管理できる形に落とす必要があります。単に夜間バッチの開始時刻を書くのではなく、業務ピーク、締め処理、バックアップ、メンテナンス、外部連携、監視抑制、担当者体制を同じ時間軸に並べます。そうしなければ、個々の処理は正しくても、組み合わせとして危険な時間帯が残ります。

管理する時間	重ねてはいけないもの	確認する理由
月末月初	重い集計、全件エクスポート、不要なリリース。	業務影響が大きく、問い合わせも増えやすい。
夜間バッチ帯	フルバックアップ、インデックス再作成、外部連携の集中。	I/O と DB 接続を奪い合い、翌朝へ遅延が波及する。
バックアップ帯	大量更新、スキーマ変更、長時間トランザクション。	復旧時点の整合性とリストア可能性に影響する。
メンテナンス帯	通常監視の過剰通知、別チームの独立作業。	作業影響と想定外障害を切り分けにくくなる。
障害対応中	自動再試行の集中、予定ジョブの継続、追加リリース。	復旧作業と原因調査を妨げる。

運用カレンダーは、予定をきれいに並べるための表ではありません。競合する処理を事前に見つけ、どの時間帯に何を禁止するかを決めるための設計資料です。

まとめ

ピーク時間帯、夜間バッチ、バックアップ、メンテナンス、障害対応を同じ運用時間として扱うと、判断基準が曖昧になります。24 時間稼働しているシステムでも、時間帯ごとに利用者、処理内容、資源競合、許容遅延、変更リスク、復旧余力は変わります。

運用設計では、何を実行するかだけでなく、いつ実行するかを決める必要があります。業務ピークでは利用者影響を見ます。夜間バッチでは依存関係と完了時刻を見ます。バックアップでは復旧可能性を見ます。メンテナンスでは許容する停止と切り戻しを決めます。障害対応中は通常時の自動化が負荷を増やさないように制御します。

時間帯は、単なるスケジュールではありません。運用判断の前提です。どの時間帯に何を優先し、何を遅らせ、何を止め、何を監視し続けるのか。そこまで決めて初めて、監視、キャパシティ設計、変更管理、障害対応が同じ設計の中でつながります。

参考書籍

参考資料

• Google SRE Book: Handling Overload
• Google SRE Book: Addressing Cascading Failures
• Google SRE Book: Release Engineering

関連する記事