インフラのログ設計入門｜収集・保管・検索でシステム運用を劇的に改善する

システム障害が発生した際に、ログがなければ原因特定に数日かかることも珍しくありません。ログ設計を正しく行えば、障害時の対応時間を数時間に短縮し、システムの信頼性を飛躍的に向上させることができます。特にクラウド環境では、ログの収集・保管・検索の仕組みを構築することで、リアルタイムな監視と分析が可能になります。

本記事では、インフラエンジニアが実務で直面するログ設計の課題を解決するための具体的な手法を、基礎から応用まで網羅的に解説します。ログの種類やフォーマット、保管期間の設定、効率的な検索方法まで、実務で即座に活用できる知識を提供します。また、AWS、Azure、GCPなど主要クラウドサービスにおけるログ管理のベストプラクティスも紹介します。

目次

• ログ設計とは何か？基礎から理解する
• ログの収集方法とベストプラクティス
• ログの保管方法とストレージ最適化
• 効率的なログ検索と分析手法
• クラウドサービスにおけるログ管理
• ログセキュリティとコンプライアンス
• 実務におけるログ設計の事例
• ログ設計に関するよくある質問
• まとめ：ログ設計でシステム運用を変える

ログ設計とは何か？基礎から理解する

ログ設計は、システムが生成するログをどのように収集・保管・分析するかを計画するプロセスです。適切なログ設計を行うことで、システムの可観測性（Observability）が向上し、障害時の迅速な対応が可能になります。一方で、ログ設計を怠ると、ログが膨大すぎて検索が困難になったり、重要なログが欠落してしまうリスクがあります。

ログの種類とその役割

ログは大きく分けて以下の4つの種類があり、それぞれ異なる目的で利用されます。

例えば、Webサーバーのアクセスログには、ステータスコード（200, 404, 500）やリクエストURL、レスポンスタイムなどが記録されます。これらのログを分析することで、パフォーマンスのボトルネックやセキュリティ上の脆弱性を特定できます。

ログ設計の原則：FAIR原則

ログ設計を行う際には、以下のFAIR原則に従うことが重要です。

• Findable（発見可能）：ログが必要なときにすぐに見つけられるように、適切なタグ付けやインデックスを設定する
• Accessible（アクセス可能）：権限を持つ関係者が必要な時にアクセスできるようにする
• Interoperable（相互運用可能）：異なるシステム間でログを共有・統合できるフォーマットを採用する
• Reusable（再利用可能）：ログを将来の分析や機械学習に活用できるように、構造化されたフォーマットで保存する

特にクラウド環境では、AWS CloudTrail、Azure Monitor、GCP Cloud Loggingなどのサービスを活用することで、FAIR原則に基づいたログ管理が容易になります。

ログ設計の失敗例とその影響

ログ設計を怠ると、以下のような問題が発生します。

• ログが膨大すぎて検索が困難に：不要なログを大量に収集すると、ストレージコストが増大し、検索パフォーマンスが低下します。
• 重要なログが欠落：ログの保管期間を短く設定しすぎると、障害発生時に必要なログが見つからないことがあります。
• フォーマットが統一されていない：異なるシステムから出力されるログのフォーマットがバラバラだと、分析が困難になります。
• セキュリティリスクの増大：機密情報を含むログが適切にマスキングされていないと、情報漏洩の原因になります。

例えば、ある企業では、ログの保管期間を30日に設定していたため、システム障害発生時に必要なログがすでに削除されており、原因特定に2週間以上かかったという事例があります。このような事態を防ぐためには、ログの保管期間を用途に応じて適切に設定することが不可欠です。

ログの収集方法とベストプラクティス

ログの収集は、ログ設計の第一歩です。適切なログ収集方法を選択することで、リアルタイムな監視と分析が可能になります。ここでは、ローカル環境とクラウド環境におけるログ収集の方法を解説します。

