기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

실패한 활동 재시도

잠시 연결이 끊기는 등 일시적인 이유로 활동이 실패하는 경우가 가끔 있습니다. 딴 때는 활동이 성공할 수 있으므로 많은 경우 활동 실패를 처리하는 적절한 방법은 활동을 재시도하는 것입니다. 시도 횟수는 여러 번이 될 수 있습니다.

활동 재시도와 관련해 다양한 전략이 있지만, 워크플로의 세부 내용에 따라 가장 좋은 전략이 무엇인지 결정됩니다. 그러한 전략은 다음과 같은 세 가지 기본 범주로 구분됩니다.

다음 단원에서는 이러한 전략을 구현하는 방법에 관해 설명합니다. 예시 워크플로 작업자는 모두 단일 활동인 unreliableActivity를 사용하는데, 이 활동에서는 임의로 다음 중 하나를 수행합니다.

성공할 때까지 재시도하는 전략

가장 단순한 재시도 전략은 결국 성공할 때까지 활동 재시도가 실패할 때마다 계속 재시도하는 것입니다. 기본 패턴은 다음과 같습니다.

다음 워크플로에서는 성공할 떄까지 재시도하는 전략을 구현합니다. 이 워크플로 인터페이스는 RetryActivityRecipeWorkflow에서 구현되고 이 워크플로의 진입점인 runUnreliableActivityTillSuccess라는 메서드가 한 개 있습니다. 워크플로 작업자는 RetryActivityRecipeWorkflowImpl에서 다음과 같이 구현됩니다.

public class RetryActivityRecipeWorkflowImpl
    implements RetryActivityRecipeWorkflow {

    @Override
    public void runUnreliableActivityTillSuccess() {
        final Settable<Boolean> retryActivity = new Settable<Boolean>();

        new TryCatch() {
            @Override
            protected void doTry() throws Throwable {
                Promise<Void> activityRanSuccessfully
                    = client.unreliableActivity();
                setRetryActivityToFalse(activityRanSuccessfully, retryActivity);
            }

            @Override
            protected void doCatch(Throwable e) throws Throwable {
                retryActivity.set(true);
            }
        };
        restartRunUnreliableActivityTillSuccess(retryActivity);
    }

    @Asynchronous
    private void setRetryActivityToFalse(
            Promise<Void> activityRanSuccessfully,
            @NoWait Settable<Boolean> retryActivity) {
        retryActivity.set(false);
    }

    @Asynchronous
    private void restartRunUnreliableActivityTillSuccess(
            Settable<Boolean> retryActivity) {
        if (retryActivity.get()) {
            runUnreliableActivityTillSuccess();
        }
    }
}

워크플로는 다음과 같이 작동합니다.

기하급수적 재시도 전략

기하급수적 재시도 전략의 경우 지정된 시간, 즉 N초 후 프레임워크에서 실패한 활동을 다시 실행합니다. 이 시도가 실패하면 프레임워크에서는 2N초 후에, 이어서 4N초 후에 실행하는 식으로 계속해서 활동을 다시 실행합니다. 대기 시간이 상당히 길어질 수 있으므로 일반적으로 무한정 재시도를 계속하는 것보다는 일정 시점에서 중단하는 것이 좋습니다.

프레임워크에서는 다음과 같이 기하급수적 재시도 전략을 구현할 수 있는 세 가지 방식을 제공합니다.

모든 접근 방식에서는 다음 구성 옵션을 지원합니다. 이 옵션에서 시간 값은 초 단위입니다.

다음 단원에서는 기하급수적 재시도 전략을 구현하는 다양한 방법에 관해 설명합니다.

@ExponentialRetry을 이용한 기하급수적 재시도

활동에 대해 기하급수적 재시도 전략을 구현하는 가장 간단한 방법은 인터페이스 정의에서 활동에 대해 @ExponentialRetry 주석을 붙이는 것입니다. 활동이 실패하면 프레임워크에서는 지정된 옵션 값에 따라 재시도 프로세스를 자동으로 처리합니다. 기본 패턴은 다음과 같습니다.

ExponentialRetryAnnotationWorkflow 워크플로 작업자는 @ExponentialRetry 주석을 사용하여 기하급수적 재시도 전략을 구현합니다. 이 작업자는 다음과 같이 인터페이스 정의가 ExponentialRetryAnnotationActivities에 구현되는 unreliableActivity 활동을 사용합니다.

