統合ログ管理は必要？ログ起点の分析から脱却する方法を解説

統合ログ管理は必要？ログ起点の分析から脱却する方法を解説

ログは、問題発生時の対応やユーザー体験を計測する際の重要な情報源であるため、一元管理して有効に活用したいと思う企業も多いでしょう。その際、「ログをどこに集めればいいのだろう」「ログを集めるためのソリューションはあるだろうか」と、ログの収集場所や方法について悩むケースは少なくありません。しかし、ログの収集は手段であり、目的ではありません。ログを収集する目的を明確にした上で、管理、保管、活用の方法を考えることが重要です。

ここでは、統合ログ管理の必要性や、ログ管理の課題、問題解決や障害対応を迅速に行うために効果的なログ管理の方法について解説します。

統合ログ管理とは？

統合ログ管理とは、システムの複数箇所から書き出される多くのログを一元的に収集し、保管する手法を指します。収集したログを、目的に応じて分析することで、システムのどこで何が起こったのかを迅速に把握できます。
近年、統合ログ管理のひとつとして、セキュリティインシデント対応を迅速化して実害を最小限にとどめることにフォーカスした「SIEM」が話題になっていますが、統合ログ管理を行う目的はほかにも、障害対応の迅速化や、ユーザー体験の向上、パフォーマンス分析などさまざまです。
本記事では、主に障害発生時の原因究明やユーザー体験の計測に役立てることを目的とした統合ログ管理について解説します。

統合ログ管理は必要？

急速に普及が進んでいるクラウドコンピューティングでは、コンテナライズやマイクロサービスなどを駆使してシステムの分散化が図られており、ログを統合的に管理する必要性が高まっています。
ログは、システム内で何が起こったのかを記録している証跡として、重要な情報源です。しかし、ログはあくまでも「結果」にすぎません。どのようなプロセスを経てこの結果が導かれたのか、分析する必要があります。最適なログ管理の方法は、集めたログをどういう目的で活用したいのかによって異なることに注意が必要です。

ログ管理の課題

統合ログ管理が注目を集めている一方で、ログ管理そのものに多くの課題があるのも実情です。主なログ管理の課題を見ていきましょう。

収集対象が多岐にわたる

ログ管理の課題として挙げられるのが、ログの収集対象が多岐にわたることです。ログはシステム内のあらゆる場所で書き出され、記録されています。分散しているログをすべて収集し、保存していたら、膨大なデータ量になってしまいます。そのため、ログ管理を行う際は、「何のためにログを収集するのか」を明確にし、どのログを、どのように、どこに集めておけば効率的かを考えておかなければなりません。その上で、生ログにタグを貼ったり、関連するログを結合したりと、分析用の加工も必要でしょう。
オンプレミスの時代であれば「とりあえずログを1ヵ所に集めておこう」といった考え方でも対応できたかもしれません。しかし、分散システムに移行している現在では、ログの収集対象の数やデータ量は膨大なため、分析・活用を考えたログ管理が重要です。

ストレージを圧迫する

ログ管理はストレージを圧迫してしまうことも課題です。特に、社内規定などでログの保存期間が定められている場合もあるでしょう。ログ管理ツールがシステムの各所で収集するログのデータ量は、システムの規模によって数百GBや数TB、数十TBにまで達することもあります。これだけのデータ量を保管し続けるとなると、自社でサーバーを立てて保存するというのは現実的ではありません。また、安価なSaaSサービスのストレージに移すと分析のたびに手間が発生します。長期保管だけではなく、分析することも考えた上で、どのような形で保管するのがよいのかを検討する必要があります。

分析・活用が難しい

ログ管理は、ログの分析・活用が難しいことも課題として挙げられます。一般的なログ管理では、システムに何らかの障害が起こった場合、ログを起点として、どのサーバーでどのような障害が起こったのかを明らかにします。しかし、エラーの原因が分からないところからスタートするため、おおよその見当を付けながら、関連するログを拾っていかねばなりません。そのためには、「ログ職人」と呼ばれるような経験と知識をもつエンジニアが必要になります。

ログ職人のスキルは、誰でも習得できるものではありません。また、ログ職人といえども、それぞれの経験と知識による推測で作業を進めるため、個人の力量には差があり、誰でも常に最短距離で障害の原因にたどり着けるわけではないのです。ログ管理の目的に応じて、分析しやすい管理方法を検討する必要があるでしょう。

オブザーバビリティの重要性

さまざまなサービスがインターネット経由で提供されるようになった現在、サービスを提供するシステムもアプリケーションも、複雑化の一途をたどっています。システム環境の複雑化によって、障害の原因特定や早期対応の難易度も高まる一方です。いくら統合ログ管理ツールを駆使しても、ログ起点での分析対応では、迅速な障害復旧を実現することが難しくなりつつあります。
つまり、迅速な障害対応が目的であれば、統合ログ管理の方法よりも、分析しやすい仕組みから考える必要があるのです。

