Amazon Aurora MySQL 모범 사례 - Amazon Aurora

Amazon Aurora MySQL 모범 사례

이 주제에서는 Amazon Aurora MySQL DB 클러스터 사용 또는 이 클러스터로의 데이터 마이그레이션과 관련된 모범 사례와 옵션에 대해 설명합니다. 이 항목의 정보는 Amazon Aurora DB 클러스터 관리에서 찾을 수 있는 몇 가지 지침과 절차를 요약하고 반복합니다.

연결되어 있는 DB 인스턴스 확인

Aurora MySQL DB 클러스터에 어떤 DB 인스턴스가 연결되었는지 판별하려면 다음 예제와 같이 innodb_read_only 전역 변수를 점검하십시오.

SHOW GLOBAL VARIABLES LIKE 'innodb_read_only';

리더 DB 인스턴스에 연결된 경우 innodb_read_only 변수는 ON(으)로 설정됩니다. 라이터 DB 인스턴스(예: 프로비저닝된 클러스터의 기본 인스턴스)에 연결되어 있는 경우 이 설정은 OFF입니다.

이 접근 방식은 애플리케이션 코드에 논리를 추가하여 작업의 균형을 조정하거나 쓰기 작업에 올바른 연결이 사용되고 있는지 확인하려는 경우에 유용할 수 있습니다. 이 기법은 단일 마스터 복제를 사용하는 Aurora 클러스터에만 적용됩니다. 멀티 마스터 클러스터의 경우에는 모든 DB 인스턴스가 innodb_read_only=OFF 설정을 가집니다.

Aurora MySQL 성능 및 크기 조정에 대한 모범 사례

Aurora MySQL 클러스터의 성능과 확장성을 개선하기 위해 적용할 수 있는 모범 사례는 다음과 같습니다.

개발 및 테스트에 T 인스턴스 클래스 사용

db.t2, db.t3 또는 db.t4g DB 인스턴스 클래스를 사용하는 Amazon Aurora MySQL 인스턴스는 연장된 시간 동안 높은 워크로드를 지원하지 않는 애플리케이션에 가장 적합합니다. T 인스턴스는 중간 정도의 기본 성능을 발휘하면서 워크로드의 필요에 따라 성능을 크게 높이는 버스트 기능을 제공하도록 설계되었습니다. 이러한 인스턴스는 CPU의 최대 성능을 자주 또는 일관적으로 사용하지 않지만 가끔 순간적인 버스트가 필요한 워크로드에 적합합니다. T DB 인스턴스 클래스는 개발 및 테스트 서버 또는 기타 비 프로덕션 서버에만 사용하는 것이 좋습니다. T 인스턴스 클래스에 대한 자세한 내용은 버스트 가능 성능 인스턴스를 참조하세요.

Aurora 클러스터가 40TB보다 큰 경우 T 인스턴스 클래스를 사용하지 마세요. 데이터베이스에 많은 양의 데이터가 있는 경우 스키마 개체를 관리하기 위한 메모리 오버헤드가 T 인스턴스의 용량을 초과할 수 있습니다.

MySQL 성능 스키마를 Amazon Aurora MySQL T 인스턴스에서 활성화하지 마세요. 성능 스키마가 활성화된 경우 인스턴스의 메모리가 부족할 수 있습니다.

작은 정보

데이터베이스가 때로는 유휴 상태이지만 상당한 워크로드가 있을 때도 있는 경우 T 인스턴스의 대안으로 Aurora Serverless v2를 사용할 수 있습니다. Aurora Serverless v2를 사용하는 경우, 용량 범위를 정의하면 Aurora가 현재 워크로드에 따라 데이터베이스를 자동으로 확장 또는 축소합니다. 자세한 내용은 Aurora Serverless v2 사용 단원을 참조하세요. Aurora Serverless v2에서 사용할 수 있는 데이터베이스 엔진 버전은 Aurora Serverless v2에 대한 요구 사항 섹션을 참조하세요.

