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

⼩南英司
Eiji KOMINAMI
JAWS KOBE ＆ OSAKA
今どんくらい⼈来てるん︖がすぐに分かる︕
CloudFrontのリアルタイムログを
Kibanaで可視化しよう

2
⾃⼰紹介
⼩南英司（こみなみえいじ）
サーバサイドの構築からアプリの実装まで
プリキュア応援アプリの開発/実装
⾼校野球速報アプリの開発/実装
M-1グランプリ視聴者投票システムの構築
...など
@eijikominami

3
本⽇ご紹介するアーキテクチャ
Amazon CloudFront Amazon Kinesis
Data Streams
Amazon Kinesis
Data Firehose
Amazon Elasticsearch
Service
AWS Lambda
Amazon Simple
Storage Service (S3)
リアルタイム
ログ
Kibanaで
可視化

4
本⽇ご紹介するアーキテクチャ
Amazon CloudFront Amazon Elasticsearch
Service
Amazon Kinesis
Data Streams
Amazon Kinesis
Data Firehose
AWS Lambda
Amazon Simple
リアルタイム
ログ
Kibanaで
可視化
数⼗秒の遅延で到達
リアルタイムにモニタリング可能

5
CloudFrontのリアルタイムダッシュボード

6
キャパシティの計算⽅法など詳細⼿順は...
https://bit.ly/39hLVsz

7
テンプレートからワンクリックデプロイ
ボタンクリックのみでデプロイ完了
https://bit.ly/3okzYqp
GitHub
eijikominami/aws-cloudformation-templates

8
Agenda
本⽇のテーマ
CloudFrontのモニタリング
構築に関するTips
Kibanaのグラフの例

CloudFrontのモニタリング
9

10
モニタリング
システムの信頼性と可⽤性, パフォーマンスを追求する⼿段
アプリケーションは正常に動作しているのか
• 「何が壊れたのか」「なぜ壊れたのか」
Well-Architectedフレームワークにも⼿法やその重要性への⾔及あり
• ログとメトリクスは、ワークロードの状態についての洞察を得るための強⼒なツール
• パフォーマンスをモニタリングして、顧客に影響を及ぼす前に修正できるようにする
CloudFrontにおけるモニタリング
（上記に加えて）アクセス数やユーザの動向の予測および分析
• CloudFrontの上限緩和申請を⾏う際には、1秒あたりのリクエスト数/転送レートが必要
– あまりに桁外れな申請値の場合、申請値の妥当性や過去の実績値を問われる
• イベントとアクセス数の相関関係の分析
– ⼤きなアクセス数のWebサイトの場合、Google Analyticsは役に⽴たない
– 何がトリガになって、いつどのくらいユーザが流⼊してきたのかを知りたい

11
従来のCloudFrontに関するモニタリング
Amazon CloudFront
Management
Console
CloudWatch
Metrics
S3 Athena QuickSight
レポーティング
CloudFrontコンソールレポート
キャッシュ統計, ⼈気オブジェクト, トップリファラ,使⽤状況, ビューア
最⼩で1時間単位の粒度
リアルタイムモニター
リクエスト, ダウンロードバイト数, アップロードバイト数
4xxエラー率, 5xxエラー率, 合計エラー率
キャッシュヒット率※, レイテンシー※, ステータスコード別エラー率※
※は追加メトリクス
最⼩で1分単位の粒度
標準ログ
1時間に数回配信
リアルタイムに分析できない
アクセス数が多い場合に
表⽰が不正確な場合あり︕︖
必要とする数値をリアルタイムに測定できない

12
Elasticsearch/Kibanaの利⽤
Amazon CloudFront Amazon Elasticsearch
Service
Amazon Kinesis
Data Streams
Amazon Kinesis
Data Firehose
AWS Lambda
Amazon Simple
リアルタイム
ログ
Kibanaで
可視化
数⼗秒の遅延で到達
リアルタイムにモニタリング可能
取得するログのサンプリング数を指定
取得するログのフィールドを指定
どのBehaviorに適⽤するか

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
様々なデータを取得可能②
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
様々なデータを取得可能③
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 ヘッダーの数

17
公式Blogにも構築⼿順の詳細あります
https://amzn.to/2Mn61IX

18
でもハマりポイントが各所に…
Data Streams
Amazon Kinesis
Data Firehose
Service
AWS Lambda
Amazon Simple
ProvisionedThroughputExceededException 発⽣時も正常に動作する︖
全てのエッジロケーションのログを収集できる︖
シャード数はどうやって計算したらよい︖
どのメトリクスを監視すれば正常性を確認できる︖
<Elasticsearch Domain>
ストレージ（EBS）の⼤きさは︖
インスタンスタイプはどれを選んだらよい︖
運⽤中に設定変更してもOK︖
どのメトリクスを監視すればよい︖
Lambdaは何をしてる︖
メモリサイズはどのくらい必要︖
Firehoseで思った以上に遅延する
S3には何を配信している︖
どのメトリクスを監視すれば正常性を確認できる︖
<Kibana>
UnixtimeをDate型で認識させたい
どんなグラフが描画できる︖