ローカル環境におけるログ収集

オンプレミス環境や仮想マシン（VM）では、以下の方法でログを収集します。

1. syslogを利用したログ転送

syslogは、Unix/Linuxシステムで広く利用されているログ転送プロトコルです。syslogを使用すると、複数のサーバーからログを一元的に収集し、ログサーバーに保存できます。

syslogの設定例（/etc/rsyslog.conf）:

<VirtualHost *:514>
  # UDPポート514でログを受信
  module(load="imudp")
  input(type="imudp" port="514")

  # ログの保存先を指定
  template(name="RemoteLogs" type="string" string="/var/log/remote/%HOSTNAME%/%PROGRAMNAME%.log")
  if $fromhost-ip != "127.0.0.1" then {
    action(type="omfile" dynaFile="RemoteLogs")
    stop
  }
</VirtualHost>

この設定により、リモートサーバーから送信されたログは、/var/log/remote/<ホスト名>/<プログラム名>.logに保存されます。

2. Fluentd/Fluent Bitを利用したログ収集

Fluentdは、ログ収集・転送・集約を行うオープンソースのソフトウェアです。Fluentdを使用すると、異なるフォーマットのログを統一された形式に変換し、複数の宛先に送信できます。

Fluentdの設定例（/etc/fluent/fluent.conf）:

<source>
  @type tail
  path /var/log/nginx/access.log
  pos_file /var/log/fluent/nginx_access.log.pos
  tag nginx.access
  format /^(?<remote>[^ ]*) - (?<host>[^ ]*) \[(?<time>[^\]]*)\] "(?<method>\S+)(?: +(?<path>[^\"]*?)(?: +\S*)?)?" (?<code>\d+)(?: (?<size>\S+))?$/
</source>

<match nginx.access>
  @type forward
  <server>
    host 192.168.1.100
    port 24224
  </server>
</match>

この設定により、NginxのアクセスログがFluentdによって収集され、別のサーバーに転送されます。

3. Filebeatを利用したログ収集

Filebeatは、軽量なログ収集ツールで、主にElastic Stack（旧ELK Stack）と連携して使用されます。Filebeatは、ログファイルをリアルタイムに監視し、ElasticsearchやLogstashに送信します。

Filebeatの設定例（filebeat.yml）:

filebeat.inputs:
- type: log
  paths:
    - /var/log/nginx/access.log
  fields:
    log_type: nginx_access

output.elasticsearch:
  hosts: ["http://elasticsearch:9200"]
  index: "nginx-access-%{+yyyy.MM.dd}"

この設定により、NginxのアクセスログがElasticsearchに送信され、Kibanaで可視化できます。

クラウド環境におけるログ収集

クラウド環境では、クラウドプロバイダーが提供するネイティブなログ収集サービスを活用できます。

1. AWSにおけるログ収集

AWSでは、以下のサービスを利用してログを収集します。

• Amazon CloudWatch Logs：EC2インスタンスやLambda関数、その他AWSサービスからのログを収集・保存します。
• AWS CloudTrail：AWS APIコールのログを記録し、セキュリティ監査やトラブルシューティングに活用します。
• Amazon OpenSearch Service：Elasticsearchを利用してログを検索・分析します。

CloudWatch Logsの設定例（AWS CLI）:

aws logs create-log-group --log-group-name /var/log/nginx
aws logs put-retention-policy --log-group-name /var/log/nginx --retention-in-days 30

この設定により、NginxのログがCloudWatch Logsに保存され、30日間保持されます。

2. Azureにおけるログ収集

Azureでは、以下のサービスを利用してログを収集します。

• Azure Monitor（Log Analytics）：Azureリソースやオンプレミス環境からのログを収集・分析します。
• Azure Sentinel：セキュリティ情報イベント管理（SIEM）システムとして、ログを活用します。
• Azure Storage：長期保存用のログストレージとして利用します。

