CloudFrontのリアルタイムログをKibanaで可視化しよう

2020年8月に利用可能となったCloudFrontのリアルタイムログ機能を使うと、Webにアクセスしているユーザ数やCloudFrontの状況を、リアルタイムにモニタリングすることが可能となります。このシステムを構築する際のポイントについてご紹介します。

Transcript

1. ⼩南 英司 Eiji KOMINAMI JAWS KOBE ＆ OSAKA 今どんくらい⼈来てるん︖がすぐに分かる︕ CloudFrontのリアルタイムログを Kibanaで可視化しよう
2. 2 ⾃⼰紹介 ⼩南 英司（こみなみ えいじ） サーバサイドの構築 から アプリの実装 まで プリキュア応援アプリの開発/実装 ⾼校野球速報アプリの開発/実装 M-1グランプリ視聴者投票システムの構築 ...など @eijikominami
3. 3 本⽇ご紹介するアーキテクチャ Amazon CloudFront Amazon Kinesis Data Streams Amazon Kinesis Data Firehose Amazon Elasticsearch Service AWS Lambda Amazon Simple Storage Service (S3) リアルタイム ログ Kibanaで 可視化
4. 4 本⽇ご紹介するアーキテクチャ Amazon CloudFront Amazon Elasticsearch Service Amazon Kinesis Data Streams Amazon Kinesis Data Firehose AWS Lambda Amazon Simple Storage Service (S3) リアルタイム ログ Kibanaで 可視化 数⼗秒の遅延で到達 リアルタイムにモニタリング可能
5. 5 CloudFrontのリアルタイムダッシュボード
6. 6 キャパシティの計算⽅法など詳細⼿順は... https://bit.ly/39hLVsz
7. 7 テンプレートからワンクリックデプロイ ボタンクリックのみでデプロイ完了 https://bit.ly/3okzYqp GitHub eijikominami/aws-cloudformation-templates
8. 8 Agenda 本⽇のテーマ CloudFrontのモニタリング 構築に関するTips Kibanaのグラフの例
9. CloudFrontのモニタリング 9
10. 10 モニタリング システムの信頼性と可⽤性, パフォーマンスを追求する⼿段 アプリケーションは正常に動作しているのか • 「何が壊れたのか」「なぜ壊れたのか」 Well-Architectedフレームワークにも⼿法やその重要性への⾔及あり • ログとメトリクスは、ワークロードの状態についての洞察を得るための強⼒なツール • パフォーマンスをモニタリングして、顧客に影響を及ぼす前に修正できるようにする CloudFrontにおけるモニタリング （上記に加えて）アクセス数やユーザの動向の予測および分析 • CloudFrontの上限緩和申請を⾏う際には、1秒あたりのリクエスト数/転送レートが必要 – あまりに桁外れな申請値の場合、申請値の妥当性や過去の実績値を問われる • イベントとアクセス数の相関関係の分析 – ⼤きなアクセス数のWebサイトの場合、Google Analyticsは役に⽴たない – 何がトリガになって、いつどのくらいユーザが流⼊してきたのかを知りたい
11. 11 従来のCloudFrontに関するモニタリング Amazon CloudFront Management Console CloudWatch Metrics S3 Athena QuickSight レポーティング CloudFrontコンソールレポート キャッシュ統計, ⼈気オブジェクト, トップリファラ,使⽤状況, ビューア 最⼩で1時間単位の粒度 リアルタイムモニター リクエスト, ダウンロードバイト数, アップロードバイト数 4xxエラー率, 5xxエラー率, 合計エラー率 キャッシュヒット率※, レイテンシー※, ステータスコード別エラー率※ ※は追加メトリクス 最⼩で1分単位の粒度 標準ログ 1時間に数回配信 リアルタイムに分析できない アクセス数が多い場合に 表⽰が不正確な場合あり︕︖ 必要とする数値をリアルタイムに測定できない
12. 12 Elasticsearch/Kibanaの利⽤ Amazon CloudFront Amazon Elasticsearch Service Amazon Kinesis Data Streams Amazon Kinesis Data Firehose AWS Lambda Amazon Simple Storage Service (S3) リアルタイム ログ Kibanaで 可視化 数⼗秒の遅延で到達 リアルタイムにモニタリング可能 取得するログのサンプリング数を指定 取得するログのフィールドを指定 どのBehaviorに適⽤するか
13. 13 様々なデータを取得可能① フィールド名 内容 timestamp エッジサーバーがリクエストへの応答を終了した⽇時 c-ip リクエスト元のビューワーの IP アドレス time-to-first-byte サーバー上で測定される、要求を受信してから応答の最初のバイトを書き込むまでの秒数 sc-status サーバーのレスポンスの HTTP ステータスコード sc-bytes サーバーがリクエストに応じてビューワーに送信したデータのバイトの合計数 cs-method ビューワーから受信した HTTP リクエストメソッド cs-protocol ビューワーリクエストのプロトコル cs-host CloudFront ディストリビューションのドメイン名 cs-uri-stem パスとオブジェクトを識別するリクエスト URL の部分 cs-bytes ビューワーがリクエストに含めたデータのバイトの合計数 x-edge-location リクエストを処理したエッジロケーション x-edge-request-id リクエストを⼀意に識別する不透明な⽂字列 x-host-header ビューワーが、このリクエストの Host ヘッダーに追加した値 time-taken サーバーが、ビューワーのリクエストを受信してからレスポンスの最後のバイトを出⼒キューに書き込むまでの秒数 cs-protocol-version ビューワーがリクエストで指定した HTTP バージョン
14. 14 様々なデータを取得可能② フィールド名 内容 c-ip-version リクエストの IP バージョン cs-user-agent リクエスト内の User-Agent ヘッダーの値 cs-referer リクエスト内の Referer ヘッダーの値 cs-cookie リクエスト内の Cookie ヘッダー cs-uri-query リクエスト URL のクエリ⽂字列の部分 x-edge-response-result-type ビューワーにレスポンスを返す直前にサーバーがレスポンスを分類した⽅法 x-forwarded-for リクエスト元のビューワーの IP アドレス ssl-protocol リクエストとレスポンスを送信するためにビューワーとサーバーがネゴシエートした SSL/TLS プロトコル ssl-cipher リクエストとレスポンスを暗号化するためにビューワーとサーバーがネゴシエートした SSL/TLS 暗号 x-edge-result-type サーバーが、最後のバイトを渡した後で、レスポンスを分類した⽅法 fle-encrypted-fields サーバーが暗号化してオリジンに転送したフィールドレベル暗号化フィールドの数 fle-status リクエストボディが正常に処理されたかどうかを⽰すコード sc-content-type レスポンスの HTTP Content-Type ヘッダーの値 sc-content-len レスポンスの HTTP Content-Length ヘッダーの値 sc-range-start 範囲の開始値
15. 15 様々なデータを取得可能③ フィールド名 内容 sc-range-end 範囲の終了値 c-port 閲覧者からのリクエストのポート番号 x-edge-detailed-result-type x-edge-result-type と同じ値 c-country ビューワーの IP アドレスによって決定される、ビューワーの地理的位置を表す国コード cs-accept-encoding ビューワーリクエスト内の Accept-Encoding ヘッダーの値 cs-accept ビューワーリクエスト内の Accept ヘッダーの値 cache-behavior-path-pattern ビューワーリクエストに⼀致したキャッシュ動作を識別するパスパターン cs-headers ビューワーリクエスト内の HTTP ヘッダー cs-header-names ビューワーリクエスト内の HTTP ヘッダーの名前 cs-headers-count ビューワーリクエスト内の HTTP ヘッダーの数
16. 構築に関するTips 16
17. 17 公式Blogにも構築⼿順の詳細あります https://amzn.to/2Mn61IX
18. 18 でもハマりポイントが各所に… Amazon CloudFront Amazon Kinesis Data Streams Amazon Kinesis Data Firehose Amazon Elasticsearch Service AWS Lambda Amazon Simple Storage Service (S3) ProvisionedThroughputExceededException 発⽣時も正常に動作する︖ 全てのエッジロケーションのログを収集できる︖ シャード数はどうやって計算したらよい︖ どのメトリクスを監視すれば正常性を確認できる︖ <Elasticsearch Domain> ストレージ（EBS）の⼤きさは︖ インスタンスタイプはどれを選んだらよい︖ 運⽤中に設定変更してもOK︖ どのメトリクスを監視すればよい︖ Lambdaは何をしてる︖ メモリサイズはどのくらい必要︖ Firehoseで思った以上に遅延する S3には何を配信している︖ どのメトリクスを監視すれば正常性を確認できる︖ <Kibana> UnixtimeをDate型で認識させたい どんなグラフが描画できる︖
19. シャード数の⾒積もりと指定 シャード数は 2のべき乗（1,2,4,8...）に。 • UpdteShardCount API は現在のシャード数の2倍もしくは1/2倍にのみ変更可能 「秒間リクエスト数 / 1,000 x バッファ係数」 で⾒積もり • バッファ係数は1.1〜1.25に。バーストトラフィックを想定する場合はそれ以上を指定。 • 最⼤5,000rpsを予想する場合は、7シャード（5,000 / 1,000 x 1.25）必要。 CloudWatch メトリクスを⽤いたモニタリング 19 Kinesis Data Streams Amazon CloudFront Amazon Kinesis Data Streams Amazon Kinesis Data Firehose Amazon Elasticsearch Service ネームスペース メトリクス 内容 AWS/Kinesis GetRecords.IteratorAgeMilliseconds 現在時刻と最後のレコードがストリームに書き込まれた時刻との差（遅延量） AWS/Kinesis PutRecord.Success PutRecord オペレーションの成功数（流⼊量） AWS/Kinesis WriteProvisionedThroughputExceeded スロットリングによって拒否されたレコードの数（エラー）
20. シャード数の変更 ProvisionedThroughputExceededException 発⽣時の挙動 • 拒否されたログは以後の処理に進めずに⽋落する • エラーが発⽣してもCloudFront⾃体の挙動には影響を与えない クオータ制限に注意 • 東京リージョンのシャード数上限値は、200シャード（= 毎秒20万リクエスト） • シャード数を変更する UpdteShardCount の1⽇あたりのコール数にも上限 あり 20 Kinesis Data Streams Amazon CloudFront Amazon Kinesis Data Streams Amazon Kinesis Data Firehose Amazon Elasticsearch Service 制限を超える利⽤を希望する場合は上限緩和を申請する シャード数を増やして対応
21. Kinesis Data Firehoseが⾏う処理 1. Kinesis Data Streams から データを取得 する 2. Lambda でレコード を Base64 デコード/整形 3. Elasticsearch への 配信が失敗した場合は S3 にレコードを配信 設定のポイント 許容できる遅延量に合わせてバッファ量を調整する ログを有効化することで、配信失敗時の原因の追求が可能に 21 Kinesis Data Firehose Amazon CloudFront Amazon Kinesis Data Streams Amazon Kinesis Data Firehose Amazon Elasticsearch Service
22. CloudWatch メトリクスを⽤いたモニタリング Elasticsearch Service への配信失敗の原因例 Elasticsearch ドメインのスペック不⾜ Elasticsearch ドメインの権限不⾜による書き込み処理の拒否 22 Kinesis Data Firehose Amazon CloudFront Amazon Kinesis Data Streams Amazon Kinesis Data Firehose Amazon Elasticsearch Service ネームスペース メトリクス 内容 AWS/Firehose DeliveryToElasticsearch.DataFreshness Kinesis Data Firehose の最も古いレコードの経過時間（遅延量） AWS/Firehose ThrottledGetShardIterator GetShardIterator オペレーションが調整された回数 AWS/Firehose ThrottledGetRecords GetRecords オペレーションが調整された回数 AWS/Firehose DeliveryToElasticsearch.Success Elasticsearchで正常にインデックスが作成されたレコードの数 CloudWatch Logs のログを⽤いて原因の調査を⾏う
23. ストレージサイズの決定 ソースデータ x (1+ レプリカの数) x 1.45 で⾒積もり可能 • 平均5,000rps のアクセスログを24時間保持する場合は... 5,000（件） x 3,600（秒）x 24（時間） x 1,000(byte) = 432（GB） 432（GB） x (1 + 1) x 1.45 = 1252 (GB） • データノードを3台作成する場合は... 1252（GB） / 3（台） = 417 GB（1インスタンスあたり） インスタンスタイプの決定 データノード : 100 GB ごとに vCPU x 2 コア/メモリ8GB • 上記条件で3マスターノード/3データノードの場合は... ヒープ領域枯渇のリスクを考慮して r5.2xlarge.elasticsearch（8vCPU/64GBメモリ） マスターノード : 10台までなら c5.large.elasticsearch 23 Elasticsearch Service Amazon CloudFront Amazon Kinesis Data Streams Amazon Kinesis Data Firehose Amazon Elasticsearch Service
24. 新規作成/設定変更には⼤きな負荷が掛かる これらの処理に10分〜数時間 掛かることに注意 運⽤への影響を避けるために... • アクセス数が多い時間帯の設定変更は避ける • これらの処理のオーバヘッドを考慮したインスタンスタイプを選択 CloudWatch メトリクスを⽤いたモニタリング 24 Elasticsearch Service Amazon CloudFront Amazon Kinesis Data Streams Amazon Kinesis Data Firehose Amazon Elasticsearch Service ネームスペース メトリクス 内容 AWS/ES MasterCPUUtilization / CPUUtilization マスター/データノードのCPU使⽤率 AWS/ES MasterJVMMemoryPressure / JVMMemoryPressure / SysMemoryUtilization マスター/データノードのヒープ/メモリ使⽤率 AWS/ES ClusterStatus.green / MasterReachableFromNode / KibanaHealthyNodes クラスタ/ノード/Kibanaの正常性 AWS/ES FreeStorageSpace ストレージの空き容量
25. Kibanaのグラフの例 25
26. 26 1秒あたりのリクエスト数 レコード数の積算
27. 27 1秒あたりのバイト数 sc-bytes（サーバーがリクエストに応じてビューワーに送信したデータのバイトの合計数）
28. 28 レスポンスタイムの推移 time-taken（サーバーがリクエストを受信してから最後のバイトを書き込むまでの秒数）
29. 29 国別のリクエスト数 c-country.keyword（ビューワーの地理的位置を表す国コード）
30. 30 ダッシュボードを作成可能
31. 31 まとめ Elasticsearch/Kibana を⽤いたCloudFrontモニタリング リアルタイムにモニタリングすることが可能な現時点で唯⼀の⼿段 様々なデータを⽤いて多⾓的に分析することが可能 • システムの信頼性と可⽤性, パフォーマンス • アクセス数、ユーザの動向 システムを構築する上での注意ポイントあり 負荷の予測とそれに対応できるリソースの事前準備が必要 予測を上回る負荷が発⽣した場合にはリソースの⼿動追加が必要 CloudWatch のメトリクスで各サービスをちゃんと監視しよう