다중성 확보

다중화에 대한 실제적인 얘기를 하자면 AP 서버에서는 확장성을 생각하는 방식과 마찬가지로 서버 여러 대를 늘어놓는게 기본이 된다. 서버를 늘어놓을 때 중요한 것은 1대나 2대 정도 정지하더라도 충분히 처리할 수 있도록 처리능력을 확보해두는 것이다.

서버는 다양한 요인으로 멈춘다. 예를 들면 엔지니어가 서버 프로세스를 중지한 채로 잊어버리는 것과 같이 인위적인 실수에서부터 서버가 물리적으로 고장 났다거나 메모리에 이상이 생겨 멈춘다거나 다양한 상황이 있다.

이에 대한 대응으로 로드밸런서로 페일오버(failover, 장애극복), 페일백(failback, 정상복귀)하여 고장난 서버를 자동적으로 분리하고, 서버가 복구되면 원상태로 복귀시키는 작업을 수행하고 있다.

페일오버는 자동으로 분리되는 것, 페일백은 정상이되면 복귀시키는 처리를 말한다. 로드밸런서는 서버에 대해 주기적으로 헬스체크를 하고 있으며, AP 서버나 DB 서버가 살았있는지 여부를 판정하고 있다.

다중성 확보

DB 서버도 마찬가지로 서버를 여러 대 나열해서 1,2 대 정지하더라도 충분한 처리능력이 있도록 해두는 것이 중요하다. 또한 마스터의 다중화도 수행하고 있다.

멀티 마스터는 구체적으로 말하면 쌍방으로 레플리케이션, 즉 서로가 서로의 슬레이브가 되는 상태로 해두고 한쪽에 쓰기작업을 하면 다른 한쪽으로 전달하고 반대쪽에 쓰더라도 다른 쪽으로 전달하는, 양방향 레플리케이션 방법이다.

다만 MySQL은 실제로 한쪽에 쓰기작업을 하면 반대쪽으로 전달되는 흐름이기 때문에 약간이나마 징녀이 있다. 따라서 밀리초 단위로 보면 데이터가 일치하지 않는 상태가 항상 존재한다. 이 타이밍에 한쪽이 다운되어 분리되면 DB로 쓰기작업을 하려던 AP 서버에서 볼 때, 쓰기 작업을 하려고 헀던 것이 실제로는 쓰이지 않는 등의 모순이 발생하는 경우가 생겨서 동기가 맞지 않는 리스크가 항상 존재한다.

엔티프라이즈에서는 이 부분에 대한 대책으로서 레플리에키션을 동기적으로 처리함으로써 대처하고 있다. 이에 따라 슬레이브까지 쓰여졌다는 것을 확인한 다음에 클라이언트에 결과를 반환하다록 할 수 있다. 이 경우에 동기는 확실하게 담보될 수 있지만 성능면에서는 큰 손실이 발생한다. 따라서 웹 서비스에서는 동기가 맞지 않는 리스크에 대해서 어느 정도 받아들임으로써 성능을 중시하는 경우가 많다.

멀티 마스터

멀티 마스터는 최근 수년 내 MySQL 서버 구축에 있어 주류가 되었다. 페일오버에 대해 구체적인 동작을 설명하자면 VRRP(Virtual Roouter Redendancy Protocol)라는 프로토콜로 감시하고 있다. VRRP에 의해 한쪽이 분리된 것을 알게되면 자신이 Active 마스터로 승격한다.

멀티 마스터 구성에서 서버는 기본적으로 2대가 있으며, Active/Standby 구성을 하고 있다. Active/Standby 구성이라는 것은 한쪽은 Active이고 다른 한쪽은 Standby가 되어 기본적으로 항상 Active 쪽만 쓰기작업을 하는 구성이다. Active인 서버가 다운되면 Standby였던 쪽이 Active로 승격해서 새로운 마스터가 되고, 다운된 서버는 수작업으로 복구시켜서 다시 Standby로 되돌리던가 다시 원래의 Active/Standby 구성으로 되돌린다. 덧붙여서, 이 Active/Standby 변환에서 사용되고 있는 VRRP는 원래 라우터용으로 개발된 프로토콜이다.

외부에서 어느 쪽 서버가 Active인지를 판단하기 위해서 Virtual IP, 이른바 가상 IP 주소(VIP)를 사용하고 있다. Active쪽에 원래 할당되어 있는 IP주소 (실제 IP 주소)와는 별도로 서비스용 가상 IP주소를 부여하고 있다.

예를들면 두 서버에 '0.1', '0.2'라는 주소가 부여되었다고 하면, 새롭게 '0.3'이라는 가상 IP 주소를 Active 쪽에 할당한다. Active 쪽이 0.1이었다고 하면 Active 쪽에서는 0.1과 0.3 두 주소로 엑세스할 수 있다. AP 서버에서는 0.3을 서비스에 사용하도록 하고 있으며, 분리되는 타이밍에 새로운 Active 쪽에 0.3을 재부여한다. 이러헥 함으로써 Ap 서버에서 보면 항상 0.3으로 액세스함으로써 Active 마스터로 액세스할 수가 있으므로 마스터 전환이 AP 서버 입장에서는 은폐되어 있다. 즉, 0.3이라는 가상 서버가 항상 살아있는 상태가 유지되는 구성이다.

다중성 확보 - 스토리지 서버

하테나에서는 이미지 파일과 같은 미디어 파일을 저장하기 위한 분산 스토리지 서버로 MogileFS를 사용하고 있다. 분산 파일 시스템으로 사용함으로써 대량의 파일을 보존할 수 있는 확장성과 일부 서버가 다운되더라도 전체 장애가 되지 않도록 다중성을 확보할 수 있다.

트래커, 스토리지 노드, 메타 정보를 저장하는 트래커 DB 라는 세 가지 요소로 구성되어 있다. 실제 파일은 스토리지 노드에 위치하며, 특정 URL에 대한 실제 파일의 위치를 나타내는 메타 정보를 DB로 관리하는 형태의 심플한 설계로 되어있다.