PlanB의 백엔드 엔지니어링

마침내 클라우드 DB의 시대가 열리고 있다라는 글을 본 적이 있었습니다. 이 기사에선 아래와 같이 이야기합니다.

"지난 몇 년 동안 많은 기업이 온프레미스 워크로드를 퍼블릭 클라우드로 옮기려 노력했다. 그러나 데이터베이스는 가장 힘든 워크로드였다. (...) 최근 유럽 최대 항공사인 라이언에어(Ryanair)가 대규모 클라우드 전환 계획을 발표했다. 인프라스트럭처를 모두 AWS로 이전하는 것으로 문자 그대로 '클라우드 올인'이다. 이번 발표에서 가장 주목해야 할 부분은 "AWS 데이터베이스로 표준화한다"는 대목이다. 마이크로소프트 SQL 서버를 아마존 오로라(Aurora)로 완전히 대체한다는 것이다. 필자는 드디어 때가 왔다고 본다. 기업이 데이터베이스를 클라우드 데이터베이스를 이전하는 행렬이 이어진다면, 이 시장의 게임은 완전히 새로운 국면에 접어드는 것이다."

사내에서 Aurora를 써본(쓰는 걸 옆에서 지켜본) 적이 있었습니다. 클라우드 컴퓨팅 자원 위에 데이터베이스를 올리는(RDS같은) 경험은 몇 번 해 봤어도, 클라우드 자체에서 제공하는 데이터베이스 엔진을 사용하는 것은 처음 하는 일이라 새로우면서도, 좋은 경험이었습니다. MySQL의 데이터를 마이그레이션한 이후, 비용도 비용이지만 속도가 눈에 띄게 빨라졌기 때문입니다. Amazon Aurora는 완전 관리형이면서, PostgreSQL, MySQL과 호환되는 RDBMS입니다.

RDS는 훌륭한 관리형 RDB 서비스지만, MySQL과 같이 지원하는 엔진들이 클라우드 환경에 최적화 되었다고 보긴 어렵습니다. 이들은 클라우드 환경에 맞게 성능과 가용성을 끌어내기 어렵다는 문제가 있었는데, Aurora는 이런 문제를 해결하기 위해 AWS가 쏟은 노력의 결과입니다. 일반적으로 MySQL에 비해 5배, PostgreSQL에 비해 3배 정도까지 처리량이 향상됩니다. MySQL과 PostgreSQL 데이터베이스에 사용되는 코드, 도구, 어플리케이션 모두 Aurora에서도 적용할 수 있어 이 둘을 즉시 대체할 수 있습니다.

EC2에서 인스턴스를 생성할 때, Red Hat, SUSE Linux, Ubuntu, Windows Server 등의 운영체제들 중 하나를 선택할 수 있었습니다. 이렇게 인스턴스를 시작하는 데 필요한 정보를 제공하는 운영체제 타입들을 AWS에선 이미지라고 부르고, 더 구체적으로는 AMI(Amazon Machine Image)라고 부릅니다. EC2 인스턴스에서 OS를 선택하는 곳을 유심히 보면, AMI라는 단어가 보입니다.

AWS에서는 이렇게 운영체제를 EC2 서비스에 사용할 수 있도록 AMI라는 개념으로 감싸고, 각각에 ID를 부여합니다. 기존 AMI로 인스턴스를 시작하고 사용자 지정한 다음, 해당 구성을 사용자 지정 AMI로 저장할 수도 있습니다. 이러한 사용자 지정 AMI에서 인스턴스를 시작하면 해당 AMI를 만들 때 지정한 사용자 정의 값을 포함하므로, 동일한 세팅을 가진 인스턴스 여러 개를 띄워 로드밸런싱하는 경우 등에 요긴하게 사용할 수 있습니다.

거의 모든 상용 서비스는 각자의 IP와 도메인을 매핑하여 사용합니다. 호스트의 도메인을 IP로 바꾸거나, 그 반대의 변환을 수행하기 위해 과거에 DNS(Domain Name System)가 개발되었고, AWS에서는 Route 53이라는 DNS를 지원하고 있습니다. Route 53의 주요 기능은 3가지입니다.

도메인 이름 등록

IP를 가지고 있고, 인바운드를 허용하고 있어 인터넷 트래픽을 받을 수 있는 EC2 등의 클라우드 서비스에 도메인을 등록할 수 있습니다. Route 53으로 도메인을 등록하는 경우, Amazon은 자동으로 도메인에 대한 호스팅 영역을 생성하며, 도메인 등록에 대한 연간 요금에 더하여 호스팅 영역에 대한 소액의 월간 요금을 부과합니다.

인터넷 트래픽 라우팅

도메인을 이용한 인터넷 트래픽이 들어오면, Route 53은 DNS가 브라우저를 실제 호스트에 연결하도록 돕습니다. 아래와 같은 모습입니다.

리소스 상태 확인

다른 말로는 health check입니다. Route 53은 도메인에 묶여 있는 호스트의 특정 엔드포인트에 자동화된 요청을 보내 정상 작동 중인지 확인합니다. 리소스를 사용할 수 없게 되었을 때 CloudWatch에 경보를 설정하며, 필요한 경우, Amazon SNS와 같은 서비스를 통해 사용자에게 알리는 등의 기능도 추가할 수 있습니다.

Amazon Athena는 서버리스 대화식 쿼리 서비스라고 소개하고 있다. 그러나 우리가 주목해야 할 핵심은 'Amazon S3의 데이터를 표준 SQL로 분석'할 수 있다는 것이다. 로그같은 대규모 데이터는 EBS나 ElasticSearch 등에 적재하기에는 너무 큰 비용이 발생하기 때문에, 접근이 적게 일어나는 시점부터(일주일인 곳도 있고, 한 달인 곳도 있고..)의 로그는 S3와 같은 스토리지에 저장하게 된다. 접근 속도는 느리겠지만 말이다. 그런데 문제는 접근 속도가 아니라 S3에 파일 형태로 저장된다는 점인데, athena가 이 문제를 해결해 준다.

S3에 적재되어 있는 데이터의 스키마만 테이블처럼 정의해 두면, 표준 SQL로 이들을 쿼리할 수 있게 된다.

Amazon Athena console에서 자체적으로 제공하는 create table wizard, 쿼리 에디터에서 hive 형태의 DDL statement, athena api, ODBC driver 등을 이용해 테이블을 생성할 수 있다. athena는 내부적으로 페이스북이 개발한 분산 SQL 쿼리 엔진인 presto를 사용하여, Hive/MapReduce에 비해 10배 정도 빠르다고 소개한다.