こんにちは、HafH で障害対応を行っている @kseta です。最近は Google Cloud と仲良くなるためにドキュメントや資料を読み込んでいる日々です。
2021年8月1日に HafH は大幅なリニューアルを実施しました。
note の冒頭にあるようにリリース時刻にシステムトラブルが発生してしまいました。当日は朝６時から JAL との航空サブスクサービス実証実験の申し込みが始まることも相まって、早朝から多数のユーザーが公開のために待機してくださってました。ユーザーのみなさまには大変なご迷惑をお掛けしました。改めて申し訳ございませんでした。
朝5時半からぶっ続けでパソコンに向き合いながら、HafH、本日リニューアル。8月1日は、とても大きな一日でした。ローンチ時には一部の皆様にアクセスしづらい状況となりご不便とご迷惑をおかけしました。
今回の障害については再発防止策を打ったものの厳密な原因は不明でした。が、調査が進みましたので、どこかの誰かが私たちと同じ失敗を踏まないように情報公開したいと思います。
HafH は Google Cloud の GAE flexible environment を利用して Next.js を利用したアプリケーションで動作しています。リリース当日は０時頃からメンテナンスモードに切り替え、朝６時にリニューアル版を公開する予定でした。
最初に問題が発生したのは０時にメンテナンスモードに切り替えたときでした。メンテナンスモードへ切り替えるためのプログラムをリリースしましたが、メンテナンスモードに切り替わるユーザーと切り替わらないユーザーが社内で発生しました。限られた時間で対応判断が必要でしたが、以下を材料としひとまず予定していたメンテナンス作業を続行することにしました。
そして朝６時の公開を迎えました。
私は深夜対応担当ではなく朝８時頃に起きて日中待機する担当でしたが朝に電話が鳴りリリース時刻に「切り替わらない」ということを知ったときは長期戦を覚悟したことを覚えています。結局、この事象は確認できた範囲では数日後まで続き、時間経過でしか解決できませんでした。
まず初動の15分でブラウザキャッシュ削除、シークレットモードでアクセス、ブラウザ変更、再デプロイ等を試してみました。これらでは解消せず GAE のエッジキャッシュにあたりをつけ、Next.js のキャッシュ設定の影響の可能性と並列で調査を行いました。
暫定回避策として URL に ?hafh-day-2021 のようなクエリパラメーターを付与すると必ずリニューアル版が表示されることに気づき SNS 等でクエリパラメーター付の新しい URL で案内を行いました。
この問題が発生しているのは Next.js で SSG を利用しているページのみであり、GAE の app.yaml に設定可能な expiration 等のパラメーターはこの事象には有効ではないこと等が確認できました。
GAE flexible のエッジキャッシュがどのような条件で作成され、既に作成されてしまったそれらをどのように削除するかは発見することができず時間経過での解決を祈るしかできませんでした。
Google のサポートの方にエンジニアと繋いでいただき以下の回答をいただきました（意訳）。
Cloud CDN がキャッシュする条件については以下に記載があります。
大筋、キャッシュ作成条件のポイントは以下の理解で良いようです。
Next.js で SSG を行うと Cache-Control: s-maxage=31536000 stale-while-revalidate が必ず設定される実装になります。この場合、必ずエッジキャッシュが作成されてしまいます。そして一度作成されると削除する方法はありません。デプロイしてもサービスを削除してもキャッシュがヒットし続けます。
# https://github.com/vercel/next.js/blob/51559f5c645c6ad8ba1bf2da74bac284015f887e/packages/next/server/send-payload.ts#L35
export function setRevalidateHeaders(
res: ServerResponse,
options: PayloadOptions
) {
if (options.private || options.stateful) {
if (options.private || !res.hasHeader('Cache-Control')) {
res.setHeader(
'Cache-Control',
`private, no-cache, no-store, max-age=0, must-revalidate`
)
}
} else if (typeof options.revalidate === 'number') {
if (options.revalidate < 1) {
throw new Error(
`invariant: invalid Cache-Control duration provided: ${options.revalidate} < 1`
)
}
res.setHeader(
'Cache-Control',
`s-maxage=${options.revalidate}, stale-while-revalidate`
)
} else if (options.revalidate === false) {
# ここでセットされる
res.setHeader('Cache-Control', `s-maxage=31536000, stale-while-revalidate`)
}
}
これを回避するためには SSR でキャッシュされないように Cache-Control をセットするか revalidate に短い時間を設定することです。
return {
props: {},
revalidate: 10
}注意点としては ISR としては機能せず Cache-Control を強制的にセットするためだけの苦しい使い方です。さらに、エッジキャッシュが複数のエッジロケーションに分散されるらしくキャッシュヒットするものしないものが混在してしまうため長い時間のキャッシュはセットするとそれはそれで問題が発生します。
最終的には Cloud CDN を GAE のフロントに配置するのがベストだと Google のサポートからもアドバイスをいただきました。
このあたりの Cloud CDN + GAE の設定や Vercel 以外での ISR の実現については以下の記事が大変参考になりました。このあたりはとても情報が少なく本当に助かりました。CatNose さんありがとうございます！
結論は冒頭にまとめたとおりです。GAE のエッジキャッシュとうまく付き合うためには Cloud CDN + GAE を使いましょう！
GAE はアプリケーションの動作環境やスケーリングをマネージしてくれる大変便利なサービスですが、それゆえに問題発生時には GAE が提供する環境とうまく付き合っていかなくてはいけません。特に今回のようなキャッシュ関連についてはキャッシュ削除機能がないために特に注意が必要です。
HafH では今回の問題に対して Cache-Control の設定によって完全に対策済ですが、よりベストなパフォーマンスと DX (Development Experience) を求めて Cloud CDN の導入を進める予定です。
HafH にはインフラに強いエンジニアがまだいません。一人目のインフラエンジニアとして興味もっていただいた方や Next.js, Rails 製の API のキャッシュ戦略を考えガンガン改善していくことに興味を持っていただいたエンジニアの方はぜひ Wantedly より応募ください😄
/assets/images/3199691/original/ee22c21f-4582-4bd0-a277-e37ebfbfa284?1647237449)
/assets/images/6210054/original/ee22c21f-4582-4bd0-a277-e37ebfbfa284?1612417321)
/assets/images/3199691/original/ee22c21f-4582-4bd0-a277-e37ebfbfa284?1647237449){kind=avatar}