Log Analyticsの設定例（Azure CLI）:

az monitor log-analytics workspace create --resource-group myResourceGroup --workspace-name myWorkspace
az monitor log-analytics workspace data-export create --resource-group myResourceGroup --workspace-name myWorkspace --name myDataExport --destination myStorageAccount --table ApplicationLogs

この設定により、アプリケーションログがLog Analyticsに送信され、ストレージアカウントにエクスポートされます。

3. GCPにおけるログ収集

GCPでは、以下のサービスを利用してログを収集します。

• Cloud Logging：GCPリソースやオンプレミス環境からのログを収集・保存します。
• Cloud Monitoring：パフォーマンスメトリクスとログを統合して監視します。
• BigQuery：ログデータを分析用に保存します。

Cloud Loggingの設定例（gcloud CLI）:

gcloud logging sinks create my-sink storage.googleapis.com/my-bucket \
  --log-filter='resource.type="gce_instance" AND logName="projects/my-project/logs/nginx"'

この設定により、GCEインスタンスのNginxログがCloud Storageに保存されます。

ログ収集のベストプラクティス

ログ収集を行う際には、以下のベストプラクティスに従うことで、効率的なログ管理が可能になります。

• ログのフォーマットを統一する：JSONやKey-Value形式など、構造化されたフォーマットを採用し、ログの解析を容易にします。
• 不要なログを収集しない：ログの量が多すぎると、ストレージコストや検索パフォーマンスに悪影響を与えます。必要なログのみを収集するようにします。
• リアルタイム収集を優先する：リアルタイムにログを収集することで、障害発生時の迅速な対応が可能になります。
• ログの圧縮と暗号化：ログを圧縮して保存することでストレージコストを削減し、機密情報を含むログは暗号化して保護します。
• ログの重複排除：同じログが複数回送信されることを防ぐため、重複排除の仕組みを導入します。

ログの保管方法とストレージ最適化

ログの保管は、ログ設計の核心部分です。適切な保管方法を選択することで、ストレージコストを削減し、検索パフォーマンスを向上させることができます。ここでは、ローカル環境とクラウド環境におけるログ保管の方法を解説します。

ローカル環境におけるログ保管

オンプレミス環境では、以下の方法でログを保管します。

1. ローテーションと圧縮

ログファイルは時間とともに膨大になるため、ローテーション（古いログのアーカイブ）と圧縮を行うことで、ストレージ使用量を抑制します。

Linuxにおけるログローテーションの設定例（/etc/logrotate.conf）:

