memcached를 적용하여 사이트 성능 향상
데이터베이스 및 데이터 소스에서부터 읽기 감소
요약： 오픈 소스 memcached 도구는 디스크나 데이터베이스와 같이 상대적으로 속도가 느린 소스에서부터 정보를 로드하는 것(및 처리하는 것)을 방지하도록 자주 사용하는 정보를 저장하기 위한 캐시입니다. 이는 전용 상황에서나 기존 환경에서 여유 메모리를 다 사용하는 메소드 중 하나로 배치할 수 있습니다. memcached의 간결성에도 불구하고 이는 때때로 올바르지 않게 사용되거나 잘못된 환경 유형에서 솔루션으로 사용됩니다. memcached 사용을 최상으로 활용하는 시점에 대해 알아봅시다.
memcached는 애플리케이션 프로세스의 속도를 높이는 데 사용된다. 여기에서는 사용자의 애플리케이션과 환경 내에서 이를 배치하기 위한 모범 사례에 주목할 것이다. 이는 저장해야 하는 것과 저장하지 말아야 할 것, 데이터의 유연한 분배를 처리하는 방법 및 데이터의 memcached로 저장된 버전을 업데이트하기 위한 메소드를 규제하는 방법이 포함된다. 또한 IBM WebSphere® eXtreme Scale을 비롯한 고가용성 솔루션의 지원에 대해서도 다룰 것이다.
모든 애플리케이션, 특히 많은 수의 웹 애플리케이션은 정보에 액세스하여 클라이언트에 리턴하는 속도를 최적화해야 한다. 하지만, 동일한 정보가 자주 리턴된다. 데이터 소스(데이터베이스 또는 파일 시스템)로부터 데이터를 로드하는 것은 비효율적이며, 정보에 액세스하려 할 때마다 궁극적으로 동일한 쿼리를 실행한다면 특히 비효율적이다.
비록 많은 수의 웹 서버는 정보를 다시 보내기 위해 캐시를 사용하도록 구성할 수 있지만, 이는 대부분 애플리케이션의 동적인 특성과 함께 작동하지 않는다. 이러한 점에서 memcached가 유용할 수 있다. 이는 네이티브 언어객체를 포함하여 모든 것을 보유할 수 있는 일반화된 메모리 저장소를 제공하여, 사용자는 다양한 정보를 저장할 수 있으며 많은 애플리케이션과 환경에서부터 액세스할 수 있다.
memcached는 많은 서버에서 여유 RAM을 활용하도록 설계된 오픈 소스 프로젝트로서, 자주 액세스하는 정보에 대해 메모리 캐시로서 작동한다. 핵심 요소는 캐시(cache)라는 단어의 사용이다. 즉, memcached는 아무 곳에서부터 로드할 수 있는 정보의 임시 스토리지를 메모리 내에 제공한다.
예를 들어, 일반적인 웹 기반 애플리케이션을 살펴보자. 동적으로 동작하는 웹 사이트 조차도 대개 페이지의 사용 내내 일부 컴포넌트나 정보 상수가 있다. 블로그 내에서 개별 블로그 포스트를 위한 카테고리의 목록은 페이지 보기 사이에 정기적으로 변경될 가능성이 낮다. 쿼리를 통해 데이터베이스로 이 정보를 매번 로드하는 것은, 특히 데이터가 변경되지 않을 때에는 비교적 비용이 많이 든다. 그림 1에서 블로그 내에서 캐시될 수 있는 일부 페이지 단편을 볼 수 있다.
그림 1. 일반적인 블로그 페이지의 캐시 가능한 요소
이 구조를 블로그, 게시자 정보, 설명의 — 블로그 자체를 포스트하는 경우에도 — 다른 요소로 추론한다. 단지 홈페이지의 내용을 표시하기 위해서 발생하는 10-20개의 데이터베이스 쿼리와 포맷팅을 식별할 수 있다. 이를 매일 수 백 또는 수 천 번 이상의 페이지 보기로 반복하면, 사용자의 서버 및 애플리케이션은 페이지 내용을 표시하는 데 필요한 것보다 훨씬 더 많은 쿼리를 실행할 것이다.
memcached를 사용하면 데이터베이스에서부터 로드된 포맷된 정보를 웹 페이지에서 직접 사용이 가능한 형태로 저장할 수 있다. 그리고 정보가 데이터베이스와 다른 처리를 통해 디스크에서부터가 아니라 RAM에서부터 로드되었기 때문에, 정보로의 액세스도 거의 동시적이다.
다시 반복하면, memcached는 디스크나 데이터베이스와 같이 상대적으로 속도가 느린 소스에서부터 정보를 로드하고 처리하는 것을 방지하도록 자주 사용하는 정보를 저장하기 위한 캐시이다.
memcached로의 인터페이스는 네트워크 연결을 통해 제공된다. 이는 여러 클라이언트와 함께 단일 memcached 서버(또는 이 기사의 후반부에서 시연할 여러 서버)를 공유할 수 있다는 뜻이다. 네트워크 인터페이스는 빠르고, 성능을 향상시키기 위해 서버는 의도적으로 인증 또는 보안 통신을 지원하지 않는다. 하지만 이로 인해 배치 옵션을 제한해서는 안 된다. memcached 서버는 네트워크의 내부에 존재해야 한다. 네트워크 인터페이스가 실용적이고 memcached 인스턴스를 여러 개 배치하기 쉬워서 여러 장비에서 여분의 램을 활용할 수 있고 캐시 전체 크기를 늘릴 수 있다.
memcached를 사용하는 스토리지 메소드는 많은 언어에 사용 가능한 해시 또는 연관 배열과 유사한 단순한 키워드/값 쌍이다. 키와 값을 제공하여 정보를 memcached로 저장하고, 지정된 키로 정보를 요청하여 정보를 복구한다.
정보는 다음 중 하나의 경우가 발생하지 않는 한, 캐시에서 영구적으로 보존된다.
- 캐시에 할당된 메모리가 고갈된다 — 이 인스턴스에서 memcached는 LRU(최근에 가장 적게 사용된) 메소드를 사용하여 캐시에서부터 항목을 제거한다. 최근에 사용되지 않은 항목이 캐시에서부터 삭제되며, 오래된 항목부터 액세스된다.
- 항목이 구체적으로 삭제된다 — 언제나 항목을 캐시에서부터 삭제할 수 있다.
- 항목이 만료된다 — 개별 항목은 만기가 있어서, 키에 대해 저장된 정보가 너무 오래될 가능성이 높을 때에 항목을 캐시에서부터 비울 수 있다.
이러한 상황은 캐시에서의 정보를 최신 상태로 보장하는 애플리케이션 논리와 결합하여 사용할 수 있다. 이러한 내용을 염두에 두고 애플리케이션에서 memcached를 사용하는 최상의 방법에 대해 살펴보자.
애플리케이션 성능을 개선하기 위해 memcached를 사용할 때 수정 가능한 다양한 핵심 프로세스와 단계가 있다.
정보를 로드할 때에 일반적인 시나리오는 그림 2에 표시된다.
그림 2. 표시하기 위해 정보를 로드하는 일반적인 순서
일반적인 경우에 단계는 다음과 같다.
- 하나 이상의 쿼리를 실행하여 데이터베이스에서부터 정보를 로드한다.
- 표시(또는 향후 처리)에 적합한 정보를 포맷한다.
- 포맷된 데이터를 사용하거나 표시한다.
memcached를 사용할 때에 캐시를 수용하기 위해 애플리케이션 논리를 약간 변경할 수 있다.
- 캐시에서부터 정보를 로드하도록 시도한다.
- 정보의 캐시된 버전이 존재하는 경우에 이를 사용한다.
- 존재하지 않는 경우:
- 하나 이상의 쿼리를 실행하여 데이터베이스에서부터 정보를 로드한다.
- 표시 또는 향후 처리에 적합한 정보를 포맷한다.
- 정보를 캐시로 저장한다.
- 포맷된 데이터를 사용한다.
이는 그림 3에 요약되어 있다.
그림 3. memcached를 사용할 때 표시하기 위해 정보 로드
이렇게 하면 데이터의 로딩은 대체적으로 3단계 프로세스가 된다. 즉, 캐시나 데이터베이스에서부터 데이터를 로드하고 적절하게 캐시에 저장하는 것이다.
최초로 이 프로세스가 발생하면, 데이터가 정상적으로 데이터베이스나 다른 소스에서부터 로드되고 memcached로 저장된다. 다음에 정보에 액세스하면 데이터베이스에서부터 로드하는 것이 아니라 memcached에서부터 빼내어 시간과 CPU 사이클을 줄여준다.
이 등식의 다른 쪽은 memcached 내에서 저장될 수 있는 정보를 변경하는 경우, memcached 버전을 업데이트하는 동시에 백엔드 정보를 업데이트하도록 보장하는 것이다. 이는 그림 4에 표시된 일반적인 순서를 그림 5에서의 약간의 수정으로 수정한다.
그림 4. 일반적인 애플리케이션에서 데이터 업데이트 또는 저장
그림 5에서는 memcached를 사용하여 수정된 순서를 보여준다.
그림 5. memcached를 사용할 때 데이터 업데이트 또는 저장
예를 들면, 기본으로 블로그를 사용하여 블로그 시스템이 데이터베이스에서 카테고리의 목록을 업데이트할 때에 업데이트는 이 순서를 따라야 한다.
- 데이터베이스에서 카테고리 목록 업데이트
- 정보 포맷
- 정보를 memcached에 저장
- 정보를 클라이언트에게 리턴
memcached 내에서 스토리지 조작은 원자적이기 때문에, 클라이언트는 부분적인 데이터만 받지 않고 정보가 업데이트되어 이전 버전이나 새 버전을 받게 된다.
대부분의 애플리케이션에서 이 두 개의 조작에 대해 우려해야 한다. 사람들이 사용하는 데이터에 액세스하면 이는 캐시에 자동으로 추가되고 캐시에서 자동으로 업데이트되는 데이터로 변경된다.
memcached를 사용하면서 중요한 고려사항은 캐시 내에 저장한 데이터를 어떻게 조직하고 이름을 지정하는가이다. 이전 블로그 예제에서 분명한 것은 일관된 이름 지정 구조를 사용해야 한다는 것이다. 이렇게 하여 블로그 카테고리, 히스토리 및 기타 정보를 로드할 수 있고, 정보를 로드하거나(및 캐시를 업데이트하거나) 데이터를 업데이트할 때에(및 캐시를 다시 업데이트할 때) 이를 사용할 수 있다.
사용자가 사용하는 정확한 이름 지정 시스템은 특정 애플리케이션에 적합하지만, 일반적으로는 대개 고유 ID 종류를 기반으로 하는 기존 애플리케이션의 유사한 구조를 사용할 수 있다. 이는 데이터베이스에서부터 정보를 빼내거나 정보 콜렉션을 대조할 때에 발생한다.
블로그 포스트를 예제로 사용하여 카테고리의 목록을 category-list 키로 항목에 저장할 수 있다. blogpost-29와 같이 포스트 ID에 대해 하나의 포스트로 연관되는 값을 사용할 수 있는 동시에 항목에 대한 설명은 29가 블로그 포스트 ID인 blogcomments-29에 저장할 수 있다. 이 방법에서는 정보를 식별하는 다른 접두부를 사용하여 엄청나게 다양한 정보를 캐시에 저장할 수 있다.
memcached 키/값 저장소의 간결성(및 보안의 부재)이라는 것은, 동시에 동일한 memcached 서버를 사용하여 다수의 애플리케이션을 지원하려는 경우, 특정 애플리케이션에 속한 데이터를 식별하는 다른 수량사의 형태를 사용하는 것을 고려할 수 있다는 의미이다. 예를 들어, blogapp:blogpost-29와 같은 애플리케이션 접두부를 추가할 수 있다. 키는 자유 형식이기 때문에, 키 이름으로 아무 문자열이나 원하는 대로 사용할 수 있다.
값 저장에 대해서는 캐시에 저장한 정보가 애플리케이션에 적합한지 확인해야 한다. 예를 들어, 블로그 시스템을 사용하면 원시 HTML이 아니라 포스트 정보를 포맷하기 위해 블로그 애플리케이션에서 사용한 오브젝트를 저장하려 할 수 있다. 이는 동일한 기본 구조가 애플리케이션 내에서 여러 장소에 사용되는 경우 더 실용적일 수 있다.
Java™, Perl, PHP 및 기타 등등을 비롯하여 대부분의 언어 인터페이스는 memcached 내에서 스토리지에 대해 언어 오브젝트를 직렬화할 수 있다. 이를 통해 사용자는 애플리케이션 내에서 수동으로 재구성하는 것이 아니라 전체 오브젝트를 저장하고 메모리 캐시에서부터 이후에 복구할 수 있다. 많은 오브젝트 또는 이들이 사용하는 구조는 특정한 종류의 해시 또는 배열 구조를 기반으로 한다. JSP 환경과 JavaScript 환경 사이에 동일한 정보를 공유하려 할 때와 같은 교차언어 환경에서는 JSON(JavaScript Object Notation) 또는 심지어 XML과 같이 아키텍처 중립형 포맷을 사용할 수 있다.
오픈 소스 제품이자 기존 오픈 소스 환경 내에서 작업하도록 개발된 memcached는 광범위한 환경과 플랫폼에서 지원된다. memcached 서버와 통신하기 위한 인터페이스는 다양하여, 종종 모든 언어에 대해 여러 구현으로 나타난다. 일반적인 라이브러리와 툴킷에 대한 참고자료를 확인한다.
지원되는 제공 인터페이스와 환경을 모두 나열할 수는 없지만, 이들은 모두 memcached 프로토콜로 제공되는 기본 API를 지원한다. 이러한 설명은 간결하며, 다른 값을 사용하여 오류를 표시할 수 있는 다른 언어의 컨텍스트 내에서 다루어야 한다. 기본 함수는 다음과 같다.
get(key)— 지정된 키를 저장한 memcached에서부터 정보를 얻는다. 키가 존재하지 않는 경우에 오류를 리턴한다.set(key, value [, expiry])— 캐시에서 ID 키를 사용하여 지정된 값을 저장한다. 키가 이미 존재하는 경우 업데이트된다. 만료 시간은 초 단위이며, 값이 30일(30*24*60*60) 미만인 경우 상대 시간으로 처리되고, 또는 이 값 이상인 경우 절대 시간(에포크)으로 처리된다.add(key, value [, expiry])— 키가 존재하지 않는 경우 캐시에 추가하고, 또는 키가 이미 존재하는 경우 오류를 리턴한다. 이는 키가 이미 존재하는 경우 업데이트하지 않고 명시적으로 새 키를 추가하려고 하는 경우 유용할 수 있다.replace(key, value [, expiry])— 지정된 키의 값을 업데이트하고, 키가 존재하지 않는 경우에 오류를 리턴한다.delete(key [, time])— 캐시에서부터 키/값 쌍을 삭제한다. 시간을 제공하는 경우, 지정된 기간 동안 이 키로 새 값을 추가하는 것이 차단된다. 제한시간을 통해 데이터 소스에서부터 값을 항상 다시 읽도록 보장할 수 있다.incr(key [, value]) — 지정된 키를 하나씩 또는 지정된 값만큼 증분한다. 수적인 값에서만 작동한다.decr(key [, value])— 지정된 키를 하나씩 또는 지정된 값만큼 감소시킨다. 수적인 값에서만 작동한다.flush_all— 캐시에서 모든 현재 항목을 무효화(또는 만료)한다.
예를 들어, Perl에서 기본 연산 세트는 Listing 1에 표시된 대로 처리될 것이다.
Listing 1. Perl에서 기본 연산 세트
use Cache::Memcached;
my $cache = new Cache::Memcached {
'servers' => [
'localhost:11211',
],
};
$cache->set('mykey', 'myvalue');
|
Listing 2에 Ruby에서의 동일한 기본 연산을 보여준다.
Listing 2. Ruby에서 기본 세트 연산
require 'memcache'
memc = MemCache::new '192.168.0.100:11211'
memc["mykey"] = "myvalue"
|
두 개의 예제 모두에서 동일한 기본 구조로, memcached 서버를 설정한 다음에 값을 지정하거나 설정하는 것을 볼 수 있다. Java 기술에서 이를 작동하는 것을 비롯하여 다른 인터페이스도 사용 가능하여, 사용자가 WebSphere 애플리케이션에서 memcached를 사용할 수 있다. memcached 인터페이스 클래스를 통해 Java 오브젝트를 바로 memcached로 직렬화할 수 있기 때문에, 복잡한 구조를 저장하고 로드할 수 있다. WebSphere와 같은 환경에서 배치할 때에 두 가지 사항이 매우 중요하다. 즉, 서비스의 복원성(및 memcached를 사용할 수 없는 경우에 해야 할 일)과 WebSphere eXtreme Scale과 같은 여러 환경이나 애플리케이션 서버를 사용할 때 성능을 개선하기 위해 캐시 스토리지를 증가시키는 방법이다. 다음으로 이러한 문제점을 모두 살펴볼 것이다.
memcached에 대한 가장 일반적인 질문 중 하나는 "캐시를 사용할 수 없을 때 어떠한 일이 발생하는가?"이다. 이전 섹션에서 명확히 한 바와 같이 캐시에서의 정보가 유일한 정보의 소스가 되어서는 안 된다. 다른 위치에서부터 캐시에 저장된 데이터를 로드할 수 있어야 한다.
현실은 애플리케이션의 성능을 저하시키는 캐시로부터 정보에 액세스할 수 없다 하더라도, 이로 인해 애플리케이션의 작동을 중지해서는 안 된다. 다음과 같이 발생 가능한 몇 가지의 시나리오가 있다.
- memcached 서비스가 고장나면, 애플리케이션은 원본 데이터 소스로부터의 정보를 로드하고 필요한 경우 표시하기 위해 포맷하도록 폴백(fall back)해야 한다. 또한 애플리케이션은 memcached에서의 정보를 로드하고 저장하기 위해 계속 시도해야 한다.
- memcached 서버가 다시 사용 가능하게 되면 애플리케이션이 자동으로 데이터를 저장하도록 시도해야 한다. 캐시된 데이터를 강제로 다시 로드해야 할 필요는 없으며, 사용자는 캐시를 정보로 로드하고 채우는 표준 액세스를 사용할 수 있다. 결과적으로 캐시는 가장 일반적으로 사용되는 데이터로 다시 채워진다.
다시 말해서, memcached는 정보의 캐시이고 유일한 소스가 아니다. memcached 서버를 손실하면 memcached 서버가 백업될 때까지 성능이 저하될 수는 있지만, 그렇다고 해서 애플리케이션을 더 이상 쓰지 못하게 되어서는 안 된다. 실제로 memcached 서버가 상대적으로 간결하고, 손상방지(crash-free)가 아니라고 해도 간결성으로 인해 오류가 더 적게 발생한다.
memcached 서버는 네트워크 전체에서 키에 대해 값을 저장하는 캐시에 불과하다. 여러 시스템이 있는 경우, 모든 여유 시스템에 memcached 인스턴스를 설정하여 엄청난 양의 네트워킹된 RAM 캐시 스토리지를 제공하고 싶을 것이다.
이 아이디어를 접하게 되면, 시스템 사이에 키/값 쌍을 복사하는 특정 분배 또는 복제 메커니즘의 종류가 필요하다고 가정하려 할 것이다. 이 접근방식의 문제점은 실제로 사용 가능한 RAM 캐시를 늘리는 것이 아니라 감소시키는 것이다. 그림 6을 살펴보면 각각 memcached 인스턴스로 액세스가 있는 세 개의 애플리케이션 서버가 있음을 볼 수 있다.
그림 6. 여러 memcached 인스턴스의 잘못된 사용
비록 각 memcached 인스턴스의 크기가 1GB(RAM 캐시의 3GB 부여)라고 하더라도 각 애플리케이션 서버가 자체 캐시만 보유하는 경우(또는 memcached 인스턴스 사이에 데이터의 복제가 있는 경우) 전체 설치는 여전히 각 인스턴스에 걸쳐서 1GB의 캐시 복제만 보유할 것이다.
memcached가 네트워크 인터페이스에 걸쳐서 정보를 제공하기 때문에 단일 클라이언트는 memcached 인스턴스에서부터 액세스 권한이 있는 데이터에 액세스할 수 있다. 데이터가 각 인스턴스에 걸쳐서 복사 또는 복제되지 않는 경우, 결과적으로는 그림 7에 표시된 대로 각 애플리케이션 서버에 사용 가능한 3GB RAM 캐시가 나타난다.
그림 7. 여러 memcached 인스턴스의 올바른 사용
이 접근방식의 문제점은 키/값 쌍을 어느 서버에 저장하도록 선택하는 것과 값을 복구하려고 할 때에 어느 memcached 서버와 대화하는지 어떻게 결정하는가이다. 솔루션은 검색 테이블과 같은 복잡도나 memcached 서버가 이 프로세스를 처리할 것이라는 예상을 무시하는 것이다. 그 대신에 memcached 클라이언트는 단순하게 생각해야 한다.
memcached 클라이언트는 이 정보를 판별하기 위해 보유하는 것이 아니라 정보를 저장할 때에 지정한 키에서 단순한 해싱 알고리즘을 사용한다. memcached 서버 목록에서부터 정보를 얻거나 저장할 때에 memcached 클라이언트는 일관된 해싱 알고리즘을 사용하여 키에서부터 수적인 값을 유추한다. 예를 들어 설명하면, mykey 키는 23875 값으로 변환된다. 정보를 저장하는 중이거나 얻는 중이든지 여부와 상관 없이, memcached 서버에서부터 고유 ID를 로드하는 것과 동일한 키를 사용하게 된다. 따라서 이 예제에서 "mykey"는 항상 23875의 값에 해시를 얻게 될 것이다.
두 개의 서버가 있는 경우 memcached 클라이언트는 이 수적인 값에 단순한 계산(예: 계수)을 수행하여 첫 번째나 두 번째로 구성된 memcached 인스턴스에 값을 저장해야 하는지 여부를 결정한다.
값을 저장할 때에 클라이언트는 저장하기 위해 사용된 키와 서버에서부터 해시 값을 결정한다. 값을 얻으면 클라이언트는 키에서부터 동일한 해시 값을 결정하고 정보를 얻기 위해 동일한 서버를 선택한다.
모든 애플리케이션 서버에서 동일한 서버 목록(및 동일한 순서)을 사용하는 경우 모든 애플리케이션 서버는 동일한 키를 저장하거나 검색할지 묻는 경우 동일한 서버를 선택하게 된다. 동일한 1GB의 공간을 복제하는 것이 아니라 현재 3GB의 memcached 공간을 공유하고 있어서, 캐시를 더 많이 사용하도록 부여하여 더 많은 사용자를 위해 애플리케이션의 성능을 개선할 가능성이 높다.
이 프로세스에 복잡도가 있지만(서버를 사용할 수 없는 경우 어떠한 일이 발생하는가와 같이), 문서에서 자세한 정보를 제공한다(참고자료 참조).
memcached는 단순한 도구인데 memcached 인스턴스를 원래 의도와 다른 부적절한 방식으로 사용하고 싶어할 수도 있다.
memcached의 가장 일반적인 잘못된 사용은 아마도 캐시가 아니라 데이터 저장소로서 사용하는 것이다. memcached의 기본 용도는, 그렇지 않았으면 다른 소스에서부터 복구되거나 구성될 수 있는 데이터에 대한 응답 시간을 개선하는 것이다. 예로는 데이터베이스에서부터 정보를 복구하는 것이다(특히, 사용자에게 정보가 표시되기 전에 포맷하거나 조작하는 경우). memcached는 메모리에 이 정보를 저장하도록 설계되어, 데이터가 복구될 때마다 해당 태스크의 반복적인 수행을 방지한다.
애플리케이션을 실행하는 데 필요한 유일한 정보의 소스로 memcached를 사용해서는 안 된다. 즉, 데이터는 항상 다른 소스에서도 끌어올 수 있어야 한다. 또한 memcached는 키/값 저장소에 불과하다는 것을 유의하자. 데이터에 걸쳐 쿼리를 수행하거나 정보를 추출하기 위해 내용 전체에 대해 반복할 수는 없다. 이를 대규모 단위에서 사용하는 데 필요한 데이터의 오브젝트나 블록을 저장하기 위해 사용해야 한다.
데이터베이스에서부터 로드되면서 데이터의 행을 저장하기 위해 memcached를 사용할 수 있다 하더라도 이는 실제로 쿼리 캐싱이며, 대부분의 데이터베이스는 자체의 쿼리 캐싱 메커니즘을 제공한다. 이와 동일한 내용을 파일시스템으로부터의 파일이나 이미지와 같은 다른 오브젝트에 대해서도 적용할 수 있다. 많은 수의 애플리케이션과 웹 서버는 이러한 유형의 작업에 대해 이미 훌륭하게 최적화된 솔루션을 보유하고 있다.
로드하고 포맷한 후에 정보의 전체 블록을 저장하기 위해 memcached를 사용하면 이로부터 더 많은 유용성과 성능 개선을 확보하게 된다. 블로그 예제를 보면, 정보를 저장하는 최상의 지점은 블로그 카테고리를 오브젝트로 포맷한 후이거나 심지어 HTML로 포맷한 이후였다. 그 다음에 memcached에서부터 컴포넌트(블로그 포스트, 카테고리 목록, 포스트 히스토리 등)를 로드하고 완성된 HTML을 다시 클라이언트에게 쓰면 블로그 페이지의 구성을 수행할 수 있다.
최대 성능을 보장하기 위해 memcached는 인증이나 암호화 중 어떠한 형태의 보안도 제공하지 않는다. 이는 사용자의 memcached 서버로의 액세스 권한을 애플리케이션 배치 환경의 동일한 비공개 구역에 두고 처리해야 한다는 의미이다. 보안이 필수인 경우 UNIX® 소켓을 사용하고 현재 호스트 액세스하는 memcached 서버에서 애플리케이션만 허용한다.
이는 유연성과 복원성 및 네트워크에서 여러 시스템에 걸쳐 RAM 캐시를 공유하는 기능이 제거되지만, 이는 이 상황에서 사용자의 memcached 데이터를 보안하는 유일한 솔루션이다.
memcached 인스턴스를 사용해서는 안 되는 사항이 있지만, 그럼에도 불구하고 memcached의 유연성을 무시해서는 안 된다. memcached가 애플리케이션과 동일한 아키텍처 상의 레벨에 있기 때문에, 이를 통합하고 연결하기에 쉽다. 그리고 memcached를 활용하기 위해 애플리케이션을 변경하는 일은 복잡하지 않다. 게다가 memcached가 캐시에 불과하기 때문에, 문제점이 발생할 때에 애플리케이션의 실행을 중지하지 않아도 된다. 올바르게 사용된다면 서버 인프라의 나머지 부분에서 로드를 낮춘다(데이터베이스와 데이터 소스에서부터 읽기 절감). 이는 하드웨어를 더 많이 요구하지 않고도 클라이언트를 더 많이 지원한다는 의미이다.
그러나 이는 단지 캐시에 불과하다는 점을 유의하자!
이 기사에서는 memcached 및 이를 사용하는 최상의 방법에 대해 다루었다. 특히 정보가 저장되는 방법, 합리적인 키를 선택하는 방법 및 저장하기 위해 정보를 선택하는 방법에 대해 살펴보았다. 또한 여러 서버의 사용, memcached 인스턴스가 고장날 때 해야 하는 일과 아마 가장 중요하게도 memcached를 사용하지 않는 방법을 비롯하여 모든 memcached 사용자가 경험하는 일부 키 배치 문제에 대해서도 살펴보았다.
memcached의 성능과 유용성은 오픈 소스 애플리케이션이자 매우 간결하고 쉬운 목표로 되어 있기 때문에, 이 간결성에서부터 나온다. 정보의 광대한 RAM 저장소를 제공하고, 네트워크에서 이를 사용 가능하고 광범위한 다양한 인터페이스와 언어 등을 통해 액세스 가능하게 하여 memcached를 엄청나게 다양한 설치로 통합할 수 있다.
교육
- MySQL memcached 문서는 일반적인 데이터베이스 배치 환경에서 memcached를 사용하는 방법에 대해 많은 정보를 제공한다.
- IBM solidDB product family를 확인하여 IBM의 상용 캐싱 솔루션인 solidDB®에 대해 배워보자.
- developerWorks 팟캐스트에서 소프트웨어 개발자를 위한 흥미로운 인터뷰와 토론을 들을 수 있다.
- developerWorks의 기술 행사 및 웹 캐스트를 통해 최신 정보를 얻을 수 있다.
- Twitter의 developerWorks 페이지를 살펴보자.
- IBM 오픈 소스 개발자에게 유익한 컨퍼런스, 기술 박람회, 웹 캐스트 및 기타 행사를 확인하고 참여하자.
- developerWorks 오픈 소스 영역에서는 오픈 소스 기술을 활용하여 개발 작업을 수행하고 이러한 기술을 IBM 제품과함께 사용하는 데 도움이 되는 사용 정보, 도구 및 프로젝트 업데이트와 가장 인기 있는 기사 및 튜토리얼을 확인할 수 있다.
- My developerWorks 커뮤니티는 매우 다양한 주제를 다루는 일반 커뮤니티로 성공적으로 운영되고 있다.
- 무료로 제공되는 developerWorks On demand demos를 통해 IBM 및 오픈 소스 기술에 대해 배우고 제품 기능을 익히자.
제품 및 기술 얻기
- memcached.org는 memcached에 대한 정보 및 이를 다운로드하고 설치하는 방법을 제공한다.
- Cache::Memcached interface for Perl은 광범위한 인터페이스를 제공한다.
- Java 기술의 경우 com.danga.MemCached class를 사용할 수 있다. 이는 일부 추가적인 장애 복구 및 다수 인스턴스 확장자를 제공한다.
- DVD로 제공되거나 다운로드할 수 있는 IBM 시험판 소프트웨어를 사용하여 후속 오픈 소스 개발 프로젝트를 구현해 보자.
- IBM 제품 평가판을 다운로드하거나 IBM SOA Sandbox의 온라인 시험판을 살펴보고 DB2®, Lotus®, Rational®, Tivoli® 및 WebSphere®의 애플리케이션 개발 도구와 미들웨어 제품을 사용해 볼 수 있다.
토론
- developerWorks 포럼 & 블로그를 통해 developerWorks 커뮤니티에 참여하자.
Martin Brown은 8년 넘게 기술 필자로 활약해왔다. Brown은 다양한 주제를 다루는 수 많은 책을 집필했고 기사를 작성했다. Brown은 펄, 파이썬, 자바(Java™), 자바스크립트, 베이직, 파스칼, 모듈라-2, C, C++, 레볼, gawk, 셸 스크립트, 윈도우(Windows®), 솔라리스, 리눅스, BeOS, 맥 OS X을 비롯하여 웹 프로그래밍, 시스템 관리, 통합에 이르리까지 다양한 개발 언어와 플랫폼을 경험했다. Brown은 마이크로소프트(Microsoft®) SME(Subject Matter Expert)이며 ServerWatch.com, LinuxToday.com, IBM developerWorks에 주기적으로 기고한다. Brown은 또한 컴퓨터월드, 애플 블로그, 기타 사이트에 주기적으로 블로그 기사를 올린다. 연락 주소는 Brown이 운영하는 웹 사이트를 참조하기 바란다.
출처 - http://www.ibm.com/developerworks/kr/library/os-memcached/index.html
'Computer Science > Cache' 카테고리의 다른 글
| EHCache (0) | 2013.02.11 |
|---|---|
| Hazelcast 소개 (0) | 2012.11.06 |
| Memcached 설치 및 사용 방법 (0) | 2012.11.06 |
| Memcached의 확장성 개선 (0) | 2012.11.06 |
| Memcached 구현 소개 (0) | 2012.11.06 |
