Tweet
Tweet

Slide 1

Slide 1 text

⽇経電⼦版のキャッシュ戦略 2021/2/9 ⽇本経済新聞社 デジタル事業 編成ユニット 梅崎裕利

Slide 2

Slide 2 text

About me Yuri Umezaki Engineer at Nikkei Inc. Python, Elasticsearch, AWS Elastic Beanstalk 電⼦版のAPI/インフラ基盤の設計や運⽤を中⼼に サービスのセキュリティ強化やデータ分析など幅広く担当 - 最近焦ったこと AWS gp3 volumeが出た直後に試したら 翌⽇600万円の請求アラートが来た (※バグでした) 翌⽇にはAWSにより修正済み. Twitterに情報無いときはRedditを⾒るのが良い 2

Slide 3

Slide 3 text

きょう話すこと - アーキテクチャ - キャッシュの⽬的 - 各構成毎のキャッシュ詳細 - キャッシュ効率を⾼める構成 - 事業戦略とのトレードオフ - 性能計測と今後 3

Slide 4

Slide 4 text

- 2010年3⽉に創刊 - ⽉間アクセス約3億 - 毎⽇約1000件の記事を配信 - デジタル購読数(電⼦版有料会員、専⾨紙ビューアーなど) 約80万⼈ - PC・モバイルサイト、iOS、 Androidアプリ ⽇経電⼦版とは 4

Slide 5

Slide 5 text

〜2019 * AWS移⾏ * 検索・レコメンド機能強化 * データ分析基盤作成・活⽤ * 内製の活性化 (現在 GitHubに約930repos) 2020 * 主要サービスはCDN配信に *「NIKKEI Financial」サービス開始 *「AI推薦」リリース *「Think!」スタート、エキスパートが投稿 バックエンドシステムの変遷 5

Slide 6

Slide 6 text

アーキテクチャ 6

Slide 7

Slide 7 text

(データの流れ視点) APIGWレイヤ - インターフェイス⼀元化 - ドキュメンテーション - 認証・認可・権限管理 - ロギング - Rate limit APIGWの後段は各システムで各々 システム構成 7

Slide 8

Slide 8 text

(⼩ネタ)API Secret発⾏ルール APIキーの中に、検索でヒットしにくい⽂字列を含めておく 例: nkseckey-xxxxxxxxxxxxxxxxxxxxxx • secretの種類が判別できる • 定期的にGitHub検索かけることでsecret流出に気が付ける • (GitHubにパターンを伝えることで検出対応してくれることも) 8

Slide 9

Slide 9 text

キャッシュ 9

Slide 10

Slide 10 text

Webの表⽰速度 表⽰が遅くなると離脱率は上がる 年々ユーザの我慢強さが減っており、 最近は更に離脱率は上がっている 10 https://medium.com/ft-product-technology/a-faster-ft-com-10e7c077dc1c https://web.dev/vitals/

Slide 11

Slide 11 text

キャッシュの⽬的 - 速度 - ⾮常に重要 - 利便性⾯ - オフライン機能 - コスト削減 - 計算量/帯域 - スケーラビリティ - 安定性⾯ - stale-if-error 11

Slide 12

Slide 12 text

キャッシュの速度効果 ⽐較的遅いページでも キャッシュで応答時間を⼤幅に短縮可能 12

Slide 13

Slide 13 text

アプリAPIのキャッシュ - アプリPush通知直後の負荷急増 - アプリ利⽤者の増加 - 突発的に普段の数百倍リクエストが来る - オートスケール → ほぼ間に合わない - 事前準備 → ⾼コスト Push直後は⼀部のデータ更新を⽌めて 表⽰に必要なものだけを返却 13

Slide 14

Slide 14 text

各レイヤでのキャッシュ - ブラウザキャッシュ(アプリ内キャッシュ) - 再利⽤時の通信量が減らせる.最速 - iOSは独⾃実装、AndroidはOkHttp - CDNキャッシュ - 配信⽬的のキャッシュとして⾼効率 - Appバックエンドキャッシュ - バックエンドAPIが落ちたときに代替 - 不安定なSaaS利⽤時など 14 Cache Cache Cache Cache

Slide 15

Slide 15 text

