データレイクを活用したAWSログ分析

はじめに

近年、急速に変化していく生活様式・ビジネススタイルに対応していくために、企業ではDX推進が喫緊の課題になっています。
DXを実現するために、企業では今まで利用されていないデータの可視化、そしてデータから知見を得る試みが進んでいます。
それに合わせて、企業のITシステムの基盤においても、複雑で大量のデータを扱うためにクラウドサービスの積極的な活用がされています。

本記事では、多様なデータを活用するために使用される手法のデータレイクと、その入門としてアマゾン ウェブ サービス（AWS）のログ分析を目的としたデータレイクの活用例についてご紹介いたします。

データレイクとは

企業がデータを元にしたビジネス判断を行うためには、まず企業内の様々な情報を収集して蓄積し、分析を行い、可視化をするというプロセスを行う必要があります。
データレイクとは、データの蓄積の段階で様々な形式・種類のデータをそのままの形で保存できる一元化された領域（レポジトリ）を指します。

一般的に、ビッグデータを格納して分析する場合、そのデータの格納先としてデータレイクとデータウェアハウスが検討候補となります。
以下、表：「データウェアハウスとデータレイクの比較」を記載します。

※引用元（https://aws.amazon.com/jp/big-data/datalakes-and-analytics/what-is-a-data-lake/）

データウェアハウスは、データの加工、変換などを実施し、構造化します。
SQLクエリなどによって、検索性を高めて分析を高速化することが可能ですが、保持させるデータは、事前にデータを構造化したリレーショナルデータに変換しておく必要があります。
データを構造化する過程で、必要なデータの取捨選択や形式の変換などが必要となり、保持できない要素は格納をあきらめざるを得ない場合があります。
そのため、分析に必要と判明したデータを後から補うなどのプランが取りにくい手法となります。

一方、データレイクは、様々なデータ形式を保管し大規模に集積する役割を持ちます。
構造化したデータに加え、非構造のデータをそのまま格納することが可能です。
将来的に「どのようなデータを分析するか」などのデータ形式の設計を慎重に実施する必要性がほとんどなく、取得したデータをそのままの形式でデータレイクへ格納することが可能となります。

また、これらの２つの手段は組み合わせることも可能です。
データレイクに格納された膨大なデータから、必要なデータのみをデータウェアハウスに移行し、SQLクエリによる高速な分析を実施することもできます。

このように、データレイクとは将来的な分析に備え、データ保持することが一番の役割となります。
まずはデータをそのままの形式で保持し、分析したい内容・手法に応じて、データを変換・活用していくことが、データレイクを用いたデータ分析の基本戦略となります。

ログ管理

初めてデータレイクを使う場合など、難しく考えすぎてしまいなかなか始められないケースがあると思います。
そういった場合には、データを蓄積・保持し、蓄積されたデータに対して後から分析するという手法をまず実践することをお勧めいたします。
データレイクの入門例として、本記事ではAWS上のログ分析をデータレイクで実践する例をご紹介いたします。

ログとは、一般的にシステム状態の把握や、システムに対する不正操作が行われていないことの監査の証跡、システムに不具合が発生した際の原因調査などに用いられるシステムが保有する、貴重な財産となります。
長期的にログを保管し、必要に応じて閲覧したいログを取捨選択できるということ、不具合を発見するためにログの成形・可視化をするということは、データレイクとは非常に相性が良いものになります。

AWSでは、Amazon CloudWatch Logsを利用することで、AWSの各サービスで生成されたログを管理することが可能です。
AWSの各サービスだけでなく、Amazon CloudWatch Agentを併用することで、Amazon EC2インスタンス上で稼働するOSやアプリケーションログも一括で管理することが可能です。
予め設定したキーワードがログに出力されたことを検知して、即座にシステム管理者に通知を行う仕組みなど、Amazon CloudWatch LogsとAmazon CloudWatchアラームなどを連携することで容易に実装が可能です。

非常に使い勝手が良く便利なサービスですが、Amazon CloudWatch Logs単体では、複数の種類のログに跨っている特定の期間のログ情報を1つの画面に表示させたいなど、複雑なログ分析には向いていないという特徴もあります。
こういった用途では、データレイクの考え方を活用すると、AWSのマネージドサービスだけで解決可能になります。
以降ではその手法について記載します。

システム構成と各サービスの処理

まずは、システム構成について説明いたします。全体構成は以下となります。

