翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
転送時の暗号化を有効にする際のベストプラクティス
転送中の暗号化を有効にする前: DNS レコードが適切に処理されていることを確認
注記
このプロセス中に、古いエンドポイントを変更および削除します。エンドポイントを誤って使用すると、Redis OSS クライアントが古いエンドポイントと削除されたエンドポイントを使用してクラスターに接続できなくなる可能性があります。
クラスターが TLS なしから TLS 優先に移行している間、古いノードごとの DNS レコードは保持され、新しいノードごとの DNS レコードは別の形式で生成されます。TLS 対応クラスターは、TLS 対応以外のクラスターとは異なる形式の DNS レコードを使用します。 は、クラスターが暗号化モードで設定されているときに両方の DNS レコードを保持 ElastiCache します。アプリケーションおよびその他の Redis OSS クライアントがそれらを切り替えられるようにすることをお勧めします。TLS 移行プロセス中に、DNS レコードの次の変更が行われます。
転送中の暗号化を有効にした場合に行われる DNS レコードの変更の説明
CME クラスターの場合
クラスターが [転送暗号化モード: 優先] に設定されている場合:
-
TLS が有効になっていないクラスターの元のクラスターエンドポイントはアクティブなままになります。クラスターを TLS 暗号化モード [なし] から [優先] に再設定しても、ダウンタイムは発生しません。
-
クラスターが TLS 優先モードに設定されている場合、新しい TLS Redis OSS エンドポイントが生成されます。これらの新しいエンドポイントは、古いエンドポイントと同じ IP (TLS なし) に解決されます。
-
新しい TLS Redis OSS 設定エンドポイントは、ElastiCache コンソールと
describe-replication-group
API へのレスポンスで公開されます。
クラスターが [転送暗号化モード: 必須] に設定されている場合:
-
TLS が有効になっていない古いエンドポイントは削除されます。TLS クラスターエンドポイントのダウンタイムは発生しません。
-
コンソールまたは
describe-replication-group
APIcluster-configuration-endpoint
から新しい ElastiCache を取得できます。
自動フェイルオーバーが有効または自動フェイルオーバーが無効な CMD クラスターの場合
レプリケーショングループが [転送暗号化モード: 優先] に設定されている場合:
-
TLS が有効になっていないクラスターの元のプライマリエンドポイントとリーダーエンドポイントはアクティブなままです。
-
クラスターが TLS
Preferred
モードに設定されると、新しいプライマリエンドポイントとリーダーエンドポイントが生成されます。この新しいエンドポイントは、古いエンドポイントと同じ IP (TLS なし) に解決されます。 -
新しいプライマリエンドポイントとリーダーエンドポイントは、 ElastiCache コンソールと
describe-replication-group
API へのレスポンスで公開されます。
レプリケーショングループが [転送暗号化モード: 必須] に設定されている場合:
-
古い TLS なしのプライマリエンドポイントとリーダーエンドポイントは削除されます。TLS クラスターエンドポイントのダウンタイムは発生しません。
-
新しいプライマリエンドポイントとリーダーエンドポイント ElastiCacheは、コンソールまたは
describe-replication-group
API から取得できます。
DNS レコードの推奨される使用方法
CME クラスターの場合
-
アプリケーションのコードでは、ノードごとの DNS レコードの代わりにクラスター設定エンドポイントを使用してください。シャードの追加や削除時に変更される可能性があるため、ノードごとの DNS 名を直接使用することはお勧めしません。
-
このプロセス中に変更されるため、アプリケーションでクラスター設定エンドポイントをハードコードしないでください。
-
このプロセス中に変更される可能性があるため、クラスター設定エンドポイントをアプリケーションにハードコードすることは推奨されません。転送中の暗号化が完了したら、
describe-replication-group
API (上記太字で表記) を使用してクラスター設定エンドポイントをクエリし、レスポンスとして取得した DNS をこの時点から使用します。
自動フェイルオーバーが有効になっている CMD クラスターの場合
-
クラスターを TLS なしから TLS 優先に移行すると、古いノードごとの DNS 名が削除され、新しい DNS 名が生成されるため、アプリケーションのコードではノードごとの DNS 名の代わりにプライマリエンドポイントとリーダーエンドポイントを使用してください。将来クラスターにレプリカを追加する可能性があるため、ノードごとの DNS 名を直接使用することはお勧めしません。また、自動フェイルオーバーが有効になっている場合、プライマリクラスターとレプリカのロールは ElastiCache サービスによって自動的に変更されます。これらの変更を追跡しやすくするために、プライマリエンドポイントとリーダーエンドポイントを使用することをお勧めします。最後に、リーダーエンドポイントを使用すると、レプリカからの読み取りをクラスター内のレプリカ間で均等に分散できます。
-
TLS 移行プロセス中に変更される可能性があるため、プライマリエンドポイントとリーダーエンドポイントをアプリケーションにハードコードすることはお勧めしません。TLS 優先への移行が完了したら、 describe-replication-group API を使用してプライマリエンドポイントとリーダーエンドポイントエンドポイントをクエリし、この時点から応答する DNS を使用します。これにより、エンドポイントの変更を動的に追跡できます。
自動フェイルオーバーが無効になっている CMD クラスターの場合
-
アプリケーションのコードでは、ノードごとの DNS 名の代わりに、プライマリエンドポイントとリーダーエンドポイントを使用します。自動フェイルオーバーが無効になっている場合、自動フェイルオーバーが有効になっているときに ElastiCache サービスによって自動的に管理されるスケーリング、パッチ適用、フェイルオーバー、およびその他の手順は、代わりにユーザーによって実行されます。これにより、さまざまなエンドポイントを手動で追跡することが容易になります。クラスターを TLS なしから TLS 優先に移行する際に、古いノードごとの DNS 名は削除され、新しい DNS 名が生成されるため、ノードごとの DNS 名を直接使用しないでください。これは、TLS 移行中にクライアントがクラスターに接続するために必須です。また、リーダーエンドポイントを使用する場合、レプリカ間で読み取りを均等に分散させ、クラスターにレプリカを追加または削除するときに DNS レコードを追跡できるという利点もあります。
-
TLS 移行プロセス中に変更される可能性があるため、クラスター設定エンドポイントをアプリケーションにハードコードすることは推奨されません。
転送中の暗号化中: 移行プロセスが終了するタイミングに注意
転送中の暗号化モードの変更は、即座に行われるわけではなく、ある程度の時間を要することがあります。これは、大規模なクラスターの場合に特にあてはまります。クラスターが TLS 優先への移行を完了した場合にのみ、TCP 接続と TLS 接続の両方を受け入れてサービスを提供できるようになります。そのため、転送中の暗号化が完了するまでは、クラスターへの TLS 接続を確立しようとするクライアントを作成しないでください。
転送中の暗号化が成功または失敗したときに通知を受け取る方法はいくつかあります (上記のコード例には示されていません)。
-
SNS サービスを使用して暗号化が完了したときに通知を受け取る
-
暗号化が完了するとイベントを発行する
describe-events
API を使用する -
ElastiCache コンソールで暗号化が完了したことを示すメッセージを表示する
暗号化が完了したかどうかを確認するロジックをアプリケーションに実装することもできます。上の例では、クラスターが移行を完了したことを確認する方法をいくつか見てきました。
-
移行プロセスが開始される (クラスターのステータスが「変更中」に変わる) まで待ち、変更が完了する (クラスターのステータスが「使用可能」に戻る) まで待つ
-
describe-replication-group
API をクエリして、クラスターのtransit_encryption_enabled
が [True] に設定されていることを確認する。
転送中の暗号化を有効にした後: 使用するクライアントが正しく設定されていることを確認
クラスターが TLS 優先モードになっている間、アプリケーションはクラスターへの TLS 接続を開き、それらの接続のみを使用する必要があります。これにより、転送中の暗号化を有効にしてもアプリケーションのダウンタイムは発生しません。SSL セクションの Redis OSS 情報コマンドを使用して、Redis OSS エンジンへのより明確な TCP 接続がないことを確認できます。
# SSL ssl_enabled:yes ssl_current_certificate_not_before_date:Mar 20 23:27:07 2017 GMT ssl_current_certificate_not_after_date:Feb 24 23:27:07 2117 GMT ssl_current_certificate_serial:D8C7DEA91E684163 tls_mode_connected_tcp_clients:0 (should be zero) tls_mode_connected_tls_clients:100