T 인스턴스를 Aurora MySQL DB 클러스터의 DB 인스턴스로 사용할 때는 다음을 권장합니다.

  • DB 클러스터에서 T 인스턴스를 DB 인스턴스 클래스로 사용하는 경우에는 DB 클러스터의 모든 인스턴스에서 동일한 DB 인스턴스 클래스를 사용하세요. 예를 들어 라이터 인스턴스에 db.t2.medium을(를) 사용하는 경우 리더 인스턴스에 대해서도 db.t2.medium을(를) 사용하는 것이 좋습니다.

  • 메모리 관련 구성 설정을 조정하지 마세요(예: innodb_buffer_pool_size). Aurora 는 T 인스턴스의 메모리 버퍼에 대해 고도로 조정된 기본값 집합을 사용합니다. 이러한 특수 기본값은 메모리가 제한된 인스턴스에서 Aurora 를 실행하는 데 필요합니다. T 인스턴스에서 메모리 관련 설정을 변경하면 버퍼 크기를 늘리려는 경우에도 메모리 부족 조건이 발생할 가능성이 훨씬 큽니다.

  • CPU 크레딧 잔고(CPUCreditBalance)를 모니터링하여 지속 가능한 수준에 있는지 확인합니다. 즉 CPU 크레딧이 사용되고 있는 속도와 동일한 속도로 축적되고 있는지 확인합니다.

    한 인스턴스에 CPU 크레딧을 소진하면 사용 가능한 CPU의 즉각적인 하락과 그 인스턴스에 대한 읽기 및 쓰기 지연 시간의 증가가 표시됩니다. 이로 인해 인스턴스의 전반적인 성능이 크게 떨어집니다.

    CPU 크레딧 잔고가 지속 가능한 수준에 있지 않다면 DB 인스턴스를 수정하여 지원되는 R DB 인스턴스 클래스 중 하나를 사용하도록 하는 것이 좋습니다(컴퓨팅 확장).

    지표 모니터링에 대한 자세한 정보는 Amazon RDS 콘솔에서 지표 보기 단원을 참조하십시오.

  • 단일 마스터 복제를 사용하는 Aurora MySQL DB 클러스터의 경우에는 라이터 인스턴스와 리더 인스턴스 간의 복제본 지연 시간(AuroraReplicaLag)을 모니터링합니다.

    라이터 인스턴스보다 먼저 리더 인스턴스에 CPU 크레딧이 부족하면 결과 지연으로 인해 리더 인스턴스가 자주 다시 시작될 수 있습니다. 애플리케이션에 리더 인스턴스의 많은 양의 읽기 작업이 분산되어 있는 동시에 라이터 인스턴스의 쓰기 작업의 양이 최소한일 때 일반적으로 나타나는 결과입니다.

    복제 지연이 지속적으로 증가하는 경우에는 DB 클러스터의 리더 인스턴스에 대한 CPU 크레딧 잔고가 소진되지 않도록 해야 합니다.

    CPU 크레딧 잔고가 지속 가능한 수준에 있지 않다면 DB 인스턴스를 수정하여 지원되는 R DB 인스턴스 클래스 중 하나를 사용하도록 하는 것이 좋습니다(컴퓨팅 확장).

  • 바이너리 로깅이 활성화된 DB 클러스터에 대해서는 트랜잭션당 삽입의 수를 100만 개 이하로 유지해야 합니다.

    DB 클러스터에 대한 DB 클러스터 파라미터 그룹에서 binlog_format 파라미터가 OFF가 아닌 값으로 설정된 경우, DB 클러스터는 삽입할 행이 100만 개 이상 포함된 트랜잭션을 수신하면 메모리 부족 문제를 겪을 수 있습니다. 여유 메모리(FreeableMemory) 지표를 모니터링하여 DB 클러스터에 사용 가능 메모리가 부족한지 확인할 수 있습니다. 그런 다음 쓰기 작업(VolumeWriteIOPS) 지표를 점검하여 라이터 인스턴스가 많은 양의 쓰기 작업을 수신 중인지 확인할 수 있습니다. 그렇다면 애플리케이션을 업데이트하여 트랜잭션 내 삽입 수를 100만 개 미만으로 제한하는 것이 좋습니다. 또는 지원되는 R DB 인스턴스 클래스(컴퓨팅 확장) 중 하나를 사용하도록 인스턴스를 수정할 수 있습니다.

비동기식 키 프리페치를 사용하여 Amazon Aurora 인덱싱된 조인 쿼리 최적화

참고

비동기식 키 미리 가져오기(AKP) 기능은 Amazon Aurora MySQL 1.15 이후 버전에서 사용할 수 있습니다. Aurora MySQL 버전에 대한 자세한 내용은 Amazon Aurora MySQL에 대한 데이터베이스 엔진 업데이트 단원을 참조하십시오.

Amazon Aurora은 AKP를 사용하여 여러 인덱스 사이에 테이블을 조인하는 쿼리 성능을 높일 수 있습니다. 이 기능은 JOIN 쿼리에서 Batched Key Access(BKA) 조인 알고리즘과 Multi-Range Read(MRR) 최적화 기능을 사용해야 하는 쿼리를 실행하면서 필요한 행을 예측하여 성능을 높이는 효과가 있습니다. BKA 및 MRR에 대한 자세한 정보는 MySQL 설명서에서 Block Nested-Loop and Batched Key Access JoinsMulti-Range Read Optimization을 참조하십시오.

