Akamai DataStream 2とは

Akamai DataStream 2とは、Akamaiのエッジプラットフォームのアクセスログを指定した宛先へ準リアルタイムにストリーミングする無償の機能です。2023年11月現在、以下の宛先にアクセスログを配信できます。

Amazon S3
Azure Storage
Custom HTTPS endpoint
Datadog
Elasticsearch
Google Cloud Storage
Loggly
New Relic
Oracle Cloud
S3-compatible destinations (Linode Object Storage対応可)
Splunk
Sumo Logic

参考: DataStream 2 - Stream logs to a destination

Elasticsearch / Kibanaとは

ElasticsearchとはElastic社の開発する全文検索エンジンです。ソースコードが公開されており、Server Side Public LicenseとElastic Licenseというデュアルライセンスで提供されています。KibanaはElasticsearch用のデータ可視化ソフトウェアで、Elasticsearchと同等の条件で提供されています。この2つのソフトウェアにLogstashと呼ばれるデータ収集パイプラインソフトウェアを組み合わせたものはELK Stackと呼ばれ、元々の用途である全文検索エンジンから発展して現在ではログ分析、データ可視化基盤としても人気があります。

この記事の目的

この記事では、Akamai DataStream 2のデータをLinode上にセットアップしたElasticsearchへ準リアルタイムに配信し、Kibanaによってこれを可視化します。この記事の手順によって最終的には以下のようなダッシュボードが完成し、DataStream 2に含まれる45個のフィールドのうち、代表的なものがグラフ化されます。

また、この記事では環境構築先としてAkamaiが2022年2月に買収したIaaS (Infrastructure as a Service)プロバイダーであるLinodeを使用します。LinodeにはStackScriptsという独自のデプロイメント自動化機能があり、アクセスログを受信するElasticsearch+Kibanaの準備を10分程度で完了させることができます (DataStream 2の初回設定時、ログの配信が開始されるまでに別途約1時間半程度の待ち時間が発生します)。

参考: Linode StackScriptsとは何か

なお、この記事ではElasticsearchとKibanaの環境を一から構築する方法を説明していますが、すでにこれらの環境を運用していて、Akamai DataStream 2用のElasticsearchのIndex Mapping、KibanaのData View、Visualization、Dashboardの定義ファイルだけが必要な方向けに、これらをGitHubでも公開しているのでダウンロードしてお使いください。

ElasticsearchとKibanaの定義ファイル

LinodeにElasticsearchとKibanaをインストールする

まずは以下のリンクから事前に準備しておいたStackScriptを開きます。このStackScriptがElasticsearch、Kibanaを自動的にインストールします。(リンク先にアクセスするにはLinodeのアカウントにログインしておく必要があります)

elasticsearch-kibana-for-akamai-datastream2
https://cloud.linode.com/stackscripts/1059555

※もし何らかの理由でこのStackScriptを開くことができなければ、このStackScriptの中身をGitHubにもアップロードしているのでご使用ください。

「Deploy New Linode」をクリックします

StackScriptにはUDF(ユーザー定義フィールド)という、デプロイメントにあたって必要なパラメータを自動的にWebの入力フォームにする機能があります。このStackScriptでは、仮想マシンにSSHログインできる非rootのユーザーのログイン情報や、ElasticsearchやKibanaの管理ユーザーのパスワード、DataStream 2がログをElasticsearchにフィードするための認証情報を仮想マシンのデプロイメント時に指定できるようになっています。以下のテキストボックスに必要事項を入力しておきます。ここで入力した値は後ほど使用するので内容を控えておきます。

仮想マシンを作成するリージョンと、仮想マシンの種類を選択します。ここでは日本の東京リージョンでDedicated 8 GBのLinodeを選択しています。

仮想マシンの名前、rootパスワードを指定して「Create Linode」をクリックします

