mixi 사례 연구

mixi는 서비스 제공 초기 단계에서memcached를 사용했다.사이트 방문량이 급격히 증가함에 따라 단순히 데이터베이스에 슬레이브를 추가하는 것만으로는 수요를 만족시킬 수 없기 때문에memcached를 도입했다.그 밖에 우리도 확장성을 높이는 방면에서 검증을 하여memcached의 속도와 안정성이 모두 수요를 만족시킬 수 있음을 증명하였다.현재memcached는mixi 서비스에서 매우 중요한 구성 부분이 되었다.
그림 1 현재 시스템 구성 요소

서버 구성 및 수량

mixi는 데이터베이스 서버, 응용 서버, 사진 서버, 역방향 프록시 서버 등 많은 서버를 사용했다.memcached만 해도 200대에 가까운 서버가 실행되고 있다.memcached 서버의 일반적인 구성은 다음과 같습니다.
CPU:Intel Pentium 4 2.8GHz
메모리: 4GB
하드 드라이브: 146GB SCSI
운영 체제: Linux(x86_64)
이 서버들은 이전에 데이터베이스 서버 등에 사용되었다.CPU 성능이 향상되고 메모리 가격이 하락함에 따라 우리는 데이터베이스 서버, 응용 서버 등을 성능이 더욱 강하고 메모리가 더 많은 서버로 적극적으로 바꾸었다.이렇게 하면mixi가 전체적으로 사용하는 서버 수의 급격한 증가를 억제하고 관리 원가를 낮출 수 있다.memcached 서버는 CPU를 거의 차지하지 않기 때문에 교체된 서버를memcached 서버로 사용합니다.

memcached 프로세스

모든memcached 서버는memcached 프로세스만 시작합니다.memcached에 할당된 메모리는 3GB이며 시작 매개 변수는 다음과 같습니다.

/usr/bin/memcached -p 11211 -u nobody -m 3000 -c 30720

x86_ 사용64 운영 체제이므로 2GB 이상의 메모리를 할당할 수 있습니다.32비트 운영 체제에서는 프로세스당 최대 2GB 메모리만 사용할 수 있습니다.2GB 이하의 메모리를 여러 개 분배하는 프로세스를 시작하는 것도 고려했지만 서버의 TCP 연결 수가 배로 증가하고 관리도 복잡해지기 때문에mixi는 64비트 운영체제를 통일적으로 사용했다.
또한 서버의 메모리가 4GB이지만 3GB만 분배된 것은 메모리 분배량이 이 값을 초과하면 메모리 교환(swap)을 초래할 수 있기 때문이다.연재 2회에서 전판은memcached의 메모리 저장소인'slab allocator'에 대해 설명했다. 당시memcached가 시작될 때 지정한 메모리 분배량은memcached가 데이터를 저장하는 양이며,'slab allocator'자체가 차지하는 메모리와 데이터를 저장하기 위한 관리 공간을 포함하지 않는다고 말했다.따라서memcached 프로세스의 실제 메모리 분배량이 지정한 용량보다 크다는 점은 주의해야 한다.
mixi가memcached에 저장된 데이터는 대부분 비교적 작다.이렇게 하면 프로세스의 크기가 지정된 용량보다 훨씬 크다.따라서 우리는 메모리 분배량을 반복적으로 바꾸어 검증하여 3GB의 크기가 swap을 일으키지 않는다는 것을 확인했다. 이것이 바로 현재 응용되고 있는 수치이다.

memcached 사용 방법 및 클라이언트

현재mixi의 서비스는 200대 정도의memcached 서버를pool로 사용하고 있습니다.서버당 용량이 3GB이면 전체에 600GB에 가까운 거대한 메모리 데이터베이스가 생긴다.클라이언트 라이브러리는 본 연재에서 여러 차례 언급한 차의 Cache::Memcached::Fast를 사용하여 서버와 상호작용을 합니다.물론 캐시의 분포식 알고리즘은 네 번째로 소개한 Consistent Hashing 알고리즘을 사용한다.
Cache::Memcached::Fast – search.cpan.org
응용층에서memcached의 사용 방법은 응용 프로그램을 개발하는 엔지니어가 스스로 결정하고 실현한다.그러나 바퀴의 재조립을 방지하고 Cache::Memcached::Fast의 교훈이 재발하는 것을 방지하기 위해 우리는 Cache::Memcached::Fast의 랩 모듈을 제공하여 사용했다.

CACHE:: MEMCACHED:: F.A.S.T.를 통한 연결 유지