@Activities(version = "1.0")
@ActivityRegistrationOptions(
    defaultTaskScheduleToStartTimeoutSeconds = 30,
    defaultTaskStartToCloseTimeoutSeconds = 30)
public interface ExponentialRetryAnnotationActivities {
    @ExponentialRetry(
        initialRetryIntervalSeconds = 5,
        maximumAttempts = 5,
        exceptionsToRetry = IllegalStateException.class)
    public void unreliableActivity();
}

@ExponentialRetry옵션에서는 다음과 같은 전략을 지정합니다.

이 워크플로 인터페이스는 RetryWorkflow에서 구현되고 이 워크플로의 진입점인 process라는 메서드가 한 개 있습니다. 워크플로 작업자는 ExponentialRetryAnnotationWorkflowImpl에서 다음과 같이 구현됩니다.

public class ExponentialRetryAnnotationWorkflowImpl implements RetryWorkflow {
    public void process() {
        handleUnreliableActivity();
    }

    public void handleUnreliableActivity() {
        client.unreliableActivity();
    }
}

워크플로는 다음과 같이 작동합니다.

IllegalStateException 예외가 발생하여 활동이 실패하면 프레임워크에서는 ExponentialRetryAnnotationActivities에 지정된 재시도 전략을 자동으로 실행합니다.

RetryDecorator 클래스를 이용한 기하급수적 재시도

@ExponentialRetry는 사용하기 간편합니다. 그러나 구성이 정적이고 컴파일 시에 설정되므로 프레임워크에서는 활동이 실패할 때마다 동일한 재시도 전략을 사용합니다. 런타임에 구성을 지정하고 필요에 따라 이를 변경할 수 있게 해주는 RetryDecorator 클래스를 사용하여 더 유연한 기하급수적 재시도 전략을 구현할 수 있습니다. 기본 패턴은 다음과 같습니다.

활동이 실패하면 프레임워크에서는 ExponentialRetryPolicy 객체의 구성에 따라 활동을 재시도합니다. 이 객체를 수정하여 필요에 따라 재시도 구성을 변경할 수 있습니다.

다음 워크플로 구현에서는 RetryDecorator 클래스를 사용하여 기하급수적 재시도 전략을 구현하는 방법을 보여줍니다. 이 구현에서는 @ExponentialRetry 주석이 없는 unreliableActivity 활동을 사용합니다. 이 워크플로 인터페이스는 RetryWorkflow에서 구현되고 이 워크플로의 진입점인 process라는 메서드가 한 개 있습니다. 워크플로 작업자는 DecoratorRetryWorkflowImpl에서 다음과 같이 구현됩니다.

public class DecoratorRetryWorkflowImpl implements RetryWorkflow {
   ...
  public void process() {
      long initialRetryIntervalSeconds = 5;
      int maximumAttempts = 5;
      ExponentialRetryPolicy retryPolicy = new ExponentialRetryPolicy(
              initialRetryIntervalSeconds).withMaximumAttempts(maximumAttempts);

      Decorator retryDecorator = new RetryDecorator(retryPolicy);
      client = retryDecorator.decorate(RetryActivitiesClient.class, client);
      handleUnreliableActivity();
  }

  public void handleUnreliableActivity() {
      client.unreliableActivity();
  }
}

워크플로는 다음과 같이 작동합니다.

활동이 실패하면 프레임워크에서는 1단계에서 지정한 구성에 따라 활동을 재시도합니다.

AsyncRetryingExecutor 클래스를 이용한 기하급수적 재시도

RetryDecorator 클래스에서는 재시도 프로세스 구성과 관련해 @ExponentialRetry보다 더 많은 유연성을 제공하지만, 프레임워크에서는 ExponentialRetryPolicy 객체의 현재 구성에 따라 여전히 재시도를 자동으로 실행합니다. 더 유연한 접근 방식은 AsyncRetryingExecutor 클래스를 사용하는 것입니다. 런타임에 재시도 프로세스를 구성할 수 있게 해줄 뿐 아니라 프레임워크에서는 단순히 활동을 실행하는 대신에 사용자 구현 AsyncRunnable.run 메서드를 호출하여 각 재시도를 실행합니다.

