カッパでも分かるiOSアプリゲーム開発

カッパがひたすらゲーム制作に関することを書くブログです。Railsに関するTipsもたまにまとめてます。

【Rails】【業務日誌】だいたい犯人はキャッシュ

スポンサードリンク

ずっと続いていた不具合の原因がやっと分かった。

エラー調査をしまくるカッパ

  • 本番でしか再現しないバグというのは調査が大変だ

(しかも本番サーバーに入れず、webからのアクセスも外部の人しかできない)

  • 仕方ないので画面共有してもらいながら通話し、chrome のデベロッパツールで調べまくる
  • NetWork タブで調べれば実行したAPIのリクエスト・レスポンスの詳細が全て丸わかりだ。良い時代になったものだ
  • そして、とある GET の API が 304 を返す時にデータ不整合が起きることが分かった

304なんて設定した覚えはねえ

  • HTTPヘッダ 304 は「not modified」。未更新を意味する
  • Rails のコードを見てみたけどどこにも 304 を返す処理なんてしてない
  • 調べてみたら、304はキャッシュとかを読み込んでる時に返すステータスコードだとか

Rails の ConditionalGet 犯人はお前だ

  • Rails では標準で ConditionalGet というキャッシュを読み込む仕組みがある
  • eTag とかいうものを参照して見比べて、違いがなければ 304 を返してキャッシュを返すという余計なお節介な仕組みだ
  • デフォルトで本番が設定ONになってる(らしい)
  • これなら本番でしか起こらないという今回のバグにも説明がつく!

どうやって対処したか 案1:変なパラメーターつける

  • ConditionalGet をオフにするというのはサービス全体に影響を及ぼすからダメだ
  • APIのリクエストパラメーターにタイムスタンプとか付ければurl変わるからキャッシュ読まれない説を提唱してみた
  • ↑「ダサいからやめましょう」と却下された。格好つけてる場合か

どうやって対処したか 案2:適切なレスポンスヘッダをつける

  • このAPIにアクセス時は Cache-Control ヘッダに no-store, must-revalidate, max-age=0 を返すように設定した
  • なんかキャッシュ関係のヘッダは色々と設定があって紛らわしい
  • no-cache という名前だけど場合によってはキャッシュをするとか命名詐欺な気がする
  • ちなみにレスポンスヘッダと聞くたびにスッポンポンを想像して悶々とするのは、きっとカッパだけではないだろう
  • なんか grape とかいうAPI簡単に作れるライブラリを使ってたせいでなかなか設定できずに参った
  • 仕方ないのでgrape-cache_control という 古い gem を入れた

https://github.com/karlfreeman/grape-cache_control

 cache_control :no_store, :must_revalidate, max_age: 0

古すぎる gem を使うことに難色を示された

レビュアー「いざという時にモンキーパッチで対応という事もあり得るんですよね?」

ばかやろー!
モンキーパッチと聞くとモンキーパンチを連想し、ルパン三世のテーマが脳内に流れて気が散る。

ちなみにルパン作品の中では異色だが『ワルサー p38』は超傑作。
後にも先にもカッパが買ったDVD作品はこれのみ

ふぅ〜じこちゅわ〜ん  って誰もがこっそり一度はモノマネの練習をする事だろう。

総括

  • 今回は大きなバグが二つあった事が非常に厄介だった
  • おかげで「もうすぐ解決します!」を2週間に渡り連呼する事になった
  • キャッシュなんてバグの元なので全部オフにしてしまえー!
  • パフォーマンスなんて知った事かー! ケー!
  • ちなみに俺とK2の間には一切のキャッシュが存在しない。関わりがないからだ