쿼리가 AKP 기능을 이용하기 위해서는 BKA와 MRR이 모두 필요합니다. 일반적으로 JOIN 절이 보조 인덱스를 사용하지만 기본 인덱스의 열도 일부 필요할 때 이러한 쿼리가 발생합니다. 예를 들어 JOIN 절이 작은 용량의 외부 테이블과 큰 용량의 내부 테이블 사이에서 인덱스 값을 기준으로 한 등가 조인을 나타내고, 테이블 용량이 커질수록 인덱스 선택의 폭이 매우 제한적일 때 AKP를 사용할 수 있습니다. AKP는 JOIN 절을 평가하는 동안 BKA 및 MRR과 함께 보조-기본 인덱스 조회를 실행합니다. 동시에 쿼리를 실행하는 데 필요한 행까지 식별합니다. 그런 다음 쿼리를 실행하기에 앞서 백그라운드 스레드를 사용하여 식별된 행이 포함된 페이지를 메모리에 비동기식으로 로드합니다.

비동기식 키 미리 가져오기(AKP) 활성화

MySQL 서버 변수 aurora_use_key_prefetchon으로 설정하여 AKP 기능을 활성화할 수 있습니다. 기본적으로 이 값은 on로 설정됩니다. 하지만 먼저 BKA 조인 알고리즘을 활성화하고 비용 기반 MRR 기능을 비활성화해야만 AKP를 활성화할 수 있습니다. 이를 위해서는 optimizer_switch MySQL 서버 변수의 값을 다음과 같이 설정해야 합니다.

  • batched_key_accesson로 설정합니다. 이 값은 BKA 조인 알고리즘의 사용을 제어합니다. 기본적으로 이 값은 off로 설정됩니다.

  • mrr_cost_basedoff로 설정합니다. 이 값은 비용 기반 MRR 기능의 사용을 제어합니다. 기본적으로 이 값은 on로 설정됩니다.

현재는 세션 수준에서만 위의 두 값을 설정할 수 있습니다. 다음은 SET 문에서 위의 두 값을 설정하여 현재 세션에 AKP를 활성화하는 방법을 설명한 예제입니다.

mysql> set @@session.aurora_use_key_prefetch=on; mysql> set @@session.optimizer_switch='batched_key_access=on,mrr_cost_based=off';

마찬가지로 다음 예제와 같이 SET 문을 사용하여 AKP와 BKA 조인 알고리즘을 비활성화한 후 현재 세션에 비용 기반 MRR 기능을 다시 활성화할 수 있습니다.

mysql> set @@session.aurora_use_key_prefetch=off; mysql> set @@session.optimizer_switch='batched_key_access=off,mrr_cost_based=on';

batched_key_accessmrr_cost_based 옵티마이저 스위치에 대한 자세한 정보는 MySQL 설명서에서 Switchable Optimizations를 참조하십시오.

비동기식 키 미리 가져오기를 위한 쿼리 최적화

쿼리의 AKP 기능 사용 여부를 확인할 수 있습니다. 이렇게 하려면 쿼리를 실행하기 전에 EXPLAIN 문을 사용하여 쿼리를 프로파일링하면 됩니다. EXPLAIN 문이 지정한 쿼리에 사용할 실행 계획에 대한 정보를 제공합니다.

Extra 문 출력에서 EXPLAIN 열은 실행 계획에 추가되는 정보에 대한 설명입니다. AKP 기능이 쿼리에 사용할 테이블에 적용되는 경우 이 열에 다음 값 중 하나가 포함됩니다.

  • Using Key Prefetching

  • Using join buffer (Batched Key Access with Key Prefetching)

EXPLAIN을 사용하여 AKP를 이용할 수 있는 쿼리의 실행 계획을 확인하는 예는 다음과 같습니다.

