はじめに

こんにちは、データ分析部の森本です。主な業務は記事配信アルゴリズムの改善とログ基盤の整備です。
Gunosyでは、ユーザーへより良い記事を提供するためにアクセスログをストリーム処理し、集計結果を記事配信アルゴリズムに活用しています。ストリームログ基盤にはSpark Streamingを利用していますが、現在Kinesis Analyticsへ移行中です。
この記事ではKinesis Analyticsへ移行する理由や運用上のTips等についてお話します。

Spark Streamingを利用したストリームログ基盤構成

f:id:moyomot:20170213185600p:plain

現在のストリームログ基盤はSpark Streamingで集計を行い、結果をRDSに保存しています。

なぜSpark StreamingからKinesis Analyticsへ移行するのか

サーバーコストと運用コストの削減を目的としています。

サーバーコストについて

Spark StreamingはEMR上で使用していますが、コストはそこそこします。例えばサーバー(m4.xlarge)10台と考えると1ヶ月およそ約30万円になります。
($0.348 + $0.060) * ¥110 * 24hour * 30day * 10台
スポット価格で運用しサーバーコストを抑えてますが、スポット価格の変動に注意する必要があります。これを複数クラスタ運用していたので、それなりのサーバーコストを要しました。またクラスタの構築コスト、運用コストを考慮するとEMRが最適なため、自前でクラスタ環境の構築は行いませんでした。

運用コストについて

長期間運用していると、ノードがしばしば落ちます。
一時的に少数のノードが落ちてもクラスタ運用に問題ありませんが、長期的にはクラスタ状況をモニタリングし、問題が発生する前にノードの追加やクラスタの再構築が必要です。主観的に休日にクラスタ整備を行うことが多く、辛いです。（本当に土日よく落ちるのかノードダウンの統計情報を可視化してみたい）

Spark Streamingはこのアクセスログ集計でオーバースペックなところもありました。
そこで、新たな基盤となるKinesis Analyticsを利用したストリームログ基盤を紹介します。

Kinesis Analyticsを利用したストリームログ基盤構成

f:id:moyomot:20170213185624p:plain ログ集計はKinesis Analyticsが担当し、Kinesis FirefoseがElasticsearchに結果を保存しています。

Kinesis Analyticsとは
ストリーミングデータをSQLクエリで集計できるサービスです。
標準SQLを使用でき、容易に実装できました。
集計はKinesis AnalyticsのSQLのみで完結するため、Sparkアプリケーションを実装するよりも開発コストを抑えることができました。今回Kinesis AnalyticsのインプットにはKinesis Stream、アウトプットにはKinesis Firefoseを使用しています。

詳細はこちらの記事が詳しいです。

data.gunosy.io

運用してみて

現在Kinesis Analyticsを利用したログ基盤は運用テスト中で、大きな問題もなく順調に稼働しています。ここでは運用上のTipsについて紹介します。

マスターデータとJOINできる

Kinesis Analyticsは、SQLクエリ上で静的ファイル（リファレンスデータ）とJOINできます。
マスターデータ的なファイルをS3に保存しておき、必要なAPIを呼ぶことでKinesis Analytics上でJOINできます。これは非常に便利な機能で重宝しています。
アクセスログ集計アプリケーションではマスターデータの更新を1日に1度Data Pipelineで行い、S3に再アップロードしています。リファレンスデータの更新はLambdaで行っています。

AddApplicationReferenceDataSource - Amazon Kinesis Analytics

監視はDatadogとAWS Lambdaで実施

Gunosyの監視はCloudWatch、Datadog、Papertrail、PagerDutyなどの各種サービスを必要に応じて利用しています。ログストリーム基盤の監視では最終的なアウトプット先であるElasticsearch Serviceに重きをおいて監視することにしました。 Elasticsearchの各種メトリックをDatadogでモニタリングし、アラート先をSlackに設定しています。また直近N分間に登録されているドキュメント数もモニタリングしたいため、ドキュメント数をカウントし、Cloudwatchに登録するオリジナルスクリプトをLambdaで実装しています。（なんでも雑にLambdaで監視し、Slackに通知したくなってしまいます）

Kinesis Analyticsの対応しているリージョンが限定的

2017年2月現在、Kinesis Analyticsの対応しているリージョンは、アイルランド、オレゴン、バージニアのみとなっています。調査したところ東京からレイテンシが最も小さいリージョンはオレゴンであったため、現在はオレゴンにKinesis Analytics環境を構築しています。この場合、東京リージョンのログストリーム環境と比べて、オレゴンまでの転送分、遅延が多少発生します。（数秒レベル）今回の用途では、そこまで遅延に対してシビアではないため利用に踏み切りましたが、利用用途に応じて検証する必要があります。

その他の所感

ElasticsearchのクエリはSQLと比較すると難しいが、中央値算出などいろいろな関数がサポートされているのが良い（なんでMySQLでは中央値を簡単に算出できないの…）
Kinesis streamのシャード数見積もり結構難しい、多めに見積もったほうが無難
Kinesis streamのシャード数分割も画面でできるようになって欲しい