Memorystore for Redis Cluster는 TLS 프로토콜 버전 1.2 이상만 지원합니다.
소개
Memorystore for Redis Cluster는 전송 계층 보안(TLS) 프로토콜을 사용하여 모든 Redis 트래픽을 암호화할 수 있습니다. 전송 중인 데이터 암호화가 사용 설정되면 Redis 클라이언트는 안전한 연결을 통해 독점적으로 통신합니다. TLS에 구성되지 않은 Redis 클라이언트는 차단됩니다. 전송 중인 데이터 암호화를 사용 설정한 경우 Redis 클라이언트에서 TLS 프로토콜을 사용할 수 있는지 확인해야 합니다.
전송 중인 데이터 암호화 기본 요건
Redis용 Memorystore에 전송 중인 데이터 암호화를 사용하려면 다음이 필요합니다.
오픈소스 Redis 버전 6.0 이전에는 기본 TLS가 지원되지 않았습니다. 따라서 일부 Redis 클라이언트 라이브러리는 TLS를 지원하지 않습니다. TLS를 지원하지 않는 클라이언트를 사용하는 경우 클라이언트에 TLS를 사용 설정하는 Stunnel 서드 파티 플러그인을 사용하는 것이 좋습니다. Stunnel을 사용하여 Redis 인스턴스에 연결하는 방법의 예시는 Stunnel 및 telnet을 사용하여 Redis 인스턴스에 안전하게 연결하기를 참조하세요.
인증 기관
전송 중인 데이터 암호화를 사용하는 Redis 클러스터에는 클러스터의 머신 인증서를 인증하는 데 사용되는 고유한 인증 기관(CA)이 있습니다. 각 CA는 Redis 인스턴스에 액세스하는 클라이언트에 다운로드하여 설치해야 하는 인증서로 식별됩니다.
인증 기관 순환
CA는 인스턴스 생성 후 10년간 유효합니다. 또한 CA 만료 전에 새 CA를 사용할 수 있게 됩니다.
이전 CA는 만료일까지 유효합니다. 따라서 Redis 인스턴스에 연결되는 클라이언트에 새 CA를 다운로드하여 설치할 수 있는 기간이 제공됩니다.
이전 CA가 만료되면 클라이언트에서 이를 제거할 수 있습니다.
서버 측 인증서 순환은 매주 이루어집니다. 새 서버 인증서는 새 연결에만 적용되며 기존 연결은 순환 중에 활성 상태로 유지됩니다.
전송 중인 데이터 암호화 사용 설정 시 성능 영향
전송 중인 데이터 암호화 기능은 오버헤드 처리와 동시에 데이터를 암호화 및 복호화합니다. 따라서 전송 중인 데이터 암호화를 사용 설정하면 성능이 저하될 수 있습니다. 또한 전송 중인 데이터 암호화를 사용하면 각 추가 연결이 연결된 리소스 비용으로 제공됩니다. 전송 중인 데이터 암호화 사용과 관련된 지연 시간을 확인하려면 전송 중인 데이터 암호화가 사용 설정된 클러스터와 중지된 클러스터로 애플리케이션 성능을 벤치마킹하여 애플리케이션 성능을 비교합니다.
성능 개선 가이드라인
가능하다면 클라이언트 연결 수를 줄입니다. 주문형 단기 연결을 만드는 대신 장기 실행 연결을 설정하여 재사용하세요.
Memorystore 클러스터의 크기를 늘립니다.
Memorystore 클라이언트 호스트 머신의 CPU 리소스를 늘립니다. CPU 수가 더 많은 클라이언트 머신은 더 나은 성능을 제공합니다. Compute Engine VM을 사용하는 경우 컴퓨팅 최적화 인스턴스를 사용하는 것이 좋습니다.
페이로드가 클수록 더 많은 왕복을 요하므로 애플리케이션 트래픽과 관련된 페이로드 크기를 줄입니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-09-04(UTC)"],[],[],null,["# About in-transit encryption\n\nThis page gives an overview of in-transit encryption for Memorystore for Redis Cluster.\n\nFor instructions how to encrypt a connection with in-transit encryption, see [Manage in-transit encryption](/memorystore/docs/cluster/manage-in-transit-encryption).\n\nMemorystore for Redis Cluster only supports TLS protocol versions 1.2 or higher.\n\nIntroduction\n------------\n\nMemorystore for Redis Cluster supports encrypting all Redis traffic using the [Transport Layer Security (TLS)](https://en.wikipedia.org/wiki/Transport_Layer_Security) protocol. When\nin-transit encryption is enabled Redis clients communicate exclusively across a\nsecure connection. Redis clients that are not configured for TLS are\nblocked. If you choose to enable in-transit encryption you are responsible for\nensuring that your Redis client is capable of using the TLS protocol.\n| **Note:** For instances with replicas, replicated data is fully encrypted at the network level based on Google Cloud encryption standards.\n\nIn-transit encryption prerequisites\n-----------------------------------\n\nIn order to use in-transit encryption with Memorystore for Redis, you need:\n\n1. A Redis client that supports TLS or a third-party TLS sidecar\n\n2. [Certificate Authorities](/memorystore/docs/cluster/about-in-transit-encryption#certificate_authorities)\n installed on the client machine accessing your Redis instance\n\nNative TLS was not supported prior to open source Redis version 6.0. As a\nresult, not every Redis client library supports TLS. If you are using a client\nthat does not support TLS, we recommend using the [Stunnel](https://www.stunnel.org/)\nthird-party plugin that enables TLS for your client. See [Securely connecting to a Redis instance using Stunnel and telnet](/memorystore/docs/cluster/connect-cluster-instance#securely_connect_to_a_memorystore_cluster_using_stunnel_and_telnet)\nfor an example of how to connect to a Redis instance with Stunnel.\n\nCertificate Authorities\n-----------------------\n\nA Redis cluster that uses in-transit encryption has unique\nCertificate Authorities (CAs) that are used to authenticate the certificates of\nthe machines in your cluster. Each CA is identified by a certificate that you\nmust download and install on the client accessing your Redis instance.\n| **Note:** CAs are valid for ten years from the date they are created. To ensure service continuity, new CAs must be installed on clients of the Redis instance before the previous CAs expire.\n\n### Certificate authority rotation\n\nCAs are valid for 10 years upon instance creation. In addition, a new CA will\nbecome available prior to CA expiration.\n\nOld CAs are valid until their expiration date. This gives you a window in which\nto download and install the new CA to clients connecting to the Redis instance.\nAfter the old CAs expires you can uninstall them from clients.\n\nFor instructions on rotating the CA, see [Managing Certificate Authority rotation](/memorystore/docs/cluster/manage-in-transit-encryption#manage_certificate_authority_rotation).\n\n### Server certificate rotation\n\nServer-side certificate rotation occurs every week. New server certificates\napply to new connections only, and existing connections remain alive during\nrotation.\n\nPerformance impact of enabling in-transit encryption\n----------------------------------------------------\n\nThe in-transit encryption feature encrypts and decrypts data, which comes with\nprocessing overhead. As a result, enabling in-transit encryption can reduce\nperformance. Also, when using in-transit encryption, each additional connection\ncomes with as associated resource cost. To determine the latency associated with\nusing in-transit encryption, compare application performance by benchmarking\napplication performance with both a cluster that has in-transit encryption\nenabled and a cluster that has it disabled.\n\n### Guidelines for improving performance\n\n- Decrease the number of client connections when possible. Establish and reuse\n long-running connections rather than creating on-demand short-lived\n connections.\n\n- Increase the size of your Memorystore cluster.\n\n- Increase the CPU resources of the Memorystore client host\n machine. Client machines with a higher CPU count yields better performance. If\n using a Compute Engine VM, we recommend compute optimized instances.\n\n- Decrease the payload size associated with application traffic because larger\n payloads require more round trips."]]
