インフラのログ設計入門｜収集・保管・検索
インフラのログ設計入門｜収集・保管・検索でシステム運用を劇的に改善する
システム障害が発生した際に、ログがなければ原因特定に数日かかることも珍しくありません。ログ設計を正しく行えば、障害時の対応時間を数時間に短縮し、システムの信頼性を飛躍的に向上させることができます。特にクラウド環境では、ログの収集・保管・検索の仕組みを構築することで、リアルタイムな監視と分析が可能になります。
本記事では、インフラエンジニアが実務で直面するログ設計の課題を解決するための具体的な手法を、基礎から応用まで網羅的に解説します。ログの種類やフォーマット、保管期間の設定、効率的な検索方法まで、実務で即座に活用できる知識を提供します。また、AWS、Azure、GCPなど主要クラウドサービスにおけるログ管理のベストプラクティスも紹介します。
目次
- ログ設計とは何か？基礎から理解する
- ログの収集方法とベストプラクティス
- ログの保管方法とストレージ最適化
- 効率的なログ検索と分析手法
- クラウドサービスにおけるログ管理
- ログセキュリティとコンプライアンス
- 実務におけるログ設計の事例
- ログ設計に関するよくある質問
- まとめ：ログ設計でシステム運用を変える
ログ設計とは何か？基礎から理解する
ログ設計は、システムが生成するログをどのように収集・保管・分析するかを計画するプロセスです。適切なログ設計を行うことで、システムの可観測性（Observability）が向上し、障害時の迅速な対応が可能になります。一方で、ログ設計を怠ると、ログが膨大すぎて検索が困難になったり、重要なログが欠落してしまうリスクがあります。
ログの種類とその役割
ログは大きく分けて以下の4つの種類があり、それぞれ異なる目的で利用されます。
| ログの種類 | 主な用途 | 具体例 | 保管期間の目安 |
|---|---|---|---|
| システムログ | OSやミドルウェアの動作状況を監視 | Linuxの/var/log/syslog、WindowsのEvent Log | 30日〜1年 |
| アプリケーションログ | アプリケーションの動作やエラーを追跡 | Webアプリケーションのアクセスログ、データベースのクエリログ | 7日〜30日 |
| セキュリティログ | 不正アクセスやセキュリティイベントの検知 | ファイアウォールのログ、認証ログ（SSH、LDAP） | 1年〜7年（法令による） |
| パフォーマンスログ | システムリソースの使用状況を分析 | CPU使用率、メモリ使用量、ネットワークトラフィック | 7日〜30日 |
例えば、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. ログストレージの階層化
ログを保管する際には、アクセス頻度に応じてストレージを階層化することで、コストを最適化します。
| ストレージ階層 | 用途 | コスト | アクセス速度 |
|---|---|---|---|
| ホットストレージ（SSD） | 直近のログ（1週間以内） | 高 | 高速 |
| ウォームストレージ（HDD） | 1週間〜1ヶ月前のログ | 中 | 中速 |
| コールドストレージ（テープ/オブジェクトストレージ） | 1ヶ月以上前のログ | 低 | 低速 |
例えば、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で探してみましょう。
Amazonアソシエイトプログラムを利用しています。
本記事はRoute Bloom編集部が公式ドキュメント・技術仕様書の一次情報をもとに作成しています。ITインフラ・技術情報は急速に変化するため、実装前に最新の公式ドキュメントをご確認ください。情報の正確性には万全を期していますが、最新情報は各公式サイトをご確認ください。
本記事はRoute Bloom編集部が各ベンダー公式ドキュメント・エンジニア監修をもとに作成しています。インフラ・クラウド構築は環境により異なります。本番環境への適用前に必ずテストを実施してください。情報の正確性には万全を期していますが、最新情報は各公式ドキュメントをご確認ください。
本記事はRoute Bloom編集部が各ベンダー・技術標準の公式ドキュメントをもとに作成しています。 インフラ・クラウド技術に関する最終判断は実際の環境・バージョンで検証のうえ実施してください。 情報の正確性には万全を期していますが、最新情報は各公式ドキュメントをご確認ください。
編集ポリシー：この記事は、Route Bloom の編集チームが最新情報を元に執筆・監修しています。情報の正確性を保つために定期的な見直しを行っています。
