はじめに
商品フィードは、作って終わりではありません。むしろ、毎日安定して配信し続けることのほうがずっと大変です。
数千SKUの商品を毎回まるごと生成していたら処理は重くなりますし、なにより厄介なのは、フィードが止まっても静かに止まること。エラー画面が出るわけではなく、ただ広告の露出が消えていきます。
この記事では、フィード生成を軽くするキャッシュと、配信が止まっていないかを見張るヘルスチェックの運用を解説します。
大量SKUを軽くさばくキャッシュ
なぜキャッシュが要るのか
Google Merchant Center（GMC）は、登録したフィードURLを定期的に取りに来ます。そのたびに数千SKUをShopifyから取得してXML化していたら、処理時間もサーバー負荷も無視できません。
ですがフィードの中身は、分単位でころころ変わるものではありません。価格や在庫が変わっても、GMCへの反映は数時間おきで十分実用的です。だったら生成結果を使い回そう——これがキャッシュの発想です。
URLが叩かれるたびに全SKUを取得・XML化。処理が重く、タイムアウトのリスクも
生成結果を数時間保持し使い回す。負荷を抑えつつ十分に新鮮なフィードを配信
TTLで「ほどよい鮮度」を保つ
キャッシュにはTTL（有効期限）を設定します。このプロジェクトでは数時間のTTLにしました。TTLが切れたら次のアクセス時に作り直し、また一定時間使い回す、という繰り返しです。
短すぎると生成が頻発して負荷が上がり、長すぎると在庫切れ商品がいつまでも掲載されてしまう。この「ほどよい鮮度」の見極めが運用のさじ加減です。在庫の動きが速い商材ほど、TTLは短めに寄せるのがよいでしょう。
ページサイズで大量SKUを分割する
数万SKU規模になると、1つのXMLにすべてを詰め込むのはメモリ的にも無理が出てきます。そこでページサイズを制御し、フィードを分割して生成・配信できるようにしておきます。
一度に扱う件数を区切ることで、SKU数がどれだけ増えてもメモリを圧迫せず、安定して返せます。商品数の成長に耐える設計を、最初から織り込んでおくと安心です。
止まったことに気づく仕組み
フィードは静かに止まる
冒頭でも触れましたが、フィードの怖いところは失敗が目に見えないことです。Shopify側の仕様変更、APIのエラー、キャッシュの不整合——原因はさまざまですが、どれも「気づいたら広告が止まっていた」という形で表面化します。
フィードが止まる＝広告が止まる
GMCはフィードから商品情報を得ています。フィードが空になったり取得できなくなったりすると、掲載商品が消え、ショッピング広告も無料リスティングも配信されなくなります。売上に直結する障害です。
ヘルスチェックAPIで生成を見張る
そこで、フィードがちゃんと生成できているかを確認する専用のヘルスチェックAPIを用意しました。フィードの生成を実際に試み、商品件数が想定の範囲にあるか、必須項目が入っているかといった観点で健全性を返します。
監視サービスがヘルスチェックAPIを一定間隔で呼ぶ
フィードが生成できるか、件数が0や異常値でないかを確認
件数の急減や生成失敗を検知したら担当者へアラート
件数の急減を異常として捉える
単に「生成できたか」だけでなく、商品件数の変化を見るのがポイントです。普段は数千件あるはずのフィードが、ある日突然数十件に減っていたら、それは明らかな異常のサインです。
生成自体は成功していても中身がスカスカ、というケースは意外と起こります。だからこそ「0件でないか」ではなく「いつもと比べて極端に少なくないか」まで見ておくと、静かな障害を早めにつかまえられます。
まとめ
フィードの運用は、「軽く作る」と「止まったら気づく」の2本柱です。
- キャッシュ：数時間のTTLで生成結果を使い回し、負荷を抑えつつ鮮度を保つ
- ページサイズ制御：大量SKUを分割し、商品数の成長に耐える
- ヘルスチェックAPI：生成の可否と件数を定期監視し、静かな障害を検知する
- 件数の急減を異常として捉え、中身が空っぽになる事故を防ぐ
フィードは止まれば広告も止まる、売上直結の仕組みです。フィードそのものの作り方は商品フィードの自動生成やマッピング設計を、掲載品質を守る仕掛けはフィード品質の管理をあわせてどうぞ。