Cache:::Memcached의 경우memcached와의 연결 (파일 핸들) 은Cache:::Memcached 패키지의 클래스 변수에 저장됩니다.mod_perl과 FastCGI 등 환경에서 패키지 내의 변수는 CGI처럼 언제든지 다시 시작하지 않고 프로세스에서 유지됩니다.그 결과memcached와의 연결을 끊지 않고 TCP 연결을 구축할 때의 비용을 줄이는 동시에 짧은 시간 내에 TCP 연결을 반복하고 끊어서 발생하는 TCP 포트 자원의 고갈을 방지할 수 있다.
단, Cache::Memcached::Fast는 이 기능이 없기 때문에 모듈 밖에서 Cache::Memcached::Fast 대상을 클래스 변수에 유지하여 지속적인 연결을 확보해야 합니다.

package Gihyo::Memcached;

use strict;
use warnings;
use Cache::Memcached::Fast;

my @server_list = qw/192.168.1.1:11211 192.168.1.1:11211/;
my $fast;  ##  

sub new {
    my $self  = bless {}, shift;
    if ( !$fast ) {
        $fast = Cache::Memcached::Fast->new({ servers => \@server_list });
    }
    $self->{_fast} = $fast;
    return $self;
}

sub get {
   my $self = shift;
   $self->{_fast}->get(@_);
}

위의 예에서 Cache::Memcached::Fast 객체는 클래스 변수 $fast에 저장됩니다.

공용 데이터 처리 및 REHASH

mixi 홈페이지의 뉴스와 같은 모든 사용자가 공유하는 캐시 데이터, 설정 정보 등 데이터는 많은 페이지를 차지하고 방문 횟수도 매우 많다.이런 조건하에서 접근은 모든memcached 서버에 집중하기 쉽다.접근 집중 자체는 문제가 되지 않지만, 일단 접근 집중된 서버에 고장이 나서memcached가 연결할 수 없게 되면 커다란 문제가 발생한다.
연재 4회에서 언급한 바와 같이,Cache::Memcached는rehash기능을 가지고 있습니다. 즉, 데이터를 저장한 서버에 연결할 수 없는 상황에서hash값을 다시 계산하여 다른 서버에 연결합니다.
하지만 Cache::Memcached::Fast에는 이 기능이 없습니다.그러나 서버 연결이 실패했을 때 단시간 내에 이 서버의 기능을 더 이상 연결하지 않을 수 있다.

my $fast = Cache::Memcached::Fast->new({
    max_failures     => 3,
    failure_timeout  => 1
});

failuretimeout 초 안에 maxfailures 이상의 연결이 실패하면 이memcached 서버에 더 이상 연결하지 않습니다.우리의 설정은 1초에 3회 이상이다.
또한 mixi는 모든 사용자가 공유하는 캐시 데이터의 키 이름에 이름 규칙을 설정합니다. 이름 규칙에 부합되는 데이터는 여러 개의memcached 서버에 자동으로 저장되고 얻을 때 한 개의 서버만 선택합니다.이 함수 라이브러리를 만들면memcached 서버 고장에 더 이상 영향을 주지 않습니다.

memcached 응용 경험

여기까지memcached 내부 구조와 함수 라이브러리를 소개했고 이어서 다른 응용 경험을 소개합니다.

Daemontools를 통해 시작

통상적으로memcached는 상당히 안정적으로 운행되지만,mixi가 현재 사용하고 있는 최신 버전 1.2.5는memcached 프로세스가 죽은 적이 몇 차례 있었다.구조상 몇 대의memcached 고장이 있어도 서비스에 영향을 주지 않지만memcached 프로세스가 죽은 서버에 대해memcached를 다시 시작하면 정상적으로 실행할 수 있기 때문에memcached 프로세스를 감시하고 자동으로 시작하는 방법을 사용합니다.그래서 데몬툴스를 사용했습니다.
Daemontools는 qmail의 저자인 DJB가 개발한 UNIX 서비스 관리 도구 모음으로 슈퍼비스라는 프로그램은 서비스 시작, 정지된 서비스 재개 등에 사용할 수 있다.
daemontools
여기는daemontools의 설치를 소개하지 않습니다.mixi는memcached를 시작하기 위해 다음run 스크립트를 사용했습니다.

#!/bin/sh

if [ -f /etc/sysconfig/memcached ];then
        . /etc/sysconfig/memcached
fi

exec 2>&1
exec /usr/bin/memcached -p $PORT -u $USER  -m $CACHESIZE -c $MAXCONN $OPTIONS

감시하다

mixi는'nagios'라는 소스 감시 소프트웨어를 사용하여memcached를 감시합니다.
Nagios: Home
nagios에서 플러그인을 간단하게 개발할 수 있고memcached의 get,add 등 동작을 상세하게 감시할 수 있습니다.그러나mixi는stats 명령을 통해memcached의 운행 상태만 확인합니다.

