Understand the SAE log collection architecture in one article

プログラムのログの重要性は言うまでもありません。トラブルシューティング、重要なノード情報の記録、早期アラート、設定とモニタリングのいずれにおいても、ログは極めて重要な役割を果たします。あらゆるカテゴリ、さらにはあらゆるアプリケーションで記録・確認が必要な重要な情報です。クラウドネイティブ時代において、ログ収集は収集方式と収集アーキテクチャの両面で従来のログ収集とは異なります。ログ収集プロセスにおける実用的な共通問題を以下にまとめました。

- K8s にデプロイされたアプリケーションの場合、ディスクサイズは物理マシンよりはるかに小さく、すべてのログを長期間保存できないため、既存データのクエリ要件がある

- ログデータは非常に重要であり、アプリケーションの再起動やインスタンスの再構築後も損失は許されない

- ログのキーワードなどに基づいてアラートを設定し、モニタリングを行いたい

- 権限制限が厳しく、SLS などのログシステムを利用またはクエリできず、独自のログ収集システムにインポートする必要がある

- Java や PHP などのアプリケーションの例外スタックトレースは複数行にまたがり、スタック例外が複数行に出力される。どのように集約して確認するか

ユーザーは実際の本番環境でログ機能を使用してどのようにデータを収集するのでしょうか。異なるビジネスシナリオと異なるビジネス要件に直面したとき、どの収集スキームが最適でしょうか。Serverless App Engine (SAE) は、フルマネージドでメンテナンス不要、高い弾力性を備えた汎用 PaaS プラットフォームとして、SLS 収集、NAS マウント収集、Kafka 収集など、さまざまなシナリオに対応する収集方式を提供しています。本記事では、各ログ収集方式の特徴と最適なユースケースを詳しく解説し、適切な収集アーキテクチャの設計と一般的な問題の回避を支援します。

SAE のログ収集方式

SLS 収集アーキテクチャ

SLS ログ収集は SAE が推奨するログ収集スキームです。データ取得、処理、クエリと分析、可視化、アラート、消費と配信をワンストップで実現します。

SAE には SLS 収集機能が既に統合されており、ビジネスログとコンテナの標準出力を簡単に SLS に収集できます。SAE に統合された SLS のアーキテクチャを以下に示します。

- SAE は Pod 内に Logtail (SLS コレクター) のサイドカーをマウントします

- その後、顧客が設定したログ収集対象のファイルまたはパスを、ボリューム形式でビジネスコンテナと Logtail サイドカー間で共有します。これが /home/admin を SAE のログ収集対象として設定できない理由です。アプリケーションの起動ファイルは /home/admin に配置されており、ボリュームをマウントすると起動ファイルが上書きされるためです

- また、Logtail のデータは SLS の内部ネットワークアドレス経由で送信されるため、外部ネットワークを開通させる必要はありません

- SLS のサイドカー収集では、サービスコンテナの動作に影響を与えないようリソース制限が設定されており、CPU 制限は 0.25 コア、メモリ制限は 100 MB です

SLS は大半のビジネスシナリオに適しており、アラートとモニタリンググラフの設定をサポートしています。多くの場合、SLS を直接選択すれば問題ありません。

NAS 収集アーキテクチャ

NAS は共有アクセス、弾力的な拡張、高い信頼性、高性能を備えた分散ファイルシステムです。高スループットと高 IOPS を提供し、ファイルのランダム読み書きとオンライン修正をサポートしており、ログシナリオに適しています。より多くのログや大容量のログをローカルに保持したい場合は、NAS をマウントし、ログファイルの保存先パスを NAS マウントディレクトリに向けることができます。SAE への NAS マウントには複雑な技術的考慮点やアーキテクチャが伴わないため、ここでは説明を省略します。

NAS をログ収集として使用する場合、ローカルディスクとして扱えます。インスタンスのクラッシュや再構築などが発生しても、ログが失われることはありません。データ損失が許容されない非常に重要なシナリオには、この方式を検討してください。

Kafka 収集アーキテクチャ

ログファイルの内容を Kafka に収集し、Kafka のデータを消費してログを収集することもできます。その後、ユーザーは必要に応じて Kafka 内のログを Elasticsearch にインポートしたり、プログラムで Kafka データを消費して処理したりできます。

Kafka 自体のログ収集方法は複数あり、最も一般的な Logstash、比較的軽量な収集コンポーネントである Filebeat、Vector などがあります。SAE が採用している収集コンポーネントは Vector です。SAE に統合された Vector のアーキテクチャを以下に示します。

- SAE は Pod 内に Vector のサイドカーをマウントします

- その後、顧客が設定したログ収集対象のファイルまたはパスを、ボリューム形式でビジネスコンテナと Vector サイドカー間で共有します

- Vector は収集したログデータを定期的に Kafka に送信します。Vector 自体には比較的豊富なパラメータ設定があり、収集データの圧縮、データ送信間隔、収集指標などを設定できます

