AWS 기술 블로그

Amazon Aurora MySQL을 사용하여 MMORPG를 개발할 때 고려해야할 점들

이 글은 SQL Server to Amazon Aurora MySQL in Game Development 시리즈 블로그의 일부로 작성되어 있습니다. 시리즈의 모든 글들은 아래 링크들을 따라가시면 읽어보실 수 있습니다.

상용 데이터베이스를 사용할 때는 라이센스 비용 부담, 최고의 성능과 안정성을 위해 높은 기술적 숙련도가 필요한 점, 온-프레미스 중심의 상용 데이터베이스를 클라우드 환경에 최적화하기 어려운 문제 등으로 인해 클라우드에서 서비스를 운영하는 경우 기존 상용 데이터베이스를 그대로 사용하기 어려운 경우가 많습니다. 그에 대한 대안으로 많은 클라우드 업체에서 클라우드에 최적화된 데이터베이스를 제공하고 있습니다. 이를 도입하게 되면 클라우드 네이티브 구현에서 오는 성능과 안정성은 물론 상용 데이터베이스 활용에 따른 라이센스 비용, 운영을 위한 비용 등도 최소화할 수 있게 됩니다. AWS 에서도 역시 Amazon AuroraAmazon DynamoDB와 같은 데이터베이스를 제공하고 있습니다. 특히 Amazon Aurora의 경우 많이 사용되는 오픈 소스 데이터베이스인 MySQL과 PostgreSQL과 호환되는 형태로 제공하고 있기에 많은 분들이 친숙하게 사용할 수 있습니다.

다만 기존에 상용 데이터베이스를 활용해서 개발을 진행하는 과정에서 익숙해지고, 많이 사용하던 기술 등을 단 시간 내에 오픈 소스 구현을 바꾸는데에는 상당한 훈련과 함께 검증 및 테스트가 필요하게 됩니다. 기존에 사용하던 쿼리문들에 대한 마이그레이션의 경우 AWS 에서 제공하는 도구나 기타 다른 도구들을 통해서 자동으로 변환하는 등의 기능을 활용할 수 있습니다. 하지만 변환된 내용에 대해서 검토하고 신규로 쿼리를 작성하는 과정에서 새로운 환경에서의 차이점 들에 대해서 익혀 두는 과정이 필요합니다. 이번 블로그 포스팅에서는 특히 게임 개발에서 많이 사용되는 기능들을 중심으로 주의해야 할 내용들을 정리하겠습니다.

구문 및 트랜잭션 처리 차이 살펴보기

트랜잭션 처리

MySQL의 경우 MS SQL Server와 트랜잭션의 기본 격리 수준이 다릅니다. MySQL은 REPEATABLE READ, MS SQL Server는 READ COMMITED를 트랜잭션에 대한 기본 격리 수준으로 가지고 있기 때문에 이 차이에 대해서 주의해야할 점들이 있습니다. REPEATABLE READ 기본 격리 수준을 제공하는 MySQL의 경우 동일한 트랜잭션 내에서 같은 쿼리를 여러 번 실행해도 일관성 있는 결과물을 얻을 수 있습니다. 만약 기존의 SQL Server 기반 애플리케이션이 READ COMMITTED의 격리 수준을 가정하고 개발되어 데이터의 불일치를 허용할 수 있지만 높은 동시성을 달성하고자 했다면 MySQL 에서는 기본 격리 수준이 REPEATABLE READ이기 때문에 명시적으로 격리 수준을 변경해주어야 합니다. 게임 로그, 행동 분석과 같이 비즈니스 크리티컬하지 않은 데이터를 처리하거나, 리더보드 업데이트와 같이 실시간 정확성이 중요하지 않은 상황, 일일 보상 계산 등의 비동기 또한 공유 잠금에서도 차이가 있는데, MySQL 에서는 잠금이 트랜잭션이 끝날 때까지 유지되기 때문에 장기 실행 쿼리가 있는 경우 잠금 경합이 발생할 가능성이 높아집니다.

저장 프로시저

많은 게임들이 SQL Server를 사용할 때 여전히 저장 프로시저를 사용하고 있기에 저장 프로시저의 차이를 확인하고 주의를 기울이는 것은 중요한 일입니다. 우선 MySQL의 저장 프로시저에서는 Table Valued Parameters를 지원하지 않습니다. 다만 비슷한 효과를 얻을 수 있는 몇 가지 대안적인 방법이 있습니다. 그 중에서 임시 테이블을 사용하도록 하여, 프로시저 호출하기 전에 임시 테이블을 생성하고 데이터를 삽입하고 프로시저 내에서 이 임시 테이블을 참조하여 데이터를 처리하도록 하는 방법이 일반적으로 많이 사용되고 있습니다. 그 외에도 JSON 또는 XML 형식이나 CSV 형식의 문자열 매개변수를 사용할 수도 있고, 테이블을 여러 개별 매개변수로 나누어 전달할 수도 있고, 소스 테이블에서 커서를 사용하여 행을 반복 처리할 수도 있습니다. 각 상황의 데이터의 구조와 양, 성능 요구사항에 따라 가장 적합한 방법을 선택해서 사용하시면 됩니다. 저장 프로시저와 관련된 내용은 Amazon Aurora MySQL 오해와 진실에서 더 자세히 설명되고 있습니다.