仮想マシンの管理ダッシュボードに画面が遷移するので、仮想マシンの状態がPROVISIONINGからRUNNINGになるまで数分待ちます。同じ画面に今作成した仮想マシンのIPアドレスが表示されているので控えておきます。

また、後のDataStream 2の設定手順で必要になるので仮想マシンのNetworkタブから仮想マシンのReverse DNSの値を調べて控えておきます。

これで仮想マシンが起動しました。起動した後はStackScriptに沿って必要なソフトウェアのインストールがバックグラウンドで自動的に進みます。インストールが終わるまで10分ほど待ってから次の「Kibanaにログインする」に進みます。

Kibanaにログインする

それではKibanaにログインできることを確認します。Webブラウザーからhttp://[仮想マシンのIPアドレス]:5601/にアクセスします。ログインユーザーはelastic、パスワードは仮想マシンのデプロイメント時に指定したものを入力します。

左上のハンバーガーボタンでメニューを表示し、Analytics → Dashboardをクリックします。

StackScriptによって「Akamai」という名前のダッシュボードが自動作成されているので、それを開きます。

上記のようにダッシュボードが表示されれば成功です。この時点ではまだDataStream 2のセットアップをしていないため何もデータがありませんが正常です。

DataStream 2をセットアップする

Akamaiの管理コンソールAkamai Control CenterからDataStream 2のセットアップをしていきます。左上のハンバーガーボタンでメニューを表示し、COMMON SERVICES → DataStreamをクリックし、以下の流れでCreate streamします。

DataStream 2に名前をつけて、ログの配信を有効化したい配信プロパティにチェックを入れます。

送信するアクセスログのフィールドを選択する画面が表示されるので、ここでは例として全てのカテゴリで「Include all」にチェックを入れます。2022年9月時点で合計45個のフィールドが選択されます。また設定画面の最下部でログのフォーマットとして「JSON」を選択します。

個人情報保護法等の関連法令を考慮して収集するログの内容を選択してください

次にDataStream 2の宛先を設定します。DestinationはElasticsearch、Display nameには任意の名前、Endpointには仮想マシン作成時に控えておいたReverse DNSのホスト名を用いて http://[Reverse DNSのホスト名]:9200/_bulk、Index nameにdatastream2、UsernameとPasswordには仮想マシンのデプロイ時に入力した「Akamai DataStream 2がElasticsearchにログをフィードする際に使用するユーザー」のユーザー名とパスワードを入力します。Send compressed dataにもチェックを入れ、右下の「Validate & Save」ボタンをクリックしてください。全ての設定値が正しいと右下に「Destination details are valid」という文字列が表示され画面が切り替わります。

最後に設定のサマリーが表示されるので期待通りの設定になっているか確認します。「Activate stream upon saving」にチェックを入れておきます。また、DataStream 2によるログの配信開始まで約1時間半かかります。ログの配信開始通知をメールで受け取りたい場合は「Receive an email once activation is complete.」にチェックを入れてメールアドレスを入力します。全て問題なければ右下の「Save stream」をクリックします。DataStream 2の有効化処理がはじまると、プロパティマネージャー側でもDataStream 2の設定が必要であることを示すメッセージが表示されるので、今設定したDataStream 2の名前を控えた上で「Proceed to Property Manager」をクリックします。

プロパティでDataStream 2を有効化する

※この節の解説は、Akamaiプロパティマネージャーの基本的な操作方法を理解しているという前提で書かれています。

DataStream 2によるログの配信は、プロパティ側でもDataStream 2のBehavior(動作)を追加し、プロパティをActivation(有効化)する必要があります。上述の手順でDataStream 2のセットアップが完了したら、プロパティの新しいバージョンを作成して、デフォルトルールに「DataStream」「Log Request Details」の Behaviorを追加し、以下の設定例を参考に設定をします。この作業はDataStream 2が有効化されるまでの待ち時間に並行して実施できます。