シャード数の⾒積もりと指定
シャード数は 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
Data Streams
Amazon Kinesis
Data Firehose
Service
ネームスペースメトリクス内容
AWS/Kinesis GetRecords.IteratorAgeMilliseconds 現在時刻と最後のレコードがストリームに書き込まれた時刻との差（遅延量）
AWS/Kinesis PutRecord.Success PutRecord オペレーションの成功数（流⼊量）
AWS/Kinesis WriteProvisionedThroughputExceeded スロットリングによって拒否されたレコードの数（エラー）

シャード数の変更
ProvisionedThroughputExceededException 発⽣時の挙動
• 拒否されたログは以後の処理に進めずに⽋落する
• エラーが発⽣してもCloudFront⾃体の挙動には影響を与えない
クオータ制限に注意
• 東京リージョンのシャード数上限値は、200シャード（= 毎秒20万リクエスト）
• シャード数を変更する UpdteShardCount の1⽇あたりのコール数にも上限あり
20
Kinesis Data Streams
Data Streams
Amazon Kinesis
Data Firehose
Service
制限を超える利⽤を希望する場合は上限緩和を申請する
シャード数を増やして対応

Kinesis Data Firehoseが⾏う処理
1. Kinesis Data Streams からデータを取得する
2. Lambda でレコードを Base64 デコード/整形
3. Elasticsearch への配信が失敗した場合は S3 にレコードを配信
設定のポイント
許容できる遅延量に合わせてバッファ量を調整する
ログを有効化することで、配信失敗時の原因の追求が可能に
21
Kinesis Data Firehose
Data Streams
Amazon Kinesis
Data Firehose
Service

Elasticsearch Service への配信失敗の原因例
Elasticsearch ドメインのスペック不⾜
Elasticsearch ドメインの権限不⾜による書き込み処理の拒否
22
Kinesis Data Firehose
Data Streams
Amazon Kinesis
Data Firehose
Service
AWS/Firehose DeliveryToElasticsearch.DataFreshness Kinesis Data Firehose の最も古いレコードの経過時間（遅延量）
AWS/Firehose ThrottledGetShardIterator GetShardIterator オペレーションが調整された回数
AWS/Firehose ThrottledGetRecords GetRecords オペレーションが調整された回数
AWS/Firehose DeliveryToElasticsearch.Success Elasticsearchで正常にインデックスが作成されたレコードの数
CloudWatch Logs のログを⽤いて原因の調査を⾏う

ストレージサイズの決定
ソースデータ 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
Data Streams
Amazon Kinesis
Data Firehose
Service

新規作成/設定変更には⼤きな負荷が掛かる
これらの処理に10分〜数時間掛かることに注意
運⽤への影響を避けるために...
• アクセス数が多い時間帯の設定変更は避ける
• これらの処理のオーバヘッドを考慮したインスタンスタイプを選択
24
Elasticsearch Service
Data Streams
Amazon Kinesis
Data Firehose
Service
AWS/ES MasterCPUUtilization / CPUUtilization マスター/データノードのCPU使⽤率
AWS/ES MasterJVMMemoryPressure / JVMMemoryPressure / SysMemoryUtilization マスター/データノードのヒープ/メモリ使⽤率
AWS/ES ClusterStatus.green / MasterReachableFromNode / KibanaHealthyNodes クラスタ/ノード/Kibanaの正常性
AWS/ES FreeStorageSpace ストレージの空き容量

26
1秒あたりのリクエスト数
レコード数の積算

27
1秒あたりのバイト数
sc-bytes（サーバーがリクエストに応じてビューワーに送信したデータのバイトの合計数）

28
レスポンスタイムの推移
time-taken（サーバーがリクエストを受信してから最後のバイトを書き込むまでの秒数）

29
国別のリクエスト数
c-country.keyword（ビューワーの地理的位置を表す国コード）

30
ダッシュボードを作成可能

31
まとめ
Elasticsearch/Kibana を⽤いたCloudFrontモニタリング
リアルタイムにモニタリングすることが可能な現時点で唯⼀の⼿段
様々なデータを⽤いて多⾓的に分析することが可能
• システムの信頼性と可⽤性, パフォーマンス
• アクセス数、ユーザの動向
システムを構築する上での注意ポイントあり
負荷の予測とそれに対応できるリソースの事前準備が必要
予測を上回る負荷が発⽣した場合にはリソースの⼿動追加が必要
CloudWatch のメトリクスで各サービスをちゃんと監視しよう

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

More Related Content

What's hot

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

More from Eiji KOMINAMI

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