기본 패턴은 다음과 같습니다.

다음 워크플로에서는 AsyncRetryingExecutor 클래스를 사용하여 기하급수적 재시도 전략을 구현하는 방법을 보여줍니다. 이 워크플로에서는 앞서 설명한 DecoratorRetryWorkflow 워크플로 동일한 unreliableActivity 활동을 사용합니다. 이 워크플로 인터페이스는 RetryWorkflow에서 구현되고 이 워크플로의 진입점인 process라는 메서드가 한 개 있습니다. 워크플로 작업자는 AsyncExecutorRetryWorkflowImpl에서 다음과 같이 구현됩니다.

public class AsyncExecutorRetryWorkflowImpl implements RetryWorkflow {
  private final RetryActivitiesClient client = new RetryActivitiesClientImpl();
  private final DecisionContextProvider contextProvider = new DecisionContextProviderImpl();
  private final WorkflowClock clock = contextProvider.getDecisionContext().getWorkflowClock();

  public void process() {
      long initialRetryIntervalSeconds = 5;
      int maximumAttempts = 5;
      handleUnreliableActivity(initialRetryIntervalSeconds, maximumAttempts);
  }
  public void handleUnreliableActivity(long initialRetryIntervalSeconds, int maximumAttempts) {

      ExponentialRetryPolicy retryPolicy = new ExponentialRetryPolicy(initialRetryIntervalSeconds).withMaximumAttempts(maximumAttempts);
      final AsyncExecutor executor = new AsyncRetryingExecutor(retryPolicy, clock);

      new TryCatch() {
          @Override
          protected void doTry() throws Throwable {
              executor.execute(new AsyncRunnable() {
                  @Override
                  public void run() throws Throwable {
                      client.unreliableActivity();
                  }
              });
          }
          @Override
          protected void doCatch(Throwable e) throws Throwable {
          }
      };
  }
}

워크플로는 다음과 같이 작동합니다.

TryCatch 클래스를 사용하여 오류를 처리하는 방법에 관한 자세한 내용은 AWS Flow Framework for Java 예외 단원을 참조하십시오.

사용자 지정 재시도 전략

실패한 활동을 재시도하기 위한 가장 유연한 접근 방식은 사용자 지정 전략으로서, 성공할 때까지 재시도하는 전략과 흡사하게 이 전략에서는 재시도를 실행하는 비동기식 메서드를 반복적으로 호출합니다. 그러나 사용자는 단순히 활동을 다시 실행하는 대신에 연속적인 재시도 실행 여부 및 방법을 결정하는 사용자 지정 로직을 구현합니다. 기본 패턴은 다음과 같습니다.

다음 워크플로에서는 사용자 지정 재시도 전략을 구현하는 방법을 보여줍니다. 이 워크플로에서는 DecoratorRetryWorkflow 및 AsyncExecutorRetryWorkflow 워크플로와 동일한 unreliableActivity 활동을 사용합니다. 이 워크플로 인터페이스는 RetryWorkflow에서 구현되고 이 워크플로의 진입점인 process라는 메서드가 한 개 있습니다. 워크플로 작업자는 CustomLogicRetryWorkflowImpl에서 다음과 같이 구현됩니다.

public class CustomLogicRetryWorkflowImpl implements RetryWorkflow {
  ...
  public void process() {
      callActivityWithRetry();
  }
  @Asynchronous
  public void callActivityWithRetry() {
      final Settable<Throwable> failure = new Settable<Throwable>();
      new TryCatchFinally() {
          protected void doTry() throws Throwable {
              client.unreliableActivity();
          }
          protected void doCatch(Throwable e) {
              failure.set(e);
          }
          protected void doFinally() throws Throwable {
              if (!failure.isReady()) {
                  failure.set(null);
              }
          }
      };
      retryOnFailure(failure);
  }
  @Asynchronous
  private void retryOnFailure(Promise<Throwable> failureP) {
      Throwable failure = failureP.get();
      if (failure != null && shouldRetry(failure)) {
          callActivityWithRetry();
      }
  }
  protected Boolean shouldRetry(Throwable e) {
      //custom logic to decide to retry the activity or not
      return true;
  }
}

워크플로는 다음과 같이 작동합니다.