Cloud SQL, 매스프레소의 데이터베이스 인프라를 위한 최적의 선택

매스프레소는 교육의 디지털 전환을 목표로 하고 있습니다. 여전히 교육의 대부분은 오프라인에서 이뤄지고 있고, 디지털의 활용은 6%대에 머무는 상황입니다. 이는 기기의 보급이나 기술적인 문제가 아니라 학생 개개인의 강점과 부족한 부분을 세밀하게 파악하는 교사의 역할이 크기 때문입니다.

하지만 이 역시 교사는 여러 명의 학생을 가르치기 때문에 개개인의 부족한 부분을 충분히 채워주기는 어렵습니다. 궁금한 점을 중심으로 오랜 시간 이끌어주는 것은 결국 과외를 비롯한 사교육으로 넘어가는 것이 일반적인 교육 환경이라고 할 수 있습니다. 매스프레소는 스마트폰만 있으면 학생들의 질문을 바탕으로 빈틈을 채워 나가는 교육 플랫폼입니다.

데이터가 중심이 되는 서비스 구조로 이전

매스프레소의 대표 서비스는 ‘콴다’입니다. 모르는 문제를 질문하면 전문 교사가 1:1로 직접 답변을 해 주어서 학습의 효과와 만족도가 높았습니다. 하지만 이용자가 늘어나다 보니 정형화된 교육 과정 안에서 비슷한 질문이 반복되는 패턴을 확인할 수 있었습니다. 이미 한번 해결해 낸 풀이가 사라지는 것이 아니라 다른 학생들에게 더 빠르게 답을 줄 수 있는 시스템적인 기회가 생긴 것입니다.

콴다 이용자들의 질문은 대부분 스마트폰으로 문제를 찍어서 전해집니다. 인공지능 기술이 빠르게 대중화되면서 글자를 읽어내는 OCR은 비약적으로 발전했고 이전과 비교할 수 없을 만큼 빠르고 정확하게 글자와 숫자를 디지털 정보로 쌓을 수 있게 됐습니다. 매스프레소는 이미지에서 문제를 정확히 읽어내고, 이를 통해서 문제의 개념을 추론하고, 연관된 콘텐츠를 찾아서 연결할 수 있는 시스템을 갖출 수 있게 됐습니다.

이 시스템의 핵심은 결국 이제까지 쌓아온, 또 앞으로 만들어 갈 문제 풀이에 대한 데이터 관리에 있습니다. 매스프레소는 더 나은 교육 환경을 위해 기술이 중심이 되는 통합 학습 플랫폼을 지향하고 있고, 그 경험을 높이기 위해서는 데이터가 체계적으로 관리되는 데이터 클러스터가 필요했습니다.

Cloud SQL로 MySQL 기반 마이크로서비스 아키텍처 데이터베이스 운영 환경 전환

초기 콴다는 전체 서비스가 한 덩어리로 설계(Monolithic Architecture) 되었습니다. 데이터베이스 역시 AWS Aurora를 이용해 단일 권한의 통합 운영이 이뤄졌습니다. 하지만 점차 서비스와 팀의 규모가 커지면서 빠른 업데이트와 기술 대응을 위해 각 요소들이 독립되는 마이크로 서비스 아키텍처로 전환이 이뤄졌습니다. 개별 마이크로서비스는 각자의 데이터베이스를 갖고 그 안에서 빠르고 안정적으로 데이터가 처리되는 방식입니다.

콴다는 초기부터 많은 서비스 요소들이 클라우드의 통합 데이터베이스에 데이터를 담아내고 있었는데, 이를 단숨에 마이크로서비스 아키텍처로 나누어 옮기는 것은 쉽지 않습니다. 매스프레소 뿐 아니라 사업 초기의 스타트업들은 데이터를 나누는 것보다 전체적으로 운영하는 것이 자원 효율성과 운영 편의성 등 모든 측면에서 나을 수 있습니다.

하지만 규모가 커지고 각 요소별로 독립적인 팀이 운영되면 각자의 데이터베이스를 관리하는 편이 낫습니다. 운영의 세분화 뿐 아니라 클라우드에 접근하는 어카운트를 구분할 필요도 있습니다. 매스프레소는 빠른 성장으로 규모가 커졌고, 이제는 마이크로 서비스 아키텍처로 옮길 필요가 있었습니다.

마침 매스프레소는 인프라를 구글 클라우드로 이전하기로 결정을 했고, 데이터베이스는 구글 Cloud SQL을 이용해 MySQL을 운영하기로 결정했습니다. MySQL은 여전히 운영에 대한 레퍼런스가 많고 읽기 속도가 빠른 장점을 갖고 있기 때문에 다른 데이터베이스로 이전하지 않고 더 나은 MySQL 환경을 갖추는 것이 낫다고 판단했습니다.

