ElastiCache ベストプラクティスとキャッシュ戦略

Amazon の推奨ベストプラクティスを以下に示します ElastiCache。これらに従うと、キャッシュのパフォーマンスと信頼性が向上します。

トピック

• 全体的なベストプラクティス
• サポートされている Valkey、Redis、OSSおよび Memcached コマンド
• Valkey と Redis OSSの設定と制限
• IPv6 Valkey、Redis、OSSMemcached のクライアント例
• クライアントのベストプラクティス (Valkey と Redis OSS）
• クライアントのベストプラクティス (Memcached)
• TLS 有効なデュアルスタック ElastiCache クラスター
• Valkey と Redis の予約済みメモリの管理 OSS
• Valkey および Redis OSSの独自設計クラスターを使用する際のベストプラクティス
• Memcached のキャッシュ戦略

TLS 有効なデュアルスタック ElastiCache クラスター

TLS が ElastiCache クラスターで有効になっている場合cluster slots、クラスター検出関数 (、、Redis cluster nodesの場合は ) cluster shardsまたは ではなく config get cluster Memcached リターンホスト名IPs。その後、ホスト名は の代わりにクラスターIPsに接続 ElastiCache し、TLSハンドシェイクを実行します。つまり、クライアントは IP 検出パラメータの影響を受けません。TLS 有効なクラスターの場合、IP Discovery パラメータは優先 IP プロトコルには影響しません。代わりに、使用される IP プロトコルは、DNSホスト名を解決するときにクライアントがどの IP プロトコルを優先するかによって決まります。

Java クライアント

IPv4 と の両方をサポートする Java 環境から接続する場合IPv6、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 プロトコルはホストの設定によって異なります。デフォルトでは、ほとんどのホストは IPv6 よりも優先されますIPv4が、この設定はホストレベルで設定できます。これは、 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時に優先する設定を更新するには、クラスターを含むCIDR範囲の優先順位IPsをデフォルトのIPv6接続の優先順位よりも高く更新します。デフォルトでは、IPv6接続の優先順位は 40 です。例えば、クラスターが 172.31.0.0:0/16 CIDR のサブネットにあると仮定すると、以下の設定により、クライアントはそのクラスター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範囲IPv4の接続よりもIPv6接続を優先するように設定ポリシーが更新されます。例えば、クラスターが 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