mysql> explain select sql_no_cache -> ps_partkey, -> sum(ps_supplycost * ps_availqty) as value -> from -> partsupp, -> supplier, -> nation -> where -> ps_suppkey = s_suppkey -> and s_nationkey = n_nationkey -> and n_name = 'ETHIOPIA' -> group by -> ps_partkey having -> sum(ps_supplycost * ps_availqty) > ( -> select -> sum(ps_supplycost * ps_availqty) * 0.0000003333 -> from -> partsupp, -> supplier, -> nation -> where -> ps_suppkey = s_suppkey -> and s_nationkey = n_nationkey -> and n_name = 'ETHIOPIA' -> ) -> order by -> value desc; +----+-------------+----------+------+-----------------------+---------------+---------+----------------------------------+------+----------+-------------------------------------------------------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | filtered | Extra | +----+-------------+----------+------+-----------------------+---------------+---------+----------------------------------+------+----------+-------------------------------------------------------------+ | 1 | PRIMARY | nation | ALL | PRIMARY | NULL | NULL | NULL | 25 | 100.00 | Using where; Using temporary; Using filesort | | 1 | PRIMARY | supplier | ref | PRIMARY,i_s_nationkey | i_s_nationkey | 5 | dbt3_scale_10.nation.n_nationkey | 2057 | 100.00 | Using index | | 1 | PRIMARY | partsupp | ref | i_ps_suppkey | i_ps_suppkey | 4 | dbt3_scale_10.supplier.s_suppkey | 42 | 100.00 | Using join buffer (Batched Key Access with Key Prefetching) | | 2 | SUBQUERY | nation | ALL | PRIMARY | NULL | NULL | NULL | 25 | 100.00 | Using where | | 2 | SUBQUERY | supplier | ref | PRIMARY,i_s_nationkey | i_s_nationkey | 5 | dbt3_scale_10.nation.n_nationkey | 2057 | 100.00 | Using index | | 2 | SUBQUERY | partsupp | ref | i_ps_suppkey | i_ps_suppkey | 4 | dbt3_scale_10.supplier.s_suppkey | 42 | 100.00 | Using join buffer (Batched Key Access with Key Prefetching) | +----+-------------+----------+------+-----------------------+---------------+---------+----------------------------------+------+----------+-------------------------------------------------------------+ 6 rows in set, 1 warning (0.00 sec)

EXPLAIN 출력 형식에 대한 자세한 내용은 MySQL 제품 설명서의 Extended EXPLAIN output format(확장된 EXPLAIN 출력 형식)을 참조하세요.

참고

MySQL 5.6 호환 및 이전 5.7 호환 버전의 경우 EXTENDED 키워드와 함께 EXPLAIN 문을 사용합니다. MySQL 5.7 및 8.0에서는 해당 키워드가 더 이상 사용되지 않습니다.

MySQL 5.6의 확장된 EXPLAIN 출력 형식에 대한 자세한 내용은 MySQL 제품 설명서의 Extended EXPLAIN output format(확장된 EXPLAIN 출력 형식)을 참조하세요.

해시 조인을 사용하여 대규모 Aurora MySQL 조인 쿼리 최적화

동등 조인을 사용하여 많은 양의 데이터를 조인해야 하는 경우 해시 조인을 통해 쿼리 성능을 향상시킬 수 있습니다. Aurora MySQL의 해시 조인을 활성화할 수 있습니다.

해시 조인 열은 복잡한 표현식이 될 수 있습니다. 해시 조인 열에서 다음과 같은 방식으로 데이터 유형을 비교할 수 있습니다.

  • int, bigint, numericbit 등과 같은 정확한 숫자 데이터 형식 범주의 모든 항목을 비교할 수 있습니다.

  • floatdouble과 같은 대략적인 숫자 데이터 형식 범주의 모든 항목을 비교할 수 있습니다.

  • 문자열 유형에 동일한 문자 세트와 콜레이션이 있는 경우 문자열 유형간에 항목을 비교할 수 있습니다.

  • 유형이 동일한 경우 날짜 및 타임스탬프 데이터 형식으로 항목을 비교할 수 있습니다.

참고

다른 범주의 데이터 유형은 비교할 수 없습니다.

Aurora MySQL의 해시 조인에는 다음의 제한 사항이 적용됩니다.

  • 왼쪽 오른쪽 외부 조인은 Aurora MySQL 버전 1 및 2에서는 지원되지 않지만, 버전 3에서는 지원됩니다.

  • 하위 쿼리가 구체화되지 않는 한 하위 쿼리와 같은 Semijoin은 지원되지 않습니다.

  • 다중 테이블의 업데이트 또는 삭제는 지원되지 않습니다.

    참고

    단일 테이블의 업데이트 또는 삭제는 지원되지 않습니다.

  • BLOB 및 공간 데이터 유형 열은 해시 조인의 조인 열일 수 없습니다.

해시 조인 활성화

해시 조인을 활성화하려면 MySQL 서버 변수 optimizer_switchhash_join=on(Aurora MySQL 버전 1과 2) 또는 block_nested_loop=on(Aurora MySQL 버전 3)으로 설정하세요. 해시 조인은 Aurora MySQL 버전 3에서 기본적으로 켜져 있습니다. 이 최적화는 Aurora MySQL 버전 1과 2에서 기본적으로 꺼져 있습니다. 다음은 해시 조인을 활성화하는 방법을 설명한 예입니다. 먼저 select @@optimizer_switch 문을 발행하여 다른 설정이 SET 파라미터 문자열에 있는지 확인합니다. optimizer_switch 파라미터에서 설정 하나를 업데이트하면 다른 설정을 지우거나 수정하지 못합니다.