오류 처리

# MySQL 에서의 SP 예외 처리 샘플
DELIMITER //

CREATE OR REPLACE PROCEDURE sampleProc(IN p_text VARCHAR(255))
BEGIN

  # 예외 처리 HANDLER 정의
  DECLARE EXIT HANDLER FOR SQLEXCEPTION
  BEGIN
    GET DIAGNOSTICS CONDITION 1
        @sqlstate = RETURNED_SQLSTATE,
        @errno = MYSQL_ERRNO,
        @text = MESSAGE_TEXT;
    # 예외 처리 작업
    ...
  END;

  # 실제 작업
  ...
END //

DELIMITER ;
SQL

오류 처리 패러다임과 구문이 다르므로 오류 처리 코드를 재작성해야 합니다. MySQL은 CONDITION이라는 개념을 사용하며, HANDLER 객체를 통해 이를 처리합니다. 또한, DIAGNOSTICS를 통해 상세한 오류 정보를 제공합니다. 오류 식별 방식도 다릅니다. MySQL은 고유의 숫자 오류 코드와 SQLSTATE 값 그리고 오류를 설명하는 문자열을 사용합니다. 구문적으로는 SIGNALRESIGNAL 문을 사용하여 SQL Server의 THROWRAISERROR와 유사한 기능을 수행합니다. 주목할 만한 차이점은 Aurora MySQL이 다중 핸들러를 지원한다는 것입니다. 이는 더 유연한 오류 처리를 가능케 하지만, 동시에 복잡성을 증가시킬 수 있습니다. 마이그레이션 시에는 코드 재작성, 철저한 테스트, 핸들러 로직 검토, 오류 코드 매핑 등이 필요합니다. 자세한 내용은 Microsoft SQL Server 2019에서 Amazon Aurora MySQL로의 T-SQL에 대한 오류 처리 마이그레이션 문서를 참조하시기 바랍니다.

JSON 및 XML 지원

# MySQL 에서의 JSON 테이블 및 그 활용 샘플
# 데이터 샘플
# {
#   "Person": "John",
#   "Country": "USA"
# }
CREATE TABLE JSONTable (DocumentIdentifier INT NOT NULL PRIMARY KEY, JSONDocument JSON);
SELECT JSON_EXTRACT(JSONDocument, '$.Person') AS PersonValue FROM JSONTable;
SQL

MySQL은 XML 지원이 제한적이지만 JSON 지원은 광범위합니다. 반면 MS SQL Server는 XML을 폭넓게 지원하지만, MySQL에서는 이러한 지원이 매우 제한적입니다. 따라서 XML 을 사용하는 쿼리를 많이 쓰는 저장 프로시저나 애플리케이션을 가지고 있다면 마이그레이션할 때는 다음과 같은 대안을 고려해야 합니다:

  • XML 데이터를 JSON으로 변환
  • XML을 문자열이나 BLOB으로 저장하고 애플리케이션 레벨에서 파싱
  • XML 처리를 위한 외부 라이브러리 사용

반면, JSON 지원에서는 MySQL이 더 강력한 기능을 제공합니다. MySQL은 네이티브 JSON 데이터 타입과 25개 이상의 전용 JSON 함수를 지원하여, JSON 문서의 저장, 검증, 쿼리를 최적화합니다. MS SQL Server에서 JSON 작업을 하던 쿼리들은 MySQL의 해당 함수로 변환하여 성능을 개선할 수 있습니다. 자세한 내용은 Microsoft SQL Server 2019에서 Amazon Aurora MySQL로의 JSON과 XML 사용 마이그레이션 문서를 참조하시기 바랍니다.

Aurora MySQL 성능 최적화 방안 살펴보기

인덱스 구조의 차이

MySQL에서는 클러스터형 인덱스가 오직 기본 키에만 적용되며, 비클러스터형 인덱스는 유니크 제약 조건과 일반 인덱스에 사용됩니다. 따라서 마이그레이션 과정에서 PK와 다른 클러스터형 인덱스가 있는 경우 모델링이나 쿼리에 대한 변경 검토가 필요합니다. 또 MS SQL Server에서 지원하는 필터링된 인덱스나 포함된 컬럼 기능은 MySQL에서 제공되지 않습니다. 포함된 컬럼 기능을 위해서는 필요한 컬럼을 인덱스의 키 컬럼으로 추가하는 식으로 대신할 수 있습니다.

