참고: Python 2.7은 2024년 1월 31일 지원 종료됩니다. 기존 Python 2.7 애플리케이션을 계속 실행하고 트래픽을 받을 수 있습니다. 그러나 지원 종료 날짜 이후에는 해당 런타임을 사용하는 애플리케이션의 재배포를 App Engine에서 차단할 수 있습니다. 지원되는 최신 Python 버전으로 마이그레이션하는 것이 좋습니다.

기존 번들 서비스용 Memcache API

이 페이지에서는 App Engine Memcache 서비스의 개요를 제공합니다. 확장 가능한 고성능 웹 애플리케이션은 특정 태스크에 대해 분산형 메모리 내 데이터 캐시를 견고한 영구 스토리지 앞에 두거나 아예 대체하여 사용하는 경우가 많습니다. 이를 위해 App Engine에 메모리 캐시 서비스가 포함되어 있습니다. Memcache 서비스를 구성, 모니터링, 사용하는 방법에 대한 자세한 내용은 Memcache 사용을 참조하세요.

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

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

Memcache는 다른 임시 값에도 유용할 수 있습니다. 그러나 다른 영구 스토리지의 지원 없이 Memcache에만 값을 저장할지 여부를 결정할 때는 갑자기 값을 사용할 수 없게 되더라도 애플리케이션 동작에 큰 무리가 없는지를 확인해야 합니다. 값은 언제든지 Memcache에서 만료될 수 있으며 값에 설정된 만료 기한 전에도 만료될 수 있습니다. 예를 들어 사용자의 세션 데이터가 갑자기 사라지면 세션이 오작동할 수 있으므로 데이터를 Memcache뿐만 아니라 Datastore에도 저장하는 것이 좋습니다.

서비스 수준

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

공유 Memcache는 App Engine 애플리케이션에 기본 제공되며 무료입니다. 이 서비스는 최선의 방식으로 캐시 용량을 제공하며, 공유 Memcache 서비스를 사용하는 모든 App Engine 애플리케이션의 전반적인 수요에 따라 용량이 달라질 수 있습니다.
전용 Memcache는 사용자의 애플리케이션에 전용으로 할당된 고정된 캐시 용량을 제공합니다. 캐시 크기의 GB 시간 단위로 요금이 청구되며, 결제가 사용 설정되어 있어야 합니다. 캐시 크기를 마음대로 제어할 수 있으므로, 비용이 많이 드는 영구 스토리지 읽기 작업을 줄이면서 앱의 성능을 예측 가능한 수준으로 유지할 수 있습니다.

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

다음 표에서는 두 가지 Memcache 서비스의 차이점을 요약하여 보여줍니다.

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

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

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

한도

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

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

캐시된 데이터 만료 방법

Memcache에는 키-값 쌍이 포함되어 있습니다. 메모리에 있는 이 쌍은 캐시에서 항목이 기록되고 검색됨에 따라 언제든지 변경될 수 있습니다.

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

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

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

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

API를 사용하거나 Google Cloud 콘솔의 Memcache 섹션에서 애플리케이션의 전체 캐시를 삭제할 수 있습니다.

캐시 통계

항목 크기별 초당 작업 수

전용 Memcache는 GB당 초당 작업 수로 평가되며 작업은 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 작업을 수행할 수 있습니다. 이 수준에 도달하려면 Memcache 키스페이스 전체에 부하를 적절히 분산해야 합니다.

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

읽기 IOP	쓰기 IOP
10000	0
8,000	1000
5000	2500
1000	4500
0	5000

Memcache 컴퓨팅 단위(MCU)

Memcache 처리량은 액세스하는 항목의 크기와 항목에 수행하려는 작업에 따라 달라질 수 있습니다. MCU(Memcache 컴퓨팅 단위)라는 단위를 사용하면 전용 Memcache에 예상되는 작업 비용과 트래픽 용량을 대략적으로 계산할 수 있습니다. MCU는 전용 Memcache GB당 1초에 10,000MCU를 예상할 수 있도록 정의됩니다. Google Cloud 콘솔은 현재 앱에서 사용 중인 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 객체를 사용해야 합니다. 이 객체는 비교 및 설정을 지원하는 메서드에서 사용되는 특정 상태 정보를 저장합니다. Memcache 함수 get() 또는 set()는 스테이트리스(Stateless) 함수이므로 이러한 함수를 사용할 수 없습니다. Client 클래스 자체는 스레드로부터 안전하지 않으므로 동일한 Client 객체를 스레드 두 개 이상에서 사용해서는 안 됩니다.

키를 검색할 경우에는 for_cas 매개변수가 True로 설정된 상태에서 비교 및 설정을 지원하는 Memcache Client 메서드(gets() 또는 get_multi())를 사용해야 합니다.

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

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

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

다음 단계

Memcache 사용에서 Memcache 구성, 모니터링, 사용 방법을 알아봅니다.
Memcache 예시 살펴보기