For Aurora MySQL version 1 and 2: mysql> SET optimizer_switch='hash_join=on'; For Aurora MySQL version 3: mysql> SET optimizer_switch='block_nested_loop=on';
참고

Aurora MySQL 버전 3의 경우 해시 조인 지원은 모든 부 버전에서 사용할 수 있으며 기본적으로 켜져 있습니다.

Aurora MySQL 2 버전의 경우, 버전 2.06 이상에서 해시 조인 지원을 사용할 수 있습니다. Aurora MySQL 2 버전에서 해시 조인 기능은 항상 optimizer_switch 값에 의해 제어됩니다.

Aurora MySQL 1.22 이전 버전의 경우, Aurora MySQL 1 버전에서 해시 조인을 활성화하는 방법은 aurora_lab_mode 세션 수준 설정을 사용하는 것입니다. 이러한 Aurora MySQL 버전에서는 해시 조인에 대한 optimizer_switch 설정이 기본적으로 활성화되어 있으므로 aurora_lab_mode를 활성화하기만 하면 됩니다.

이 설정을 사용하면 옵티마이저는 비용, 쿼리 특성 및 리소스 가용성을 기반으로 해시 조인을 사용하도록 선택합니다. 비용 견적이 정확하지 않으면 옵티마이저가 해시 조인을 선택하게 할 수 있습니다. 그렇게 하려면 MySQL 서버 변수 hash_join_cost_basedoff으로 설정합니다. 다음은 옵티마이저가 해시 조인을 선택하도록 하는 방법을 설명한 예제입니다.

mysql> SET optimizer_switch='hash_join_cost_based=off';
참고

이 설정은 비용 기반 옵티마이저의 결정보다 우선합니다. 이 설정은 테스트 및 개발에 유용할 수 있지만, 프로덕션 환경에서는 사용하지 않는 것이 좋습니다.

해시 조인에 대한 쿼리 최적화

쿼리가 해시 조인을 활용할 수 있는지 확인하려면 EXPLAIN 문을 사용하여 쿼리를 먼저 프로파일링하십시오. EXPLAIN 문이 지정한 쿼리에 사용할 실행 계획에 대한 정보를 제공합니다.

Extra 문 출력에서 EXPLAIN 열은 실행 계획에 추가되는 정보에 대한 설명입니다. 해시 조인이 쿼리에 사용할 테이블에 적용되는 경우 이 열에 다음과 비슷한 값이 포함됩니다.

  • Using where; Using join buffer (Hash Join Outer table table1_name)

  • Using where; Using join buffer (Hash Join Inner table table2_name)

다음은 EXPLAIN을 사용하여 해시 조인 쿼리의 실행 계획을 확인하는 예제입니다.

mysql> explain SELECT sql_no_cache * FROM hj_small, hj_big, hj_big2 -> WHERE hj_small.col1 = hj_big.col1 and hj_big.col1=hj_big2.col1 ORDER BY 1; +----+-------------+----------+------+---------------+------+---------+------+------+----------------------------------------------------------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+----------+------+---------------+------+---------+------+------+----------------------------------------------------------------+ | 1 | SIMPLE | hj_small | ALL | NULL | NULL | NULL | NULL | 6 | Using temporary; Using filesort | | 1 | SIMPLE | hj_big | ALL | NULL | NULL | NULL | NULL | 10 | Using where; Using join buffer (Hash Join Outer table hj_big) | | 1 | SIMPLE | hj_big2 | ALL | NULL | NULL | NULL | NULL | 15 | Using where; Using join buffer (Hash Join Inner table hj_big2) | +----+-------------+----------+------+---------------+------+---------+------+------+----------------------------------------------------------------+ 3 rows in set (0.04 sec)

출력에서 Hash Join Inner table은 해시 테이블을 작성하는 데 사용하는 테이블이며 Hash Join Outer table은 해시 테이블을 프로브하는 데 사용하는 테이블입니다.

확장된 EXPLAIN 출력 형식에 대한 자세한 정보는 MySQL 제품 설명서에서 Extended EXPLAIN Output Format을 참조하십시오.

Aurora MySQL 2.08 이상에서는 SQL 힌트를 사용하여 쿼리에서 해시 조인을 사용하는지 여부와 조인의 빌드 및 프로브 측에 사용할 테이블에 영향을 줄 수 있습니다. 자세한 내용은 Aurora MySQL 힌트 단원을 참조하십시오.

Amazon Aurora를 사용하여 MySQL 데이터베이스 읽기 조정