キャッシュ戦略 - キャッシュヒット率をいかに⾼めるか - 低頻度更新コンテンツ→URLにrevisionを含めてimmutable化 - JS, CSSなど. ブラウザキャッシュを使う - 中頻度更新コンテンツ→SSR+変更イベントで更新 - 記事ページ - 低キャッシュ効率/⾼頻度のもの→CSR - 個⼈別のお知らせ 効率・更新頻度に合わせてエンドポイントを分離 15

Slide 16

Slide 16 text

記事の変更を即時に反映させる 変更記事のIDをkeyに削除 表⽰に必要な変更は⼀元管理 キャッシュクリア 16 Cache Cache Cache Cache 記事変更 ユーザ情報変更

Slide 17

Slide 17 text

ポイント キャッシュ変更に必要なイベントを集約 • 本⽂変更 • メタデータ変更 17

Slide 18

Slide 18 text

キャッシュ効率を⾼める構成 Cookie等に権限情報を含めておき、CDNで権限毎のCacheを持つ 19

Slide 19

Slide 19 text

ビジネス要件との競合FAQ - ABテストはキャッシュが難しくない？ - Fastly内で判定してキャッシュ出し分けをしているためキャッシュ可能 - 同時実⾏のABテスト分効率は下がる →ABテスト期間を⻑期にしないという制約で対応 - 会員種別や機能が増えるとキャッシュ効率が下がるのでは？ - ページ毎に必要な権限を整理しなるべく効率を落とさないように - 機能毎にSSRとCSRを使い分けて対処 20

Slide 20

Slide 20 text

ちょっと細かい話 権限は改ざんされないようJWT等にしてCDN内で検証 オリジンのVaryヘッダを切り替えることで キャッシュ範囲をツリー式に分岐できる 21 https://www.fastly.com/blog/getting-most-out-vary-fastly

Slide 21

Slide 21 text

その他 - コスト削減 - 計算量/帯域 - スケーラビリティ - 安定性⾯ - stale-if-error 22

Slide 22

Slide 22 text

Stale-If-Error バックエンドが死んでいる場合でも、キャッシュを返して エラーの影響を最⼩限にする機能 FastlyとAPIGWに実装 • BFFやその後段が死んでも、Fastlyで正常時のレスポンスを返却 • APIGWのバックエンドサービスが死んでもRedisのキャッシュで対応 • APIGWのMySQLやRedisが死んでもインメモリデータ等で対処 → DBの更新が容易に 23

Slide 23

Slide 23 text

表⽰速度改善と今後 24

Slide 24

Slide 24 text

改めて表⽰速度とは - サーバがレスポンスを返すまでの時間 - コンテンツの表⽰が始まる時間 - 画⾯内のコンテンツを表⽰し終わる時間 → 意外と難しい サーバのログ(CDNやALB、Nginxなどのログ)では、正しく計測できない - CDNのアクセスログはsend-queueに⼊れたタイミング - アプリログ: socket-queueに溜まっていた時間が⼊らない - 直列ロードなどで待ち時間が増えるケースも → 性能チェックはクライアント側でやるのが望ましい 25

Slide 25

Slide 25 text

Google Web Vitals サイトの健全性を⽰す重要指標 LCP: 主要コンテンツが表⽰されるまでの時間 FID: 最初の⼊⼒までの遅延 CLS:視覚的な安定性(レイアウトのズレ) https://web.dev/vitals/ 26

Slide 26

Slide 26 text

アプリの表⽰時間 Performance Monitoring SDK などを活⽤ 通信時間などが取得可能 ⼀⽅、画⾯表⽰にかかる時間は実装によって変わるので 何をベンチマークとするか、個別に測定ポイントを決めて計測する必要がある 27

Slide 27

Slide 27 text

おわりに 今回はキャッシュ戦略を中⼼にシステムを紹介 性能維持にはモニタリングが必要 - WebVitalsを活⽤ - データ分析基盤内に機能を⼊れて広く計測 - アプリ側に⼊れて調査 継続的な分析を複数視点で取り組んでいく 28

Slide 28

Slide 28 text

⽇経はエンジニアの仲間を募集中 ⽇本経済新聞社デジタル事業 では [API-バックエンド] [SRE] [Web] [アプリ] などの各チームでエンジニアを募集しています https://hack.nikkei.com/jobs/ エンジニア向けTwitter @nikkeideveloper DMお待ちしてます カジュアル⾯談からご気軽に! 29