翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# を使用するためのベストプラクティス AWS SDK for Java 2.x
<a name="best-practices"></a>

## API タイムアウトを設定してリクエストのハングを防止する
<a name="bestpractice5"></a>

SDK は、接続タイムアウトやソケットタイムアウトなど、一部のタイムアウトオプションにはデフォルト値を提供しますが、API コールタイムアウトや個々の API コール試行タイムアウトには[デフォルト値](https://github.com/aws/aws-sdk-java-v2/blob/a0c8a0af1fa572b16b5bd78f310594d642324156/http-client-spi/src/main/java/software/amazon/awssdk/http/SdkHttpConfigurationOption.java#L134)を提供しません。個々の試行とリクエスト全体の両方にタイムアウトを設定するのがグッドプラクティスです。これにより、リクエストの完了までの時間が長くなるような一時的な問題や、致命的なネットワーク上の問題が発生した場合に、アプリケーションが最適な方法で迅速に失敗するようになります。

`[ClientOverrideConfiguration\$1apiCallAttemptTimeout](https://sdk.amazonaws.com/java/api/latest/software/amazon/awssdk/core/client/config/ClientOverrideConfiguration.html#apiCallAttemptTimeout())` と `[ClientOverrideConfiguration\$1apiCallTimeout](https://sdk.amazonaws.com/java/api/latest/software/amazon/awssdk/core/client/config/ClientOverrideConfiguration.html#apiCallTimeout())` を使用して、サービスクライアントが行うすべてのリクエストにタイムアウトを設定できます。

次の例は、カスタムタイムアウト値を使用する Amazon S3 クライアントの設定を示しています。

```
S3Client.builder()
        .overrideConfiguration(
             b -> b.apiCallTimeout(Duration.ofSeconds(<custom value>))
                   .apiCallAttemptTimeout(Duration.ofMillis(<custom value>)))
        .build();
```

**`apiCallAttemptTimeout`**  
この設定では、1 回の HTTP 試行にかかる時間を設定します。この時間が経過すると API コールを再試行できます。

**`apiCallTimeout`**  
このプロパティの値は、すべての再試行を含む実行全体の時間を設定します。

サービスクライアントでこれらのタイムアウト値を設定する代わりに、[https://sdk.amazonaws.com/java/api/latest/software/amazon/awssdk/core/RequestOverrideConfiguration.html#apiCallTimeout()](https://sdk.amazonaws.com/java/api/latest/software/amazon/awssdk/core/RequestOverrideConfiguration.html#apiCallTimeout()) と `[RequestOverrideConfiguration\$1apiCallAttemptTimeout()](https://sdk.amazonaws.com/java/api/latest/software/amazon/awssdk/core/RequestOverrideConfiguration.html#apiCallAttemptTimeout())` を使用して 1 つのリクエストを設定できます。

次の例では、カスタムタイムアウト値を使用して 1 つの `listBuckets` リクエストを設定します。

```
s3Client.listBuckets(lbr -> lbr.overrideConfiguration(
        b -> b.apiCallTimeout(Duration.ofSeconds(<custom value>))
               .apiCallAttemptTimeout(Duration.ofMillis(<custom value>))));
```

これらのプロパティを一緒に使用すると、すべての再試行に費やされる合計時間にハードリミットを設定します。また、低速なリクエストに対して、フェイルファストするよう、個々の HTTP リクエストを設定することもできます。

## サービスクライアントを再利用してパフォーマンスを向上させる
<a name="bestpractice1"></a>

各[サービスクライアント](work-witih-clients.md)は独自の HTTP 接続プールを維持します。プールにすでに存在する接続を新しいリクエストで再利用できるため、新しい接続を確立する時間を短縮できます。効果的に使用されていない接続プールが多すぎることによるオーバーヘッドを避けるため、クライアントの 1 つのインスタンスを共有することをおすすめします。すべてのサービスクライアントはすべてスレッドセーフです。

クライアントインスタンスを共有したくない場合は、クライアントが必要ないときにインスタンスで `close()` を呼び出してリソースを解放してください。

## 未使用のサービスクライアントを閉じてリソースの漏洩を防ぐ
<a name="bestpractice-close-client"></a>

不要になった場合は、[サービスクライアント](work-witih-clients.md)を閉じてスレッドなどのリソースをリリースします。クライアントインスタンスを共有したくない場合は、クライアントが必要ないときにインスタンスで `close()` を呼び出してリソースを解放してください。

## 入力ストリームを閉じて接続プールの枯渇を防ぐ
<a name="bestpractice2"></a>

`[S3Client\$1getObject](https://sdk.amazonaws.com/java/api/latest/software/amazon/awssdk/services/s3/S3Client.html#getObject(java.util.function.Consumer,java.nio.file.Path))` などのストリーミング操作では、`[ResponseInputStream](https://sdk.amazonaws.com/java/api/latest/software/amazon/awssdk/core/ResponseInputStream.html)` を直接操作する場合は、次を実行することをお勧めします。
+ できるだけ早く入力ストリームからすべてのデータを読み取ります。
+ できるだけ早く入力ストリームを閉じます。

このような推奨を行うのは、入力ストリームは HTTP 接続からのデータの直接ストリームであり、ストリームからのデータがすべて読み取られてストリームが閉じられるまで、基盤となる HTTP 接続を再利用できないためです。これらのルールに従わないと、開いているが未使用の HTTP 接続を大量に割り当てて、クライアントがリソースを使い果たす可能性があります。

## アプリケーションワークロードの HTTP パフォーマンスを最適化する
<a name="bestpractice3"></a>

SDK には、一般的なユースケースに適用される[デフォルト HTTP 設定](https://github.com/aws/aws-sdk-java-v2/blob/master/http-client-spi/src/main/java/software/amazon/awssdk/http/SdkHttpConfigurationOption.java)セットが用意されています。お客様には、ユースケースに基づいてアプリケーションの HTTP 構成を調整することをお勧めします。

手始めに、SDK には[スマート設定のデフォルト](http-configuration.md#http-config-smart-defaults)機能が用意されています。この機能は、バージョン 2.17.102 で始めることで使用できます。ユースケースに応じて、適切な設定値が得られるモードを選択します。

## 非同期クライアント用の OpenSSL で SSL パフォーマンスを向上させる
<a name="bestpractice4"></a>

デフォルトでは、SDK の [https://sdk.amazonaws.com/java/api/latest/software/amazon/awssdk/http/nio/netty/NettyNioAsyncHttpClient.html](https://sdk.amazonaws.com/java/api/latest/software/amazon/awssdk/http/nio/netty/NettyNioAsyncHttpClient.html) は JDK のデフォルトの SSL 実装を `SslProvider` として使用します。テストの結果、OpenSSL は JDK のデフォルト実装よりもパフォーマンスが優れていることがわかりました。Netty コミュニティでは [OpenSSL の使用も推奨しています](https://netty.io/wiki/requirements-for-4.x.html#tls-with-openssl)。

OpenSSL を使用するには、依存関係に `netty-tcnative` を追加します。設定の詳細については、「[Netty プロジェクトのドキュメント](https://netty.io/wiki/forked-tomcat-native.html)」を参照してください。

プロジェクト用に `netty-tcnative` を設定すると、`NettyNioAsyncHttpClient` インスタンスは自動的に OpenSSL を選択します。または、次のスニペットに示すように、`NettyNioAsyncHttpClient`ビルダーを使用して明示的に `SslProvider` を設定することもできます。

```
NettyNioAsyncHttpClient.builder()
                        .sslProvider(SslProvider.OPENSSL)
                        .build();
```

## SDK メトリクスを使用してアプリケーションのパフォーマンスをモニタリングする
<a name="bestpractice6"></a>

SDK for Java は、アプリケーションのサービスクライアントの[メトリクスを収集](metrics.md)できます。これらのメトリクスを使用して、パフォーマンスの問題を特定したり、全体的な使用傾向を確認したり、返されたサービスクライアントの例外を確認したり、特定の問題を掘り下げて理解したりすることができます。

アプリケーションのパフォーマンスをより深く理解するために、メトリクスを収集して Amazon CloudWatch Logs を分析することをお勧めします。