Facebook geographic distributed architecture

페이스북의 경우 DR(재해 복구)와 로드 밸런싱의 목적으로 미국내에 서부와 동부 두군데에 IDC를 유지합니다.

이렇게 두개 이상의 다른 장소에 시스템을 배포하는 것 구조를 geographic distributed architecture라고 합니다. 이러한 아키텍쳐에 있어서 가장 중요한점은

IDC간의 데이타 동기화,라우팅 그리고 성능 향상을 위한 캐슁입니다.

라우팅은 REQUEST가 들어왔을때, 어느 IDC로 보낼것인가를 결정하는 방법입니다. 페이스북의 경우 미국내에 IDC가 있는데, 서부는 미국 서부와 아시아권을 동부는 유럽쪽을 커버합니다. 그리고 로드 밸런싱을 Global Load Balancer라는 것을 이용하는데, 아마 국가별 IP를 기반으로 라우팅을 하리라 생각됩니다. (추정)

동기화의 경우 해당 IDC에서 Write된 내용을 다른 IDC에 반영하는 방식인데, 이건 아무리 빨라도 물리적으로 거리가 멀기때문에, 데이타의 불일치성이 발생할 수 있습니다. 이것이 가장 큰 문제입니다. 페이스북의 경우 MySQL을 클러스터로 묶어서 데이타를 동기화 시키고, 불일치성을 막기 위해서 DB앞에 Cache를 넣고, 데이타 업데이트시 Cache를 업데이트 시키는 방식을 이용하고 있습니다. 그리고 동기화를 좀더 쉽게 하기 위해서 Write나 update성 transaction은 무조건 서부의 Master database를 이용하고, Read만 동부에서 제공합니다. 이렇게 하면 data sync를 양방향으로 할 필요없이 서부에서 동부로 단방향으로만 해주면 됩니다.

캐슁은 성능을 보장하기 위함인데, 특히 데이타가 IDC마다 없고, 중앙이나 특정 지역에 집중되서 저장되어 있을 경우에는 데이타를 가지고오기 위해서 WAN구간을 거쳐야 하기 때문에 이를 해결하기 위해서 Cache를 이용합니다. 페이스북의 경우 MySQL의 데이타 동기화의 Latency를 해결하기 위해서 사용하고 DB Access 자체의 성능을 높이기 위해서 사용한것으로 보입니다.

그리고 이러한 Latency 문제를 해결하기 위해서 양쪽 IDC간에 dedicated fiber망을 설치했더군요. 다른 방법으로는 Akamai 같은 망 벤더에서 제공하는 ADN (Application distribution network)을 사용하는 방법이 있습니다만 금액이 매우 비쌉니다. Global ERP 같은 경우에 종종 사용되는것 같더군요.  또는 WAN 가속기를 이용하는 방법도(패킷을 압축하고, TCP/IP 프로토콜을 최적화 해주는 장비) 하나의 방법은됩니다만 드라마틱한 성능 향상은 쉽지 않습니다.

그나마 페이스북은 IDC가 한나라안에 있고 2개뿐이 없어서 비교적 난이도가 높지 않은것으로 보입니다만, 여러 나라에 IDC를 놓고 SYNC를 맞추려면 만만한 작업이 아닐것 같습니다.

그밖에도 법적인 이슈. (한국은 실명 인증을 해야 한다. 위치 정보 사업자 등록을 해야한다. 유럽은 사용자 정보는 유럽 밖으로 나갈 수 없다. 미국은 SOX법등..)에 따라서 아키텍쳐가 영향을 많이 받기 때문에 기술적인 접근말고도 비지니스적인 고려가 많이 되어야 합니다.