翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
ElastiCache のベストプラクティスとキャッシュ戦略
Amazon ElastiCache の推奨されるベストプラクティスを以下に紹介します。これらに従うと、キャッシュのパフォーマンスと信頼性が向上します。
トピック
TLS が有効なデュアルスタック ElastiCache クラスター
ElastiCache クラスターで TLS が有効になっている場合、クラスター検出関数 (Redis の場合は cluster slots、cluster shards、cluster nodes) または Memcached の場合は config get cluster は、IP ではなくホスト名を返します。次に、IP の代わりにホスト名を使用して ElastiCache クラスターに接続し、TLS ハンドシェイクを実行します。つまり、クライアントは IP 検出パラメータの影響を受けません。TLS が有効なクラスターでは、IP 検出パラメータは優先 IP プロトコルに影響しません。代わりに、使用する IP プロトコルは、DNS ホスト名を解決する際にクライアントがどの IP プロトコルを使用するかによって決まります。
Java クライアント
IPv4 と IPv6 の両方をサポートする Java 環境から接続する場合、後方互換性のために Java はデフォルトで IPv6 よりも IPv4 を優先します。ただし、IP プロトコルプリファレンスは JVM 引数を使用して設定できます。IPv4 を優先するには、JVM は -Djava.net.preferIPv4Stack=true を受け入れ、IPv6 セット -Djava.net.preferIPv6Stack=true を優先します。-Djava.net.preferIPv4Stack=true を設定すると、JVM は IPv6 接続を行わなくなります。Valkey または Redis OSS の場合、これには他の非 Valkey アプリケーションや非 Redis OSS アプリケーションへの接続も含まれます。
ホストレベルの設定
一般に、クライアントまたはクライアントランタイムに IP プロトコルプリファレンスを設定するための構成オプションが提供されていない場合、DNS 解決を実行するとき、IP プロトコルはホストの設定に依存します。デフォルトでは、ほとんどのホストは IPv4 よりも IPv6 を優先しますが、この優先度はホストレベルで設定できます。これは、ElastiCache クラスターへのリクエストだけでなく、そのホストからのすべての DNS リクエストに影響します。
Linux ホスト
Linux では、gai.conf ファイルを変更して IP プロトコルプリファレンスを設定できます。gai.conf ファイルは /etc/gai.conf の下にあります。gai.conf の指定がない場合は、/usr/share/doc/glibc-common-x.xx/gai.conf に /etc/gai.conf にコピーできるサンプルを用意し、デフォルトの設定をコメント解除する必要があります。ElastiCache クラスターに接続するときに IPv4 を優先するように設定を更新するには、クラスター IP を含む CIDR 範囲の優先順位をデフォルトの IPv6 接続の優先順位よりも高く更新します。デフォルトでは、IPv6 接続の優先順位は 40 です。例えば、クラスターが CIDR 172.31.0.0:0/16 のサブネットにあると仮定すると、以下の設定では、クライアントはそのクラスターへの IPv4 接続を優先することになります。
label ::1/128 0 label ::/0 1 label 2002::/16 2 label ::/96 3 label ::ffff:0:0/96 4 label fec0::/10 5 label fc00::/7 6 label 2001:0::/32 7 label ::ffff:172.31.0.0/112 8 # # This default differs from the tables given in RFC 3484 by handling # (now obsolete) site-local IPv6 addresses and Unique Local Addresses. # The reason for this difference is that these addresses are never # NATed while IPv4 site-local addresses most probably are. Given # the precedence of IPv6 over IPv4 (see below) on machines having only # site-local IPv4 and IPv6 addresses a lookup for a global address would # see the IPv6 be preferred. The result is a long delay because the # site-local IPv6 addresses cannot be used while the IPv4 address is # (at least for the foreseeable future) NATed. We also treat Teredo # tunnels special. # # precedence <mask> <value> # Add another rule to the RFC 3484 precedence table. See section 2.1 # and 10.3 in RFC 3484. The default is: # precedence ::1/128 50 precedence ::/0 40 precedence 2002::/16 30 precedence ::/96 20 precedence ::ffff:0:0/96 10 precedence ::ffff:172.31.0.0/112 100
gai.conf の詳細については、Linux のメインページ
Windows ホスト
Windows ホストのプロセスも同様です。Windows ホストの場合は netsh interface ipv6 set prefix CIDR_CONTAINING_CLUSTER_IPS PRECEDENCE LABEL を実行できます。これは Linux ホストで gai.conf ファイルを変更するのと同じ効果があります。
これにより、指定された CIDR 範囲の IPv6 接続よりも IPv4 接続を優先するように優先設定ポリシーが更新されます。例えば、クラスターが 172.31.0.0:0/16 CIDR のサブネット内にあると仮定した場合、netsh interface ipv6 set prefix ::ffff:172.31.0.0:0/112 100 15 を実行すると、次の優先順位表になり、クライアントがクラスターに接続する際に IPv4 を優先することになります。
C:\Users\Administrator>netsh interface ipv6 show prefixpolicies Querying active state... Precedence Label Prefix ---------- ----- -------------------------------- 100 15 ::ffff:172.31.0.0:0/112 20 4 ::ffff:0:0/96 50 0 ::1/128 40 1 ::/0 30 2 2002::/16 5 5 2001::/32 3 13 fc00::/7 1 11 fec0::/10 1 12 3ffe::/16 1 3 ::/96
