フィードのキャッシュとヘルスチェック運用

はじめに

商品フィードは、作り終えたら完成という性質のものではありません。毎日きちんと届け続けることのほうが、作ることよりずっと手のかかる部分です。

大きく2つの課題があります。1つは処理の重さ。数千SKU（色やサイズまで分けて数えたときの商品の単位）を毎回まるごと作り直していると、時間もサーバーの負荷もかさみます。もう1つは、失敗が表に出ないこと。フィードが作れなくなっても、管理画面に赤いエラーが出るわけではありません。ショッピングの掲載商品が消え、売上が落ちてから気づくことになります。

この記事では、フィード生成を軽くするキャッシュ（一度作った結果をとっておいて使い回す仕組み）と、配信が止まっていないかを確認するヘルスチェックの運用を説明します。どちらも派手さはありませんが、入れていないと後で困る部分です。

数千件を毎回作り直さない

Googleは決まった間隔でURLを取りに来る

Google Merchant Center（以下GMC。Googleに商品情報を登録しておく管理画面）は、登録されたフィードのURLを定期的に取りに来ます。こちらから送るのではなく、向こうから取りに来る形です。

そのたびに数千SKUぶんの商品データを取得して変換していたら、1回あたりの処理はかなり重くなります。時間がかかりすぎるとGMC側で時間切れになり、フィードが読み込まれないまま終わることもあります。読み込まれなければ、商品情報は更新されません。

作った結果を数時間ぶん使い回す

フィードの中身は、分単位で変わるものではありません。価格や在庫が動いても、GMCへの反映が数時間おきであれば実用上は十分です。それなら、一度作った結果をとっておいて使い回せばいい。これがキャッシュの考え方です。

同じ内容を何度も作り直すのをやめて、作り置きを配る形に変えた、ということです。

有効期限の長さは在庫の動きに合わせる

キャッシュには有効期限を設定します。このプロジェクトでは数時間としました。期限が切れたら次にURLを取りに来られたタイミングで作り直し、また一定時間その結果を使い回す、という繰り返しです。

短くしすぎると生成が頻繁に走って負荷が上がりますし、長くしすぎると売り切れた商品がいつまでも掲載されたままになります。在庫の動きが速い商材ほど期限は短めに、動きの緩やかな商材なら長めに。決め打ちの正解はないので、掲載のズレが許容できる範囲を運用側と決めて合わせるのが現実的でした。

もう1つ覚えておきたいのは、期限を短くしてもGoogle側の反映が同じだけ速くなるわけではない、ということ。GMCがURLを取りに来る間隔と、取り込んだ内容を掲載に反映するまでの時間は、こちらでは制御できません。こちらの期限を1時間に縮めても、GMCが1日1回しか取りに来なければ、掲載の鮮度は変わらないわけです。負荷だけが増えることになるので、期限はGMC側の取得間隔と釣り合う長さに収めるのが無難でした。

一度に扱う件数を区切る

商品数が数万SKU規模になると、1つのファイルにすべてを詰め込むこと自体が難しくなります。作っている途中でメモリを使い切ってしまうためです。

そこで、一度に扱う件数を区切って分割しながら生成できるようにしておきます。区切りを設けておけば、商品数がどれだけ増えても処理が破綻しません。商品数はたいてい増える方向にしか動かないので、この設計は最初から入れておくのが安心です。

止まったことに気づく仕組みを別に持つ

フィードが止まると、警告なしに広告も止まる

フィードの厄介なところは、失敗が画面に出ないことです。商品データを取り出す側の仕様変更、通信のエラー、キャッシュの不整合。原因はさまざまですが、どれも「気づいたら掲載が止まっていた」という形で表面化します。

だからこそ、フィード本体とは別に「ちゃんと作れているか」を外から確認する仕組みが要ります。

生成できているかを確認する専用のURLを用意する

そこで、フィードが正しく生成できるかを確認するための専用URL（ヘルスチェック）を用意しました。呼ばれると実際にフィードの生成を試み、商品件数が想定の範囲にあるか、必須の項目が入っているかを見て、結果を返します。

要は、人が毎朝手で確認していた作業を、機械に定期的にやらせているだけです。

件数の急な減少を異常として扱う

見るべきなのは「作れたかどうか」だけではありません。商品件数の変化まで見るのが要点です。普段は数千件あるはずのフィードが、ある日だけ数十件に減っていたら、生成そのものは成功していても中身に問題があります。

商品データの取得が途中で止まった、除外の条件が意図せず広く効いてしまった。こうした「成功しているのに中身が薄い」状態は、実際に起こります。判定を「0件でないか」ではなく「いつもと比べて極端に少なくないか」まで広げておくと、掲載が痩せていく段階で手を打てます。

通知の届け先と、気づいたあとの動き方を先に決めておく

監視を入れても、通知が誰も見ていない場所に届いていては意味がありません。担当者が普段使っているチャットや、メールで受け取れるようにして、届いた通知に誰が最初に反応するかまで決めておきます。

あわせて決めておきたいのが、通知を出す基準の厳しさです。細かい変動でも毎回鳴るようにすると、そのうち誰も内容を読まなくなります。逆にゆるくしすぎると、肝心なときに鳴りません。件数が普段の半分を下回ったとき、あるいは生成に2回続けて失敗したとき、といった形で、確認しに行く価値のある条件に絞るのが実際的でした。

まとめ

フィードの運用は、「軽く作る」と「止まったら気づく」の2本柱で考えると整理しやすくなります。

• キャッシュ：数時間ぶん結果を使い回し、処理の重さと鮮度のバランスを取る
• 有効期限：在庫の動きの速さに合わせて長さを決める。決め打ちの正解はない
• 件数の区切り：一度に扱う量を制限し、商品数が増えても破綻しないようにする
• ヘルスチェック：生成の可否と件数を定期的に確認し、表に出ない失敗を検知する

フィードは、止まればショッピング広告も無料リスティングも止まる、売上に直結する仕組みです。作り込むだけでなく、動き続けているかを見張る側にも同じくらい手をかける価値があります。

フィードそのものの作り方は商品フィードの自動生成とマッピング設計で、掲載の質を守る仕掛けはフィード品質の管理で扱っています。