MySQL DB 인스턴스에서 Amazon Aurora를 사용하여 Amazon Aurora의 읽기 조정 기능을 활용하고 MySQL DB 인스턴스에 대한 읽기 작업을 확장할 수 있습니다. Aurora을 사용하여 MySQL DB 인스턴스에 대한 읽기 조정을 수행하려면 Aurora MySQL DB 클러스터를 생성한 후 이 클러스터를 MySQL DB 인스턴스의 읽기 전용 복제본으로 설정합니다. 그런 다음 Aurora MySQL 클러스터에 연결하여 읽기 쿼리를 처리합니다. 이러한 설정은 RDS for MySQL DB 인스턴스 또는 Amazon RDS 외부에서 실행 중인 MySQL 데이터베이스에 적용됩니다. 자세한 정보는 Amazon Aurora를 사용하여 MySQL 데이터베이스 읽기 조정을 참조하십시오.

Aurora MySQL 고가용성을 위한 모범 사례

Aurora MySQL 클러스터의 유효성을 개선하기 위해 적용할 수 있는 모범 사례는 다음과 같습니다.

MySQL 데이터베이스에서 Amazon Aurora를 재해 복구용으로 사용

MySQL DB 인스턴스에서 Amazon Aurora를 사용하여 재해 복구용 오프사이트 백업을 생성할 수 있습니다. MySQL DB 인스턴스의 재해 복구용으로 Aurora을 사용하려면 Amazon Aurora DB 클러스터를 생성한 후 이 클러스터를 MySQL DB 인스턴스의 읽기 전용 복제본으로 설정합니다. 이러한 설정은 RDS for MySQL DB 인스턴스 또는 Amazon RDS 외부에서 실행 중인 MySQL 데이터베이스에 적용됩니다.

중요

MySQL DB 인스턴스와 Amazon Aurora MySQL DB 클러스터 간의 복제를 설정할 때 필요할 경우 정상 상태를 유지하고 수리하는지 확인하도록 복제를 모니터링해야 합니다.

Amazon Aurora MySQL DB 클러스터를 생성하고 이 클러스터를 MySQL DB 인스턴스의 읽기 전용 복제본으로 설정하는 방법에 대한 자세한 정보는 Amazon Aurora를 사용하여 MySQL 데이터베이스 읽기 조정의 절차를 따르십시오.

재해 복구 모델에 대한 자세한 내용은 Amazon Aurora MySQL 클러스터에 가장 적합한 재해 복구 옵션을 선택하는 방법을 참조하세요.

감소된 중단 시간으로 MySQL에서 Amazon Aurora MySQL로 마이그레이션

라이브 애플리케이션을 지원하는 MySQL 데이터베이스에서 Amazon Aurora MySQL DB 클러스터로 데이터를 가져올 때 마이그레이션하는 동안 서비스가 중단되는 시간을 줄일 수 있습니다. 그렇게 하려면 Amazon Relational Database Service 사용 설명서가동 중지 시간을 단축하여 MySQL 또는 MariaDB DB 인스턴스로 데이터 가져오기에 나온 절차를 따르세요. 이 절차는 대규모 데이터베이스로 작업하는 경우에 특히 유용합니다. 이 프로시저를 사용하여 네트워크에서 AWS로 전달되는 데이터의 양을 최소화하여 가져오기 비용을 줄일 수 있습니다.

이 절차에는 데이터베이스 데이터의 복사본을 Amazon EC2 인스턴스로 전송하고 데이터를 새 RDS for MySQL DB 인스턴스로 가져오는 작업을 수행하는 단계가 나열되어 있습니다. Amazon Aurora가 MySQL과 호환되므로 Amazon Aurora DB 클러스터를 대상 Amazon RDS MySQL DB 인스턴스로 대신 사용할 수 있습니다.

Aurora MySQL DB 인스턴스의 성능 저하, 자동 재시작 및 장애 조치 방지

워크로드가 많거나 워크로드가 DB 인스턴스의 할당된 리소스 이상으로 급증하는 경우 애플리케이션과 Aurora 데이터베이스를 실행하는 데 사용되는 리소스가 소진될 수 있습니다. CPU 사용률, 메모리 사용량, 사용된 데이터베이스 연결 수와 같은 데이터베이스 인스턴스에 대한 지표를 얻으려면 Amazon CloudWatch, 성능 개선 도우미 및 향상된 모니터링에서 제공하는 지표를 참조할 수 있습니다. DB 인스턴스 모니터링에 대한 자세한 내용은 Amazon Aurora 클러스터에서 지표 모니터링 섹션을 참조하세요.

