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

기존 번들 서비스용 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 서비스를 사용할 때는 다음과 같은 한도가 적용됩니다.

캐시된 데이터 값의 최대 크기는 1MiB(2^20바이트)에서 키 크기와 구현별로 달라지는 약 73바이트의 오버헤드를 뺀 값입니다.
키는 250바이트보다 클 수 없습니다. 자바 런타임에서는 250바이트보다 긴 객체 또는 문자열은 해시됩니다. 다른 런타임은 다르게 동작합니다.
'멀티' 일괄 작업에 포함될 수 있는 요소 수에는 제한이 없습니다. 총 호출 크기 및 가져오는 총 데이터 크기는 32MB를 초과할 수 없습니다.
Memcache 키에 null 바이트를 포함할 수 없습니다.

사용 가능한 API

App Engine Memcache는 하위 수준 Memcache API와 JCache 사양이라는 두 가지 인터페이스를 지원합니다. 다음 섹션에서는 각 인터페이스에 대해 자세히 설명합니다.

하위 수준 API

하위 수준 Memcache API는 JCache보다 풍부한 기능을 지원합니다. 예를 들면 다음과 같습니다.

원자적으로 정수 카운터 값 증가 및 감소
더 많은 캐시 통계 노출(예: 가장 오래 전에 사용된 항목이 액세스된 후 경과된 시간, 캐시에 포함된 모든 항목의 총 크기)
조건부 데이터 저장 작업 확인 및 설정
AsyncMemcacheService를 사용하여 비동기식으로 Memcache 작업 수행

하위 수준 API는 Memcache 서비스에 액세스하는 데 필요한 MemcacheService 및 AsyncMemcacheService를 제공합니다. 이 API는 JCache가 제공하는 API보다 기능이 풍부합니다.

하위 수준 Memcache API의 동기식 및 비동기식 사용 예는 Memcache 예제를 참조하세요.

JCache

App Engine 자바 SDK는 JCache API를 지원합니다. JCache는 캐시된 데이터에 대한 맵과 유사한 인터페이스를 제공합니다. 키를 사용하여 캐시에 값을 저장하고 검색하며, 키와 값은 직렬화 가능한 모든 유형 또는 클래스일 수 있습니다. 자세한 내용은 Memcache 사용을 참조하세요.

지원되지 않는 JCache 기능

JCache는 다음과 같은 기능을 지원하지 않습니다.

JCache 리스너 API는 앱의 API 호출을 처리하는 동안에 실행될 수 있는 onPut 및 onRemove와 같은 리스너만 부분적으로 지원합니다. onEvict와 같이 백그라운드 처리를 요구하는 리스너는 지원하지 않습니다.
앱에서 캐시에 특정 키가 포함되어 있는지 여부를 테스트할 수 있지만 캐시에 특정 값이 포함되어 있는지 여부를 테스트할 수 없습니다. 즉, containsValue()는 지원되지 않습니다.
앱에서 캐시의 키 또는 값의 내용을 덤프할 수 없습니다.
앱에서 캐시 통계를 수동으로 재설정할 수 없습니다.
put() 메서드는 키의 알려진 이전 값을 반환하지 않으며 항상 null을 반환합니다.

캐시된 데이터 만료 방법

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

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

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

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

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

API를 사용하거나 Google Cloud Console의 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
10,000	0
8,000	1,000
5,000	2,500
1,000	4,500
0	5,000

Memcache 컴퓨팅 단위(MCU)

Memcache 처리량은 액세스하는 항목의 크기와 항목에 수행하려는 작업에 따라 달라질 수 있습니다. MCU(Memcache 컴퓨팅 단위)라는 단위를 사용하면 전용 Memcache에 예상되는 작업 비용과 트래픽 용량을 대략적으로 계산할 수 있습니다. MCU는 전용 Memcache GB당 1초에 10,000MCU를 예상할 수 있도록 정의됩니다. Google Cloud Console은 현재 앱에서 사용 중인 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 구성, 모니터링, 사용 방법 알아보기