はじめに
こんにちは、アプリケーションチームの川北・小沼です。
LANSCOPE エンドポイントマネージャー クラウド版（以下、クラウド版）では、PC 操作ログに関する機能を提供しています。PC 上の操作をログとして取得し、保存・分析をすることで、インシデント発生時の調査などにお使いいただける機能です。
PC 操作ログを扱うための「ログ基盤」は AWS 環境に構築しています。過去数回行ったリプレースで、ログ基盤の運用はしばらく安心できると踏んでいましたが、 リプレース直後、動的パーティショニングにクォータが設定されるという出来事がありました。
当時はハードリミットに対してまだまだ余裕のある状態でした。しかし、製品の成長に伴いハードリミット抵触までのカウントダウンが始まり、 さらなるリプレースに向けての戦いが始まりました。
本記事では、ログ基盤が抱えていた課題とその改善方法についてご紹介します。
なお、過去実施したリプレースについては AWS ブログの「大規模なデータを Amazon Kinesis Data Firehose の動的パーティショニングとAmazon Athena を利用して、ニアリアルタイムに処理する事例の紹介」でご覧いただけます。よければご参照ください。
ログ基盤の課題
課題のあるログ基盤の構成は以下の図の通りです。
課題1. 動的パーティショニングのクォータ
Amazon Kinesis Data Streams で受信したログは、Amazon Data Firehose 経由で S3 に配信していました。このとき、Amazon Data Firehose の動的パーティショニング を用いて、ログに含まれるテナント ID ごとに区切って保存していました。 これはテナント分離の観点からです。
課題は、動的パーティショニングに「配信ストリームごとに扱えるアクティブパーティション数」のクォータが設定されたことです。
テナントごとにパーティションを作る都合、将来的にクォータに抵触することが予測されました。したがって、Amazon Data Firehose の動的パーティショニングに頼ることなく、パーティション分割を実現する必要が出てきました。
なお、構成図上では赤枠で囲んだ部分が該当します。
課題2.アーキテクチャの複雑さ
ログ検索では「リアルタイム性」と「検索性能」の両方が求められます。つまり、受信したログはできるだけ早く参照できると同時に、検索時のレスポンス時間も短くする必要があります。
この要件を満たすために、旧ログ基盤は「ストリームレイヤー」と「バッチレイヤー」のそれぞれで操作ログを扱う複雑な構成（Lambda アーキテクチャ）となっていました。
具体的には、リアルタイム性を担保するためのストリームレイヤーでは、受信したデータは「直近ログ」としてそのままのデータ形式で S3 に配信していました。 下の図のように、受信した 1 データには複数のログが含まれます。したがって、直近ログを参照するときは都度「フラット化」する必要がありました。
フラット化には若干のオーバーヘッドがあるため、「過去ログ」と S3 バケットを分け、検索期間を短くすることで直近ログの性能を担保していました。
一方で過去ログについては、バッチレイヤーで生成をしていました。夜間のバッチ処理で受信データをフラット化して S3 に保存するような機構となっています。直近ログよりデータ量は多いものの、フラット化しておくことで検索時の性能を担保する形です。
2 つのレイヤーで操作ログを処理することから、受信時刻を考慮した実装が必要でした。これにより、特にバッチレイヤーの仕様や構成が複雑になっていました。
構成図上では、赤枠で囲んだ部分になります。
リプレース後のログ基盤
上記の課題を解消するために、以下のアプローチを取りました。
- Amazon Managed Service for Apache Flink で「フラット化 + パーティションごとの保存」をリアルタイムで行い、レイヤーを 1 本化
Amazon Managed Service for Apache Flink とは
Apache Flink は以下のような特徴を持つ分散処理フレームワークです。
- ストリーミングデータのリアルタイム処理に適している
- Exactly-Once を保証し、データの重複や欠損が起こらない
- Python、Scala などに対応
そして、それをマネージドサービスとして AWS が提供しているのが Amazon Managed Service for Apache Flinkです。
以下のような理由から、Flink を採用しました。
- 動的パーティショニングと比較しても遜色の無いストリーミング処理速度
- マネージドサービスで、運用負荷を下げられること
- クラウド版で使い慣れている Scala を活用できること
リプレース時の取り組み
クラウド版で取得する「PC操作ログ」は働き方の可視化や情報漏洩時の経路確認に使えます。 したがって、「遅延」や「欠損」に対して非常に敏感に取り扱っています。
このような背景から、調査時は以下 2 つの観点を重点的にチェックし問題ないことを確認しました。
性能計測
- 本番環境で流れているログ量を捌けるかどうかのテスト
データの欠損チェック
- 動的パーティショニングの時と比較して、漏れなく書き込めているかをチェックし欠損が起こっていないこと
- 動的パーティショニングが出力したログとFlinkで書き込んでいたログをそれぞれAthenaで取得して比較
- 動的パーティショニングの時と比較して、漏れなく書き込めているかをチェックし欠損が起こっていないこと
おわりに
本記事では、PC 操作ログ基盤が抱えていた課題とその改善の取り組みを紹介しました。
動的パーティショニングのクォータ抵触前にリプレースすることができました。性能面の課題もなく稼働しており、アーキテクチャもシンプルになって運用も楽になりました。
クォータも考慮してアーキテクチャを考える重要性を改めて認識することができました。 また、時代によってベストプラクティスや最適な設計は変わるため、定期的に見直しをかけることも重要かと思います。
ここまでお読みいただきありがとうございました。 本内容がお役に立てれば幸いです。
