Movatterモバイル変換

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

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

3本⽇ご紹介するアーキテクチャAmazon CloudFront Amazon KinesisData StreamsAmazon KinesisData FirehoseAmazon ElasticsearchServiceAWS LambdaAmazon SimpleStorage Service (S3)リアルタイムログKibanaで可視化

4本⽇ご紹介するアーキテクチャAmazon CloudFront Amazon ElasticsearchServiceAmazon KinesisData StreamsAmazon KinesisData FirehoseAWS LambdaAmazon SimpleStorage Service (S3)リアルタイムログKibanaで可視化数⼗秒の遅延で到達リアルタイムにモニタリング可能

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

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

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

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

CloudFrontのモニタリング9

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

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

12Elasticsearch/Kibanaの利⽤Amazon CloudFront Amazon ElasticsearchServiceAmazon KinesisData StreamsAmazon KinesisData FirehoseAWS LambdaAmazon SimpleStorage Service (S3)リアルタイムログ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でもハマりポイントが各所に…Amazon CloudFront Amazon KinesisData StreamsAmazon KinesisData FirehoseAmazon ElasticsearchServiceAWS LambdaAmazon SimpleStorage Service (S3)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 メトリクスを⽤いたモニタリング19Kinesis Data StreamsAmazon CloudFront Amazon KinesisData StreamsAmazon KinesisData FirehoseAmazon ElasticsearchServiceネームスペースメトリクス内容AWS/Kinesis GetRecords.IteratorAgeMilliseconds 現在時刻と最後のレコードがストリームに書き込まれた時刻との差（遅延量）AWS/Kinesis PutRecord.Success PutRecord オペレーションの成功数（流⼊量）AWS/Kinesis WriteProvisionedThroughputExceeded スロットリングによって拒否されたレコードの数（エラー）

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

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

CloudWatch メトリクスを⽤いたモニタリングElasticsearch Service への配信失敗の原因例Elasticsearch ドメインのスペック不⾜Elasticsearch ドメインの権限不⾜による書き込み処理の拒否22Kinesis Data FirehoseAmazon CloudFront Amazon KinesisData StreamsAmazon KinesisData FirehoseAmazon ElasticsearchServiceネームスペースメトリクス内容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.elasticsearch23Elasticsearch ServiceAmazon CloudFront Amazon KinesisData StreamsAmazon KinesisData FirehoseAmazon ElasticsearchService

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

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

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

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

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

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

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

Movatterモバイル変換

Change Language

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

Embed presentation

Recommended

More Related Content

What's hot

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

More from Eiji KOMINAMI

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