日経電子版のキャッシュ戦略 / The cache strategy of the Nikkei online edition

■イベント 

【Engineering Team Presentation】各社の事業を支えるアーキテクチャ
https://sansan.connpass.com/event/200589/

■登壇概要
タイトル：日経電子版のキャッシュ戦略
発表者：株式会社日本経済新聞社　デジタル事業デジタル編成ユニット
Tech Lead　梅崎 裕利

▼Builders Box
https://buildersbox-online.com/

Transcript

1. ⽇経電⼦版のキャッシュ戦略 2021/2/9 ⽇本経済新聞社 デジタル事業 編成ユニット 梅崎裕利
2. About me Yuri Umezaki Engineer at Nikkei Inc. Python, Elasticsearch, AWS Elastic Beanstalk 電⼦版のAPI/インフラ基盤の設計や運⽤を中⼼に サービスのセキュリティ強化やデータ分析など幅広く担当 - 最近焦ったこと AWS gp3 volumeが出た直後に試したら 翌⽇600万円の請求アラートが来た (※バグでした) 翌⽇にはAWSにより修正済み. Twitterに情報無いときはRedditを⾒るのが良い 2
3. きょう話すこと - アーキテクチャ - キャッシュの⽬的 - 各構成毎のキャッシュ詳細 - キャッシュ効率を⾼める構成 - 事業戦略とのトレードオフ - 性能計測と今後 3
4. - 2010年3⽉に創刊 - ⽉間アクセス約3億 - 毎⽇約1000件の記事を配信 - デジタル購読数(電⼦版有料会員、専⾨紙ビューアーなど) 約80万⼈ - PC・モバイルサイト、iOS、 Androidアプリ ⽇経電⼦版とは 4
5. 〜2019 * AWS移⾏ * 検索・レコメンド機能強化 * データ分析基盤作成・活⽤ * 内製の活性化 (現在 GitHubに約930repos) 2020 * 主要サービスはCDN配信に *「NIKKEI Financial」サービス開始 *「AI推薦」リリース *「Think!」スタート、エキスパートが投稿 バックエンドシステムの変遷 5
6. アーキテクチャ 6
7. (データの流れ視点) APIGWレイヤ - インターフェイス⼀元化 - ドキュメンテーション - 認証・認可・権限管理 - ロギング - Rate limit APIGWの後段は各システムで各々 システム構成 7
8. (⼩ネタ)API Secret発⾏ルール APIキーの中に、検索でヒットしにくい⽂字列を含めておく 例: nkseckey-xxxxxxxxxxxxxxxxxxxxxx • secretの種類が判別できる • 定期的にGitHub検索かけることでsecret流出に気が付ける • (GitHubにパターンを伝えることで検出対応してくれることも) 8
9. キャッシュ 9
10. Webの表⽰速度 表⽰が遅くなると離脱率は上がる 年々ユーザの我慢強さが減っており、 最近は更に離脱率は上がっている 10 https://medium.com/ft-product-technology/a-faster-ft-com-10e7c077dc1c https://web.dev/vitals/
11. キャッシュの⽬的 - 速度 - ⾮常に重要 - 利便性⾯ - オフライン機能 - コスト削減 - 計算量/帯域 - スケーラビリティ - 安定性⾯ - stale-if-error 11
12. キャッシュの速度効果 ⽐較的遅いページでも キャッシュで応答時間を⼤幅に短縮可能 12
13. アプリAPIのキャッシュ - アプリPush通知直後の負荷急増 - アプリ利⽤者の増加 - 突発的に普段の数百倍リクエストが来る - オートスケール → ほぼ間に合わない - 事前準備 → ⾼コスト Push直後は⼀部のデータ更新を⽌めて 表⽰に必要なものだけを返却 13
14. 各レイヤでのキャッシュ - ブラウザキャッシュ(アプリ内キャッシュ) - 再利⽤時の通信量が減らせる.最速 - iOSは独⾃実装、AndroidはOkHttp - CDNキャッシュ - 配信⽬的のキャッシュとして⾼効率 - Appバックエンドキャッシュ - バックエンドAPIが落ちたときに代替 - 不安定なSaaS利⽤時など 14 Cache Cache Cache Cache
15. キャッシュ戦略 - キャッシュヒット率をいかに⾼めるか - 低頻度更新コンテンツ→URLにrevisionを含めてimmutable化 - JS, CSSなど. ブラウザキャッシュを使う - 中頻度更新コンテンツ→SSR+変更イベントで更新 - 記事ページ - 低キャッシュ効率/⾼頻度のもの→CSR - 個⼈別のお知らせ 効率・更新頻度に合わせてエンドポイントを分離 15
16. 記事の変更を即時に反映させる 変更記事のIDをkeyに削除 表⽰に必要な変更は⼀元管理 キャッシュクリア 16 Cache Cache Cache Cache 記事変更 ユーザ情報変更
17. ポイント キャッシュ変更に必要なイベントを集約 • 本⽂変更 • メタデータ変更 17
18. キャッシュ効率を⾼める構成 Cookie等に権限情報を含めておき、CDNで権限毎のCacheを持つ 19
19. ビジネス要件との競合FAQ - ABテストはキャッシュが難しくない？ - Fastly内で判定してキャッシュ出し分けをしているためキャッシュ可能 - 同時実⾏のABテスト分効率は下がる →ABテスト期間を⻑期にしないという制約で対応 - 会員種別や機能が増えるとキャッシュ効率が下がるのでは？ - ページ毎に必要な権限を整理しなるべく効率を落とさないように - 機能毎にSSRとCSRを使い分けて対処 20
20. ちょっと細かい話 権限は改ざんされないようJWT等にしてCDN内で検証 オリジンのVaryヘッダを切り替えることで キャッシュ範囲をツリー式に分岐できる 21 https://www.fastly.com/blog/getting-most-out-vary-fastly
21. その他 - コスト削減 - 計算量/帯域 - スケーラビリティ - 安定性⾯ - stale-if-error 22
22. Stale-If-Error バックエンドが死んでいる場合でも、キャッシュを返して エラーの影響を最⼩限にする機能 FastlyとAPIGWに実装 • BFFやその後段が死んでも、Fastlyで正常時のレスポンスを返却 • APIGWのバックエンドサービスが死んでもRedisのキャッシュで対応 • APIGWのMySQLやRedisが死んでもインメモリデータ等で対処 → DBの更新が容易に 23
23. 表⽰速度改善と今後 24
24. 改めて表⽰速度とは - サーバがレスポンスを返すまでの時間 - コンテンツの表⽰が始まる時間 - 画⾯内のコンテンツを表⽰し終わる時間 → 意外と難しい サーバのログ(CDNやALB、Nginxなどのログ)では、正しく計測できない - CDNのアクセスログはsend-queueに⼊れたタイミング - アプリログ: socket-queueに溜まっていた時間が⼊らない - 直列ロードなどで待ち時間が増えるケースも → 性能チェックはクライアント側でやるのが望ましい 25
25. Google Web Vitals サイトの健全性を⽰す重要指標 LCP: 主要コンテンツが表⽰されるまでの時間 FID: 最初の⼊⼒までの遅延 CLS:視覚的な安定性(レイアウトのズレ) https://web.dev/vitals/ 26
26. アプリの表⽰時間 Performance Monitoring SDK などを活⽤ 通信時間などが取得可能 ⼀⽅、画⾯表⽰にかかる時間は実装によって変わるので 何をベンチマークとするか、個別に測定ポイントを決めて計測する必要がある 27
27. おわりに 今回はキャッシュ戦略を中⼼にシステムを紹介 性能維持にはモニタリングが必要 - WebVitalsを活⽤ - データ分析基盤内に機能を⼊れて広く計測 - アプリ側に⼊れて調査 継続的な分析を複数視点で取り組んでいく 28
28. ⽇経はエンジニアの仲間を募集中 ⽇本経済新聞社デジタル事業 では [API-バックエンド] [SRE] [Web] [アプリ] などの各チームでエンジニアを募集しています https://hack.nikkei.com/jobs/ エンジニア向けTwitter @nikkeideveloper DMお待ちしてます カジュアル⾯談からご気軽に! 29