実現している処理は以下３つとなります。

① Amazon CloudWatch LogsからAmazon S3へログを転送する

データレイク用に用意したAmazon S3バケット上に、Amazon CloudWatch Logsで管理されているログが自動で転送される設定を実施します。
Amazon Kinesis Data Firehoseでは、デリバリーストリームを新規で１つ作成し、 宛先としてデータレイク用Amazon S3バケットを指定 します。
Amazon CloudWatch Logsの各ロググループでは、サブスクリプションフィルターを設定し、その宛先として、 作成したデリバリーストリームを指定 します。
※上記設定は、 青字以外は全て初期値で問題ありません。

② ログデータからデータカタログを生成する

AWS GlueデータベースとAWS Glueクローラを新規で作成します。
AWS Glueデータベースには名称以外の設定項目はありません。AWSGlueクローラには、 対象となるAWS Glueデータベースと、データレイク用のAmazon S3バケットを指定 します。
その後、作成したAWS Glueクローラを実行するとAmazon S3上のデータが自動で読み込まれ、対象データに対するデータカタログを自動生成します。
※上記設定は、 青字以外は全て初期値で問題ありません。

③ ログを分析し結果を出力する

Amazon Athenaを用いて、対象となるデータカタログに対してSQLクエリを実行します。
SELECT文を実行する際のWHERE句で任意の条件を抽出し、結果を取得することが出来ます。

SQLクエリの実行例

本構成のSQL実行例を記載します。

3~5行目は、SQLクエリにて抽出するデータの要素を選択しています。
7~8行目は抽出するデータのフィルター条件を設定しています。
本例の場合は、データレイク用Amazon S3に格納されたログイベントから、所定の日付時刻より新しい全てのログイベント抽出し、タイムスタンプでソートする処理となります。

また、１行目のWITH datasetや6行目のCross JOIN UNNESTは、SQLクエリ対象のログデータ（Amazon CloudWatch Logs上のログイベント）がJSON形式のネスト構造をもつため、フラット化させるために必要となる記述となり、記載のお作法はAmazon Athenaのユーザガイドで閲覧することが出来ます。
対象データに応じて必要なクエリを考える労力は必要とはなりますが、Amazon Athena特有のお作法さえ習得してしまえば、様々なデータ形式のデータに対して、馴染みのあるSQLクエリで分析が可能なため、データレイクを管理するための専用スキルが不要という利点を感じていただけると思います。

最後に

本記事では、データレイクやその入門として、AWSログ分析について解説いたしました。
データレイクは難しいものではないということを感じていただけると幸いです。

データレイクを利用する上で最も難しい点は、分析の対象として、各社の企業の機密情報や、サービス利用ユーザーの個人情報などがデータレイク上に格納される可能性がある点です。
2022年に個人情報保護法が改正されたことで、サービス利用ユーザーの権利保護が強化され、サービス提供者側の責務が増えた半面、“仮名加工情報”などさらなるデータの利活用を促進させる制度も新設されました。

個人情報を含むデータを分析する場合、サービス利用ユーザーから頂いた情報を管理するため、データレイク上での必要十分な権限や、サービス提供者側の体制なども適切に管理・検討する必要があります。
もし権限や組織の体制の考え方について興味がある方は、『AWSでデータレイクを構築するには』を本記事と併せて閲覧いただけると幸いです。
ルールを順守しながらデータレイクを利用したい場合、AWSを活用することで事前準備や専用スキルは最小限に達成が出来ると思いますので、是非ご検討いただきたいです。

また、今回紹介したAWSログ分析の手法については、別のアプローチとして、Amazon CloudWatch Logs Insightsを使う構成もあります。
データレイク構成では、安価なデータ格納場所であるAmazon S3にデータを溜めることを基本方針としますが、直近のログを対象に分析する場合にはAmazon CloudWatch Logs Insightsを活用して直接Amazon CloudWatch Logsを分析する方が良い場合もあります。同様の構成を実現されたい場合はAmazon CloudWatch Logsの利用も検討いただければと思います。

今回紹介した構成以外にも、データレイクやビッグデータの活用は、TISのAWS関連サービスにてご相談を受け付けておりますので、是非お気軽にお問合せください。

著：TIS株式会社
IT基盤技術事業本部 IT基盤技術事業部
IT基盤エンジニアリング第1部
主任　栗谷本　賢志