클라우드 서비스의 장점 중 하나는 운영 부담이 줄어든다는 것이다. 관리형 서비스는 운영 자동화와 더불어 운영 노하우 및 관행의 획득을 목적삼아 도입하면 참으로 이점이 많다.
그러나 관리형 서비스는 한계가 분명하다. 예를 들어 RDS 최신 버전에 버그가 있고 이 때문에 하루에 몇 번씩 장애를 겪는다면 어떻게 할 것인가? MySQL을 직접 운영한다면 이슈 트래커 또는 관련 커뮤니티를 뒤져 해법을 찾을지 모른다. 최악의 경우엔 직접 패치를 구현할 수도 있다. 그 편이 장애로 잃는 돈보다 크다면 말이다. 그저 누군가 해결해주리라 기대하고 손만 빨지 않아도 된다.
클라우드 서비스 공급자가 대부분의 문제를 해결해주지 않느냐는 말을 하는 사람도 있다. 정말 그렇게 믿는다면 계약서와 SLA를 확인해보라. SLA가 없는 서비스가 대부분일 것이다. SLA가 있어도 피해보상은 매우 제한적일 것이다. 그리고 그러한 SLA 조건은 여러분이 직접 운영한다면 결코 조직에서 허용하지 않을 수치일 가능성이 높다. 서비스마다 SLA가 다르니 SLA 0.90인 서비스 하나와 SLA 0.80인 서비스 하나를 동시에 이용한다면 최악의 경우 SLA는 0.72에 불과하다. 그러므로 이러한 위험은 관리해야 한다. 그리고 위험 관리의 책임은 서비스 제공자가 아닌 여러분에게 있다.
서비스 안정성 외에도 유연함에서도 관리형 서비스의 한계는 명확하다. MySQL 성능이 조금 모자란다고 4xlarge에서 8xlarge로 넘어가야 한다면? 그것도 마스터와 슬레이브를 합쳐 5대짜리 클러스터라면? 여러분이 직접 운영한다면 memcached 플러그인을 도입한다던가 소프트웨어 기반의 SAN을 도입해 더 저렴하게 해결할 수도 있다. 이는 비용 요소의 유연함 문제이지만 다른 유연함도 문제가 있다.
예를 들어, AWS Aurora는 대체로 훌륭하지만 워크로드에 따라선 사용시나리오의 유연함은 떨어진다. 오로라의 성능 이점은 스토리지 수준의 커스터마이징에서 오는데 이러한 커스터마이징은 Binlog를 희생해서 얻는다. 빈로그를 활성화하면 오로라의 성능이 저하될 수 있으면 상황에 따라선 선택하기 어려운 옵션이 될 수 있다. 이는 Zendesk Maxwell 같은 빈로그 스트리밍 도구를 이용하기 힘들다는 뜻이다. 이러한 도구가 주는 아키텍처 상의 이점을 누리지 못한다. 때에 따라선 이러한 손실이 Aurora의 다른 장점을 능가할 수도 있을 것이다.
분명 관리형 서비스는 이점이 많다. 그러한 이점은 내가 아니라도 서비스 제공자나 클라우드를 사랑하는 많은 이가 충분히 알리고 있다. 그러니 나는 남들이 말을 아끼는 부분에 대해 말하려 한다.
관리형 서비스의 최대 이점은 아마도 책임전가일 것이다. 데이터베이스 장애가 나면 내가 시달리지 않아도 된다. 이를테면 AWS 탓을 하면 그만이다. 나는 결코 이를 비난하는 것이 아니다. 그렇다고 옹호하는 것도 아니다. 다만 그러한 한정적 책임에는 장점과 단점이 모두 있다는 이야기를 하고 싶다. 어떤 환경이든 그 속에서 가장 바람직한 균형점을 찾고자 노력하는 조직에서 여러분이 일하길 바랄 뿐이다.
