サーバーが正常であっても、数週間気づかれないまま放置されていたような業務上の失敗まで発見します。
3つのサービスにおける13箇所のサーバーコンポーネントと、伝票送信や通知メッセージ配信といった実際の業務結果を統合的に監視します。サーバーAPIやユーザーPC上のアプリで発生したエラーを集約し、Slack通知から管理画面での原因特定へとスムーズに移行できる運用ツールを開発しました。
- 0.5秒→0.1秒低速なクエリの改善直後における、注文サービスDBの平均応答時間
- 6件監視アラートによって発見し、原因を修正した運用上の問題
- 13か所1分ごとに確認するサーバーコンポーネント
独自に開発した管理者用ステータス画面です。サービスごとの現在の状態と稼働履歴を表示します。内部識別情報は伏せてあります。
翻訳参考図・韓国語の原本を見る- 担当する役割
- 監視基準と通知フローを設計しました。監視プログラム、サーバー状態画面、業務結果の確認機能、APIエラーやPCアプリのエラー収集機能、そしてそれらを一元管理する管理者コンソールまで、すべて自社で開発しました。
- 成果
- サーバーの状態、実際の業務処理結果、APIやPCアプリのエラーを統合的に監視するシステムを構築しました。アラート、復旧通知、定期レポートを管理コンソールと連携させ、監視によって特定された「クエリの遅延」や「請求書・通知メッセージ（AlimTalk）連携の問題」など、計6件の不具合の原因を修正しました。
- 1サーバー監視13箇所を正常、性能低下、障害、確認不可と判定
- 2業務結果の確認リクエストが受け付けられたかどうかではなく、実際に処理されたかどうかで判定
- 3通知とレポート3回連続失敗するとアラーム、復旧時にもう一度、1日2回定期報告
- 4エラーの収集サーバーAPIのエラーとPCアプリのエラーを収集し、同じ種類のエラーごとにグループ化しました。
この技術によって期待される変化
小規模チームの運用対応
担当者が複数の管理画面を常時監視する代わりに、異常や復旧を通知で確認できるため、繰り返しのチェックにかかる負担を軽減し、原因の特定に集中できるようになります。
顧客に届く前に問題を検知
サーバーが正常に稼働していても、配送情報や業務通知が漏れてしまうといった失敗を検知し、顧客からの問い合わせが入る前に対処できるようサポートします。
改善につながるエラー記録
サーバーやユーザーのPCで発生したエラーを統合して繰り返される問題を特定し、修正前後の状態を比較できるような、運用上の根拠を残します。
問題と解決策
問題サーバーが正常であっても、伝票の送信や通知メッセージ（AlimTalkなど）の配信が失敗したまま残ってしまうことがあります。
解決リクエストの受付と実際の処理結果を区別し、業務の失敗や未完了の実行も監視対象に含めました。
問題管理者の分析作業中や、最初の結果を待機している状態が、実際の障害のように見えていました。
解決作業の発生元を区別し、「収集待ち」、「結果未確認」、「確定失敗」に分類することで、対応が必要な異常を把握できるようにしました。
問題障害発生中に収集接続が切断された場合、その期間の状態履歴は空となります。
解決観測データを一時的に保存し、接続が復旧した際に重複なく送信することで、障害から復旧までの流れを連続して確認できるようにしました。
問題サーバーの応答が遅延したり切断されたりした際、エラーの送信を待機してしまうと、「家具ビルダー」での編集作業と出力処理の両方が停止してしまいます。
解決編集や出力の処理を待たずにエラーを個別に送信するようにし、同じエラーが繰り返し送信されるのを制限しました。
問題エラーメッセージには、トークンやファイルパスが含まれる場合があります。
解決パソコンとサーバーの両方で機密部分を消した最初の行だけを残し、図面内容は送りません。
確認した結果
- 管理者のステータス画面、Slackへの報告、および障害・復旧履歴を照合しました。
- 低速なクエリを修正した直後、DBの平均応答時間が0.5秒台から0.1秒前後へと変化した様子を、運用グラフで確認しました。
- 請求書、通知トーク（AlimTalk）、DB接続など、監視アラートから原因を追跡し、対応した6件を記録しました。
13箇所を1分ごとに確認します
設計・加工プラットフォーム8箇所
- Nginx (運用、開発)フロントエンドサーバーの自己応答
- APIサーバー (運用、開発)ステータス応答とエンジンのロード
- GPUウォーカー (運用、開発)最後のハートビート
- DB (運用、開発)リンクと低速な参照
家具注文サービス3箇所
- Webサービス (運用)最初の画面とアプリファイルの応答
- DB (運用)リンクと低速な参照
- DB関数呼び出し (運用)関数別の平均応答時間
工場管理サービス2箇所
- Webサービス (運用)ログイン画面およびアプリファイル応答
- APIサーバー (運用)読み取り専用の要求に対する応答
- 定期タスク
- 決済後の処理
- 作業キュー
- 外部連携
- 通知トークの送信
エラーは発生するたびに収集されます。
サーバーAPI設計・加工プラットフォーム
5xxと処理できなかった例外はすべて、4xxはサンプルのみ
APIエラー画面同じエラーをグループ化し、処理状況と履歴を記録する
ユーザーPCアプリ家具ビルダー、コネクタ、プロッター
作業を中断せず、エラー箇所と対象のみを送信
ローカルアプリの問題報告画面プログラムごとの推移、エラーコードごとのグループ化、処理完了表示
監視によって発見された実際の問題 6件
オレンジ色の線は、注文サービスDBのデータです。記録を開始した日の夜、クエリの遅延を修正した直後、平均応答時間が0.5秒台から0.1秒前後まで低下しました。
翻訳参考図・韓国語の原本を見る監視を開始した初日、注文サービスのDBの平均応答時間が0.5秒前後と遅く、管理画面での期間別推移の照会に平均4〜5秒かかっていることが検知されました。
クエリを修正した直後、データベースの平均応答時間が0.1秒前後まで短縮されました。同じ原因による他の17件のクエリも、同様の方法で修正しました。
配布チェック処理において、データベーストランザクションを開いたままファイルストアを読み込んだため、接続が10秒を超えて保持されました。
DBルックアップだけが接続内で行われ、ファイルチェックは接続を閉じた後にしました。
同時に開始された2件の請求書送信が、いずれも失敗として記録されました。
転送の競合などによる、図面（または請求書等）の重複転送を解消しました。
配送通知メッセージ（AlimTalk）4件の送信結果が届いていません。直近120日間を確認したところ、結果が届いていないメッセージが65件ありました。
送信後に結果が得られなかったメッセージについて、1分ごとに再照会して照合するようにしました。
9月初旬から6週間にわたり、請求書全体を送信するたびに、ある注文の送信が失敗していました。
すでに登録されている番号と比較し、完了として記録されるように修正しました。
仮想口座への入金時に注文完了の通知メッセージを再送しようとしましたが、拒否されました。
注文時に送信済みの「通知トーク（AlimTalk）」が、入金時にも再度送信されないようにしました。
運用時に確認する画面
1日2回、すべてのコンポーネントの状態を報告します。障害や復旧に関するアラートも、同じ通知フローを通じて送信されます。
翻訳参考図・韓国語の原本を見る一時的な突発値と、継続的な異常を比較してみます。
翻訳参考図・韓国語の原本を見る障害の開始から復旧までの期間を記録します。
翻訳参考図・韓国語の原本を見る