Edited at

システム保守・運用における経年劣化チェックポイント

More than 1 year has passed since last update.


この文書について

システムを使い続けていくと、リリース当初と環境が変わってしまい、性能が変わってしまうことがある。

また、リリース当初には気づかなかった設計や実装の不備に気づくことがある。

どのような指標をどのような観点で確認すべきか、

また発覚した場合にはどのような対処をするか、まとめる。

対象読者: 保守・運用担当者 (願わくば開発者もDevOpsの観点で)


概要


  • いつ実施するか

  • 確認する指標


    • 処理時間

    • サーバ1台あたりのリソース消費



  • 劣化要員


    • ストレージのデータ増


      • レコード数の増加による処理時間の増加



    • 利用頻度・処理対象の増加



  • 対処


    • 設定や実装の不備があれば、見直し

    • スケールアップ、スケールアウト




いつ実施するか


  • リリース後1ヶ月経ってから

  • 半期に1度程度定期的に

  • アラートが発生したら即見直し


確認する指標

アプリケーションサーバ、DBサーバなどサーバの役割ごとに確認する


アプリケーションサーバ


  • 処理時間がリリース前に実施した負荷試験・性能試験結果から長くなっていないか、確認する


    • APIであれば、リクエストからレスポンスまでの応答時間(Latency)を確認する


      • AWSであれば、ELBについてCloudWatchで確認可能

      • apacheの場合は、ログで %D をログ出力していれば確認できる



    • バッチやワーカーの場合、アプリケーションログの処理開始時刻と終了時刻を確認する



  • 下記の指標がリリース当初と比べて増えていないか、確認する


    • CPU使用率・メモリ使用量・DISK使用量



      • topdf コマンドなどで確認






DBサーバ・ストレージサーバ


  • 下記の指標がリリース当初と比べて増えていないか、確認する


    • CPU使用率・メモリ使用量・DISK使用量


      • AWSであれば、RDSについてCloudWatchで確認可能





  • RDBでは、SlowQueryログが出ていないか、確認する


劣化要因


アプリケーションサーバ系


  • 【環境変化】 利用頻度が増加した


    • サービスが流行ってきて、APIのリクエスト数が増えた・Push配信の配信対象者が多くなった



  • 【設計実装不備】 ログの退避がされていない


    • 古いログが削除されていないので、DISKを圧迫する




ストレージサーバ系


  • 【環境変化】 レコードが増えた


    • ユーザのレコード


      • ゲームアプリのリセマラなどアンインストールすると新規会員になるようなケースが該当



    • ユーザが作成するコンテンツのレコード


      • CGM系のコンテンツ、そのコンテンツに対するコメントなど





  • 【設計実装不備】 インデックスが不適切


    • リリース前に負荷試験をしなかったり、シナリオが不十分で気づかれなかったケースが該当




対処


アプリケーションサーバ系


  • アプリケーションサーバのスケールアップ・スケールアウト

  • ログのローテーション見直し


ストレージサーバ系


暫定対応


  • サーバのスケールアップ

  • 古いレコードの削除


根本対応


  • テーブル設計の見直し


    • インデックスの見直し



  • ストレージ設計の見直しとデータ移行


    • 参照系だけの性能が問題ならレプリカやキャッシュの導入

    • マスタが問題なら、インフラ構成見直し


      • シャーディング

      • パーティショニング