SQL Server 인덱스 유형/기능 MySQL 변경 고려 대상
Clustered Index InnoDB의 기본 키 (Primary Key)
Non-Clustered Index 일반 인덱스 (Secondary Index)
XML Index 지원하지 않음 (대체: 텍스트 컬럼에 일반 인덱스)
Columnstore Index 지원하지 않음 (대체: 일반 인덱스)
Filtered Index 부분 인덱스 (MySQL 8.0 이상) 또는 WHERE 절을 사용한 뷰에 인덱스 생성
Included Columns 복합 인덱스 또는 커버링 인덱스로 구현

인덱스 조인 쿼리 최적화

Aurora MySQL에서는 비동기 키 프리페치(Asynchronous Key Prefetch, AKP) 기능을 사용하여 인덱스를 통한 테이블 조인 쿼리의 성능을 향상시킬 수 있습니다. JOIN 절이 작은 용량의 외부 테이블과 큰 용량의 내부 테이블 사이에서 인덱스 값을 기준으로 한 등가 조인을 나타내고, 테이블 용량이 커질수록 인덱스 선택의 폭이 매우 제한적일 때 AKP를 사용할 수 있습니다. 이를 사용하기 위해서는 몇 가지 조건이 만족되어야 사용할 수 있게 되는데 이 조건들이 만족될 경우 JOIN 절 평가 중에 필요한 행을 식별하고, 백그라운드 스레드를 사용하여 해당 행을 포함하는 페이지를 비동기적으로 메모리에 로드함으로써 쿼리 성능을 향상시킬 수 있습니다. 필요한 조건을 포함하여 AKP와 관련된 자세한 내용은 비동기 키 프리페치를 사용하여 Aurora MySQL 인덱싱된 조인 쿼리 최적화하기 문서를 참조하시기 바랍니다.

대규모 조인 쿼리 최적화

대량의 데이터를 등가 조인으로 조인할 때 해시 조인을 사용하면 쿼리 성능을 개선할 수 있습니다. 해시 조인이 지원되는 버전에 대한 자세한 내용, 데이터 타입에 대한 호환성 내역, 지원되지 않는 상황에 대한 내용, 필요한 설정과 관련된 자세한 내용은 해시 조인을 사용하여 대규모 Aurora MySQL 조인 쿼리 최적화하기 문서를 참조하시기 바랍니다.

그 외에 성능 최적화와 관련된 자세한 내용은 Microsoft SQL Server 2019에서 Amazon Aurora MySQL로의 인덱스 마이그레이션 문서와 Aurora MySQL을 위한 성능 튜닝 문서를 참조하시기 바랍니다.

Aurora MySQL 관리 및 모니터링 포인트

데이터베이스 옵션 설정

SQL Server의 데이터베이스 옵션들은 Aurora MySQL에 적용되지 않습니다. SQL Server의 경우 데이터베이스와 스키마의 개념이 나뉘어 있지만, MySQL 에서 두 개념을 동일하게 취급합니다. 따라서 별도의 데이터베이스 옵션이라는 개념은 MySQL 에 적용할 수 없습니다. Aurora MySQL에서는 SQL Server의 데이터베이스 및 서버 옵션에 해당하는 설정을 전체 Aurora 클러스터에 적용되는 설정을 담고 있는 클러스터 파라미터 그룹과 개별 데이터베이스 인스턴스에 적용되는 설정을 가지고 있는 데이터베이스 인스턴스 파라미터 그룹을 통해 관리합니다. 두 데이터베이스의 설정과 관련된 차이에 대한 자세한 내용은 Microsoft SQL Server 2019에서 Amazon Aurora MySQL로의 설정 마이그레이션 문서를 참조하시기 바랍니다.

파라미터 클러스터 파라미터 그룹 인스턴스 파라미터 그룹
character_set_server O X
max_connections X O
innodb_buffer_pool_size X O
binlog_format O X
slow_query_log X O
time_zone O X

성능 모니터링

그림1. 성능 개선 도우미

