5. 3. 통계 쿼리 속도 비교
server type 수행시간 순위
IDC FIO (24core 64GB) 34분 47초 2
aurora r3.2x ( 8core 61GB) - (lost connection 으로 인해 결과 없음)
aurora r3.4x (16core 122GB) - (lost connection 으로 인해 결과 없음)
aurora r3.8x (32core 244GB) 1시간 20분 17초 4
EC2 r3.8x (32core 244GB) 52분 26초 3
EC2 r3.8x (32core 244GB) 2시간 54초 5
EC2 r3.8x (32core 244GB) 31분 5초 1
테스트 결과
AWS SR 답변 내용
6. 4. Alter 속도 비교
server type 수행시간 순위
IDC FIO (24core 64GB) 2016-06-16 15:26:37 ~ 2016-06-17 01:25:16 (9시간 58분 39초) 1
aurora r3.2x ( 8core 61GB) - (/tmp 크기 제약으로 인해 실패)
aurora r3.4x (16core 122GB) 2016-06-14 10:52:21 ~ 2016-06-15 01:49:16 (14시간 56분 55초) 5
aurora r3.8x (32core 244GB) 2016-06-14 10:52:21 ~ 2016-06-14 24:36:15 (13시간 43분 54초) 2
EC2 r3.8x (32core 244GB) 2016-06-15 16:03:41 ~ 2016-06-16 09:22:46 (17시간 19분 5초) 6
EC2 r3.8x (32core 244GB) 2016-08-18 17:39:37 ~ 2016-08-19 07:28:08 (13시간 49분 31초) 4
EC2 r3.8x (32core 244GB) 2016-08-17 18:56:44 ~ 2016-08-18 08:41:45 (13시간 45분 1초) 3
테스트 결과
테스트 방법
- 200GB 크기의 테이블에 datetime 컬럼 추가 후 속도 측정
- alter table 데이터베이스.테이블 add 컬럼 datetime(6) default null
server class /tmp size
db.r3.l 20 GB
db.r3.xl 60 GB
db.r3.2xl 120 GB
db.r3.4xl 250 GB
db.r3.8xl 420 GB
Aurora DB 클래스 별 /tmp 크기
7. 5. OLTP 부하 테스트
server type read write transaction time 순위
IDC FIO (24core 64GB) 14000238 (29228.05 per sec) 4000068 (8350.87 per sec) 1000017 (2084.99 per sec) 479 sec 1
aurora r3.2x ( 8core 61GB) 14015414 (10474.01 per sec) 4004402 (2992.82 per sec) 1001100 ( 748.14 per sec) 1338 sec 6
aurora r3.4x (16core 122GB) 14001400 (12568.58 per sec) 4000389 (3591.01 per sec) 1000096 ( 897.14 per sec) 1114 sec 5
aurora r3.8x (32core 244GB) 14013006 ( 9093.44 per sec) 4003711 (2598.12 per sec) 1000927 ( 649.50 per sec) 1541 sec 7
EC2 r3.8x (32core 244GB) 14001330 (19664.78 per sec) 4000380 (5618.51 per sec) 1000095 (1404.45 per sec) 712 sec 4
EC2 r3.8x (32core 244GB) 14002436 (22372 per sec) 4000696 (6392 per sec) 1000174 (1598.00 per sec) 625 sec 3
EC2 r3.8x (32core 244GB) 14002772 (23399.55 per sec) 4000792 (6685.58 per sec) 1000198 (1671.40 per sec) 598 sec 2
테스트 결과
테스트 방법
- 32개 thread에서 20개 테이블에 100만 transaction(read+write)을 발생시켜 처리속도 비교
실행 구문
sysbench --test=/sysbench경로/sysbench/tests/db/oltp.lua --num-threads=32 --max-time=0 --max-requests=1000000
--oltp_tables_count=20 --report-interval=1 --oltp-table-size=100000 --mysql-user=root --mysql-password=비밀번호
--mysql-table-engine=innodb --rand-init=on --mysql-db=test --mysql-host=mysql DB IP(or DNS) run
8. 5. OLTP 부하 테스트
테스트 결과
테스트 방법
- 500개 thread에서 250개 테이블에 600초 동안 read 수행 후 처리량 비교
실행 구문
sysbench --test=/sysbench경로/sysbench/tests/db/oltp.lua --oltp-tables-count=250 --mysql-user=root --mysql-password=비밀번호
--mysql-port=3306 --db-driver=mysql --oltp-table-size=25000 --mysql-db=test --max-requests=0 --oltp-simple-ranges=0
--oltp-distinct-ranges=0 --oltp-sum-ranges=0 --oltp-order-ranges=0 --max-time=600 --oltp-read-only=on --num-threads=500
--mysql-host=mysql DB IP(or DNS) run
server type read write transaction time 순위
IDC FIO (24core 64GB) 89390780 (148984.63 per sec) 0 8939078 (14897.42 per sec) 600 sec 2
aurora r3.2x ( 8core 61GB) 32496890 ( 54161.48 per sec) 0 3249689 ( 5415.68 per sec) 600 sec 7
aurora r3.4x (16core 122GB) 48923680 ( 81539.46 per sec) 0 4892368 ( 8143.30 per sec) 600 sec 5
aurora r3.8x (32core 244GB) 49568430 ( 82614.05 per sec) 0 4956843 ( 8257.13 per sec) 600 sec 4
EC2 r3.8x (32core 244GB) 48582260 ( 80970.43 per sec) 0 4858226 ( 8091.53 per sec) 600 sec 6
EC2 r3.8x (32core 244GB) 85345360 (142231.61 per sec) 0 8534536 (14223.16 per sec.) 600 sec 3
EC2 r3.8x (32core 244GB) 94708710 (157847.85 per sec) 0 9470871 (15783.79 per sec.) 600 sec 1
참고 사이트 : https://d0.awsstatic.com/product-marketing/Aurora/RDS_Aurora_Performance_Assessment_Benchmarking_v1-2.pdf
9. 5. OLTP 부하 테스트
테스트 결과
테스트 방법
- 1000개 thread에서 250개 테이블에 600초 동안 write 수행 후 처리량 비교
실행 구문
sysbench --test=/sysbench경로/sysbench/tests/db/oltp.lua --oltp-tables-count=250 --mysql-user=root --mysql-password=비밀번호
--mysql-port=3306 --db-driver=mysql --oltp-table-size=25000 --mysql-db=test --max-requests=0 --max-time=600
--oltp_simple_ranges=0 --oltp-distinct-ranges=0 --oltp-sum-ranges=0 --oltp-order-ranges=0 --oltp-point-selects=0
--num-threads=1000 --mysql-host=mysql DB IP(or DNS) run
server type read write transaction time 순위
IDC FIO (24core 64GB) 0 39269677 (65449.46 per sec) 9817414 (16360.60 per sec.) 600 sec 1
aurora r3.2x ( 8core 61GB) 0 11818545 (19697.57 per sec) 2954584 ( 4922.97 per sec) 600 sec 4
aurora r3.4x (16core 122GB) 0 18581074 (30968.45 per sec) 4645182 ( 7740.81 per sec) 600 sec 3
aurora r3.8x (32core 244GB) 0 21451006 (35751.67 per sec) 5362635 ( 8933.87 per sec) 600 sec 2
EC2 r3.8x (32core 244GB) 0 7158665 (11931.10 per sec) 1789664 ( 2971.14 per sec) 600 sec 7
EC2 r3.8x (32core 244GB) 0 7341178 (12228.16 per sec.) 1835293 ( 3057.04 per sec) 600 sec 6
EC2 r3.8x (32core 244GB) 0 7422540 (12364.14 per sec) 1855634 ( 3091.03 per sec) 600 sec 5
참고 사이트 : https://d0.awsstatic.com/product-marketing/Aurora/RDS_Aurora_Performance_Assessment_Benchmarking_v1-2.pdf
10. 6. 제약사항 및 해결방안
1. /tmp 영역에 대한 크기 제약
- aurora DB 클래스 별 /tmp 크기 제약
- RDS는 인스턴스 생성 시 data, log, tmp 영역의 크기를 계산하여 디스크 볼륨 할당 필요
- 해결방안 : 클래스별 /tmp 크기에 따라 테이블 사이즈에 제한을 두고 운영
alter 가 필요한 경우 높은 클래스의 replica를 생성하여 master change 후 진행
2. 통계 쿼리 수행 시 lost connection 발생
- aurora DB의 경우 OLTP 용도로 설계되어 OLAP 용도 쿼리 성능 저하 발생
- 해결방안 : 쿼리의 조건의 범위를 줄여서 여러 번 수행, 별도의 EC2 DB를 replication으로 연결하여 배치용도로 운영
3. lvs 개념의 부재
- EC2 서버에 lvs 설정 시 loop back이나 IP 변조가 되지 않아 lvs 사용 불가
- RDS의 경우 실제 서버 IP는 숨겨져 있고 endpoint(DNS)를 통해 접근하는 방식이어서 여러 개의 DNS를 하나로 묶을 수 없음
- 해결 방안 : RDS -> maria DB JDBC connector 사용 시 load balancing, failover(10~20초) 지원 (java application만 가능)
참고 사이트 : https://mariadb.com/kb/en/mariadb/failover-and-high-availability-with-mariadb-connector-j/
EC2 -> 자체 지원하는 load balancer (ELB)가 있음
AWS에서 DNS 기반으로 failover 지원 및 load balancing 기능 개발 중
4. master change 시 down time 필요
- aurora DB에서 replica 운영 시 master change에 최대 1분의 down time 필요 (replica가 없는 경우 최대 15분의 down time 필요)
참고 사이트 : http://aws.amazon.com/ko/rds/aurora/faqs/ 의 고가용성 및 복제
- 해결 방안 : DB서버로 들어오는 쿼리를 일정시간 막는 기능 필요 (내부 개발자에 의해 개발됨)
5. OS 영역 접근 불가
- RDS 환경인 경우 로컬 디스크에 접근 할 수 없어 쉘 스크립트 사용 할 수 없고 agent 설치가 불가 (모니터링, cdc 등)
- 해결 방안 ; lamda를 사용하여 쉘 기능 대체 (개발을 할 줄 알아야함. 아직 seoul region 미지원)
agentless 방식의 모니터링 사용(exem, cloudwatch, datadog 등)
cdc용도의 EC2 DB를 replication 연결하여 운영
AWS DMS 사용 (8월 초 seoul region 적용)
11. 6. 제약사항 및 해결방안
6. mysql super 권한 X
- RDS 환경인 경우 mysql DB의 super 권한이 없어서 파라미터 변경 구문 사용 불가, change master 구문 사용 불가
- 해결방안 : 파라미터 변경시 parameter group에서 변경 (일부 파라미터의 경우 DB 재시작 후 적용됨)
replication 연결 시 자체 지원 procedure를 통해서 가능
참고 사이트 : http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/Appendix.MySQL.SQLRef.html
7. replication 연결 시 master_host 길이 제약
- RDS의 경우 실제 서버 IP는 숨겨져 있고 endpoint(DNS)를 통해 접근하는 방식
- aurora : identifier.(1개)cluster-(8개)고유값(숫자+영어12개).(1개)리전명(14개).rds.amazonaws.com(18개) -> identifier를 제외하고 54자리
- RDS mysql : identifier.(1개)고유값(숫자+영어12개).(1개)리전명(14개).rds.amazonaws.com(18개) -> identifier를 제외하고 46자리
- change master 구문의 master_host 길이는 varchar 60자리
참고 사이트 : http://dev.mysql.com/doc/refman/5.7/en/change-master-to.html
- 해결방안 : aurora DB를 replication 마스터로 사용할 경우 identifier 길이를 6자 이내로 설정 (RDS mysql은 14자 이내)
identifier를 코드 값으로 설정하고 별도의 테이블에 관리
8. fusion I/O 대비 성능 저하
테스트 내용 1위 2위
replication 속도 비교 IDC FIO (24core 64GB) aurora r3.8x (32core 244GB)
통계쿼리 속도 비교 EC2 r3.8x (32core 244GB) / 디스크 , 파라미터 튜닝 IDC FIO (24core 64GB)
alter 속도 비교 IDC FIO (24core 64GB) aurora r3.8x (32core 244GB)
OLTP read+write IDC FIO (24core 64GB) EC2 r3.8x (32core 244GB) / 디스크 , 파라미터 튜닝
OLTP rerad EC2 r3.8x (32core 244GB) / 디스크 , 파라미터 튜닝 IDC FIO (24core 64GB)
OLTP write IDC FIO (24core 64GB) aurora r3.8x (32core 244GB)
