Microservices Communication Patterns (Saga, Circuit Breaker) · レッスン

Sagaの再試行戦略

指数バックオフやサーキットブレーカーを考慮し、Sagaの各ステップに効果的な再試行機構を設計します。

レッスン 2/411 ステップ

「Sagaの再試行戦略」はCoddyKit上の無料Microservices Communication Patterns (Saga, Circuit Breaker)レッスンです。これはレッスン2/4です。下記で完全なレッスンを無料で読むことができます。その後、ブラウザ内の組み込みコードエディタと24時間対応のAIチューターでハンズオン演習できます。これはMicroservices Communication Patterns (Saga, Circuit Breaker)学習パスの一部であり、ウェブとCoddyKitアプリ全体で進捗が同期されます。 Microservices Communication Patterns (Saga, Circuit Breaker)コースには全4レッスンが含まれています。

このレッスンの一部はまだ翻訳されておらず、英語で表示されています。

Why Retries in Sagas?

When a saga executes, its individual steps often involve calling other microservices. These calls can sometimes fail due to temporary issues like network glitches, service restarts, or brief overloads.

Retry strategies are essential mechanisms that allow saga steps to automatically re-attempt failed operations, helping the overall saga complete successfully despite transient errors.

Basic Retry: Limitations

A simple retry mechanism might just wait a fixed, short period (e.g., 1 second) and then re-attempt the operation. While better than nothing, this approach has limitations:

It can quickly overwhelm a service that is already struggling.
If many services retry at the same fixed interval, it can create a 'retry storm'.
It doesn't adapt to the severity or duration of the failure.

Exponential Backoff Explained

Exponential backoff is a smarter retry strategy. Instead of a fixed delay, it progressively increases the waiting time between successive retries. This gives a failing service more time to recover before being hit again.

Start with a small initial delay (e.g., 100ms).
Double or multiply the delay for each subsequent retry (200ms, 400ms, 800ms...).
This strategy significantly reduces the load on a recovering service.

Exponential Backoff in Action

Let's look at a simple Java example of how exponential backoff increases the delay between retry attempts:

public class RetryExample {
  public static void main(String[] args) throws InterruptedException {
    int maxRetries = 3;
    long initialDelayMs = 100; // Start with 100ms

    for (int i = 0; i < maxRetries; i++) {
      System.out.println("Attempt " + (i + 1) + " at " + System.currentTimeMillis() % 100000 + "ms");
      // Simulate a failing operation
      if (i < maxRetries - 1) {
        System.out.println("Operation failed. Retrying in " + initialDelayMs + "ms...");
        Thread.sleep(initialDelayMs);
        initialDelayMs *= 2; // Double the delay
      } else {
        System.out.println("Operation succeeded!");
      }
    }
  }
}

Adding Jitter to Backoff

Even with exponential backoff, if many services start failing and retrying at the same time, their delays might still synchronize. This can lead to a 'thundering herd' problem where they all retry simultaneously.

Adding jitter (a small, random amount of time) to the calculated backoff delay helps prevent this. It randomizes the exact retry times, spreading out the requests and reducing peak load.

Retries and Circuit Breakers

While retries handle transient failures, sometimes a service is truly down or critically impaired. Continuously retrying such a service is wasteful and can worsen the problem.

This is where circuit breakers come in. A circuit breaker wraps an operation and, if it fails too many times, 'opens the circuit' to prevent further calls to the failing service. This protects the calling service from waiting on a dead resource and gives the failing service time to recover without being hammered by retries.

Circuit Breaker States & Retries

The states of a circuit breaker directly impact retry behavior:

Closed: Operations are allowed. If failures occur, retries (with backoff/jitter) are attempted normally.
Open: The circuit breaker immediately fails any request without attempting the operation. This means no retries are made, saving resources and failing fast.
Half-Open: A limited number of requests are allowed through to test if the service has recovered. If these 'test' requests succeed, the circuit closes; if they fail, it re-opens. Retries can be applied to these test requests.

Customizing Retry Policies

Effective retry strategies are often configurable. Key parameters you can customize include:

Maximum Retries: The absolute limit of how many times an operation should be re-attempted.
Maximum Delay: An upper bound for the backoff delay to prevent excessively long waits.
Timeout: How long to wait for a single attempt of an operation to complete before considering it a failure.
Retryable Exceptions: Defining which types of errors (e.g., network errors vs. business logic errors) should trigger a retry.

Idempotency is Key for Retries

When implementing retries, it's crucial that the operations being retried are idempotent. An operation is idempotent if executing it multiple times has the same effect as executing it once.

For example, if a 'charge credit card' operation is retried, but the original request actually went through, an idempotent design prevents the customer from being charged twice. This is a vital concept for reliable distributed transactions.

Check Your Understanding

Let's test your knowledge on retry strategies in sagas.

対話的なレッスンで答える

Recap: Retry Strategies

In this lesson, we explored crucial retry strategies for robust saga execution. We learned about:

The importance of retries for transient failures in saga steps.
How exponential backoff intelligently increases retry delays.
Adding jitter to prevent synchronized retry storms and the 'thundering herd' problem.
The role of circuit breakers in preventing retries to persistently failing services.
Configurable retry policies and the critical need for idempotent operations.

These techniques are vital for building resilient microservices that can recover from temporary issues and maintain high availability.

無料で開始

AI チューターと学ぶ Microservices Communication Patterns (Saga, Circuit Breaker) — 無料

ブラウザでリアルコードを書いて実行し、24/7 の AI チューターから瞬時にサポートを受け、ウェブまたはアプリで続きから学習できます。

コース: 12
レッスン: 48

無料で学習を始めるコース全体を表示

よくある質問

「Sagaの再試行戦略」レッスンは無料ですか？

はい。「Sagaの再試行戦略」の完全なテキストはこのウェブで無料で読めます。インタラクティブに演習し（組み込みコードエディタと24時間対応のAIチューター）、Microservices Communication Patterns (Saga, Circuit Breaker)コースの残りをアンロックするには、CoddyKit PROにアップグレードしてください。 Microservices Communication Patterns (Saga, Circuit Breaker)コースには全4レッスンが含まれています。

「Sagaの再試行戦略」で何を学びますか？

指数バックオフやサーキットブレーカーを考慮し、Sagaの各ステップに効果的な再試行機構を設計します。ブラウザで直接実行するハンズオンコードでMicroservices Communication Patterns (Saga, Circuit Breaker)を演習し、24時間対応のAIチューターがレッスンを進める中での質問に答えます。

Microservices Communication Patterns (Saga, Circuit Breaker)を始めるのに経験は必要ですか？

事前経験は必要ありません。CoddyKitのMicroservices Communication Patterns (Saga, Circuit Breaker)は初級者から上級者向けに構成されているため、ここから始めるか最初から始めて、自分のペースで進むことができます。これはレッスン2/4です。

「Sagaの再試行戦略」レッスンにはどのくらい時間がかかりますか？

ほとんどのCoddyKitレッスンは約5～10分かかります。各レッスンはコンパクトでインタラクティブなので、着実に進歩し、ウェブとアプリ全体で正確に前回の場所から再開できます。

このMicroservices Communication Patterns (Saga, Circuit Breaker)レッスンでコードを書いて実行できますか？

はい。すべてのMicroservices Communication Patterns (Saga, Circuit Breaker)レッスンに組み込みコードエディタが含まれているため、ブラウザでリアルコードを書いて実行し、即座のAIフィードバックを取得できます。ローカル設定は不要です。

このコースのすべてのレッスン

← Microservices Communication Patterns (Saga, Circuit Breaker)に戻る