/var/log/nginx/*.log {
  daily
  missingok
  rotate 30
  compress
  delaycompress
  notifempty
  create 0640 www-data adm
  sharedscripts
  postrotate
    /usr/sbin/nginx -s reload
  endscript
}

この設定により、Nginxのログは毎日ローテーションされ、30日分のログが保持されます。また、古いログは圧縮され、ストレージ使用量を削減します。

2. ログストレージの階層化

ログを保管する際には、アクセス頻度に応じてストレージを階層化することで、コストを最適化します。

例えば、AWS S3では、S3 Standard（ホット）、S3 Infrequent Access（ウォーム）、S3 Glacier（コールド）の階層を利用して、ストレージコストを最適化できます。

クラウド環境におけるログ保管

クラウド環境では、クラウドプロバイダーが提供するストレージサービスを活用して、ログを保管します。

1. AWSにおけるログ保管

AWSでは、以下のストレージサービスを利用してログを保管します。

• Amazon S3：オブジェクトストレージで、ログを長期保存できます。
• Amazon S3 Glacier：低コストのアーカイブストレージで、長期保存に適しています。
• Amazon OpenSearch Service：検索・分析用のストレージとして利用します。

S3へのログ保存例（AWS CLI）:

aws s3 cp /var/log/nginx/access.log s3://my-log-bucket/nginx-access/2024/01/01/access.log

このコマンドにより、NginxのアクセスログがS3に保存されます。

2. Azureにおけるログ保管

Azureでは、以下のストレージサービスを利用してログを保管します。

• Azure Blob Storage：オブジェクトストレージで、ログを長期保存できます。
• Azure Archive Storage：低コストのアーカイブストレージで、長期保存に適しています。
• Azure Data Lake Storage：大規模なログデータを分析用に保存します。

Blob Storageへのログ保存例（Azure CLI）:

az storage blob upload --account-name mystorageaccount --container-name mycontainer --name nginx-access/2024/01/01/access.log --file /var/log/nginx/access.log

このコマンドにより、NginxのアクセスログがBlob Storageに保存されます。

3. GCPにおけるログ保管

GCPでは、以下のストレージサービスを利用してログを保管します。

• Cloud Storage：オブジェクトストレージで、ログを長期保存できます。
• Cloud Storage Nearline/Coldline：低コストのアーカイブストレージで、長期保存に適しています。
• BigQuery：大規模なログデータを分析用に保存します。

Cloud Storageへのログ保存例（gsutil）:

gsutil cp /var/log/nginx/access.log gs://my-log-bucket/nginx-access/2024/01/01/access.log

このコマンドにより、NginxのアクセスログがCloud Storageに保存されます。

ログ保管のベストプラクティス

ログを保管する際には、以下のベストプラクティスに従うことで、効率的なログ管理が可能になります。

• 保管期間を用途に応じて設定する：ログの用途に応じて保管期間を設定し、ストレージコストを最適化します。
• 圧縮と暗号化：ログを圧縮して保存することでストレージコストを削減し、機密情報を含むログは暗号化して保護します。
• アクセス制御：ログへのアクセスを制限し、不正アクセスを防止します。
• 監査ログの保管：ログへのアクセスや変更を監査し、ログ自体の改ざんを防止します。
• ストレージ階層の活用：アクセス頻度に応じてストレージを階層化し、コストを最適化します。

効率的なログ検索と分析手法

ログの検索と分析は、ログ設計の最終目的です。適切な検索手法を選択することで、障害時の迅速な対応やシステムの最適化が可能になります。ここでは、ローカル環境とクラウド環境におけるログ検索と分析の方法を解説します。

ローカル環境におけるログ検索

オンプレミス環境では、以下のツールを利用してログを検索します。

1. grepを利用したテキスト検索

grepは、Unix/Linuxシステムで広く利用されているテキスト検索ツールです。grepを使用すると、ログファイルから特定のパターンを検索できます。

grepの使用例:

grep "404" /var/log/nginx/access.log

このコマンドにより、NginxのアクセスログからHTTP 404エラーを検索できます。

2. awkを利用したログ解析

awkは、テキスト処理に特化したプログラミング言語です。awkを使用すると、ログファイルから特定のフィールドを抽出し、集計や分析ができます。

awkの使用例:

awk '{print $1, $9}' /var/log/nginx/access.log | sort | uniq -c | sort -nr

このコマンドにより、Nginxのアクセスログからステータスコードとリクエスト数を集計し、降順にソートします。

3. sedを利用したログ編集

sedは、テキスト編集に特化したツールです。sedを使用すると、ログファイルから不要な行を削除したり、フォーマットを整形できます。

sedの使用例:

sed '/^#/d' /var/log/nginx/access.log > cleaned_access.log

このコマンドにより、Nginxのアクセスログからコメント行を削除し、新しいファイルに保存します。

クラウド環境におけるログ検索

クラウド環境では、クラウドプロバイダーが提供するログ検索サービスを活用できます。

1. AWSにおけるログ検索

AWSでは、以下のサービスを利用してログを検索します。

• Amazon CloudWatch Logs Insights：CloudWatch Logsに保存されたログを検索・分析します。
• Amazon OpenSearch Service：Elasticsearchを利用してログを検索・分析します。
• AWS Athena：S3に保存されたログをSQLで検索・分析します。

CloudWatch Logs Insightsの検索例:

fields @timestamp, @message
| filter @message like /404/
| stats count(*) by bin(5m)

このクエリにより、CloudWatch Logsに保存されたログからHTTP 404エラーを検索し、5分ごとの発生回数を集計します。

2. Azureにおけるログ検索

Azureでは、以下のサービスを利用してログを検索します。

• Azure Monitor Logs（Kusto Query Language）：Log Analyticsに保存されたログを検索・分析します。
• Azure Data Explorer：大規模なログデータを検索・分析します。

Kusto Query Languageの検索例:

AzureDiagnostics
| where Category == "AppServiceConsoleLogs"
| where Message contains "404"
| summarize count() by bin(TimeGenerated, 5m)

このクエリにより、Azure App ServiceのコンソールログからHTTP 404エラーを検索し、5分ごとの発生回数を集計します。

3. GCPにおけるログ検索

GCPでは、以下のサービスを利用してログを検索します。

• Cloud Logging Logs Explorer：Cloud Loggingに保存されたログを検索・分析します。
• BigQuery：BigQueryに保存されたログをSQLで検索・分析します。

Cloud Logging Logs Explorerの検索例:

resource.type="gce_instance"
logName="projects/my-project/logs/nginx"
textPayload:"404"

このクエリにより、GCEインスタンスのNginxログからHTTP 404エラーを検索します。

ログ検索のベストプラクティス

ログを検索する際には、以下のベストプラクティスに従うことで、効率的なログ検索が可能になります。

• 検索クエリを最適化する：不要なフィールドや条件を除外し、検索クエリを最適化します。
• インデックスを活用する：検索対象のフィールドにインデックスを設定し、検索パフォーマンスを向上させます。
• リアルタイム検索を優先する：リアルタイムにログを検索することで、障害発生時の迅速な対応が可能になります。
• 検索結果を可視化する：検索結果をグラフやダッシュボードで可視化し、傾向や異常を把握しやすくします。
• 検索履歴を保存する：頻繁に使用する検索クエリを保存し、再利用できるようにします。

クラウドサービスにおけるログ管理

クラウドサービスを利用する際には、クラウドプロバイダーが提供するネイティブなログ管理サービスを活用することで、効率的なログ収集・保管・検索が可能になります。ここでは、AWS、Azure、GCPにおけるログ管理のベストプラクティスを解説します。

AWSにおけるログ管理

AWSでは、以下のサービスを組み合わせてログ管理を行います。

1. AWS CloudTrail

AWS CloudTrailは、AWS APIコールのログを記録し、セキュリティ監査やトラブルシューティングに活用します。CloudTrailは、以下の機能を提供します。

• APIコールの記録：AWS APIの実行履歴を記録し、誰が何を実行したかを追跡します。
• イベントの分類：管理イベント（AWSリソースの作成・変更・削除）とデータイベント（S3オブジェクトのアクセス・Lambda関数の実行）に分類します。
• ログの保存と分析：CloudTrailログはS3に保存され、AthenaやOpenSearch Serviceで分析できます。

CloudTrailの設定例（AWS CLI）:

aws cloudtrail create-trail --name my-trail --s3-bucket-name my-log-bucket
aws cloudtrail start-logging --name my-trail

この設定により、AWS APIコールのログがS3に保存されます。

2. Amazon CloudWatch Logs

Amazon CloudWatch Logsは、EC2インスタンスやLambda関数、その他AWSサービスからのログを収集・保存します。CloudWatch Logsは、以下の機能を提供します。

• この記事で学んだスキルをさらに深めたい方へ

  インフラエンジニアのスキルアップに役立つ技術書です。Amazonで探してみましょう。

  • Linux・インフラ技術書をAmazonで探す

  Amazonアソシエイトプログラムを利用しています。