レッスン: エラー処理と retry

学習のねらい

Orchestrator-Workers パターンでシステムを構築する際、ワーカーはLLM APIやWebサイトなどの外部サービスと連携することがよくあります。 しかし、これらの外部サービスは常に安定しているとは限りません。ネットワークの一時的な問題、APIのレート制限、サービス側の障害などにより、処理が失敗することは避けられません。 このレッスンでは、外部API連携時のエラーに適切に対処するための Retry (リトライ) 処理の実装方法、システム全体の信頼性を高めるための Graceful Degradation (グレースフルデグラデーション)、そして問題発生時に迅速に対応するための Alert (アラート) 通知について学びます。

外部 API 失敗時の Retry (リトライ)

一時的なネットワーク障害やサービス側の負荷によるエラーは、少し時間を置いてから再試行することで成功する場合があります。 このような状況に対応するために Retry (リトライ) 処理を実装することは非常に有効です。

リトライ処理を実装する際のポイントは以下の通りです。

• 最大リトライ回数 (max_retries): 無限にリトライしないよう、何回まで再試行するかを決めます。通常は3回〜5回程度が目安です。
• 待機時間 (backoff): リトライの間に一定時間待機することで、サービスへの負荷を軽減し、問題が解決する時間を稼ぎます。リトライ回数に応じて待機時間を長くする Exponential Backoff (指数バックオフ) が推奨されます (例: 1秒 -> 2秒 -> 4秒 -> 8秒...)。
• 対象エラーの選択: すべてのエラーに対してリトライするのではなく、一時的なエラー (例: HTTP 5xx エラー、レート制限エラー) のみに限定し、永続的なエラー (例: 入力値不正の HTTP 4xx エラー) は即座に失敗させるようにします。

Pythonでは、tenacityなどのライブラリを使うと、デコレーター (@retry) を使って簡単にリトライ処理を実装できます。

# tenacity を使ったリトライの例
from tenacity import retry, wait_exponential, stop_after_attempt, Retrying

@retry(wait=wait_exponential(multiplier=1, min=4, max=10), stop=stop_after_attempt(5))
def call_external_api():
    print("API を呼び出し中...")
    # ここで外部API呼び出し
    # 一時的なエラーをシミュレート
    import random
    if random.random() < 0.7: # 70%の確率で失敗
        raise ConnectionError("一時的なネットワークエラー")
    print("API 呼び出し成功！")
    return "データ"

# 実行例
try:
    data = call_external_api()
    print(f"取得データ: {data}")
except Exception as e:
    print(f"最終的に失敗しました: {e}")

Graceful Degradation (グレースフルデグラデーション)

リトライしてもタスクが成功しない場合や、一部の機能が利用できない場合に、システム全体が停止するのではなく、限定的な機能で動作を継続する 設計を Graceful Degradation (グレースフルデグラデーション) と呼びます。 これは、「完璧な機能が提供できなくても、できる範囲でユーザーに価値を提供し続ける」という考え方です。

• グレースフルデグラデーションの例:
  • 代替データの利用: ニュース記事の要約が失敗した場合、要約を諦めて元の記事のURLだけをレポートに含める。
  • キャッシュの利用: リアルタイムデータ取得が失敗した場合、前回の成功時のキャッシュデータを利用する。
  • 一部機能の無効化: 高度な分析機能が失敗した場合、基本的な情報提供のみに切り替える。
  • 手動介入の促進: 自動処理が失敗した場合、その部分だけを人間が手動で補完できるようなフローを用意する。

AIシステム、特にLLMは「幻覚 (hallucination)」と呼ばれる誤った情報を生成するリスクや、外部APIの依存性が高いため、グレースフルデグラデーションの設計はシステムの堅牢性を高める上で非常に重要です。

失敗 Alert (アラート) の通知

リトライやグレースフルデグラデーションによって一時的な問題を吸収できたとしても、根本的な問題の解決には担当者の介入が必要です。 そのため、タスクが最終的に失敗した場合や、特定の閾値を超えてエラーが発生した場合に、開発者や運用チームに Alert (アラート) を通知する仕組みを導入しましょう。

• アラートの送信先: Slack、メール、PagerDutyなどの通知サービス。
• アラートに含める情報:
  • どのタスクが失敗したか
  • いつ失敗したか
  • どのようなエラーメッセージか (スタックトレースも含むと良い)
  • 再試行回数
  • 影響範囲 (例: 「週次レポート生成タスクが完全に失敗した」)
• アラートの粒度: すべてのエラーをアラートにするのではなく、本当に人間が介入すべき重要なエラーに絞り込みましょう。過剰なアラートは「アラート疲れ」を引き起こし、本当に重要な通知を見逃す原因になります。

適切なアラートは、問題の早期発見と迅速な対応を可能にし、システム停止時間を最小限に抑えることにつながります。

まとめ

外部APIと連携するAIシステムでは、エラー処理と信頼性向上のための設計が不可欠です。 一時的な問題にはリトライで対処し、完全に失敗する場合にはグレースフルデグラデーションで機能の継続を図りましょう。 そして、最終的な失敗や重要な問題発生時には、適切なアラートで担当者に通知し、迅速な対応を促すことが大切です。