こんにちは。エンタープライズソリューショングループの石川です。大企業連携システムの基盤の開発や運用を担当していて、日々発生するエラーの監視や調査も行っています。今回は手間と時間がかかりがちだったエラー調査を、ChatGPTを使って改善した話をします。
エラー調査の背景
カタログサイトの概要とエラー発生時の影響
大企業連携は、各企業様が持つ購買システムとサプライヤが提供するシステムが相互に連携することで購買を実現しています。当社もサプライヤのうちの一つであり、購買システム向けにカタログサイトと呼ばれるECサイトを提供しています。カタログサイトには商品の検索や購入したい商品を選択する機能などのほか、購買システムから送信される注文要求を受け付ける機能（以降ではこの機能を「注文受付」と呼びます）があります。
当社のカタログサイトではそれらの機能が同一のシステムで稼働しており、例えばユーザーが商品を検索する機能で障害が発生すると注文受付にも影響が及ぶ場合があります。そのため、注文受付が影響を受ける可能性があるエラーが発生した場合には、都度確認を行っています。
注文受付が影響を受ける理由とエラーの具体例
カタログサイトではアプリケーションサーバーにuWSGIを利用しています。uWSGIは受け取ったリクエストを複数のプロセス（uWSGIワーカー）に振り分けて処理を行っています。1つのプロセスでは複数のリクエストが同時に処理されているため、エラーによってプロセスが異常終了すると関係のないリクエストの処理も中断されてしまうのです。注文受付が影響を受けるエラーの一例として、worker * (pid: ****) is taking too much time to die...NO MERCY !!!のエラーがあります。あるカテゴリに含まれる商品一覧を表示するページで、商品点数が非常に多いために処理時間が長くなることで発生するエラーです（この問題はすでに対応済みです）。
エラー発生時の調査手順
エラーが発生すると、Slackのチャンネルにエラーメッセージが通知されます。注文受付が影響を受ける可能性のあるエラーが通知された場合、次の手順で影響の有無の調査を行っています。
1. 注文受付へのリクエストがないか確認
エラー発生時刻付近のアクセスログを取得し、注文受付へのリクエストに対して失敗のレスポンスを返しているログがないか確認します。アクセスログはBigQueryに格納される仕組みになっているため、SQLを実行して該当時間帯のログを取得します。注文受付へのリクエストがない場合は、注文受付に影響はないと判断できるため調査を終了します。
次以降はここで該当するリクエストがあることが分かった場合の手順です。
2. 購買システムに注文情報を再送信する仕組みがあるか確認
注文要求の送信元である購買システムには、リクエストの失敗を検知して注文要求を再送信する仕組みがある場合があります。各購買システムが再送信の仕組みを持っているかはスプレッドシートによって管理しており、リクエストごとに照らし合わせながら確認します。
購買システムに再送信の仕組みがある場合は再送信される注文要求を待機します。再送信の仕組みがない場合は次に示す3.の対応を行います。ただし、再送信の仕組みがある購買システムからの注文要求でも、エラーが出荷締切時刻の直前に発生した時は注意が必要です。再送信による注文受付の時刻が出荷締切時刻を超えてしまうと、予定とは異なって当日出荷できなくなってしまう可能性があるためです。このような場合にも次の対応を行います。
3. 再送信の仕組みがない購買システムの場合は、社内の担当グループに対応依頼
再送信の仕組みがない購買システムからの注文要求であるなどの場合は、社内の担当グループに対応依頼を行います。担当グループは注文を社内の基幹システムに取り込めているかを確認します。もし取り込めていない場合は購買システムの担当者に再注文の依頼などの対応を行います。
この調査手順を図に示すと上のようになります。1.の段階で注文受付へのリクエストがないと分かる場合がほとんどですが、そうでない場合は非常に手間と時間がかかる調査です。
MonoChatに聞きながらGASアプリケーションを作成
実現したかったこと
エラー発生時の調査手順をもとに、実現したかったことは下記の3点です。
- SQL文を書かずにアクセスログを取得したい
- GUIから日時範囲などを指定して実行したい
- 購買システムが注文要求を再送信するかの確認を省力化したい
- SQLの出力結果をもとに、自動的に判別したい
- 上記2項目の調査手順をワンストップで実行したい
改善のためのアプリケーションを作成
実現したかったことを実現するために、作成のしやすさと他の人の利用しやすさを考え、MonoChatを使ってGASアプリケーションを作成しました。MonoChatはAzure OpenAI ServiceのAPIを利用したSlackボットです。詳しくは下記の記事で紹介しています。
手始めに実現したいことを伝えてみました。
要件を伝えただけで、MonoChatがそれらしいコードを出力してくれました。BigQuery APIの有効化が必要なことまで教えてくれています。この結果をもとに実際の動作を確認してみます。
画面出力はいい感じですが、実行してみるとエラーが発生しました。
データ調査元のBigQueryのテーブルはタイムスタンプによるパーティショニングテーブルとなっているのですが、そこに渡す値が適切な形式になっていないようです。実行したSQLを出力してみるとタイムスタンプの秒の部分がありません。そこで、秒が:00になるように修正して実行します。
実行結果として取得されたデータが表の形式で出力されました。これでSQLを書かずにアクセスログを取得することができました。
アクセスログに含まれるリクエストのパスは購買システムごとに異なるため、ここで得られた情報をもとに影響を受ける購買システムが分かります。社内の担当グループに対応依頼が必要かどうかを判断するためには、購買システムが注文要求を再送信するかどうかを確認する必要があります。そこで、スプレッドシートからその情報を取得する関数も作ってもらいました。
出力されたコードはうまく動きましたが、少し冗長に感じました。コードレビューのようにコメントしてみます。
コードがかなりスッキリしました。このようなやり取りを重ねながら、購買システムごとに再送信の仕組みがあるかどうかを判断する関数を作成できました。この後、結果表示の見た目を整えたり影響があった購買システムを集計する機能を追加したりし、最終的には下記のようなアプリケーションになりました。
※「チャネル」は購買システムを識別する番号
改善の費用対効果
改善の費用対効果を考えるために、改善前と改善後の調査にかかる時間（コスト）を比較します。改善前はエラー調査に180分/月かかっていたところ、改善後は75分/月でできるようになったと見積もりました。今回のGASアプリケーションの作成に360分かかったとして、改善後では4カ月でコストを回収できるという結果になりました。改善施策を導入したのは2023年6月のため、この記事を執筆している10月末にはすでにコストを回収できていると言えます。
振り返り
今回はChatGPT（MonoChat）を利用してエラー調査を改善しました。ChatGPTとやり取りをしつつゼロからアプリケーションを作成するのは初めてだったため、新鮮な体験でした。これまでであれば「リファレンスを調べる→実装する→動作検証を行う」のプロセスで進めていた開発が、「ChatGPTに聞く→出力されたコードの動作を検証する」のプロセスに変わったことでスピーディに開発を進められたと思います。しかし全てをChatGPT任せにするのではなく、例えばコードを出力させるよりも短時間でできるような軽微な変更や、命令が複雑で意図した出力を得られない場合は手動でやったほうが良かったりもしました。アプリケーションが完成した状態を100とするならば、0→75くらいのところまでをChatGPTに任せて、そこから25の部分を手動でやるというのが良いのかもしれないと思いました。
改善施策を導入する上では、ChatGPTを利用して短時間でアプリケーションを実装できるのは費用対効果を高められるメリットがあると感じました。今後も機会があればChatGPTを活用して業務改善をしていきたいと思います。
大企業連携システムの基盤の開発や運用に興味を持った方がいれば、カジュアルMTGや採用へのご応募をお待ちしています！