워크로드가 사용 중인 리소스를 소진하면 DB 인스턴스가 느려지거나, 다시 시작되거나, 다른 DB 인스턴스로 장애 조치될 수 있습니다. 이를 방지하려면 리소스 사용률을 모니터링하고, DB 인스턴스에서 실행되는 워크로드를 검사하고, 필요한 경우 최적화하세요. 최적화가 인스턴스 지표를 개선하지 못하고 리소스 소진을 완화할 수 없다면 한도에 도달하기 전에 DB 인스턴스를 스케일 업하는 것을 고려해 보세요. 사용 가능한 DB 인스턴스 클래스 및 사양에 대한 자세한 내용은 Aurora DB 인스턴스 클래스 섹션을 참조하세요.

MySQL 기능에 대한 권장 사항

다음 기능은 MySQL 호환성을 위해 Aurora MySQL에서 사용할 수 있습니다. 그러나 Aurora 환경에서는 성능, 확장성, 안정성 또는 호환성 문제가 있습니다. 따라서 이러한 기능을 사용할 때 정해진 가이드라인을 따르는 것이 좋습니다. 예를 들어 프로덕션 Aurora 배포에는 특정 기능을 사용하지 않는 것이 좋습니다.

Aurora MySQL 버전 3에서 멀티스레드 복제 사용

기본적으로 Aurora은 Aurora MySQL DB 클러스터가 이진 로그 복제의 읽기 전용 복제본으로 사용될 때 단일 스레드 복제를 사용합니다.

Aurora MySQL은 멀티스레드 복제를 금지하지 않지만 이 기능은 Aurora MySQL 버전 3 이상에서만 지원됩니다.

Aurora MySQL 버전 1과 2는 MySQL에서 다중 스레드 복제와 관련된 여러 문제를 물려받았습니다. 이러한 버전의 경우 프로덕션 환경에서 다중 스레드 복제를 사용하지 않는 것이 좋습니다.

다중 스레드 복제를 사용할 경우 모든 사용을 철저히 테스트할 것을 권장합니다.

Amazon Aurora에서의 복제에 대한 자세한 정보는 Amazon Aurora를 사용한 복제 단원을 참조하십시오. Aurora MySQL 버전 3의 멀티스레드 복제에 대한 자세한 내용은 다중 스레드 이진 로그 복제(Aurora MySQL 버전 3 이상) 섹션을 참조하세요.

네이티브 MySQL 함수로 AWS Lambda 함수 호출

Amazon Aurora 버전 1.16 이상을 사용하는 경우 lambda_synclambda_async 네이티브 MySQL 함수를 사용하여 Lambda 함수를 호출하는 것이 좋습니다.

더 이상 사용되지 않는 mysql.lambda_async 프로시저를 사용하는 경우 저장 프로시저의 mysql.lambda_async 프로시저로 호출하는 것이 좋습니다. 트리거 또는 클라이언트 코드와 같은 여러 소스에서 저장 프로시저를 호출할 수 있습니다. 이 접근 방식을 통해 임피던스 불일치 문제를 방지하고 데이터베이스 프로그래머가 Lambda 함수를 보다 쉽게 호출할 수 있습니다.

Amazon Aurora에서 Lambda 함수 호출에 대한 자세한 정보는 Amazon Aurora MySQL DB 클러스터에서 Lambda 함수 호출 단원을 참조하십시오.

Amazon Aurora MySQL에서 XA 트랜잭션 방지

XA가 PREPARED 상태인 경우 복구 시간이 길어질 수 있으므로 Aurora MySQL에서 XA(eXtended Architecture) 트랜잭션을 사용하지 않는 것이 좋습니다. Aurora MySQL에서 XA 트랜잭션을 사용해야 하는 경우 다음 모범 사례를 따르십시오.

  • XA 트랜잭션을 PREPARED 상태로 열어두지 마십시오.

  • XA 트랜잭션을 가능한 작게 유지하십시오.

MySQL에서 XA 트랜잭션 사용에 대한 자세한 정보는 MySQL 설명서의 XA TRANSACTIONS를 참조하십시오.

DML 문 동안 외래 키 켜기 유지

foreign_key_checks 변수가 0(off)으로 설정되어 있을 때는 데이터 정의 언어(DDL) 문을 실행하지 않는 것이 좋습니다.

외래 키의 일시적 위반이 필요한 행을 삽입하거나 업데이트해야 하는 경우, 다음 단계에 따르십시오.

  1. foreign_key_checks0로 설정합니다.

  2. 데이터 조작 언어(DML)를 변경합니다.

  3. 완료된 변경이 외래 키 제약 조건을 위반하지 않아야 합니다.

  4. foreign_key_checks1(on)로 설정합니다.

