## Memo
- ![[Pasted image 20250310141801.png|600]]
## Memo with LLM
- chat: https://claude.ai/chat/90c9669d-b130-4386-a72f-57a5c738f00d
```markdown:
自己調整型ログ観測性によるクラウドネイティブアプリケーション」の要約
この論文は、クラウドネイティブアプリケーション向けに「SALO（Self-Adjusting Log Observability）」と呼ばれる自律型システムを提案しています。SALOは、常時すべてのコンポーネントから無差別にログを収集する従来のアプローチとは異なり、必要なときに必要な場所から適切な粒度でログを選択的に収集します。
**背景と課題**
現代のマイクロサービスベースのアプリケーションでは、観測性データ（ログ、メトリクス、トレースなど）の量が大幅に増加しています。特にログは観測性データの中で最も大きな部分を占め、以下の課題を引き起こしています：
1. ストレージと保持のコストが高い
2. ログ量がアプリケーションのワークロードに比例して増加し、パフォーマンスに影響する
3. 大量のデータがAIOps（AI for IT Operations）モデルの効果を低下させる
**SALOの設計**
SALOは以下の3つの主要な疑問に対応するように設計されています：
1. **いつ収集するか？** - 各コンポーネントに付属する「GateKeeper」と呼ばれる軽量なサイドカーがコンポーネントの健全性を監視し、異常が検出された場合にログレベルを動的に調整します。
2. **どこから収集するか？** - 障害の「爆発半径」に基づいて、障害が発生したコンポーネントだけでなく、影響を受ける可能性のある隣接コンポーネントからもログを収集します。
3. **どの粒度で収集するか？** - 障害の影響度に応じて、コンポーネントごとに適切なログレベル（CRITICAL、ERROR、WARN、INFO、DEBUG）を決定します。
**実装と評価**
SALOはKubernetesやOpenShiftなどのコンテナオーケストレーションプラットフォーム向けに実装されました。評価には「Quote of the Day（QoTD）」と「[[TrainTicket]]（TT）」という2つのマイクロサービスベースのアプリケーションが使用されました。実験結果から：
1. ログ量を最大95%削減しながら、障害分類などのダウンストリームAIOpsタスクの品質を維持または向上させた
2. 障害の「カスケード」（一つのコンポーネント障害が他のコンポーネントに波及する現象）を効果的に検出
3. システムのオーバーヘッドが最小限（CPUとメモリの使用量が低い）
結論
SALOは、ログ観測性のコストを大幅に削減しながら、ダウンストリームのAIOpsタスクに必要なデータ品質を維持することに成功しています。これにより、ストレージ、転送、保持のコストが削減され、観測性パイプラインがより効率的になります。
**主な関連研究の解説**
---
論文で言及されている主な関連研究は、観測性（Observability）、ログ処理、およびAIOpsの領域に分類できます。以下に各領域の重要な関連研究を解説します。
**観測性（Observability）フレームワーク**
観測性は、システムの内部状態をその外部出力から推測する能力を指します。以下の研究が重要です：
Marie-Magdelaine et al. (2020)は、AWSで構築されたクラウドネイティブアプリケーション向けの観測性フレームワークを実装しました。このフレームワークは、ローカルサイトからのテレメトリーデータを中央の場所に収集して分析するアプローチを示しています。
IntelligentMonitorとして知られるThantharate (2023)の研究と、5GC-Observerとして知られるKhichane et al. (2022)の研究は、リアルタイムデータ収集とインテリジェントな分析を用いた観測性フレームワークを提案しています。
また、[[Prometheus]]、[[Jaeger]]、[[Zipkin]]、[[Grafana]]、[[Thanos]]などの産業ツールが観測性パイプラインで広く使用されています。
**ログ処理の技**術
ログは最も重要な観測性データの一つですが、その量と非構造化された性質が課題となっています：
Yu et al. (2012)は有用なログのサンプリング手法を提案し、He et al. (2018)、Zhang et al. (2022)、He et al. (2018)は非構造化ログを構造化フォーマットに解析する方法を研究しました。
DeCelles et al. (2019)、Li et al. (2024)、Christensen and Li (2013)は共通性と可変性に基づいたログの圧縮方法を開発しました。
**異常検出とAIOps**
ログデータを用いた異常検出はAIOpsの重要なタスクです：
Zhang et al. (2019)は不安定なログデータに対する堅牢なログベースの異常検出を研究しました。
Son et al. (2017)はHadoopエコシステムを使用した大規模ログデータの異常検出を提案しました。
Valli et al. (2023)はAIOpsのログデータにおける重要性を調査しました。
**関連研究とSALOの差別化**
これらの既存研究と比較して、SALOは以下の点で独自性を持っています：
1. 既存のアプローチの多くは、すべてのデータを収集してから事後処理する方法を取っていますが、SALOはソースで選択的なログ収集を行います。
2. 従来の手法では手動での介入が必要な場合が多いのに対し、SALOは完全に自律的に動作します。
3. SALOは、単にログ量を削減するだけでなく、障害の「爆発半径」に基づいて関連するコンポーネントからのログ収集を適応的に調整する独自のアプローチを採用しています。
4. 多くの既存研究がログの解析や圧縮に焦点を当てていますが、SALOはそれ以前の段階であるログの収集自体を最適化することで、全体的な効率を向上させています。
これらの差別化により、SALOはログデータ量を大幅に削減しながらも、ダウンストリームのAIOpsタスクにとって重要なデータの品質を維持することに成功しています。
```
```markdown
# SALO (Self-Adjusting Log Observability) システムの詳細解説
SALO (Self-Adjusting Log Observability) はクラウドネイティブアプリケーション向けの自律型ログ観測性システムです。従来の手法と異なり、SALOは必要なときに、必要な場所から、適切な粒度でログを選択的に収集します。以下にSALOの詳細について説明します。
## システムアーキテクチャ
SALOは主に2つの主要コンポーネントから構成されています：
1. **GateKeeper**: アプリケーションの各コンポーネント（マイクロサービス）に付属する軽量なサイドカーです。
2. **Central Controller**: アプリケーション全体を監視し、各GateKeeperと通信する中央制御システムです。
## GateKeeper
GateKeeperは各マイクロサービスに付属し、以下の3つの主要機能を提供します：
1. **健全性検出 (Health Detection)**:
- Drain3というログテンプレートマイナーを使用して、コンポーネントのログパターンを学習します。
- 健全な状態のログからテンプレートモデルを構築し、新しいログパターンが出現した場合に異常として検出します。
- 一定時間枠内に未知のテンプレートIDが検出された場合、コンポーネントは「不健全」と判断されます。
2. **ログフィルタリング (Log Filtering)**:
- コンポーネントから出力されるログをインターセプトし、設定されたログレベルに基づいてフィルタリングします。
- コンポーネントが健全な場合は最小限のログレベル（L1: CRITICAL）のみを通過させます。
- コンポーネントが不健全な場合や、隣接するコンポーネントで障害が検出された場合は、ログレベルを上げて詳細なログを通過させます。
3. **バッファリング (Buffering)**:
- 障害が発生した場合、障害発生前のログも分析のために必要になります。
- GateKeeperは設定された期間、最大ログレベル（L5: DEBUG）のログを一時的なバッファに保存します。
- 異常が検出された場合、バッファされたログも含めて分析用に提供されます。
Central Controller
Central Controllerはアプリケーション全体を監視し、以下の機能を担います：
1. **健全性監視**:
- 定期的に各GateKeeperに問い合わせを行い、コンポーネントの健全性状態とログレベルを評価します。
2. **障害の影響範囲計算 (Blast Radius)**:
- あるコンポーネントで異常が検出された場合、アプリケーションのトポロジーに基づいて潜在的に影響を受ける隣接コンポーネントを特定します。
- 「爆発半径」（Blast Radius）と呼ばれる影響範囲をkホップ（k = 1, 2, 3など）で計算します。
3. **ログレベル調整指示**:
- 影響を受ける可能性のあるコンポーネントに対して、適切なログレベルを計算し、それらのGateKeeperに指示を送ります。
- 障害が修正された場合、ログレベルをデフォルト値に戻す指示も送ります。
## ログレベル決定のアルゴリズム
SALOは障害の影響を受ける可能性のあるコンポーネントのログレベルを決定するために、2つの方法を採用しています：
1. **静的均等重み付け (Static Equal Weightage)**:
- 各コンポーネントから出るエッジに均等な重みを割り当てます。
- 例えば、あるコンポーネントが3つの隣接コンポーネントを持つ場合、障害カスケードの影響確率は均等に分配されます。
2. **動的相互作用ベース重み付け (Dynamic Interaction-based Weightage)**:
- コンポーネント間の実際の相互作用頻度に比例してエッジの重みを割り当てます。
- 障害のあるコンポーネントとの相互作用が多いコンポーネントほど、影響を受ける可能性が高いと判断されます。
これらの重み付けに基づいて、各コンポーネントに適切なログレベル（L1: CRITICAL、L2: ERROR、L3: WARN、L4: INFO、L5: DEBUG）が割り当てられます。例えば、エッジの重みが0-20の範囲にある場合はL1、20-40の範囲にある場合はL2というように設定されます。
## 実装の詳細
SALOの実装は、KubernetesやOpenShiftなどのコンテナオーケストレーションプラットフォーム向けに設計されています：
1. **GateKeeper**:
- Python 3で実装された297行のコードで構成されています。
- Dockerイメージとしてパッケージ化され、マイクロサービスのサイドカーコンテナとしてデプロイされます。
- RESTサーバーとしてAPIエンドポイントを提供し、ログレベルの調整やマイクロサービスの健全性状態の取得が可能です。
2. **Central Controller**:
- Python 3で実装された272行のコードで構成されています。
- 別の名前空間にコンテナポッドとしてデプロイされます。
- スケーラビリティに対応するために必要に応じて複製できます。
3. **通信フロー**:
- GateKeeperは自らをCentral Controllerに登録します。
- Central Controllerは定期的にGateKeeperのエンドポイントに問い合わせを行い、マイクロサービスの健全性状態を確認します。
- Central ControllerはKialiと連携して、アプリケーションのリアルタイム相互作用トポロジーを取得します。
- 健全性状態の変化（健全→不健全、または不健全→健全）に基づいて、適切なログレベル調整指示が送信されます。
## 評価結果
SALOは以下の観点から評価されました：
1. **ログ量削減**: 最大95%のログ量削減を達成し、特にEk=3シナリオ（k=3ホップの動的相互作用ベース重み付け）では、わずか5%のログ量で効果的な分析が可能でした。
2. **ダウンストリームタスクへの影響**: 障害分類などのAIOpsタスクにおいて、ログ量を大幅に削減しても分類精度は維持され、むしろノイズ減少により精度が向上しました。
3. **カスケード障害の検出**: 特にEk=3シナリオでは、障害カスケードの影響を受けるすべてのコンポーネントを正確に特定し、適切なログレベルでデータを収集できました。
4. **システムオーバーヘッド**: GateKeeperのCPU使用量は約2ミリコア、メモリ使用量は約110MB、Central Controllerは約9ミリコアのCPUと59MBのメモリを使用する程度で、システム全体への負荷は最小限でした。
SALOは、ログ観測性のコストを大幅に削減しながらも、障害診断や分析に必要なデータ品質を維持するという目標を達成しています。特に大規模なマイクロサービスベースのアプリケーションにおいて、その効果は顕著でした。
```
## Abstract
特にマイクロサービスアーキテクチャに依存するアプリケーションの複雑化に伴い、ログ、メトリクス、トレースなどを含む[[Observability]]データの量が大幅に増加している。さらに、クラウドの広範な展開により、可観測性はこれらのシステムの健全性とパフォーマンスを把握するために不可欠であり、運用チームは「取り残されることへの不安」から、可能な限り多くのデータを収集するようになっている。しかし、可観測性データの収集、保存、分析には、リソースと資金面で多大なコストがかかる。特に、ログは可観測性データ量の大部分を占めるため、可観測性のコストに最も大きな影響を与える。さらに、ログには非構造的でノイズが多いという特性があるため、故障の分類、故障診断、ログの異常検出など、IT運用([[AIOps]]タスクやDay-2運用)における下流のAIの有効性は、ログデータ量によって悪影響を受ける可能性がある。したがって、ログの可観測性の多さ、Day-2運用への影響、デバッグ可能性のバランスを取ることが不可欠である。本稿では、SALO(Self-Adjusting Log Observability)という自律システムを紹介する。SALOは、すべてのコンポーネントから無差別に継続的に収集するという従来のやり方とは対照的に、リアルタイムの必要性、場所、粒度に基づいてログを厳選して収集する。我々の実験では、SALOはログの量を大幅に削減し、下流のAIOps利用のためのデータ品質を維持しながら、特に事後診断タスクでは最大95%削減できることが示された。ログデータの量が減れば、ストレージ、転送、保持にかかるコストが削減されるだけでなく、可観測性パイプラインも合理化され、よりスリムで効率的、かつリソース消費の少ないものになる。