기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
일반적인 ElastiCache 사용 사례 및 ElastiCache 활용 방법
최신 뉴스, 10대 리더보드, 제품 카탈로그를 게재할 때나 이벤트 티켓을 판매할 때 가장 중요한 것은 속도입니다. 웹 사이트와 비즈니스의 성공 여부는 콘텐츠를 제공하는 속도에 상당한 영향을 받습니다.
뉴욕 타임즈의 "For Impatient Web Users, an Eye Blink Is Just Too Long to Wait(참을성 없는 웹 사용자에게는 눈 깜박하는 시간조차 너무 길게 느껴져)
다른 사용자가 데이터를 원할 경우 캐시된 데이터를 훨씬 더 빠르게 제공할 수 있습니다. 웹 페이지든 비즈니스 결정을 주도하는 보고서용이든 이는 동일하게 적용되는 사실입니다. 귀사에서는 웹 페이지를 캐시하지 않고 지연 시간을 최소화하여 제공할 여유가 있습니까?
가장 많이 요청되는 항목을 캐시하려 할 것이라는 사실은 어쩌면 자명한 것일 수 있습니다. 요청 빈도가 낮은 항목을 캐시하려고 하지 않는 이유는 무엇입니까? 가장 최적화된 데이터베이스 쿼리나 원격 API 호출이라 할지라도 인 메모리 캐시에서 플랫 키를 검색하는 것보다 현저히 느려집니다. 현저히 느려지면 고객이 다른 곳으로 떠나는 경향이 있습니다.
다음 예제에서는 ElastiCache를 사용하여 애플리케이션의 전반적인 성능을 개선할 수 있는 몇 가지 방법을 보여줍니다.
인 메모리 데이터 스토어
인 메모리 키-값 스토어의 주된 목적은 지연 시간이 1밀리초 미만인 매우 빠른 속도와 저렴한 비용으로 데이터 복사본에 액세스할 수 있게 하는 것입니다. 대부분의 데이터 스토어에는 자주 액세스하지만 거의 업데이트하지 않는 데이터 영역이 있습니다. 또한 데이터베이스를 쿼리하면 키-값 페어 캐시에서 키를 찾는 것에 비해 확실히 속도가 느리고 비용이 많이 듭니다. 일부 데이터베이스 쿼리는 특히 수행하는 데 있어 많은 비용이 듭니다. 예로는 여러 표에 걸친 조인이나 복잡한 계산이 포함된 쿼리를 들 수 있습니다. 이러한 쿼리 결과를 캐시하여 쿼리 가격을 한 번만 지불합니다. 그런 다음 쿼리를 다시 실행할 필요 없이 여러 번 데이터를 빠르게 검색할 수 있습니다.
어떻게 캐시해야 합니까?
캐시할 데이터를 결정할 때 다음과 같은 요인을 고려합니다.
속도 및 비용 - 캐시가 아닌 데이터베이스에서 데이터를 얻는 것이 항상 더 느리고 비용도 많이 듭니다. 다른 데이터베이스 쿼리에 비해 원래 느리고 비용이 많이 드는 데이터베이스 쿼리도 있습니다. 예를 들어, 여러 테이블에서 조인을 수행하는 쿼리는 간단한 싱글 테이블 쿼리에 비해 훨씬 더 느리고 비용이 많이 소요됩니다. 속도가 느리고 비용이 많이 드는 쿼리를 통해서만 얻을 수 있는 데이터라면 캐시가 필요합니다. 비교적 빠르고 간단한 쿼리로 얻을 수 있는 데이터라도 다른 요인에 따라 캐싱이 필요할 수 있습니다.
데이터 및 액세스 패턴 - 캐시할 항목을 결정할 때는 데이터 자체와 액세스 패턴을 이해해야 합니다. 예를 들어, 빠르게 변하거나 거의 액세스하지 않는 데이터는 캐시할 필요가 없습니다. 캐시를 통해 실질적인 이점을 누리려면 비교적 정적이고 자주 액세스하는 데이터여야 합니다. 소셜 미디어 사이트의 개인 프로필을 예로 들 수 있습니다. 반대로, 캐시해도 속도나 비용이 나아지지 않는다면 데이터를 캐시할 필요가 없습니다. 예를 들어 검색 결과를 반환하는 웹 페이지의 쿼리와 결과는 대부분 고유하기 때문에 그러한 웹 페이지를 캐시하는 것은 의미가 없습니다.
기한 경과 - 정의하자면 캐시된 데이터는 기한이 경과한 데이터입니다. 경우에 따라 데이터 기한이 지나지 않았더라도 언제나 기한이 지난 데이터로 간주하고 취급해야 합니다. 데이터를 캐시할지 여부를 결정할 때는 애플리케이션의 데이터 기한 경과 허용 범위를 확인해야 합니다.
애플리케이션에서 기한이 지난 데이터를 허용할 수 있는 상황도 있고 그렇지 않은 상황도 있습니다. 예를 들어 사이트에서 공개적으로 거래된 주가를 제공한다고 가정합니다. 고객이 가격이 n분 지연될 수 있다는 고지 사항과 함께 어느 정도의 기한이 경과할 수 있음을 받아들일 수 있습니다. 하지만 주식을 매각하거나 매입하는 중개인에게 주식의 가격을 제공할 때는 실시간 데이터가 필요합니다.
다음에 해당하는 경우 데이터 캐시를 고려하세요.
캐시 검색에 비해 느린 속도와 높은 비용으로 데이터를 얻습니다.
사용자가 자주 데이터에 액세스합니다.
데이터가 비교적 동일하게 유지되거나 빠르게 변경되어도 기한 경과가 큰 문제가 되지 않습니다.
자세한 내용은 다음 자료를 참조하세요.
ElastiCache for Redis 사용 설명서의 캐싱 전략
게임 리더보드(Redis 정렬 세트)
Redis 정렬 세트는 리더보드의 컴퓨팅 복잡성을 애플리케이션에서 Redis 클러스터로 옮깁니다.
게임의 상위 10개 점수와 같은 리더보드는 계산적으로 복잡합니다. 이는 특히 동시 플레이어가 많고 점수가 지속적으로 바뀌는 경우에 그렇습니다. Redis 정렬 세트는 고유성 및 요소 순서를 둘 다 보장합니다. Redis 정렬 세트를 사용하면 정렬 세트에 새 요소가 추가될 때마다 실시간으로 순위를 다시 매깁니다. 그다음에 올바른 숫자 순서의 세트에 해당 요소가 추가됩니다.
다음 다이어그램을 통해 ElastiCache for Redis 게임 리더보드가 어떻게 작동하는지 알 수 있습니다.
예 - Redis 리더보드
이 예제에서는 ZADD를 사용하여 게이머 4명과 이들의 점수를 정렬 목록에 입력합니다. ZREVRANGEBYSCORE 명령이 높은 점수에서 낮은 점수 순서로 플레이어를 나열합니다. 그런 다음 ZADD를 사용해 기존의 항목을 덮어써 June의 점수를 업데이트합니다. 마지막으로, ZREVRANGEBYSCORE에서 높은 점수에서 낮은 점수 순서로 플레이어를 나열합니다. 이 목록에서는 June이 순위가 상승했음을 알 수 있습니다.
ZADD leaderboard 132 Robert ZADD leaderboard 231 Sandra ZADD leaderboard 32 June ZADD leaderboard 381 Adam ZREVRANGEBYSCORE leaderboard +inf -inf 1) Adam 2) Sandra 3) Robert 4) June ZADD leaderboard 232 June ZREVRANGEBYSCORE leaderboard +inf -inf 1) Adam 2) June 3) Sandra 4) Robert
다음 명령을 통해 June은 모든 플레이어 중 자신의 순위를 알 수 있습니다. 순위는 0부터 시작하므로 ZREVRANK가 두 번째 위치에 있는 June에 대해 1을 반환합니다.
ZREVRANK leaderboard June 1
자세한 내용은 정렬 세트에 대한 Redis 설명서
메시징(Redis Pub/Sub)
이메일 메시지를 보낼 때 지정된 수신자 한 명 이상에게 메시지가 전송됩니다. pub/sub 패러다임에서는 메시지를 받을 사람을 모르는 상태에서 특정 채널로 메시지를 보냅니다. 메시지를 받는 사람은 채널을 구독하는 사람입니다. 예를 들어 news.sports.golf 채널을 구독한다고 가정해 보겠습니다. news.sports.golf 채널을 구독하는 모든 사람이 news.sports.golf에 게시되는 메시지를 받게 됩니다.
Redis pub/sub 기능은 키 스페이스와 아무 관계가 없으므로 어떤 수준에서도 간섭이 발생하지 않습니다. 다음 다이어그램에는 ElastiCache for Redis 메시징을 설명하는 부분이 있습니다.
구독
채널의 메시지를 받으려면 해당 채널을 구독합니다. 단일 채널, 지정된 여러 채널 또는 패턴에 맞는 모든 채널을 구독할 수 있습니다. 구독을 취소하려면 구독할 때 지정한 채널에서 구독을 취소해야 합니다. 또는 패턴 일치를 사용하여 구독한 경우 이전에 사용했던 패턴과 동일한 패턴으로 구독을 취소합니다.
예 - 단일 채널 구독
단일 채널을 구독하려면 구독할 채널을 지정하는 SUBSCRIBE 명령을 사용하세요. 다음 예제에서는 클라이언트가 news.sports.golf 채널을 구독합니다.
SUBSCRIBE news.sports.golf
얼마 후 클라이언트가 구독을 취소할 채널을 지정하는 UNSUBSCRIBE 명령을 사용하여 채널 구독을 취소합니다.
UNSUBSCRIBE news.sports.golf
예 - 지정된 여러 채널 구독
특정한 여러 채널을 구독하려면 SUBSCRIBE 명령으로 채널을 나열하세요. 다음 예제에서는 클라이언트가 news.sports.golf, news.sports.soccer 및 news.sports.skiing 채널을 구독합니다.
SUBSCRIBE news.sports.golf news.sports.soccer news.sports.skiing
특정 채널 구독을 취소하려면 UNSUBSCRIBE 명령을 사용하고 구독을 취소할 채널을 지정합니다.
UNSUBSCRIBE news.sports.golf
여러 채널의 구독을 취소하려면 UNSUBSCRIBE 명령을 사용하고 구독을 취소할 채널을 지정합니다.
UNSUBSCRIBE news.sports.golf news.sports.soccer
모든 구독을 취소하려면 UNSUBSCRIBE를 사용하고 각 채널을 지정합니다. 또는 UNSUBSCRIBE를 사용하고 채널을 지정하지 않습니다.
UNSUBSCRIBE news.sports.golf news.sports.soccer news.sports.skiing
또는
UNSUBSCRIBE
예 - 패턴 일치를 사용하는 구독
클라이언트는 PSUBSCRIBE 명령을 사용하여 패턴과 일치하는 모든 채널을 구독할 수 있습니다.
다음 예제에서는 클라이언트가 모든 스포츠 채널을 구독합니다. SUBSCRIBE를 사용할 때처럼 모든 스포츠 채널을 개별적으로 나열하는 것은 아닙니다. 대신 PSUBSCRIBE 명령을 사용하여 패턴 일치를 사용합니다.
PSUBSCRIBE news.sports.*
예 구독 취소
이 채널의 구독을 취소하려면 PUNSUBSCRIBE 명령을 사용하세요.
PUNSUBSCRIBE news.sports.*
중요
[P]SUBSCRIBE 명령과 [P]UNSUBSCRIBE 명령에 보낸 채널 문자열이 일치해야 합니다. news.*에 PSUBSCRIBE한 후 news.sports.*에서 PUNSUBSCRIBE하거나 news.sports.golf에서 UNSUBSCRIBE할 수 없습니다.
게시
채널의 모든 구독자에게 메시지를 보내려면 채널과 메시지를 지정하는 PUBLISH 명령을 사용하세요. 다음 예제에서는 "It’s Saturday and sunny. I’m headed to the links." 메시지를 news.sports.golf 채널에 게시합니다.
PUBLISH news.sports.golf "It's Saturday and sunny. I'm headed to the links."
클라이언트는 구독한 채널에 게시할 수 없습니다.
자세한 내용은 Redis 설명서의 Pub/Sub
권장 데이터(Redis 해시)
Redis의 INCR 또는 DECR을 사용하면 컴파일 권장 사항이 단순화됩니다. 사용자가 제품을 "좋아할" 때마다 item:productID:like 카운터가 증가하고 "싫어할" 때마다 item:productID:dislike 카운터가 증가합니다. Redis 해시를 사용하여 제품을 좋아하거나 싫어한 모든 사람의 목록을 보존할 수도 있습니다.
예 - 호불호
INCR item:38923:likes HSET item:38923:ratings Susan 1 INCR item:38923:dislikes HSET item:38923:ratings Tommy -1
기타 Redis 사용
Salvatore Sanfilippo의 블로그 게시글(How to take advantage of Redis just adding it to your stack(단순히 Redis를 스택에 추가하여 Redis를 이용하는 방법)
ElastiCache 고객 추천사
Airbnb, PBS, Esri 등의 기업이 어떻게 Amazon ElastiCache를 활용해 고객 환경을 개선하여 비즈니스 성장을 도모하고 있는지에 관해서는 Amazon ElastiCache 추천사
다른 ElastiCache 고객 사용 사례는 튜토리얼 동영상에서 보실 수 있습니다.
