# 2021/02/06 メンター相談

###### tags: `メンター相談`,`2月`

## 画像以外にキャッシュを使う場面はあるか？

[質問全文](https://airtable.com/tblA4yYGHwaqDYKwx/viwAUwNVsR9rOkW6u/recaht4arAH4rZLCA)

> 普段業務を行なっていて、画像やJavaScriptなどの静的コンテンツをキャッシュすること以外に何かコンテンツをキャッシュすることはありますか？(例えば、session_idをRedisに保存するなど) また、その際にどんなことを意識されますか？(キャッシュの有効期限は？どのタイミングでキャッシュの書き込みを行う？キャッシュの保存容量は？)

- 主に画像、バンドル済JavaScriptしかキャッシュしない
- 事故が怖い
- Next.jsのレポートより
- リソースの半分は画像 -> **画像がキャッシュできれば十分**
- 最初に必要なリソースのみを読み込む
- キャッシュするなら
- manifest.json 等一度あげたら変わらないもの
- cdn系のサービスを選ぶときのプロバイダ選定基準
- Fastly
- インスタントパージ機能あり
- **どれだけ一瞬でキャッシュを消せるかを重要視する**
- Nginx
- パージ用のエンドポイントがある
- (nginxのキャッシュパージ用モジュール、どれだったか調べる)
- 参考文献
- [Blog - Next.js 10 | Next.js](https://nextjs.org/blog/next-10)
- > Furthermore, 30% of images on web pages are outside of the initial viewport, meaning the browser loads images that a user does not see until they scroll further down the page.
- > (DeepL翻訳)さらに、ウェブページ上の画像の30%は、最初のビューポートの外にあります。つまり、ブラウザは、ユーザーがページをさらに下にスクロールしないと見えない画像を読み込みます。
- [Web application caching and purging | Fastly](https://www.fastly.com/products/web-and-mobile-performance/caching-and-purging)
- > Instant Purge lets you update stale content within 150 milliseconds or less on a global average - this is considerably faster than other CDNs.
- > (DeepL翻訳) Instant Purge では、グローバル平均で 150 ミリ秒以内に古いコンテンツを更新することができ、これは他の CDN よりもかなり高速です。

## リバースプロキシにて、レスポンスを丸ごとキャッシュすることはあるか？

[質問全文](https://airtable.com/tblA4yYGHwaqDYKwx/viwAUwNVsR9rOkW6u/recfip6hKvAEbszyN)

> リバースプロキシとして設定したNginxで、レスポンスを丸ごとキャッシュすることでレスポンスを高速化するという記事を見かけたのですが、一般的にこのようなキャッシュの使い方はされますか？トラフィックの多いサービスなどで瞬間的にリクエストを捌く際には有効な方法のひとつになりますか？

- 丸ごとキャッシュはしない
- 動的コンテンツをキャッシュするのが怖い
- Redisを選ぶ場合が多かった
- Redis or Nginxのキャッシュ
- Redisのキャッシュより2,3倍Nginxの方が早い
- Nginxで返せる APIまで到達しない
- 緻密に制御したい場合Redis
- 参考文献
- https://github.com/openresty/redis2-nginx-module

## キャッシュの使い方が面白い・上手いと思ったサービスは？

[質問全文](https://airtable.com/tblA4yYGHwaqDYKwx/viwAUwNVsR9rOkW6u/recZ0wrdH5SyTmRps)

> キャッシュの使い方が面白い・上手いと思ったサービスは何かありますか？

- DEV.to
- 超速い
- キャッシュをうまく使っているので、速い
- キャッシュと遅延回避を重要視
- 初めに重要なドキュメントのみを取得
- お気にいり・コメント等は後で取得
- 画像形式がwebp
- [WebP | Wikipedia](https://ja.wikipedia.org/wiki/WebP)
- > Googleの示した事例では、ファイルサイズは非可逆圧縮モードで（同一画像、同等画質の）JPEGと比較して25-34%小さくなり、可逆圧縮モードでPNGと比較して28%小さくなるとしている。
- 技術スタックが公開されている (Heroku, Fastly や Ruby on Rails を使用していることがわかる)
- [Making dev.to Incredibly fast](https://dev.to/ben/making-devto-insanely-fast)
- [The dev.to tech stack](https://dev.to/ben/the-devto-tech-stack)
- zenn.dev
- devtoをリスペクトしている
- resume
- Fastlyを利用している
- [Fastly + Rails + Herokuでページをキャッシュする方法](https://catnose99.com/rails-heroku-fastly/)
- ブログ (書き込み少なく・読み込み多い)ものにキャッシュは有効
- debtoolsで低速回線をエミュレートできる (Slow 3G等)

## Access-Control-Allow-Originの設定

[質問全文](https://airtable.com/tblA4yYGHwaqDYKwx/viwAUwNVsR9rOkW6u/recHwUeD1GR2lY7br)

> Access-Control-Allow-Originの値の設定に関して質問です。
>
> CORS設定は、全てのドメインに一律で同じ設定をするのではなく、CORSを許可したいドメインにのみ、CORSの設定をするようにするのが良いのでは？
>
> またそのようにすれば、ワイルドカードを設定すること自体は特に問題にはならないのでは？（もし認証情報を持ったクッキーを付与したい場合は、そもそもワイルドカードは設定できない）
> ...
> これについて業務ではこのように設定している、もっとこうした方が良いなど、ご意見伺いたいです。

- ホワイトリストされたオリジンで判定する方法について
- 似た作りにしたことがある
- (ホワイトリスト対象に `www.site.example` と `site.example` が指定されている件についての指摘)
- CNAMEで解決できるので、DNSで解決したい
- -> Applicationには業務に関係するロジックだけを持ちたい ので
- クッキー送信しないように allow対象のオリジンは絞ることが多い
- 外部に公開するAPIの設定について
- (ホワイトリスト方式を使わずに) Allow-Originにワイルドカードを指定している場合が多い
- TwitterAPIはCORSをサポートしない
- バックエンドから使われる想定。ブラウザから叩かれることを想定していない
- APIキーの隠し場所に困る
- バックエンドは隠しやすい
- ブラウザにキーを隠すことができない
- [Will Twitter API support CORS Headers soon?](https://twittercommunity.com/t/will-twitter-api-support-cors-headers-soon/28276/2)
- > This has been requested before, and there are no plans at present - the typical pattern is that requests to the Twitter API happen at the backend rather than directly, say, from within a browser-based app.
- squarespaceも同様
- -> 外部に公開するAPIはAPIキーの隠し場所に困るので、バックエンドからのアクセスのみを想定する場合が多い。よって、ホワイトリスト形式を多用することはないのではないか？

## 各ブラウザのキャッシュ上限は？

[質問全文](https://airtable.com/tblA4yYGHwaqDYKwx/viwAUwNVsR9rOkW6u/recKyFTwV6iTLuKk9)

> Chromeは、デフォルトのキャッシュサイズは、const int kDefaultCacheSize = 80 * 1024 * 1024; （87行目）で PreferredCacheSizeInternal（58行目）のロジックで変化していく
>
> Firefoxは、
おそらく1GB（デフォルトの最大キャッシュサイズを確認できる方法があったので、浦川のPCで確認したところだと1GBになっていました。）
確認方法は以下のとおりです
`about:config`をアドレスバーに打ち、`browser.cache.disk.capacity`を検索する

- すばらしい回答
- 課題の意図
- ブラウザの仕様がまちまちであることに気づく
- キャッシュサイズは意外と小さい
- キャッシュは消える可能性があるよ
- キャッシュ環境はユーザーの端末に左右されるので、あまり信頼しない
- (cookieも同様)

## ブラウザキャッシュしてはいけないケース

[質問全文](https://airtable.com/tblA4yYGHwaqDYKwx/viwAUwNVsR9rOkW6u/recApwQDJ1Z3r0qdv)

> 「ブラウザキャッシュをしてはいけないケース」はどのようなケースがあるでしょうか？
>
>「してはいけない」ようなケースが思いつきませんでした。例えば、頻繁に変わる動的なページだったとしても no-cache 等を指定して、検証を行う方がパフォーマンス的に有利なのでは無いか、と考えました。
>
> - 機密情報 -> ブラウザキャッシュなので問題ない？
> - 動的なページ -> no-cache 等で毎回検証する方がパフォーマンス的に有利？(検証に成功した場合、リソースを取得しなくてよいため)

- no-cache no-storeはほぼ同義 (キャッシュされない、されたとしても毎度問い合わせる = 問い合わせが発生する)
- nocacheは毎度問い合わせる 問い合わせで遅延が発生
- メルカリのCDN
- no-cacheにしたからといって安心できない
- [CDN切り替え作業における、Web版メルカリの個人情報流出の原因につきまして](https://engineering.mercari.com/blog/entry/2017-06-22-204500/)
- CDNのキャッシュの仕様も調査する必要がある
- `Cache-Control: private`
- PayPalの脆弱性
- no-cacheを使用
- 存在しないCSSに対してキャッシュを保存させる
- 機密情報も一緒にキャッシュされてしまっていた
- [Web Cache Deception Attack Tricks Servers Into Caching Pages with Personal Data](https://www.bleepingcomputer.com/news/security/web-cache-deception-attack-tricks-servers-into-caching-pages-with-personal-data/)
- 記事内に動画も添付されていました。
- > Taking PayPal as an example, Gil discovered that if a user accesses a link pointing to a non-existent resource, the PayPal server will create a cache for the URL section up until the non-existent resource.
- > (DeepL翻訳) Gil氏は、PayPalを例にとると、ユーザーが存在しないリソースを指すリンクにアクセスした場合、PayPalサーバーは、存在しないリソースまでのURL部分のキャッシュを作成することを発見しました。
- まとめ
- no-cacheはキャッシュ保存される -> キャッシュ流出の可能性がある
- no-storeも仕様によっては安心できない
- プライベートキャッシュであっても機密情報はキャッシュしない
- **予期しないところから脆弱性が生まれることがある**
- 機密情報が漏れるリスクを上回るほどのメリットがあるとき以外は使うべきではない (no-cacheはあまりメリットがないと思われる)

### 関連質問

- 画像が多いとすぐキャッシュ上限に達してしまう？
- 画像はCDNにキャッシュさせることが多い
- ブラウザキャッシュの場合、一度目はキャッシュから返せない
- CDNなら誰かが取得していればキャッシュされる
- (しかしCDN・ブラウザに同じキャッシュ指示が届くので、結果的にブラウザにもキャッシュされてしまう？)
- 一瞬でキャッシュを破棄したいときどうするか (例: dev.toの画像ファイル名)
- 長い一意な文字列
- ファイル名を変えて、キャッシュを破棄させる
- fastlyのコンテンツの定義 三種類
- saticコンテント
- dynamicコンテント
- 一度目と二度目の内容が変わる
- 例えばTwitter
- -> 2回同じになることはないので、キャッシュできない
- event drivenコンテント
- 例：マイページ、ニュース記事、コメント
- -> 変更されるまで変わらないので、一瞬でキャッシュを破棄できるならキャッシュしてもいい！
- 参考文献
- [The rise of event-driven content (or how to cache more at the edge) | Fastly](https://www.fastly.com/blog/rise-event-driven-content-or-how-cache-more-edge)
- [Leveraging your CDN to cache "uncacheable" content | Fastly](https://www.fastly.com/blog/leveraging-your-cdn-cache-uncacheable-content)
- 石原さん質問
- ブラウザキャッシュ = プライベードキャッシュ をしてはいけないケースだと思った
- ブラウザならば機密情報を保持してもいいはず？
- 回答
- **予期しないところから脆弱性が生まれることがある**
- 機密情報が漏れるリスクを上回るほどのメリットがあるとき以外は使うべきではない (no-cacheはあまりメリットがないと思われる)
- PCを破棄するときにブラウザキャッシュ見たら確認できてしまう。みたいな記事を見た

## その他

- インスタントパージの使用場面
- コンテンツが削除された時・古くなった時
- 管理画面からもできるかもしれないが、プログラムから削除できた方が便利
- fastlyはどこからでも一瞬で消せることを謳っている すごい！
- cdn系サービスの使い分け
- クラウドフロントが多い
- AWSで構成管理することが多く、クラウドフォーメーションで一括管理できるから
- 複雑なキャッシュ制御したことない インスタントパージ等必要なかった
- パフォーマンスはアプリケーションがボトルネックになることが多い
- データベースからのデータ取得の仕方でパフォーマンスに差が出る
- Redisって？
- キーバリュー型のメモリ上に存在しているデータベース
- 使用場面
- 一番多いのが
- 消えても困らない情報
- 変わらない情報
- 致命的ではない情報 (いいねの数)
- 一旦Redisに入れておいて、Redisから返す
- ゲーム
- オンメモリじゃないと追いつかない
- 検索結果
- 検索を毎回データベースにかけに行くのはたいへん
- redisで回答をキャッシュしておいた
- ただし、レコメンドには使えない
- 検索用のSaaSが出てきて、今後は減っていくかも？
- 例えば [Algolia](https://www.algolia.com/)
- GitHubプライベートレポジトリのURL変わらない
- 画像をプライベートにできる？
- アクセス制御が必要
- -> 安易にキャッシュが使えなくなる
- あまりしないかも、、？
- S3
- アクセスコントロールリストで制御できる
- パフォーマンスを損なわずにアクセス制御する方法
- 調べておく
- Firebaseだとセキュリティールールで簡単に制御できる