이 페이지에서는 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 | 무료 |
| 용량 |
|
용량 보장 없음 |
| 성능 | 항목 크기가 1KB 미만인 경우 GB당 1초에 최대 읽기 10,000회 또는 최대 쓰기 5,000회(전용). 자세한 내용은 캐시 통계를 참조하세요. | 보장되지 않음 |
| 영구 저장소 | 아니요 | 아니요 |
| SLA | 없음 | 없음 |
전용 Memcache 요금은 15분 단위로 청구됩니다. USD 외의 통화로 지불하는 경우 Cloud Platform SKU에 해당 통화로 표기된 가격이 적용됩니다.
앱에 Memcache 용량이 더 필요하면 영업팀에 문의하세요.
한도
Memcache 서비스를 사용할 때는 다음과 같은 한도가 적용됩니다.
- 캐시된 데이터 값의 최대 크기는 1MiB(2^20바이트)에서 키 크기와 구현별로 달라지는 약 73바이트의 오버헤드를 뺀 값입니다.
- 키는 250바이트보다 클 수 없습니다. Go 런타임에서 Memcache를 더 큰 키로 설정하려고 시도하면 오류가 발생합니다. 다른 런타임은 다르게 동작합니다.
- '멀티' 일괄 작업에 포함될 수 있는 요소 수에는 제한이 없습니다. 총 호출 크기 및 가져오는 총 데이터 크기는 32MB를 초과할 수 없습니다.
- Memcache 키에 null 바이트를 포함할 수 없습니다.
추천 및 권장사항
Memcache를 사용할 때는 애플리케이션을 다음과 같이 설계하는 것이 좋습니다.
캐시된 값을 항상 사용할 수 없는 경우를 처리합니다.
- Memcache는 내구성 있는 스토리지가 아닙니다. 제거 정책에 따라 캐시가 가득 차면 키가 삭제됩니다. 캐시 구성 변경 또는 데이터 센터 유지보수 등으로 인해 캐시 중 일부 또는 전체가 플러시될 수도 있습니다.
- Memcache를 일시적으로 사용할 수 없게 될 수 있습니다. Memcache 작업은 캐시 구성 변경 또는 데이터 센터 유지보수 이벤트를 비롯한 다양한 이유로 실패할 수 있습니다. 실패한 작업을 포착하되 이러한 오류를 최종 사용자에게 노출하지 않도록 애플리케이션을 설계해야 합니다. 이 안내는 특히 Set 작업에 적용됩니다.
가능한 경우 API의 일괄 처리 기능을 사용합니다.
- 이렇게 하면 특히 작은 항목의 경우 앱의 성능과 효율성이 향상됩니다.
Memcache 키스페이스 전반에 부하를 분산하세요.
Memcache 항목 수가 너무 적거나 하나뿐이면 트래픽의 균형이 맞지 않아 앱을 확장하는 데 문제가 생깁니다. 이 권장사항은 초당 작업 수와 대역폭 모두에 적용됩니다. 데이터를 명시적으로 샤딩하면 이 문제가 완화되는 경우가 많습니다.
예를 들어 자주 업데이트되는 카운터를 여러 키로 분할하고 합계가 필요한 경우에만 다시 읽어서 합산할 수 있습니다. 마찬가지로 HTTP 요청이 있을 때마다 읽어야 하는 데이터 500,000개를 여러 키로 분할하고 일괄 API를 한 번 호출하여 다시 읽을 수 있습니다. 값을 인스턴스 메모리에 캐시하면 더 좋습니다. 전용 Memcache의 경우 단일 키의 최대 액세스 속도는 GB당 속도보다 1~2배 느립니다.
캐시에서 값을 가져오려면 자체 키를 보관하세요.
- Memcache는 키를 나열하는 방법을 제공하지 않습니다. 캐시 특성으로 인해 캐시를 중단하지 않고는 키를 나열할 수 없습니다. 또한 Python, 해시 긴 키, 원본 키 등 일부 언어는 애플리케이션에만 알려집니다.
캐시된 데이터 만료 방법
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 구성, 모니터링, 사용 방법에 대해 알아보세요.
- Memcache API 참조 확인