そこで、重要なのが「オブザーバビリティ」という概念です。オブザーバビリティは、オブザーブ（Observe、観測する）と、アビリティ（Ability、能力）を組み合わせた複合語で、日本語では「可観測性」あるいは「観測する能力」などと訳されます。システム上で何らかの異常が起こった際に、それを通知するだけでなく、どこで何が起こったのか、なぜ起こったのか、どうやって直すのかを把握する能力を表す指標、あるいは仕組みを指します。
オブザーバビリティでは、システム上のすべてのテレメトリデータを参照し、そして、インフラ、アプリケーション、クラウドの各リソース、ユーザーエンドであるブラウザなどのあらゆる情報を、関連づけて観察・記録が可能です。そのため、障害が起こった際、それが「どこで、どのリクエストによって引き起こされたのか」を瞬時に特定し、そのリクエストに紐づいたログに行き着くことができます。特定の誰かにしかできない職人技に頼る必要はありません。
こうした分析の仕組みを実現できるのが、オブザーバビリティ・プラットフォーム「New Relic」です。

オブザーバビリティについては、下記の記事をご覧ください。
＜オブザーバビリティとは？監視との違い、必要性について解説＞
https://newrelic.com/jp/blog/best-practices/what-is-observability-difference-from-monitoring

ログ管理の概念を変えるNew Relic

ログ管理の目的が障害対応の迅速化やユーザー体験の向上であるなら、New Relicがおすすめです。New Relicの機能は広範囲に及びますが、ここではログの管理と分析という視点からNew Relicの特徴をご紹介します。

オブザーバビリティを実現するために必要なMELT

New Relicでは、オブザーバビリティを実現するために、「メトリクス（Metrics）」「イベント（Event）」「ログ（Log）」「トレース（Trace）」の4種類のデータが使われており、それぞれの頭文字をとって「MELT」と呼んでいます。MELTの中でも、特にトレースを活用することにより、複数のシステムをまたいだ処理を行う際の結果を分析しやすくなります。
New Relicなら、ログだけではなく、このような他のデータも併せて収集するため、一連のプロセス上のどこに原因があるのかを容易に突き止めることが可能なのです。

オブザーバビリティベースのログ分析機能「Logs in Context」

New Relicの「Logs in Context」は名称のとおり、コンテクスト化されたログを収集する機能です。New Relicはアプリケーション内に小さなエージェントを組み込み、そこから情報を収集します。これにより、システムでエラーが発生した際や性能低下が発生した時に、トレースからどこで何が起こったのかを特定しつつ、エラー発生時に具体的にどのようなログを出力していたかを1クリックで確認できます。
また、複数のシステムを横断して観測することもできるため、性能の低下やエラーを発生させているシステムと処理を特定し、その一連の処理に関連するログを簡単に洗い出すことも可能です。障害発生時だけでなく、障害の事前回避やレスポンスの向上など、ユーザー体験の向上に活かすことができます。
New Relicでこれらの作業を行う際、ログ職人のようなスキルは必要ありません。Logs in Contextを使えば、誰でも必要なログに素早くたどり着くことができ、迅速かつ正確なトラブルシューティングが可能になるのです。

長期保管が可能な「Live Archive」

現在では多くの企業でログの長期保管が奨励され、社内規定などで定められていることも少なくありません。しかし、ログのデータ量が増えてくると、ストレージスペースの拡大によるコストの問題によって、長期保管がしにくくなります。安価な別のストレージに移行すると、ログの検索や分析に手間がかかってしまいます。このジレンマを解決するのが、New Relicの「Live Archive」です。
Live ArchiveはNew Relicのログ保管領域に保存されているログデータを、保存期間が切れた後に自動的にアーカイブし、Live Archive領域に移動して長期保管します。アーカイブされたログはダウンロードする手間もなく、New Relicの操作感そのままに分析が可能です。ログデータの移動や再インデックス、外部ストレージの管理などの工数が不要で、それらの作業に伴うコストをカットすることもできます。
Live Archiveを活用することで、長期保管に伴う手間やコストの懸念を払拭できるでしょう。

New Relicを活用して、ログ起点での分析から脱却しよう

統合ログ管理という言葉から「システム内の各所で書き出されるログをできるだけ多く収集し、分類して保管する」ことを目的として考える人も少なくありません。しかし、統合ログ管理は、手段であって目的ではありません。最も大切なのは「何のためにログを集め、保管するのか」という点です。
収集したログは、「障害の原因を特定し復旧する」「ユーザー体験の向上を図る」「システムのパフォーマンスを観測し、リソースの最適化を図る」といった、さまざまな用途に活用できます。
どのような用途に使うにしても、書き出されたログを起点に分析しようとすると、ログ職人のようなエンジニア個人のスキルに頼らざるをえません。
New Relicを導入すれば、数クリックで障害の原因を特定し、ユーザー体験を向上させ、どのリソースがオーバースペックなのかを正確に判断することが可能です。エンジニアにとっても、またビジネスの成長を考える上でも、ログ起点の分析という先の見えない作業に時間を費やすよりも、開発というよりクリエイティブな業務に時間を使うほうが有意義といえます。

職人技と人海戦術に頼るログ管理からの脱却を目指すなら、New Relicの導入を検討してみてはいかがでしょうか。
New Relic導入のご相談については、お問い合わせフォームよりご連絡ください。