Aurora MySQL에서는 Amazon CloudWatch, 성능 개선 도우미, 향상된 모니터링 등 AWS 네이티브 도구들을 활용하여 DB 인스턴스 사용량을 평가하고 모니터링할 수 있습니다. SQL Server의 경우 SQL Server Management Studio(SSMS)의 활동 모니터, 확장 이벤트와 같은 다양한 도구들을 통해서 SQL Server의 성능 모니터링을 진행할 수 있습니다. 하지만 Aurora MySQL의 경우 이러한 도구들이 지원되지 않기 때문에 1분 단위로 데이터베이스 인스턴스의 CPU 사용률, 가용 메모리 등의 상세한 성능 지표를 제공하는 Amazon CloudWatch, SQL Server의 활동 모니터와 유사하게 데이터베이스의 부하를 시각화하고 성능 문제의 근본 원인을 파악할 수 있도록 하는 성능 개선 도우미, OS 수준의 메트릭을 통해 보다 깊이 있는 성능 분석을 가능하게 하는 향상된 모니터링과 같은 기능들을 사용하셔야 합니다. 이와 관련한 자세한 내용은 Amazon Aurora 클러스터에 대한 지표 모니터링을 참고하시기 바랍니다.

Aurora MySQL 사용 시 제한 사항 확인하기

시스템 접근 제한

# LOAD DATA FROM S3 의 샘플 코드
LOAD DATA FROM S3  's3://amzn-s3-demo-bucket/data.txt'
    INTO TABLE table1
    (column1, column2)
    SET column3 = CURRENT_TIMESTAMP;
SQL

Amazon Aurora는 관리형 서비스이므로 셸이나 파일 시스템에 직접 접근할 수 없습니다. 이로 인해 LOAD DATA INFILE 문을 사용한 데이터 가져오기나 로컬 MySQL 인스턴스에서 실행되는 일부 유지 관리 스크립트를 사용할 수 없습니다. 그 대신 자동 백업, 자동 소프트웨어 패치, 자동 스토리지 확장 등의 자동화된 관리 작업을 활용하고, LOAD DATA FROM S3SELECT INTO OUTFILE S3 와 같이 Amazon S3와의 상호 작용을 통하여 로컬 파일 시스템을 활용하던 기능들을 대신할 수 있습니다. 데이터베이스의 각종 로그들의 경우 인스턴스에 대한 직접 접속을 제한하기 때문에 Aurora MySQL은 Amazon CloudWatch Logs를 통해서 중앙 집중식으로 관리하고 분석할 수 있습니다. SQL Server에서 직접 로그 파일을 분석하거나 시스템 저장 프로시저를 통하여 로그를 조회할 필요가 없고, 기존 로그 분석 파이프라인과 쉽게 통합하여 로그를 활용할 수 있습니다. 이와 관련된 자세한 내용은 Amazon Aurora MySQL을 다른 AWS 서비스와 통합하기 문서를 참고하시기 바랍니다.

결론

Amazon Aurora MySQL은 MMORPG 개발에 있어 Microsoft SQL Server의 대안으로 권장드리고 있지만, 두 시스템 사이에 존재하는 중요한 차이점과 관리형 서비스이기에 발생하는 차이점들도 존재하며, 대안으로 접근할 때 이러한 차이점들을 잘 숙지하고 적절히 대응해야 합니다. AWS에서는 이러한 차이점들을 검토하실 수 있도록 다양한 자료를 제공하고 있고, 특히나 Microsoft SQL Server 2019에서 Amazon Aurora MySQL로의 마이그레이션 문서를 통해서 다양한 내용들을 포괄적으로 살펴볼 수 있도록 제공해 드리고 있습니다. 클라우드 환경에서의 직접 관리형 상용 라이선트 데이터베이스 사용의 어려움을 많을 많이 듣고 접하신다면 데이터베이스 변경에 따른 장점들을 살펴보시고, 게임 운영 아키텍처를 현대화하고 확장성 있게 개선할 수 있는 기회를 얻으실길 바라겠습니다. 기존 시스템과의 차이점을 충분히 이해하고, 필요한 부분에서는 AWS 의 지원을 받으면, 충분히 성공적으로 마이그레이션하실 수 있을 것으로 생각합니다.

Junseong Jang

Junseong Jang

장준성 솔루션스 아키텍트는 게임 개발 업계에서 오랜 기간 게임 백엔드 개발자로 일한 경험을 바탕으로 국내 다양한 게임 업체들이 AWS에서 성공적으로 게임을 서비스하도록 도움을 주고 있습니다.

Deokhyun Lee

Deokhyun Lee

이덕현 데이터베이스 스페셜리스트 솔루션즈 아키텍트는 AWS의 다양한 데이터베이스 서비스를 활용해 서비스를 구성하고자 하는 고객에들게 최적화되고 효율적인 데이터베이스 서비스 구성을 컨설팅하고 지원하는 역할을 수행하고 있습니다.

Hyunchang Sung

Hyunchang Sung

성현창 솔루션즈 아키텍트는 게임 고객들이 AWS에서 성공적으로 게임을 개발하고 운영할 수 있도록 지원하고 있습니다. 게임 업계에서 오랫동안 게임 서버 프로그래머로 일했던 경험을 살려 게임 개발 및 서비스 전반에서 고객들에게 필요한 도움을 드리고 있습니다.