MySQL HA over AWS 옵션

메모를 안해놓으면 또 까먹기 때문에, 정리 차원에서 몇가지 정리

1. MySQL HA over AWS

먼저 MySQL을 아마존 위에서 Zone간 Fail Over를 위해서 몇가지를 고민했다.

1) MySQL Cluster

MySQL의 클러스터링 버전으로, Zone간 Fail Over가 이론적으로 가능하다. 제품 자체도 기존 MySQL과 상당히 차별화 되어 있다.그러나 가격이 상당히 비싼 편이고, 아직은 AWS위에 deployment된 reference가 없기 때문에 상당한 risk를 둬야 한다.

2) Garela, Tungsten

오픈소스로 Replication을 보장하지만, 국내 Support가 없기 때문에, Bug Fix가 어렵다. 그래서 Pass

3) HAProxy

상당히 재미있는 개념인데, Proxy로 어떻게 DB Replication을 하느냐 하는 의문이 들었는데, 원리 자체는 쉽다. 양쪽 Zone에 MySQL을 배치한후, 그 앞에 HAProxy를 넣어서, SQL 부하를 양쪽에 똑같이 분산 시킨다(복제) 즉. insert SQL을 치면 양쪽에 모두 보내서 복제 하는 방식이다. Garela가 이런 방식의 구현 방식을 취한다고 한다.

그러나, 이 아키텍쳐의 경우 Application단에서, write/read를 명시적으로 나눠줘야 하고, error 핸들링이 어려우며 분산 트렌젝션 처리등이 어려운 제약 사항을 가지고 있다.

4) RDS
만사 제일 편한 옵션이기는 한데, 다양한 replication architecture 사용이 어렵다. 그리고 MySQL over EC2에 비해서 용량상 제약이 따른다.

5) Oracle Golden Gate

일단 내가 아는 DB Replication 솔루션 중에 최강이다. 그만큼 가격도 최강이다. 모 업체가 위의 옵션을 다 고민도 해보고 production에 적용도 해봤는데,결론이 OGG(Oracle Golden Gate)로 왔다.

기본적으로 이러한 여러가지 옵션이 존재하는 이유가, MySQL EE의 HA 옵션은 DBCR (Linux의 HA솔루션)을 이용하는 방식인데, 전통적인 HA 방식으로 서버가 죽으면, 상대편 서버로 HA하면서 IP를 옮기는 방식인데, 아마존에서는 작동을 안한다고 한다. 그리고 Fail over는 IP를 넘겨서 한다고 쳐도 (물론 back단에서는 MySQL 의 기능을 이용해서 data replicaiton을 해야 한다.) Fail Back이 어떻게 되는지에 대해서 상세한 시나리오는 없다.

조금 더 리서치가 필요한 영역이긴 한데, 이미 다들 안되는 방향으로 잡아서 더 이상 파보지는 않았다.