Kafka 収集は SLS 収集の補完です。実際の本番環境では、権限制限が非常に厳しい顧客がいます。SAE の権限のみを持ち、SLS の権限を持たない場合、ログを Kafka に収集して後続の閲覧に利用したり、ログに対して二次処理を行ったりする必要があるため、Kafka ログ収集スキームを選択できます。

重要なパラメータの解説：

- multiline.start_pattern は、このルールに適合する行を検出すると新しいデータポイントとして扱います

- multiline.condition_pattern は、このルールに適合する行を検出すると前の行と結合し、1 行として扱います

- sinks.internal_metrics_to_prom を設定すると、Vector の収集メタデータを Prometheus に送信します

ベストプラクティス

実際の使用では、ビジネス要件に応じて異なるログ収集方式を選択できます。logback 自体のログ収集戦略では、ファイルサイズとファイル数の制限を設定する必要があります。制限しない場合、Pod のディスクがいっぱいになりやすくなります。Java を例にとると、以下の設定では最大 7 ファイル、各ファイル最大 100 MB を保持します。

この log4j の設定は一般的なログローテーション設定です。

ログローテーションには主に作成モードとコピー&トランケートモードの 2 つがあり、ログ収集コンポーネントによってこれらへのサポートレベルが異なります。

作成モードでは、元のログファイルをリネームしてから新しいログファイルを作成して置き換えます。

1. イベントログを書き込む前に、最大ファイル容量に達したか判定します。達していない場合は書き込みを完了し、達した場合は第 2 フェーズに移行します

2. まず現在の currentlyActiveFile が指すファイルをクローズしてから、元のファイルをリネームし、新しいファイルを作成します。このファイルの名前は、前の currentlyActiveFile が指していたファイルと同じです

3. currentlyActiveFile が指すファイルを、第 2 フェーズで作成した新しいファイルに変更します

コピー&トランケートモードでは、出力中のログをコピーしてから元のログを空にします。

実際のケーススタディ

ここでは、お客様の本番環境における実際のシナリオを紹介します。

お客様 A のケースでは、ログローテーションでプログラムのログを管理しつつ、SLS にログを収集しています。また、キーワードに基づくアラートを設定して、システム監視を実現しています。

まず、log4j の設定により、ログファイルは最大 10 個、各 200 MB に制限され、ディスク使用量を適切に維持できます。ログファイルは /home/admin/logs パスに保存されます。詳細な設定についてはここでは省略し、ベストプラクティスのセクションで説明した設定を利用できます。

次に、SAE の SLS ログ収集機能を通じてログを SLS に収集します。

最後に、プログラムのログ内のキーワードや 200 ステータスコードの比率など、特定のルールに基づいてアラートを設定します。

NGINX のログを活用して、監視システムの設定を完了します。

よくある質問

ログマージの概要

ログ収集の際、1 行ずつではなく、複数行のログを 1 行に結合して収集する必要がある場合が多くあります。たとえば、Java の例外ログなどが該当します。このような場合にログマージ機能を使用します。

SLS にはマルチライン収集モードがあり、このモードでは複数行統合用の正規表現を設定する必要があります。

Vector にも同様のパラメータがあります。multiline.start_pattern は新しい行の正規表現を設定するために使用します。この正規表現に適合すると、新しい行として扱われます。multiline.mode パラメータと組み合わせて使用できます。詳細なパラメータについては Vector の公式ドキュメントを参照してください。

ログ収集の損失分析

SLS 収集と Vector から Kafka への収集は、いずれも収集ログが失われないことを保証します。収集したチェックポイント情報はローカルに保存されます。サーバーの予期しないシャットダウンやプロセスのクラッシュなどの異常が発生しても、最後に記録された位置から収集が再開され、可能な限りデータ損失を防ぎます。

ただし、これによりログが絶対に失われないことが保証されるわけではありません。特定の極端なシナリオでは、ログ収集が失われる可能性があります。たとえば：

1. K8s Pod のプロセスがクラッシュし、liveness チェックが継続的に失敗したことで Pod が再構築される

2. ログが非常に高速にローテーションされる（たとえば、1 秒に 1 回）

3. ログ収集速度が長期間にわたりログ生成速度に追いつかない

シナリオ 2 および 3 については、アプリケーションが不要なログを出力しすぎていないか、ログローテーションの設定が異常でないかを確認する必要があります。通常、これらの状況は発生しないためです。シナリオ 1 については、ログ要件が非常に厳格で Pod の再構築後もログを失いたくない場合、マウントした NAS をログストレージパスとして使用できます。これにより、Pod の再構築後もログが失われることはありません。

まとめ

本記事では、SAE が提供する各種ログ収集スキームと、関連するアーキテクチャおよびシナリオ別の利用特徴について解説しました。要点は以下の 3 点です。

1. SLS 収集は大半のシナリオに適応でき、実用的である

2. NAS 収集はいかなるシナリオでもログが失われず、ログ要件が非常に厳格なシナリオに適している

3. Kafka 収集は SLS 収集の補完であり、ログの二次処理が必要な場合や、権限などの理由で SLS を利用できない場合に、Kafka へのログ収集を選択できる