Stream version	DataStream 2
Stream names	DataSteam 2のセットアップ時に指定した名前
Sampling rate	ログを送信する割合 (100で全てのログを送信)
Log *** Header	リクエストに含まれる当該ヘッダーを収集するかどうか
Cookie Mode	リクエストに含まれるCookieを収集するかどうか
Include Custom Log Field	カスタムのログフィールドを追加するかどうか
Custom Log Field	カスタムのログフィールドに入れる値 (ここでは例として通信に使用しているTLSのCipher Suiteの名前を含めていますが、空欄でも構いません)
Log Akamai Edge Server IP Address	リクエストを処理したエッジサーバーのIPアドレスを収集するかどうか (これは必ずOnにしてください)

個人情報保護法等の関連法令を考慮して収集するログの内容を選択してください

設定が終わったらプロパティを保存してActivationします。DataStream 2とプロパティの両方が有効化されると、アクセスログがKibanaに表示されはじめます。

お疲れさまでした! これでAkamaiのアクセスログを準リアルタイムに見られるようになりました

今回使用したStackScriptはアクセスログに含まれる代表的な値を可視化するダッシュボードを作成しますが、DataStream 2がフィードするアクセスログには他にもさまざまなフィールドが含まれています。これをベースにKibanaのGUI上でダッシュボードをカスタマイズするのも良いでしょう。

発展的な使い方

条件付きのアクセスログ送信

全てのアクセスログをDataStream 2でログの分析基盤にフィードし、ログの分析基盤側で必要性に応じた条件で絞り込んでいくことが一般的な使い方ですが、一定の条件を満たしたログのみをDataStream 2でフィードするということも可能です。これはログの量が膨大でログの分析基盤側の負荷を軽減したい場合や、正常系の通信のログにあまり興味がなく異常系のログのみを見たいという場合に有用です。実装例として、たとえばAkamaiのプロパティのデフォルトルールからDataStream 2のBehaviorを削除し、以下のような条件でDataStream 2を有効化するように実装すると、リクエスト先が/foo/bar/配下でレスポンスコードが200 206 304 以外のときのみログをDataStream 2で飛ばすということができます。

カスタムフィールドの活用

DataStream 2がフィードするアクセスログには、カスタムフィールドと呼ばれるフィールドが存在します。ここには1000バイトまで任意の文字列を追加できるので、エッジサーバーが持つビルトイン変数やプロパティのユーザー変数を含めることができます。

参考: プロパティマネージャーのビルトイン変数一覧

たとえば以下の例ではカスタムフィールドに「エッジからクライアントにレスポンスを全て返すまでにかかった転送時間」を含めています。

この値をKibanaのData ViewでRuntime fieldとしてパースすることで、新しいフィールドにすることができます。

String ctt=dissect('ctt:%{ctt_val}').extract(doc["customField"].value)?.ctt_val;
if (ctt != null) emit(Integer.parseInt(ctt));

また、Akamaiのエッジ上で動作するエッジ・コンピューティング・プラットフォームであるEdgeWorkersを使うと、JavaScript ベースのコードで、任意のユーザー変数をセットできます。それをカスタムフィールドに含めることで、EdgeWorkersアプリケーションのデバッグ情報やビジネスロジック上興味のある値などをログの分析基盤で集計することができるようになります。2023年6月現在、カスタムフィールドの長さは1000バイトまでという制約があることに注意してください。

参考: Request Object setVariable()

EdgeWorkersのデバッグ

EdgeWorkersでは各種の制約(CPU時間、メモリ使用量、実行時間など)を超えると動作が途中で打ち切られます。これを踏まえて実際に運用してみると、リクエストの内容に依存した特定条件下でのみ正しく動作しないという状況に遭遇することがあります。エラーの統計情報はAkamaiのポータルサイトであるAkamai Control Centerから確認できますが、エラー発生時のリクエスト情報の詳細は見られません。DataStream 2を使えば、エラーが発生した際のリクエスト情報のみならず、EdgeWorkersランタイムの詳しい動作状況がewExecutionInfoとewUsageInfoというフィールドに載るため、トラブルシューティングに役立ちます。

