하드웨어/OS 구성하기¶

캐싱서비스를 구성하기 위해 제일 먼저 선행되어야 하는 작업은 어떤 서버HW/가상인스턴스를 준비할 것인가? 에 대한 답을 내려야 한다.

Important

정답 서비스 규모에 따라 다르다.

고객이 On-Premise 환경에서 서버를 구매해야 하는 경우라면 가장 가성비가 좋은 서버 를, AWS 환경이라면 AWS 환경구성 를 가이드한다. 이유는 간단하다. 캐싱서비스의 데이터 성격은 DB와 달라 High Availity를 보장하기보다는 Active-Active로 다중화하고 장애가 발생하여도 초기화하여 다시 투입하는 것으로 정상화가 가능하다. 때문에 서비스 규모에 따라 마음 편하게 Scale-In/Out 할 수 있는 구성이 권장된다.

하드웨어 상세구성¶

일반적으로 서버를 구성할 때는 CPU, 메모리, 디스크를 주로 고려한다. 10Gbps급의 높은 성능을 요구하는 서비스라면 각 구성요소가 서비스 특성을 만족해야 원하는 성능을 얻을 수 있다.

Note

보통 헤비(heavy)한 서비스라고 하는 경우 기술적으로 I/O 병목을 의미하는 경우가 많다.

CPU¶

Quad 코어 이상을 권장한다. M2는 Many-Core에 대해 확장성(Scalability)를 가진다. 코어가 많으면 많을수록 초당 처리량은 증가한다. 단, 높은 처리량이 반드시 높은 트래픽을 의미하는 것은 아니다.

../../_images/10g_cpu.jpg — 클라이언트가 많을수록 동시처리량이 높아야 한다.¶

4KB인 파일을 약 26만번을 전송하는 것과 1GB파일을 한번 전송하는 것은 같은 대역폭을 사용한다. CPU선택의 가장 큰 기준은 얼마나 많은 동시접속을 처리하는가이다.

메모리¶

메모리 인덱싱 방식을 사용하므로 4GB이상을 권장한다. ( 메모리 구조 참조) 자주 접근되는 콘텐츠는 항상 메모리에 상주하지만 그렇지 않은 컨텐츠는 디스크에서 로딩한다. 따라서 컨텐츠가 많고 집중도가 낮다면(Long-tail) 디스크 부하 증가로 성능이 저하될 수 있다. 서비스되는 콘텐츠 개수와 상관없이 콘텐츠 크기가 커서 디스크 I/O 부하가 높다면 메모리를 증설하여 부하를 낮출 수 있다.

디스크¶

캐싱서비스라면 OS를 제외하고 최소 3개 이상의 캐싱전용 디스크를 권장한다. 디스크 역시 많으면 많을수록 많은 콘텐츠를 캐싱할 수 있을뿐만 아니라 I/O부하도 분산된다.

../../_images/localcachestorage.png — 항상 OS와 M2는 콘텐츠와 별도의 디스크로 구성한다.¶

일반적으로 OS가 설치된 디스크에 M2을 설치한다. 로그 역시 같은 디스크에 구성하는 것이 일반적이다. 로그는 서비스 상황을 실시간으로 기록하기 때문에 항상 쓰기 부하 가 발생한다.

M2는 디스크를 RAID 0 처럼 사용한다. 성능과 RAID 의 상관여부는 고객 서비스 특성에 따라 달라진다. 하지만 파일 변경이 빈번하지 않고 콘텐츠의 크기가 물리적 메모리 크기보다 훨씬 큰 경우 RAID 를 통한 읽기 속도 향상이 효과적일 수 있다.

NIC¶

매우 신뢰성이 높아 딱히 고려할 필요 없다.

OS¶

OS는 일반적인 64bit 리눅스 구성이라면 동작에 문제가 없다.