이전 이후의 서비스들은 대부분 자체 데이터베이스를 갖고 운영하게 됐고, 기존의 서비스들도 서서히 옮길 기회를 갖게 됐습니다. 단순한 데이터베이스의 분리 외에 API 형태로 바꾸어서 검색을 비롯한 데이터 접근 방법도 개선했습니다. 데이터베이스에서 작업이 이뤄져도 다른 부분에서는 접근에 영향이 없고, 데이터의 동기화도 훨씬 안전하게 이뤄집니다.

매끄러웠던 대규모 데이터베이스 이전

가장 큰 숙제는 이전이었습니다. 클라우드 간에 수 십 TB수준의 데이터를 옮기는 것은 쉽지 않은 도전이었습니다. 외부 솔루션을 이용하는 대신 MySQL의 바이너리 로그 복제(Binlog Replication) 방식을 이용하기로 했습니다. 하지만 AWS Aurora의 바이너리 로그 저장 기간은 7일이 전부였습니다. 그 안에 모든 데이터를 Cloud SQL로 옮겨야 했습니다.

이전 과정에서 초기 복제는 AWS의 EC2로 MySQL 데이터베이스를 내보낸 뒤 EC2의 VM으로 데이터를 압축해 Google Compute Engine으로 전송했습니다. 구글 클라우드로 데이터를 안전하게 가져온 뒤에는 어렵지 않게 Cloud SQL에 데이터를 적재할 수 있었습니다.

로그 저장 기간으로 인해 초기 복제는 7일 이내를 목표로 삼았지만 구글 클라우드와 Cloud SQL 스토리지의 좋은 성능으로 인해 2일 남짓한 시간만에 이뤄졌고, 동기화, 최적화 등 나머지 과정을 마치는 데 4일이 채 걸리지 않았습니다. AWS Aurora를 중단하고 Google Cloud SQL로 운영 데이터베이스를 옮기는 과정에서도 Cut-over를 위해 2분 정도 운영이 멈춰졌을 뿐 전체 서비스에는 거의 영향을 끼치지 않았습니다.

스타트업에 적절한 관리형 데이터베이스 환경

이전 이후 Cloud SQL은 안정적인 MySQL 운영 환경을 갖춰주었습니다. 구글 클라우드에는 멀티존 서비스가 기본적으로 더해져서 자연스럽게 재해 복구 환경을 갖출 수 있었습니다. 전반적으로 구축과 운영 비용이 절감되는 효과를 얻었습니다.

가장 큰 효과는 성능에 있습니다. Cloud SQL은 갑작스런 트래픽 증가에도 빠르고 유연하게 대응할 수 있었습니다. 늘어나는 트래픽을 미리 예측해서 인프라를 확장하는 것은 물론이고, 실시간으로 필요한 만큼의 자원을 확보하는 것도 손쉬웠습니다.

무엇보다 전반적인 자원 관리가 매끄럽다는 강점이 눈에 띕니다. 짧은 시간에 트래픽이 몰리면 기존의 경우 CPU 점유율이 80%까지 갑자기 튀어 오르는 경우가 있었는데 Cloud SQL은 40~50% 선에서 안정적으로 유지되었습니다. 이전 과정에서 매스프레소의 데이터베이스 최적화와 튜닝이 더해진 효과지만 이전에 비해서 비용을 35% 가량 줄이는 효과도 있었습니다.

백업과 복구의 속도도 크게 높아졌고 페일오버에 대한 구성도 더 안정적으로 이뤄졌습니다. 구글 클라우드의 안정성을 바탕으로 제 3의 Cloud SQL의 고가용성 구성 대신 장애가 일어나면 동기화된 읽기 데이터베이스가 쓰기 데이터베이스로 전환해서 역할을 이어가도록 구성했습니다. 경험에서 나오는 온프레미스의 데이터베이스 운영 방법 중 하나로, Cloud SQL은 이를 매끄럽게 받아들일 수 있는 유연성을 갖추고 있습니다.

또한 Cloud SQL의 Insight는 매끄러운 데이터 기반의 소통을 만들어주는 역할도 해 주었습니다. DBA들은 대체로 스스로 데이터베이스를 한 눈에 파악할 수 있는 모니터링 도구를 구성하기 때문에 클라우드에서 제공하는 모니터링 시스템이 직접적으로 운영에 필요하지는 않습니다. 하지만 구글 클라우드의 Insight는 쉽고 간결한 구성으로 DBA가 아닌 개발자들도 현재 각자가 이용하는 데이터베이스의 상황을 쉽게 이해할 수 있도록 해 주었습니다. 이를 통해 각자가 익숙한 방법으로 데이터베이스 상황을 살피고, 서로 소통할 수 있는 문화가 자리를 잡았습니다.

전체적으로 매스프레소는 데이터베이스 인프라에 대한 관리형 서비스를 통해 데이터베이스의 성능, 유연성 등을 높이고자 하는 목표를 갖고 있었습니다. Cloud SQL의 Notification과 Query Insights 등 어드바이저 기능들이 개발자들의 편의도를 크게 높여 주면서 데이터베이스에 대한 부담을 덜어내고 매끄러운 개발 환경을 만드는 데에 큰 역할을 해 주었습니다.