行動ログ収集 API サーバの Fastly Compute 移行〜高スケーラビリティ、高信頼性、高メンテナンス性を目指して 〜

Fastly 基幹イベント Yamagoya 2023 の登壇資料です。

https://www.fastly.com/jp/press/press-releases/yamagoya-2023

Transcript

1. Copyright ⓒ 2023 Nikkei Inc. All rights reserved. ⾏動ログ収集 API サーバの Fastly Compute 移⾏ 〜⾼スケーラビリティ、⾼信頼性、⾼メンテナンス性を⽬指して 〜 1
2. Copyright ⓒ 2023 Nikkei Inc. All rights reserved. ⾃⼰紹介 名前︓⽟越 敬典 (たまこし ひろのり） 所属︓⽇本経済新聞社プラットフォーム推進室 職種︓データエンジニア 最近︓⼆児の⽗として育児（8割) と仕事（2割) に奮闘中 2
3. Copyright ⓒ 2023 Nikkei Inc. All rights reserved. 本資料の⽬的と狙い 3 ⽬的 ⾏動ログ収集 API サーバを Fastly Compute に移⾏したら、 既存の問題を⼀挙に解決し、スケラービリティもメンテナンス性も⾼めること ができたという成功事例を伝えること 狙い Edge Computing 活⽤の⼀参考例として検討材料に含めてもらうことが できたら嬉しい
4. Copyright ⓒ 2023 Nikkei Inc. All rights reserved. Agenda 4 1 WHAT: 移⾏の対象 Fastly Compute の移⾏対象のシステムは何︖ 1 WHY: 移⾏の理由 Fastly Compute に移⾏したのは なぜ︖ 2 HOW: 移⾏の⽅法と効果 どのように移⾏し、移⾏した結果どうだったのか︖ 3
5. Copyright ⓒ 2023 Nikkei Inc. All rights reserved. 1. WHAT: 移⾏の対象 5
6. Copyright ⓒ 2023 Nikkei Inc. All rights reserved. 移⾏対象システム概要 ⽇経が運営する各種サービスのお客様の⾏動ログを収集するための REST API サーバ 「記事を読んだ」「ページをスクロールした」等の各種⾏動ログを付帯情報と共に収集する 6 ⽇経電⼦版 記事を読んだ ページを⾒た ページをスクロールした お客様 ⽇経が提供するサービス ⽇経電⼦版 ⽇経電⼦版 サービス上でアクションを起こす アクション例 HTTP リクエスト ⾏動ログ収集 API サーバ 付帯情報 Nikkei ID, 記事ID .. etc 内製データ基盤
7. Copyright ⓒ 2023 Nikkei Inc. All rights reserved. ⾏動ログ収集 API サーバの重要性 ⾏動ログ収集 API サーバは内製データ基盤における最も重要なコンポーネントの⼀つ 重要な理由 1. ⾏動ログの収集ができない = デジタルマーケティングに必要なデータが⽋損する 2. リアルタイムのレコメンド、マーケティング施策発⽕の源泉である 7 施策実⾏ 集計・可視化 蓄積 計測（リアルタイム） データ取り込み 計測 拡張 データベース BIツール 施策発動 バッチ デジタルマーケティングのための内製データ分析基盤 Atlas MA ツール 施策発動 ここを担うのが ⾏動ログ収集 API サーバ
8. Copyright ⓒ 2023 Nikkei Inc. All rights reserved. ⾏動ログ収集 API サーバ ⾏動ログ収集 API サーバの機能 VCL では実装が難しいが、フルスタック Web Application Framework が必要なほどでない機能を提供 8 ページをスクロールした 付帯情報 Nikkei ID, 記事ID .. etc 記事を読んだ ページを⾒た リクエストパラメータ クエリパラメータ リクエストボディ { “action”: “view”, “category”: “page”, ... } JSON 検 証 変 換 補 正 統 合 リクエストヘッダ HTTP リクエスト 連 携 基本的には⾏動ログを受け取り、データ基盤に連携することが唯⼀の機能。 ただし、ただ右から左に流すだけではない。
9. Copyright ⓒ 2023 Nikkei Inc. All rights reserved. ⾏動ログ収集 API サーバの特徴 ⾏動ログ収集 API サーバにはメディア特有の特徴的なアクセスパターンがある 9 全世界からアクセス アクセスのある国数 250 以上 突発的かつ急激な負荷増加の発⽣ 多様なデバイスからのアクセス デバイスの種類 平均秒間リクエスト数 約 2,000 req/sec 最⼤秒間リクエスト数 約 40,000 req/sec 4,000 種類 以上 ⽉間リクエスト数 約 40 億 INBOUND データ転送量 約 7 TB ⽉間トータルリクエスト
10. Copyright ⓒ 2023 Nikkei Inc. All rights reserved. ⾏動ログ収集 API サーバの特徴: 補⾜ 突発的かつ急激な負荷増加は「ニュースメディア x ⾏動ログ」という組み合わせによって⽣じる 10 ニュースメディア ⾏動ログ 突発的かつ急激な リクエスト増加 事件発⽣ 号外/速報 記事を読んだ ページを⾒た 通知を開いた 数⼗万⼈の お客様 ⾏動ログ収集 API サーバ ほぼ同時刻に複数の アクションが⼀⻫に⾏われる 短時間で急激に リクエスト数が増加
11. Copyright ⓒ 2023 Nikkei Inc. All rights reserved. ⾏動ログ収集 API サーバに求められる要件 ⾏動ログ収集 API はあくまで脇役。収集元サービスに迷惑をかけないよう機能を提供する必要がある。 11 要件1 全世界からのリクエストに対してクライアントになるべく早く（約 100 msec 程度以内には） レスポンスを返すこと 要件2 急激なリクエスト数増加にも耐えられること（データ⽋損が発⽣しないこと） 要件3 クライアントから⼀部不整合な⾏動ログデータが送信されたとしてもエラーを返さずにデータ補正を ⾏えること
12. Copyright ⓒ 2023 Nikkei Inc. All rights reserved. 移⾏前のアーキテクチャ AWS の Elastic Beanstalk を利⽤し、5つのリージョンに API サーバを合計400台程度稼働させ、 Route53 で地理的近接性ルーティングでクライアントに近いリージョンのサーバにルーティングさせる 12 DNS 荷重による Blue/Green デプロイメント 5 リージョンで構成 合計 400 インスタンス以上の EC2 Auto Scaling + CPU バースティング
13. Copyright ⓒ 2023 Nikkei Inc. All rights reserved. 2. WHY: 移⾏の理由 13
14. Copyright ⓒ 2023 Nikkei Inc. All rights reserved. 移⾏の理由 移⾏前の⾏動ログ収集APIサーバには３つの観点で⼤きな問題があり、まとめて解決するために移⾏を決断 14 1. アーキテクチャ観点の問題 2. 運⽤観点の問題 3. 機能観点の問題 スケールアウト性能が不⾜ 運⽤コストが⾼い 不整合なデータの連携
15. Copyright ⓒ 2023 Nikkei Inc. All rights reserved. アーキテクチャ観点での問題 急激かつ突発的な負荷上昇に耐えられるほどスケールアウト性能がない。 常時起動インスタンス数を増やしたり、Warm Pool を活⽤することでも部分的に対応できるがコストが増加する 15 … 事件発⽣ 号外/速報 記事を読んだ ページを⾒た 通知を開いた 数⼗万⼈の お客様 ほぼ同時刻に複数の アクションが⼀⻫に⾏われる 数秒でリクエスト数急増 ⾏動ログ収集 API サーバ Auto Scaling によってリクエスト処理 できるようになるまで 50 秒 ~ 数分程度かかるため間に合わない CPU バースティングのクレジット数にも限界 がある
16. Copyright ⓒ 2023 Nikkei Inc. All rights reserved. 安倍元⾸相銃撃事件発⽣時のサーバダウン 安倍元⾸相銃撃事件発⽣時に⽇経電⼦版で号外が出され、プッシュ通知が⾶び、瞬間的に普段の数⼗倍の リクエストが⾏動ログ収集APIサーバに届けられ、サーバがダウンし、⼀定期間⾏動ログデータが⽋損するという事態が⽣じた。 16 安倍元⾸相、撃たれ⼼肺停⽌ 演説中に襲った41歳男逮捕 - ⽇本経済新聞 https://www.nikkei.com/article/DGXZQOUE082ZV0Y2A700C2000000/ … ⾏動ログ収集 API サーバ DOWN 起動中の インスタンスは過負荷で terminate AWS の API リミットに抵触し、 新規インスタンスも 追加できない 内製データ基盤稼働開始以降初めて 数時間のデータ⽋損が⽣じた
17. Copyright ⓒ 2023 Nikkei Inc. All rights reserved. 運⽤観点での問題 シンプルに運⽤コストが⾼い 内製データ基盤のデータエンジニア3⼈で運⽤するには⾮常に運⽤コストが⾼いシステムであった 17 OS のアップグレード⼯数がかかる OS のアップグレード (Amazon Linux1 から Amazon Linux2) にかかった期間 緊急度の⾼いサポート対応が必要 緊急度 high (本番環境の重要な機能に障害発⽣中) 以上の AWS サポートケースを起票して 対応した回数 (半年間) 煩雑なリリース作業 リリースするたびにかかる ⼈⼿による作業時間 2ヶ⽉ 3 回 約 4 - 5 時間
18. Copyright ⓒ 2023 Nikkei Inc. All rights reserved. 機能観点での問題 不整合なデータが⾏動ログデータとして連携される 簡易的なデータ補正ではクライアントから送信される異常データを完全に補正することができない クライアントは⼀部のデータ不整合のみでログ送信が失敗することは許容できない 18 ⾏動ログ収集 API サーバ 内製データ基盤内の データストアへの 連携が失敗 分析レポートの 集計値の⼤幅な変動 期待する値 不正な場合 オブジェクト ⽂字列 { "why": "object" } "{ ¥"why¥": ¥"object¥" }" 期待する値 不正な値 正の浮動⼩数点値 負の浮動⼩数点値 2.533333 -200,000,000.0
19. Copyright ⓒ 2023 Nikkei Inc. All rights reserved. 3. HOW: 移⾏の⽅法と効果 19
20. Copyright ⓒ 2023 Nikkei Inc. All rights reserved. 次世代⾏動ログAPIサーバのアーキテクチャ 次世代⾏動ログAPIサーバは全て Fastly Compute で稼働させる構成に移⾏ 20 Fastly Compute Rust SDK Message Queue 管理するサーバ台数は 400 から 0 に リージョンごとに構成管理も必要なし 旧⾏動ログ収集 API サーバ 新⾏動ログ収集 API サーバ 瞬時にグローバルスケールする
21. Copyright ⓒ 2023 Nikkei Inc. All rights reserved. Fastly Compute を選択した理由 ほぼ無限のスケーラビリティと developer フレンドリーなツール群の提供があり、 先ほどあげたすべての問題を解決しうるものであると判断したため 他の選択肢と⽐較したときの理由 21 理由1 Fastly は⻑年⽇経電⼦版他のサービスを⽀える CDN として利⽤してきた実績と 適切なテクニカルサポートが受けられる安⼼感がある 理由2 バックエンド転送を⾮同期で⾏い、バックエンドからリクエストを待たずにクライアントに対して レスポンスを返すことができる (Request::send_async) https://docs.rs/fastly/latest/fastly/struct.Request.html#method.send_async 理由3 リアルタイムログストリーミングによりデータ基盤で利⽤している BigQuery や PubSub と 容易に連携することができる
22. Copyright ⓒ 2023 Nikkei Inc. All rights reserved. Rust を SDK として選択した理由 決め⼿はパフォーマンス。 処理時間で課⾦される Fastly Compute で最もパフォーマンスの良い実装が実現できそうだったため 他の SDK の⾔語と⽐較して Rust を選択した理由 22 理由1 Fastly Compute で最初に GA になった SDK で利⽤実績が最も多い 理由2 ⼀般に High Performance な Rust を採⽤することで処理時間課⾦の Fastly Compute の コストを抑えられる 理由3 serde/json_serde という強⼒なシリアライズ/デシリアライズフレームワークを活⽤できる
23. Copyright ⓒ 2023 Nikkei Inc. All rights reserved. アーキテクチャ観点の改善 負荷テストでも良好なパフォーマンスとスケールアウト性能が得られ、期待通りの性能を維持している ⽇経社内負荷テスト基盤 (GKE + locust 環境) で計測 23 ケース 同時接続ユーザ数 Spawn Rate 最⼤ RPS レスポンスタイム (msec) (99%tile) エラー発⽣件数 1 100 10 6857.9 27 0 2 200 10 13532 28 0 3 500 10 28870.4 35 0 4 1000 10 39059.5 57 0 5 1000 1000 43667.6 50 0 6 2000 20 49706.8 54 0 ⽇経社内負荷テスト基盤 Cage について https://hack.nikkei.com/blog/advent20221206/ 急激なリクエスト数増加にも 耐えることができる
24. Copyright ⓒ 2023 Nikkei Inc. All rights reserved. Fastly Compute: TIPS1 バックエンドホストのオプション設定がデフォルトのままの場合バックエンド転送のエラーが 記録されてしまうケースがあるため、状況に応じて設定値を変更する必要がある 24 設定項⽬ 意味 デフォルト値 設定値 Maximum connection バックエンドの接続最⼤数 200 1,000 Connection timeout 接続タイムアウトまでどのくらい待機するか(msec) 1,000 msec 10,000 msec First byte timeout バックエンドサーバーが HTTP レスポンスボディの最初のバイト を返すまで待機する時間 (msec) 15,000 msec 150,000 msec Between bytes timeout バックエンドサーバがバイトを返してから 次のバイトを返すまでの待機期間(msec) 10,000 msec 100,000 msec 参考: https://docs.fastly.com/ja/guides/working-with-hosts タイムアウトによるデータの⽋損を防ぐため ⼤きめの値を設定 急激な負荷増加時に バックエンド転送エラーを防ぐ場合に⼤きめ の値を設定する
25. Copyright ⓒ 2023 Nikkei Inc. All rights reserved. Fastly Compute: TIPS2 リアルタイムログストリーミングによるログ転送にはレイテンシがあるため使い所を⾒極める必要がある ⾏動ログ収集APIサーバは、レコメンドやマーケティング施策の発⽕にも利⽤されるためできるだけ レイテンシを抑える必要があったため、リアルタイムログストリーミングによるログ連携を採⽤しなかった 25 ログ集約サーバ Compute Compute Compute Compute LOG LOG LOG LOG OR 転送トリガー条件 15 秒間経過 ログデータが 5MiB を超える Pub/Sub リアルタイムログストリーミング Google CloudPubSub 転送のアーキテクチャ (*1) トリガー条件については Fastly サポートからの回答により判明 (*2) トリガー条件をサポート経由で例えば 5 秒程度に短くする依頼を⾏うことはできる（要相談) LOG LOG LOG LOG
26. Copyright ⓒ 2023 Nikkei Inc. All rights reserved. 運⽤観点の改善 fastly cli を活⽤してリリース⼯数を劇的に削減し、メンテナンス性を向上させた 26 従来 現在稼働していない⾯ (Blue or Green) に新バージョンをデプロイ Step 1 現在稼働していない⾯ (Blue or Green) のインスタンス台数を増やす Step 2 DNS 荷重を新バージョンの⾯に 10, 50, 100%流すように順に切り替える Step 3 切り替え前の⾯のインスタンス台数を 減らす Step 4 Fastly Compute 移⾏後 簡易版⼿順（これを⼿動で実⾏) fastly cli Github Actions リリースブランチにpushされたら Github Actions で fastly cli によって⾃動的に新バージョンをデプロイ 約 4 - 5 時間 作業時間 約 2 - 3 分
27. Copyright ⓒ 2023 Nikkei Inc. All rights reserved. Fastly Compute: TIPS3 リアルタイムログストリーミングを活⽤してログのバックアップを⾏う ⾏動ログ収集APIサーバに不備があった場合に処理を再送できるようにリクエストのバックアップと処理後の⾏動ログの バックアップをリアルタイムログストリーミングで取得 27 新⾏動ログ収集 API サーバ 検 証 変 換 補 正 統 合 リ ク エ ス ト 出 ⼒ { “action”: “view”, “category”: “page”, ... } JSON 連 携 処理結果出⼒ Cloud Storage リアルタイムログストリーミング LOG BigQuery Cloud Storage リクエスト 外部表 処理後の⾏動ログ 外部表 LOG
28. Copyright ⓒ 2023 Nikkei Inc. All rights reserved. 機能観点の改善 serde/json_serde を活⽤してデータの補正を⾏うことで不整合なデータが連携されることを防ぐ これ⾃体は Fastly とは無関係の話だが、Fastly Compute が Rust SDK を提供してくれたおかげで Rust を採⽤でき、 Rust を採⽤できたことによりこうした強⼒なデータ補正が容易に実装できるようになった 28 期待する値 不正な場合 オブジェクト ⽂字列 { "why": "object" } "{ ¥"why¥": ¥"object¥" }" 期待する値 不正な値 正の浮動⼩数点値 負の浮動⼩数点値 2.533333 -200,000,000.0 カスタム デシリアライザ カスタム デシリアライザ 補正 補正した値 オブジェクト { "why": "object" } 補正した値 - null 新⾏動ログ収集 API サーバ
29. Copyright ⓒ 2023 Nikkei Inc. All rights reserved. まとめ 29
30. Copyright ⓒ 2023 Nikkei Inc. All rights reserved. まとめ ⾏動ログ収集 API サーバを Fastly Compute に移⾏したら既存の問題を解決し、 スケーラビリティとメンテナンス性を⾼めることができた 30 1. アーキテクチャ観点 2. 運⽤観点 3. 機能観点 突発的かつ急激な負荷増加に耐えられない アーキテクチャ 瞬時にグローバルスケールする Fastly Compute によって突発的かつ急激な 負荷増加にも耐えデータ⽋損を抑える 各リージョンごとに配置される数百台のサーバ管 理と複雑なリリース作業 サーバレス + fastly cli による リリース⼯数の劇的な削減 不整合なデータを許容することによる データの品質の低下 Rust の強⼒なシリアライズライブラリを 活⽤した⾼度なデータ補正の実現による データの品質の向上