Memcache 개요

이 페이지에서는 App Engine Memcache 서비스의 개요를 제공합니다. 확장 가능한 고성능 웹 애플리케이션은 일부 작업에서 강력한 영구 저장소를 사용하기에 앞서 또는 이 저장소 대신 분산형 메모리 내 데이터 캐시를 사용하는 경우가 많습니다. 이를 위해 App Engine에 메모리 캐시 서비스가 포함되어 있습니다. Memcache 서비스를 구성, 모니터링, 사용하는 방법에 대한 자세한 내용은 Memcache 사용을 참조하세요.

메모리 캐시를 사용하는 경우

메모리 캐시의 용도 중 하나는 일반적인 데이터 저장소 쿼리의 속도를 높이는 것입니다. 여러 요청이 동일한 매개변수를 사용하여 동일한 쿼리를 수행하고 결과 변경사항을 즉시 웹 사이트에 표시할 필요가 없는 경우 애플리케이션이 결과를 Memcache에서 캐시 처리할 수 있습니다. 그런 다음 후속 요청이 Memcache를 확인하여 결과가 없거나 만료된 경우에만 데이터 저장소 쿼리를 수행하면 됩니다. 세션 데이터, 사용자 환경설정, 웹페이지의 쿼리를 통해 반환되는 기타 데이터가 캐시 처리에 적합한 대상입니다.

Memcache는 다른 임시 값에도 유용할 수 있습니다. 하지만 다른 영구 저장소를 사용하지 않고 값을 Memcache에만 저장할지 여부를 고민할 때는 갑자기 값을 사용할 수 없게 되더라도 애플리케이션이 적정 수준으로 동작하는지 확인해야 합니다. 값은 언제든지 Memcache에서 만료될 수 있으며 값에 설정된 만료 기한 전에도 만료될 수 있습니다. 예를 들어 사용자의 세션 데이터가 갑자기 사라지면 세션이 오작동할 경우 해당 데이터를 Memcache 외에 데이터 저장소에도 저장해야 합니다.

서비스 수준

App Engine은 두 가지 수준의 Memcache 서비스를 지원합니다.

  • 공유 Memcache는 App Engine 애플리케이션의 무료 기본값입니다. 이 서비스는 최선의 방식으로 캐시 용량을 제공하며, 공유 Memcache 서비스를 사용하는 모든 App Engine 애플리케이션의 전반적인 요구에 따라 달라질 수 있습니다.

  • 전용 Memcache는 애플리케이션 전용으로 할당되는 고정 캐시 용량을 제공합니다. 캐시 크기의 GB 시간 단위로 요금이 청구되며, 결제가 사용 설정되어 있어야 합니다. 캐시 크기를 제어할 수 있으면 보다 예측 가능한 방식으로 앱을 작동할 수 있고, 비용이 많이 드는 영구 저장소에서의 읽기 수를 줄일 수 있습니다.

두 Memcache 서비스 수준 모두 동일한 API를 사용합니다. 애플리케이션의 Memcache 서비스를 구성하려면 Memcache 사용을 참조하세요.

다음 표에 두 가지 Memcache 서비스의 차이점이 요약되어 있습니다.

기능 전용 Memcache 공유 Memcache
가격 1시간에 GB당 $0.06 무료
용량
us-central
1~100GB
다른 지역
1~20GB
보장되는 용량 없음
성능 GB당 1초에 최대 10,000 읽기 또는 5,000 쓰기(전용)(1KB 미만의 항목). 자세한 내용은 캐시 통계를 참조하세요. 보장되지 않음
영구 저장소 아니요 아니요
SLA 없음 없음

전용 Memcache 요금은 15분 증분 단위로 청구됩니다. USD 외의 통화로 지불하면 Cloud Platform SKU에 해당 통화로 표기된 가격이 적용됩니다.

앱에 Memcache 용량이 더 필요하면 영업팀에 문의하세요.

한도

Memcache 서비스를 사용할 때는 다음과 같은 한도가 적용됩니다.

  • 캐시 처리된 데이터 값의 최대 크기는 1MB(10^6바이트)입니다.
  • 키는 250바이트를 초과할 수 없습니다. Python 런타임에서는 키가 250바이트보다 큰 문자열인 경우 해시 처리됩니다. 다른 런타임은 다르게 동작합니다.
  • '다중' 일괄 작업에 요소를 원하는 만큼 포함할 수 있습니다. 총 호출 크기 및 가져오는 총 데이터 크기는 32MB를 초과하지 않아야 합니다.
  • Memcache 키에 null 바이트를 포함할 수 없습니다.

캐시 처리된 데이터가 만료되는 방식