参考: DataStream 2 log details

Web Application Firewallの検知状況の監視

AkamaiのWeb Application Firewall (WAF)には、Web Security Analytics (WSA)と呼ばれる高度なログ分析機能がついているため、サイバー攻撃の分析はほとんどの場合WSAだけで完結します。その一方で、DataStream 2にもWAFの検知状況の概要がログのフィールドに含まれているので、DataStream 2でしか見られないフィールドを活用して補完的な分析をしたり、ログのフィード先である分析ツールに含まれる機械学習などの高度な機能を活用することができたりします。以下の画面は、ディレクトリ・トラバーサル攻撃をWAFが検知し、その情報がDataStream 2のデータから確認できる様子です。

Common Media Client Data (CMCD)の可視化

Common Media Client Data (CMCD)は、動画プレーヤーが収集した様々なメトリクスをCDNのエッジサーバーやオリジンサーバーに送信するための標準化されたデータフォーマットです。CTA WAVEプロジェクトは2020年9月にCMCDの仕様を公開しました。

Web Application Video Ecosystem - Common Media Client Data (英語)

CMCDをサポートする動画プレーヤーは、HTTPのリクエストヘッダーやクエリパラメーターを通じて様々な情報をサーバーに送信します。Akamai Adaptive Media Delivery (AMD)を使っている場合、DataStream 2のログにCMCDのフィールドを追加することができ、この記事で構築したElasticsearch + Kibanaで動画の再生品質や各種情報を可視化することができます。これにより、既存の動画QoS/QoE測定ツールから得られる情報に加えて、Akamaiのログと品質メトリクスを相関させることが可能になります。CMCDの使用の利点についての詳しい情報は、以下の記事も参照してください。

Get More from Your Player Analytics and CDN Logs with CMCD (英語)

多くの動画プレーヤーはCMCDをクエリパラメーターとしてサーバーに送信する実装になっていますが、リクエストヘッダー経由でCMCDデータを送信したい場合は、AMDでCORSヘッダー設定を追加する必要があります。CORSヘッダーを変更するには以下のガイドを参照してください。

Common Media Client Data (英語)

※2023年4月19日に、この記事で参照されているStackScriptを更新しました。この日付以降にStackScriptを使用してElasticsearch + Kibanaをインストールすると、CMCDをサポートするインデックステンプレート、データビュー、ダッシュボードも作成されます。

実運用に向けての考慮点

この記事では説明をシンプルにするために実運用においては配慮すべき点をいくつかカバーできていません。実運用に際してはたとえば以下の点を考慮する必要があります。

DataStream 2のログ転送エラーアラートの有効化
ElasticsearchのAPIエンドポイントのHTTPS化
Elasticsearchノードの冗長化
Linode Block Storageを使った仮想マシンの追加ストレージの確保
アクセスログのライフサイクル管理

この記事ではSSL証明書の取得手順を省略するためにElasticsearchのHTTPSを無効化しています。実運用に向けては正式なSSL証明書を取得してDataStream 2からElasticsearchへの通信をHTTPS化することを推奨します。DataStream 2は自己署名証明書を受け入れないので、Elasticsearchに正規の認証局が発行したSSL証明書をデプロイする必要があります。「Elasticsearch Let's Encrypt」などのキーワードでインターネットを検索すると関連情報が見つかります。

また、HTTPSを無効化するためにStackScriptがElasticsearchの設定ファイルを書き換えているので、再びHTTPS対応にするためにはSSL証明書のデプロイと併せて/etc/elasticsearch/elasticsearch.ymlにあるxpack.security.http.sslのenabledフラグをtrueにする必要があります。その後DataStream 2の設定を変えて、アクセスログをフィードする宛先のエンドポイントをhttp://からhttps://にします。

補足情報

関連記事

アカマイ・テクノロジーズ合同会社のQiitaではLinode関連など開発者向けの記事を記載しております。