define command {
command_name                   check_memcached
command_line                   $USER1$/check_tcp -H $HOSTADDRESS$ -p 11211 -t 5 -E -s 'stats\r
quit\r
' -e 'uptime' -M crit
}

또한 mixi는stats 디렉터리의 결과를 rrdtool을 통해 도형으로 바꾸어 성능 감시를 하고 매일 메모리 사용량을 보고서로 작성하여 메일로 개발자와 공유한다.

memcached의 성능

연재에서 소개한 바와 같이memcached의 성능은 매우 우수하다.우리 미스의 실제 사례를 봅시다.여기에 소개된 도표는 서비스가 사용하는 접근이 가장 집중된memcached 서버입니다.
그림 2 요청 수
그림 3 유량
그림 4 TCP 접속 수
요청 수, 트래픽 및 TCP 접속 수 순으로 위에서 아래로 이동합니다.요청 수는 최대 15000qps이고 데이터는 400Mbps에 달하며 이때 연결 수는 10000개를 넘었다.이 서버는 특별한 하드웨어가 없습니다. 바로 처음에 소개한 일반적인memcached 서버입니다.CPU 사용률은 다음과 같습니다.
그림 5 CPU 사용률
보아하니, 여전히 idle의 부분이 있다.따라서memcached의 성능은 매우 높아 웹 응용 프로그램 개발자로서 임시 데이터나 캐시 데이터를 안심하고 저장할 수 있는 곳이다.

호환 어플리케이션

memcached의 실현과 프로토콜은 매우 간단하기 때문에memcached와 호환되는 실현이 많다.일부 기능이 강한 확장은memcached의 메모리 데이터를 디스크에 써서 데이터의 지속성과 군더더기를 실현할 수 있다.연재 세 번째에 소개된 바와 같이 앞으로memcached의 저장층은 확장 가능한 (pluggable) 이 기능들을 점차적으로 지원할 것이다.
여기서memcached와 호환되는 몇 가지 응용 프로그램을 소개합니다.
repcached:memcached에 복제 (replication) 기능을 제공하는 패치..
Flared: QDBM에 저장합니다.비동기식 복제와fail over 등의 기능을 동시에 실현했습니다..
memcachedb: Berkley DB에 저장합니다.메시지 큐도 이루어졌어요.
Tokyo Tyrant: 데이터를 Tokyo Cabinet에 저장합니다.memcached 프로토콜과 호환될 뿐만 아니라 HTTP를 통해 접근할 수 있습니다..

Tokyo Tyrant 사례

mixi는 상기 호환 응용 프로그램의 Tokyo Tyrant를 사용했습니다.Tokyo Tyrant는 평림이 개발한 Tokyo Cabinet DBM의 네트워크 인터페이스입니다.이것은 자신의 프로토콜이 있지만memcached 호환 프로토콜도 가지고 있으며 HTTP를 통해 데이터 교환도 할 수 있다.Tokyo Cabinet은 데이터를 디스크에 쓰는 구현이지만 속도가 상당히 빠르다.
mixi는 Tokyo Tyrant를 캐시 서버로 사용하지 않고 키 값을 저장하여 조합된 DBMS로 사용합니다.주로 사용자의 마지막 접근 시간을 저장하는 데이터베이스로 사용된다.이것은 거의 모든mixi 서비스와 관련이 있으며, 사용자가 페이지에 방문할 때마다 데이터를 업데이트해야 하기 때문에 부하가 상당히 높다.MySQL의 처리가 매우 무겁고memcached를 단독으로 사용하여 데이터를 저장하면 데이터를 잃어버릴 수 있기 때문에 Tokyo Tyrant를 도입했다.그러나 클라이언트를 재개발할 필요가 없고 Cache::Memcached::Fast만 그대로 사용하면 된다는 것도 장점 중 하나입니다.Tokyo Tyrant에 대한 상세한 정보는 당사의 개발 블로그를 참고하십시오.
mixi Engineers "Blog – Tokyo Tyrant에 따른 고부하 DB 구축
mixi Engineers'블로그 – 도쿄(Cabinet|Tyrant)의 새로운 기능

총결산

이번까지'memcached 전면 분석'시리즈가 끝났다.우리는memcached의 기초, 내부 구조, 분산 알고리즘과 응용 등 내용을 소개했다.읽은 후에 당신이memcached에 흥미를 가지게 된다면 우리의 영광입니다.mixi의 시스템, 응용에 관한 정보는 본사의 개발 블로그를 참고하십시오.읽어주셔서 감사합니다.
다음에서 시작합니다.http://tech.idv2.com/2008/07/31/memcached-005/