Memcache에는 키/값 쌍이 포함되어 있습니다. 캐시에서 항목을 쓰고 검색하면 언제든지 메모리에 있는 이 쌍이 변경될 수 있습니다.

기본적으로 Memcache에 저장된 값은 가능한 한 길게 유지됩니다. 새 값이 캐시에 추가되고 캐시의 메모리가 부족해지면 값이 제거될 수 있습니다. 메모리 부족으로 인해 값이 제거될 때는 가장 오래 전에 사용된 값이 먼저 제거됩니다.

앱은 값이 저장될 때 만료 시간을 제공할 수 있습니다. 이는 값이 추가된 시점을 기준으로 하는 시간(초) 또는 미래의 절대 Unix Epoch 시간(1970년 1월 1일 자정을 기준으로 하는 초 단위 시간)일 수 있습니다. 값은 이 시간 전에 제거되며, 다른 이유로 더 일찍 제거될 수도 있습니다. 기존 키에 저장된 값을 늘려도 만료 시간은 업데이트되지 않습니다.

드물지만 메모리 부족 이외의 이유로 만료 전에 캐시에서 값이 사라지는 경우도 있습니다. Memcache는 서버 오류가 발생해도 복원 가능하지만 Memcache 값이 디스크에 저장되지 않으므로 서비스 오류로 인해 값을 사용하지 못하게 될 수 있습니다.

일반적으로 애플리케이션에서는 캐시 처리된 값이 항상 사용 가능한 상태일 것이라고 예상해서는 안 됩니다.

애플리케이션의 전체 캐시는 API를 통해 또는 Google Cloud Platform 콘솔의 Memcache 섹션에서 삭제할 수 있습니다.

캐시 통계

항목 크기별 초당 작업

전용 Memcache의 속도는 GB당 1초에 수행되는 작업을 기준으로 계산됩니다. 여기서 작업은 get, set, delete 등 개별 캐시 항목 액세스로 정의됩니다. 작업 속도는 대략 다음 표에 따라 항목 크기별로 다릅니다. 이 속도를 초과하면 API 지연 시간이 늘어나거나 오류가 발생할 수 있습니다.

다음 표에는 캐시의 GB당 유지되는 전용 get-hit 또는 set 작업의 최대 개수가 나와 있습니다. get-hit 작업은 지정된 키로 저장된 값이 있음을 알아낸 다음 해당 값을 반환하는 get 호출입니다.

항목 크기(KB) 최대 get-hit 작업/초 최대 set 작업/초
≤1 10,000 5,000
100 2,000 1,000
512 500 250

여러 캐시 GB를 사용할 수 있도록 구성된 앱은 이론적으로 GB 수에 GB당 속도를 곱하여 계산되는 집계 작업 속도를 달성할 수 있습니다. 예를 들어 5GB의 캐시를 사용할 수 있도록 구성된 앱은 1KB의 항목에서 초당 50,000개의 Memcache 작업을 수행할 수 있습니다. 이러한 수준을 달성하려면 App Engine Memcache 권장사항에 설명된 대로 Memcache 키스페이스에서 부하를 잘 분산시켜야 합니다.

각 IO 패턴에서 위에 나열된 한도는 읽기 또는 쓰기에 적용됩니다. 동시 읽기 쓰기의 경우에는 한도가 차등 적용됩니다. 즉, 더 많은 수의 읽기 작업이 수행될수록 수행 가능한 쓰기 작업의 수가 줄어들고 그 반대도 마찬가지입니다. 다음 각 항목은 1GB의 캐시당 1KB 값을 동시에 읽고 쓸 때 적용되는 IOP 한도의 예입니다.

읽기 IOP 쓰기 IOP
10000 0
8000 1000
5000 2500
1000 4500
0 5000

MCU(Memcache 컴퓨팅 단위)

Memcache 처리량은 액세스하는 항목의 크기와 항목에서 수행하려는 작업에 따라 달라질 수 있습니다. MCU(Memcache 컴퓨팅 단위)라는 단위를 사용하여 작업 비용을 대략 계산하고 전용 Memcache에서 예상할 수 있는 트래픽 용량을 예측할 수 있습니다. MCU는 전용 Memcache 1GB당 1초에 10,000 MCU를 예상할 수 있도록 정의됩니다. Google Cloud Platform 콘솔에 앱이 현재 사용 중인 MCU가 표시됩니다.

MCU는 대략적인 통계적 추정치이며 선형적 단위가 아닙니다. 값을 읽거나 쓰는 캐시 작업마다 값의 크기에 따라 달라지는 해당 MCU 비용이 있습니다. set의 MCU는 값 크기에 따라 달라지며, 이는 성공한 get-hit 작업 비용의 2배입니다.