또한 외래 키 제약 조건에 대한 다음과 같은 다른 모범 사례에 따르십시오.

  • 클라이언트 애플리케이션이 init_connect 변수의 일부로 foreign_key_checks 변수를 0으로 설정하지 않아야 합니다.

  • mysqldump와 같은 논리적 백업으로부터 복원이 실패하거나 불완전할 경우, 같은 세션에서 다른 작업을 시작하기 전에 foreign_key_checks1로 설정되어 있는지 확인합니다. 논리적 백업은 시작할 때 foreign_key_checks0으로 설정합니다.

로그 버퍼를 플러시하는 빈도 구성

MySQL Community Edition에서 트랜잭션의 내구성을 높이려면 InnoDB 로그 버퍼를 내구성 있는 스토리지로 플러시해야 합니다. innodb_flush_log_at_trx_commit 파라미터를 사용하여 로그 버퍼가 디스크로 플러시되는 빈도를 구성합니다.

innodb_flush_log_at_trx_commit 파라미터를 기본값인 1로 설정하면 트랜잭션이 커밋될 때마다 로그 버퍼가 플러시됩니다. 이 설정은 데이터베이스 ACID 준수 상태를 유지하는 데 도움이 됩니다. 기본 설정인 1을 그대로 유지하는 것이 좋습니다.

innodb_flush_log_at_trx_commit을 기본값이 아닌 값인 0 또는 2로 변경하면 데이터 조작 언어(DML) 지연 시간을 줄이는 데 도움이 되지만 로그 레코드의 내구성은 저하될 수 있습니다. 이러한 내구성 결여로 인해 데이터베이스 ACID 규정을 준수하지 못하게 됩니다. 서버 재시작 시 데이터 손실 위험을 예방하기 위해 데이터베이스를 ACID 규정을 준수하는 것이 좋습니다. 이 파라미터에 대한 자세한 내용은 MySQL 설명서에서 innodb_flush_log_at_trx_commit을 참조하세요.

Aurora MySQL에서는 다시 실행 로그 처리가 스토리지 계층으로 오프로드되므로 DB 인스턴스에서 로그 파일을 플러시하지 않습니다. 쓰기가 실행되면 라이터 DB 인스턴스에서 Aurora 클러스터 볼륨으로 직접 다시 실행 로그가 전송됩니다. 네트워크를 통과하는 유일한 쓰기는 다시 실행 로그 레코드입니다. 데이터베이스 계층에서 작성되는 페이지는 없습니다.

기본적으로 Aurora MySQL에서는 innodb_flush_log_at_trx_commit 파라미터가 1로 설정됩니다. 트랜잭션을 커밋하는 각 스레드는 Aurora 클러스터 볼륨의 확인을 기다립니다. 이 확인은 이 레코드와 모든 이전 다시 실행 로그 레코드가 기록되어 쿼럼을 얻었음을 나타냅니다. 로그 레코드를 유지하고 쿼럼을 얻으면 자동 커밋이든 명시적 커밋이든 관계없이 트랜잭션의 내구성이 확보됩니다. Aurora 스토리지 아키텍처에 대한 자세한 내용은 Amazon Aurora 스토리지에 관한 이해를 돕는 문서를 참조하세요.

Aurora MySQL은 MySQL Community Edition처럼 로그를 데이터 파일로 플러시하지 않습니다. 하지만 innodb_flush_log_at_trx_commit 파라미터를 사용하여 다시 실행 로그 레코드를 Aurora 클러스터 볼륨에 쓸 때 내구성 제약을 완화할 수 있습니다. innodb_flush_log_at_trx_commit을 기본값이 아닌 값(0 또는 2)으로 설정하면 데이터베이스는 다시 실행 로그 레코드가 Aurora 클러스터 볼륨에 기록된다는 확인을 기다리지 않습니다. 이러한 설정은 클라이언트에 대한 DML 지연 시간을 줄일 수 있지만 장애 조치 또는 재시작 시 데이터가 손실될 수도 있습니다. 따라서 innodb_flush_log_at_trx_commit 파라미터를 기본값 1로 유지하는 것이 좋습니다.

MySQL Community Edition과 Aurora MySQL 모두에서 데이터 손실이 발생할 수 있지만 아키텍처가 다르기 때문에 데이터베이스마다 동작이 다릅니다. 이러한 아키텍처 차이로 인해 데이터 손실 정도가 달라질 수 있습니다. 데이터베이스가 ACID 규정을 준수하도록 하려면 innodb_flush_log_at_trx_commit을 항상 1로 설정하세요.

참고

Aurora MySQL 버전 3에서는 innodb_flush_log_at_trx_commit 파라미터를 구성할 수 없습니다. Aurora MySQL 버전 3에서는 ACID를 준수하는 기본 설정 1을 항상 사용합니다.