はじめに

近年のソフトウェア開発では、システムの大規模化やクラウドサービスの普及に伴い、マイクロサービスアーキテクチャの採用が進んでいます。

マイクロサービスは、システムを独立した小さなサービスに分割することで、開発の柔軟性・スケーラビリティ・耐障害性を高めることができます。
しかし一方で、サービス間通信が複雑化するため、**ログの管理とトレーサビリティ（追跡性）**が課題となります。

本記事では、この「ログ管理の煩雑さ」を解消するために、実践的なベストプラクティスを紹介します。

マイクロサービスのメリットとデメリット

メリット

独立性と柔軟性: サービスごとに開発・デプロイ可能。影響範囲を限定できる。
技術選択の自由: サービスごとに最適な技術スタックを利用可能。
スケーラビリティ: 必要なサービスだけを水平スケールできる。
アジリティ: 小規模なチームが独立して機能追加・改善を進めやすい。

デメリット

リクエストが複数サービスを横断: 単一の処理フローを追うのが困難。
ログの分散: 各サービスが独立してログを出力し、全体像を掴みにくい。
監視の複雑化: サービスが増えるほど、モニタリングや通知設計も複雑に。

実践

想定構成

例として、複数のAWS Lambda関数が連携し、最終的にデータベースや外部SaaSにアクセスする構成を考えます。
この場合、各Lambdaは独立してログを出力するため、単純にCloudWatchを見るだけではリクエスト全体の流れを追いにくくなります。

ログ出力（Python）

基本的な利用方法

標準ライブラリ logging を利用すれば簡単にログを出力可能です。

import logging

logger = logging.getLogger(__name__)
logger.setLevel(logging.INFO)

handler = logging.StreamHandler()
formatter = logging.Formatter(
    '%(asctime)s - %(name)s - %(levelname)s - %(message)s'
)
handler.setFormatter(formatter)
logger.addHandler(handler)

これは小規模なサービスであれば十分ですが、マイクロサービス全体で追跡するには不十分です。

応用編: カスタムロガー & 構造化ログ

複数サービスを横断するリクエストを追跡するには、構造化ログ（JSON形式）と共通のリクエストIDが不可欠です。

import logging, json, os

class JsonFormatter(logging.Formatter):
    def format(self, record):
        log_entry = {
            "timestamp": self.formatTime(record, self.datefmt),
            "level": record.levelname,
            "service": os.getenv("SERVICE_NAME", "unknown"),
            "request_id": getattr(record, "request_id", "N/A"),
            "message": record.getMessage(),
            "details": getattr(record, "details", {})
        }
        return json.dumps(log_entry, ensure_ascii=False)

logger = logging.getLogger(__name__)
logger.setLevel(logging.INFO)
handler = logging.StreamHandler()
handler.setFormatter(JsonFormatter('%Y-%m-%dT%H:%M:%S%z'))
logger.addHandler(handler)

ポイント:

extra引数を活用し、request_idやdetailsを動的に付与する。
JSON形式で出力することで、後段の分析や検索が容易になる。

ログ収集と通知

ログを出力するだけでは不十分で、収集・正規化・通知まで含めて設計する必要があります。

CloudWatch Logs にLambdaごとのログを集約。
Subscription Filter で特定のログを抽出し、別のLambdaへ転送。
正規化とS3集約: JSONフォーマットで整理し、長期保管やAthenaによる分析に備える。
通知連携:
- CloudWatch Alarm → SNS → Slack / PagerDuty
- 例: エラー件数が一定閾値を超えたら即通知

👉 こうした流れを取ると、リアルタイム検知 + 長期分析が両立できます。

分析の実践（CloudWatch Logs Insights）

CloudWatch Logs Insightsを活用すれば、クエリベースで柔軟にログを分析可能です。

サンプルクエリ

サービス別エラー件数

fields @timestamp, service, level
| filter level = "ERROR"
| stats count(*) as error_count by service
| sort error_count desc

リクエストIDでフローを追跡

fields @timestamp, service, message
| filter request_id = "test-request-id-123"
| sort @timestamp asc

特定エラータイプを調査

fields @timestamp, service, details.error_type
| filter level = "ERROR" and details.error_type = "TimeoutError"
| sort @timestamp desc

補足: 実務でさらに有効なポイント

OpenTelemetry導入: 単なるログに加え、分散トレーシング（Trace ID, Span ID）を仕込むと、リクエスト全体の可視化が格段に楽になる。
ELK / OpenSearch 連携: CloudWatchだけでなく、ElasticsearchやOpenSearchにログを転送してダッシュボード可視化。
構造化ログの共通ライブラリ化: チーム内で統一されたフォーマットを持たせると、全サービス横断で解析可能に。
PIIやセキュリティ配慮: ユーザー情報や機密データをそのままログに出さないルールを設けることも重要。

まとめ

マイクロサービスでは、ログが分散するため従来以上に統合的なログ戦略が必要です。

構造化ログ（JSON形式）で統一
共通のリクエストIDを付与
CloudWatchやS3で収集・正規化
Insightsや外部ツールで分析
通知とトレーシングを組み合わせる

これらを組み合わせることで、効率的なログ管理・迅速なトラブルシューティング・システム全体の可観測性向上を実現できます。