값 항목 크기(KB) get-hit의 MCU 비용 set의 MCU 비용
≤1 1.0 2.0
2 1.3 2.6
10 1.7 3.4
100 5.0 10.0
512 20.0 40.0
1024 50.0 100.0

값을 읽거나 쓰지 않는 작업의 MCU 비용은 고정되어 있습니다.

작업 MCU
get-miss 1.0
delete 2.0
increment 2.0
flush 100.0
stats 100.0

get-miss 작업은 지정된 키로 저장된 값이 없음을 알아내는 get입니다.

비교 및 설정

비교 및 설정은 동시에 처리되는 여러 요청이 동일한 Memcache 값을 원자적으로 업데이트할 수 있도록 하여 경합 상태를 방지하는 기능입니다.

비교 및 설정의 핵심 논리적 구성요소

다른 동시 쓰기 요청을 받을 수 있는 Memcache 키의 값을 업데이트하는 경우 Memcache Client 객체를 사용해야 합니다. 이 객체는 비교 및 설정을 지원하는 메소드에 사용되는 특정 상태 정보를 저장합니다. 상태 비추적 함수인 get() 또는 set()는 사용할 수 없습니다. Client 클래스 자체는 threadsafe가 아니므로 둘 이상의 스레드에서 동일한 Client 객체를 사용해서는 안 됩니다.

키를 검색할 때는 비교 및 설정을 지원하는 Memcache Client 메소드(for_cas 매개변수를 True로 설정한 get_multi() 또는 gets())를 사용해야 합니다.

키를 업데이트할 때는 비교 및 설정을 지원하는 Memcache Client 메소드(cas() 또는 cas_multi())를 사용해야 합니다.

다른 핵심 논리적 구성요소로는 App Engine Memcache 서비스와 해당 서비스의 비교 및 설정과 관련된 동작이 있습니다. App Engine Memcache 서비스는 그 자체가 원자적으로 동작합니다. 즉, 동일한 앱 ID에 대해 동시 요청 두 개가 Memcache를 사용할 경우 이러한 요청은 동일한 Memcache 서비스 인스턴스로 이동하며, Memcache 서비스에는 동일한 키에 대한 동시 요청이 적절하게 직렬화되도록 충분한 내부 잠금이 유지됩니다. 특히, 이는 동일한 키에 대한 cas() 요청 두 개가 실제로는 동시에 실행되지 않는다는 것을 의미합니다. Memcache 서비스는 들어오는 첫 번째 요청을 처리하여 완료한 다음(값 및 타임스탬프 업데이트) 두 번째 요청을 처리하기 시작합니다.

Python에서 비교 및 설정을 사용하는 방법에 대한 자세한 내용은 동시 쓰기 처리를 참조하세요.

권장사항

Memcache를 사용할 때 다음과 같은 권장사항을 따르면 좋습니다.

  • Memcache API 오류를 적절하게 처리. Memcache 작업은 다양한 이유로 실패할 수 있습니다. 애플리케이션은 이러한 오류를 최종 사용자에게 노출하지 않고 실패한 작업을 포착하도록 설계되어야 합니다. 이 권장사항은 특히 Set 작업에 적용됩니다.

  • 가능하면 API의 일괄 처리 기능 사용(특히 작은 항목의 경우). 이렇게 하면 앱의 성능과 효율성이 향상됩니다.

  • Memcache 키스페이스에서 부하 분산. 하나 또는 소량의 Memcache 항목을 사용하면 트래픽의 균형이 맞지 않아 앱 확장 기능이 제한됩니다. 이 권장사항은 초당 작업과 대역폭 모두에 적용됩니다. 데이터를 명시적으로 분할하면 이 문제가 완화되는 경우가 많습니다.

    예를 들어 자주 업데이트되는 카운터를 여러 키로 분할하고 합계가 필요할 때만 이를 다시 읽어서 합산할 수 있습니다. 마찬가지로, HTTP 요청이 있을 때마다 읽어야 하는 500,000개의 데이터를 여러 키로 분할한 다음 단일 일괄 API 호출을 사용하여 다시 읽을 수 있습니다. 값을 인스턴스 메모리에서 캐시 처리하면 더 좋습니다. 전용 Memcache의 경우 단일 키에서의 최대 액세스 속도가 GB당 속도보다 한두 자릿수 더 느려야 합니다.

여러 프로그래밍 언어 간에 Memcache를 공유하는 것을 포함하여 동시 실행, 성능, 이전에 대한 자세한 내용과 추가 권장사항을 보려면 App Engine Memcache 권장사항 문서를 참조하세요.

다음 단계

이 페이지가 도움이 되었나요? 평가를 부탁드립니다.

다음에 대한 의견 보내기...

App Engine standard environment for Python 2