산동네 게임 DBA 이야기 (어썸피스 홍병기 님)
중요 Configuration
튜닝시 가장중요한건 ?
최소점검시간으로 IDC or Cloud 이전
평소확인해야할것들
NoSQL 에 대해
장애경험 및 조치
CPU 가 100% 가까울때 긴급조치?
OS 메모리 관리의 중요성
샤딩안하고 DML 성능 높이기 ?
샤딩적용은 ?
효율적인 로그관리요령
백업 및 복구
통계 및 머신러닝
회사에서 벌어지는 일들
DBA 피드백
괜찮은 DBA ?
14. 오늘 발표할 내용
- 중요 Configuration
- 튜닝시 가장중요한건 ?
- 최소점검시간으로 IDC or Cloud 이
전
- 평소확인해야할것들
- NoSQL 에 대해
- 장애경험 및 조치
- CPU 가 100% 가까울때 긴급조치?
- OS 메모리 관리의 중요성
- 샤딩안하고 DML 성능 높이기 ?
- 샤딩적용은 ?
- 효율적인 로그관리요령
- 백업 및 복구
- 통계 및 머신러닝
- 회사에서 벌어지는 일들
- DBA 피드백
- 괜찮은 DBA ?
20. MariaDB 의 중요한 옵션은 무엇이고 왜 그런가요 ? (1)
Innodb_flush_log_at_trx_commit
참고 : https://mariadb.com/kb/en/library/innodb-system-
variables/#innodb_flush_log_at_trx_commit
21. MariaDB 의 중요한 옵션은 무엇이고 왜 그런가요 ? (1)
Innodb_flush_log_at_trx_commit
Buffer Pool Log Buffer OS Cash/ Buffer
0
1
2
메모리 영역 디스크 영역
DMLTable
DMLTable
DMLTable
Transaction (Commit/ Rollback)
Transaction (Commit/ Rollback)
Transaction (Commit/ Rollback)
매 1초마다 Write OS Cash & Flush DIsk
매 1초마다 Flush DIsk
22. MariaDB 의 중요한 옵션은 무엇이고 왜 그런가요 ? (1)
Innodb_flush_log_at_trx_commit
Buffer Pool Log Buffer OS Cash/ Buffer
0
1
2
메모리 영역 디스크 영역
DMLTable
DMLTable
DMLTable
Transaction (Commit/ Rollback)
Transaction (Commit/ Rollback)
Transaction (Commit/ Rollback)
매 1초마다 Write OS Cash & Flush DIsk
매 1초마다 Flush DIsk
Durability
23. MariaDB 의 중요한 옵션은 무엇이고 왜 그런가요 ? (1)
Innodb_flush_log_at_trx_commit
Buffer Pool Log Buffer OS Cash/ Buffer
0
1
2
메모리 영역 디스크 영역
DMLTable
DMLTable
DMLTable
Transaction (Commit/ Rollback)
Transaction (Commit/ Rollback)
Transaction (Commit/ Rollback)
매 1초마다 Write OS Cash & Flush DIsk
매 1초마다 Flush DIsk
Better Performance
Better Performance
24. MariaDB 의 중요한 옵션은 무엇이고 왜 그런가요 ? (1)
Innodb_flush_log_at_trx_commit
1초 쯤이야.. 그정도는 괜찮지 않아 ?
25. MariaDB 의 중요한 옵션은 무엇이고 왜 그런가요 ? (1)
Innodb_flush_log_at_trx_commit
1초 쯤이야.. 그정도는 괜찮지 않아 ?
너무나 큰 디스크 성능차이
26. MariaDB 의 중요한 옵션은 무엇이고 왜 그런가요 ? (2)
Sync_binlog
참고 : https://mariadb.com/kb/en/library/binary-log/
27. MariaDB 의 중요한 옵션은 무엇이고 왜 그런가요 ? (2)
sync_binlog
평소엔 몰랐는데 DISK 부하가 많을땐 0 옵션이 많은 도움.
28. MariaDB 의 중요한 옵션은 무엇이고 왜 그런가요 ? (2)
sync_binlog
Sync_bin !=1 이 아닌경우 Master 가 Crash 되면 Slave 는 반드시 재구축해줘야함.
29. MariaDB 의 중요한 옵션은 무엇이고 왜 그런가요 ? (3)
Innodb_buffer_pool_size 와 Innodb_buffer_pool_instances
참고 : https://mariadb.com/kb/en/library/xtradbinnodb-buffer-pool/
30. MariaDB 의 중요한 옵션은 무엇이고 왜 그런가요 ? (3)
Innodb_buffer_pool_size 와 Innodb_buffer_pool_instances
5,000 file IO /s 10 file IO /s메모리에서 읽게
60. 부하가 몰릴때 CPU 를 낮출 조치
mysql> TRUNCATE TABLE performance_schema.events_statements_summary_by_digest;
mysql>
SELECT IF(LENGTH(DIGEST_TEXT) > 64, CONCAT(LEFT(DIGEST_TEXT, 30), ' ... '
, RIGHT(DIGEST_TEXT, 30)), DIGEST_TEXT) AS query,
IF(SUM_NO_GOOD_INDEX_USED > 0 OR SUM_NO_INDEX_USED > 0, '*', '') AS full_scan, COUNT_STAR AS exec_count,
SUM_ERRORS AS err_count,
SUM_WARNINGS AS warn_count,SEC_TO_TIME(SUM_TIMER_WAIT/1000000000000) AS exec_time_total
, SEC_TO_TIME(MAX_TIMER_WAIT/1000000000000) AS exec_time_max
, (AVG_TIMER_WAIT/1000000000) AS exec_time_avg_ms, SUM_ROWS_SENT AS rows_sent,
ROUND(SUM_ROWS_SENT / COUNT_STAR) AS rows_sent_avg, SUM_ROWS_EXAMINED AS rows_scanned,DIGEST AS digest
FROM performance_schema.events_statements_summary_by_digest ORDER BY SUM_TIMER_WAIT DESC LIMIT 20;
참고 : http://www.markleith.co.uk/2012/07/04/mysql-performance-schema-statement-digests/
Help Desk 역할. 거의 할일은 신규입사자가 생길때만 하고 고장난경우는 재부팅을 요청하거나 어느정도 시간이 지나면 그냥 고쳐지기도 합니다.
아직 작은 스타트업같은 회사라 다양한 업무를 병행하고 있습니다. 많은 분들을 편입시켰습니다. 산업기능요원이 되고 싶으신 인재는 저희 회사에 지원해주세요. (보충역 상시채용)
장르는 FPS
누가 이런거 얘기좀 해줬으면 했는데 결국 다 겪게됨. 저는 원래 기존에 SQLServer DBA 를 약간 오랜기간 했었습니다.
누가 이런거 얘기좀 해줬으면 했는데 결국 다 겪게됨
누가 이런거 얘기좀 해줬으면 했는데 결국 겪으면서 알아냄. 어려운건 저도 잘 모릅니다. 구글링을 잘하면 여러가지 정보가 아주 잘 나옵니다. 암묵지는 존재하겠지만요.
부하가 많은 디비서버 1대, 최대동접 12만, DAU 50만, 다운로드수 약 1,000 천만.
Topology
DB Master - 마스터 디비 게임데이터 전체 저장
DB Slave 1 : 1차 슬레이브, 마스터디비에서 부하가 많이 발생할경우 일부 샤드역할도 함.
DB Slave 2 : 2차 슬레이브, DW 로 넘기는 스케쥴링(Embulk 이용)
DB Slave 3 : 3차 슬레이브는 클라우드를 언제든지 옮길수 있도록 준비하기 위해 낮은 사양의 슬레이브를 둔것.
결제 관련Transaction 처리는 별도의 Database 가 있고 그 Database 에서는 옵션을 1 로 해주는걸 추천함.
0 : client thread 는 log buffer 까지만 기록후 끝. 별도의 thread 가 디스크 완전 저장까지 1초 단위로 실행
1 : commit 이나 rollback 실행시마다 log buffer 내용을 disk 로 쓰고 flush 함.
2 : OS 에 맞긴다. (매 1초마다 flush to disk ) 그러나 OS 장애시 1초동안 데이터 손실
3 : MariaDB 10.0 이후 버전에 존재 하는 옵션임.
결제 관련Transaction 처리는 별도의 Database 가 있고 그 Database 에서는 옵션을 1 로 해주는걸 추천함.
0 : client thread 는 log buffer 까지만 기록후 끝. 별도의 thread 가 디스크 완전 저장까지 1초 단위로 실행
1 : commit 이나 rollback 실행시마다 log buffer 내용을 disk 로 쓰고 flush 함.
2 : OS 에 맞긴다. (매 1초마다 flush to disk ) 그러나 OS 장애시 1초동안 데이터 손실
3 : MariaDB 10.0 이후 버전에 존재 하는 옵션임.
결제 관련Transaction 처리는 별도의 Database 가 있고 그 Database 에서는 옵션을 1 로 해주는걸 추천함.
0 : log buffer 까지만 기록후 끝. 이후 후속처리 디스크 완전 저장까지 1초 단위로 실행 1초동안 데이터 손실 (어떤 서적에서는 0 이 고성능 디스크를 요구한다고 되어 있는데 그건 저의 경우는 아니었음)
1 : commit 이나 rollback 실행시마다 log buffer 내용을 disk 로 쓰고 flush 함.
2 : OS 에 맞긴다. (매 1초마다 flush to disk ) 그러나 OS 장애시 1초동안 데이터 손실
3 : MariaDB 10.0 이후 버전에 존재 하는 옵션임.
DISK I/O 를 가장 많이 줄일수 있는 옵션
결제 관련Transaction 처리는 별도의 Database 가 있고 그 Database 에서는 옵션을 1 로 해주는걸 추천함.
0 : log buffer 까지만 기록후 끝. 이후 후속처리 디스크 완전 저장까지 1초 단위로 실행 1초동안 데이터 손실 (어떤 서적에서는 0 이 고성능 디스크를 요구한다고 되어 있는데 그건 저의 경우는 아니었음)
1 : commit 이나 rollback 실행시마다 log buffer 내용을 disk 로 쓰고 flush 함.
2 : OS 에 맞긴다. (매 1초마다 flush to disk ) 그러나 OS 장애시 1초동안 데이터 손실
3 : MariaDB 10.0 이후 버전에 존재 하는 옵션임.
DISK I/O 를 가장 많이 줄일수 있는 옵션
결제 관련Transaction 처리는 별도의 Database 가 있고 그 Database 에서는 옵션을 1 로 해주는걸 추천함.
0 : log buffer 까지만 기록후 끝. 이후 후속처리 디스크 완전 저장까지 1초 단위로 실행 OS & DB 장애시 1초동안 데이터 손실 (어떤 서적에서는 0 이 고성능 디스크를 요구한다고 되어 있는데 그건 저의 경우는 아니었음)
1 : commit 이나 rollback 실행시마다 log buffer 내용을 disk 로 쓰고 flush 함.
2 : OS 에 맞긴다. (매 1초마다 flush to disk ) 그러나 OS 장애시 1초동안 데이터 손실
3 : MariaDB 10.0 이후 버전에 존재 하는 옵션임.
DISK I/O 를 가장 많이 줄일수 있는 옵션
결제 관련Transaction 처리는 별도의 Database 가 있고 그 Database 에서는 옵션을 1 로 해주는걸 추천함.
0 : log buffer 까지만 기록후 끝. 이후 후속처리 디스크 완전 저장까지 1초 단위로 실행 1초동안 데이터 손실
1 : commit 이나 rollback 실행시마다 log buffer 내용을 disk 로 쓰고 flush 함.
2 : OS 에 맞긴다. (매 1초마다 flush to disk ) 그러나 OS 장애시 1초동안 데이터 손실
3 : MariaDB 10.0 이후 버전에 존재 하는 옵션임.
DISK I/O 를 가장 많이 줄일수 있는 옵션
결제 관련Transaction 처리는 별도의 Database 가 있고 그 Database 에서는 옵션을 1 로 해주는걸 추천함.
0 : log buffer 까지만 기록후 끝. 이후 후속처리 디스크 완전 저장까지 1초 단위로 실행 1초동안 데이터 손실
1 : commit 이나 rollback 실행시마다 log buffer 내용을 disk 로 쓰고 flush 함.
2 : OS 에 맞긴다. (매 1초마다 flush to disk ) 그러나 OS 장애시 1초동안 데이터 손실
3 : MariaDB 10.0 이후 버전에 존재 하는 옵션임.
DISK I/O 를 가장 많이 줄일수 있는 옵션
binary_log 를 disk 에 플러시를 어떻게 해줄것인가 하는것, 0 은 OS 에 맡기는것이고 1은 autocommit 옵션에 따라
쓰는 방식이 다릅니다. sync_bin 는 디스크 부하가 많을때 sync_bin =0 으로 변경해주면 많이 완화됨.
단 sync_bin != 1 이 아닌경우 Master 가 Crash 되면 Slave 를 재구축 해줘야함.
1) binlog=OFF
2) binlog=ON sync_binlog=0
3) binlog=ON sync_binlog=1 # autocommit on 이면 statement(실행구문) 당 one write 이고 아니면 transaction 당 one write
binary_log 를 disk 에 플러시를 어떻게 해줄것인가 하는것, 0 은 OS 에 맡기는것이고 1은 autocommit 옵션에 따라
쓰는 방식이 다릅니다. sync_bin 는 디스크 부하가 많을때 sync_bin =0 으로 변경해주면 많이 완화됨.
단 sync_bin != 1 이 아닌경우 Master 가 Crash 되면 Slave 를 재구축 해줘야함.
1) binlog=OFF
2) binlog=ON sync_binlog=0
3) binlog=ON sync_binlog=1 # autocommit on 이면 statement(실행구문) 당 one write 이고 아니면 transaction 당 one write
binary_log 를 disk 에 플러시를 어떻게 해줄것인가 하는것, 0 은 OS 에 맡기는것이고 1은 autocommit 옵션에 따라
쓰는 방식이 다릅니다. sync_bin 는 디스크 부하가 많을때 sync_bin =0 으로 변경해주면 많이 완화됨.
단 sync_bin != 1 이 아닌경우 Master 가 Crash 되면 Slave 를 재구축 해줘야함.
1) binlog=OFF
2) binlog=ON sync_binlog=0
3) binlog=ON sync_binlog=1 # autocommit on 이면 statement(실행구문) 당 one write 이고 아니면 transaction 당 one write
Innodb_buffer_pool_size 와 Innodb_buffer_pool_instances 가 셋업중에서 제일 중요하며
이 수치는 물리머신을 기준으로 50%~80% 정도의 메모리 할당과 2GB 단위로
instance 값을 1개씩 늘려주는 형태로 하시면됩니다. 이걸 안해줬더니 디스크로부터 읽더군요.
Innodb status 에 갯수만큼 메모리를 어떻게 사용하는지 나옵니다.
Innodb_buffer_pool_size 와 Innodb_buffer_pool_instances 가 셋업중에서 제일 중요하며
이 수치는 물리머신을 기준으로 50% 이상의 메모리 할당과 2GB 단위로
instance 값을 1개씩 늘려주는 형태로 하시면됩니다. 이걸 안해줬더니 디스크로부터 읽더군요.
Innodb status 에 갯수만큼 메모리를 어떻게 사용하는지 나옵니다.
SSD 여서 초반에 눈치를 못챘습니다.
이렇게 옮겨야 하는경우가 많았습니다. IDC 의 문제, 클라우드업체의 문제등등 점검시간을 아주 짧게 가져가야하는데 알아야할 방법입니다.
이거 굉장히 여러번 해봤습니다. 복제 솔루션 굿 !
error_log, deadlock, slave status, analyze table, right config, backup, disk usage, 이런 모든것들을 자동화 해서 알람기능을 갖추는걸 추천합니다.
error_log, deadlock, slave status, analyze table, right config, backup, disk usage, 이런 모든것들을 자동화 해서 알람기능을 갖추는걸 추천합니다.
error_log, deadlock, slave status, analyze table, right config, backup, disk usage, 이런 모든것들을 자동화 해서 알람기능을 갖추는걸 추천합니다.
error_log, deadlock, slave status, analyze table, right config, backup, disk usage, 이런 모든것들을 자동화 해서 알람기능을 갖추는걸 추천합니다.
error_log, deadlock, slave status, analyze table, right config, backup, disk usage, 이런 모든것들을 자동화 해서 알람기능을 갖추는걸 추천합니다.
error_log, deadlock, slave status, analyze table, right config, backup, disk usage, 이런 모든것들을 자동화 해서 알람기능을 갖추는걸 추천합니다. 재부팅후에 config 값이 변동되는 경우가 있습니다.
error_log, deadlock, slave status, analyze table, right config, backup, disk usage, 이런 모든것들을 자동화 해서 알람기능을 갖추는걸 추천합니다.
error_log, deadlock, slave status, analyze table, right config, backup, disk usage, 이런 모든것들을 자동화 해서 알람기능을 갖추는걸 추천합니다.
error_log, deadlock, slave status, analyze table, right config, backup, disk usage, 이런 모든것들을 자동화 해서 알람기능을 갖추는걸 추천합니다.
error_log, deadlock, slave status, analyze table, right config, backup, disk usage, 이런 모든것들을 자동화 해서 알람기능을 갖추는걸 추천합니다.
exec_count 로 전체 실행횟수, errors 에러발생횟수, error_pct 에러발생률, first_seen 과 last_seen 으로 최초 발견과 마지막 발견을 확인 할수 있습니다. 이걸 토대로 에러를 찾고 수정한이후 계속 발생되는지 확인할수 있습니다. (DBA 의 경우 last_seen 을 계속 체크하면서 Server 개발자에게 Reporting 하거나 수행되는 쿼리문에 오류는 없는지 상호 확인합니다. )
공부하는건 좋은데 라이브 적용은 매우 신중
너무 여러가지 언어나 데이터베이스 활용은 엔지니어를 추후 엔지니어 구하기 힘듬.
복구해줘야할때, 롤백해야할때, 보상을 해줘야할때 이런걸 모두 미리 생각하고 진행해야함.
RDB 라면 금방 해결할 문제들이 NoSQL 에서는 복구과정에서 큰 이슈가 될수 있음.
Corruption, 하드웨어 문제, 클라우드선택의 중요성
Corruption, 하드웨어 문제, 클라우드선택의 중요성복제 구성이 있었기 때문에 Federated 구성을 통해 안전한 복구가 되었음. 이문제로 인해 여러차례 반복 커럽션이 났고 결국 하드웨어 문제임을 인식 다른 업체로 이전작업을 했습니다.
Signal 6 Error
Show engine innodb status 로 마지막 데드락만 확인가능set global innodb_print_all_deadlocks=ON; 이 옵션을 이용하면 errorlog 에 계속 남음.
슬레이브 중지 (나중에 켜도 됨.
innodb_flush_log_at_trx_commit =0 or 2
sync_bin=0
stop slave
analyze to table (통계업데이트)
Request 를 최대한 미리 예상해야하나 쉽지 않은 문제.
슬레이브 중지 (나중에 켜도 됨.
innodb_flush_log_at_trx_commit =0 or 2
sync_bin=0
stop slave
analyze to table (통계업데이트)
시간이 오래걸리는 쿼리문(일명 악성쿼리문)을 찾아서 옳바른 실행계획으로 실행이 되고 있는지 확인 및 조치
슬레이브 중지 (나중에 켜도 됨.
innodb_flush_log_at_trx_commit =0 or 2
sync_bin=0
stop slave
analyze to table (통계업데이트)
슬레이브 중지 (나중에 켜도 됨.
innodb_flush_log_at_trx_commit =0 or 2
sync_bin=0
stop slave
analyze to table (통계업데이트)
슬레이브 중지 (나중에 켜도 됨.
innodb_flush_log_at_trx_commit =0 or 2
sync_bin=0
stop slave
analyze to table (통계업데이트)
슬레이브 중지 (나중에 켜도 됨.
innodb_flush_log_at_trx_commit =0 or 2
sync_bin=0
stop slave
analyze to table (통계업데이트)
Innodb buffer pool sizing 신중.
Innodb buffer pool sizing 신중.
Innodb buffer pool sizing 신중.
슬레이브 중지 (나중에 켜도 됨.
innodb_flush_log_at_trx_commit =0 or 2
sync_bin=0
stop slave
analyze to table (통계업데이트)
어제와 오늘 일주일전과 오늘 이런형태로 비교하면서 분석
swappiness = 10 매우중요 , OOM kill 당하는 경우 (Out of memory kill)
기본수치는 60으로 되어 있음. 개인적으로 권장수치는 10입니다. 0 으로 운용해본결과 결과적으로 메모리가 부족해서 mysql 이 멈춘적 이 있습니다. 아래 차트를 보시면 swappiness=0 으로 해놨을 때 메모리부족으로 OOM Kill 을 당했었고 swappiness=10 은 정상적입니 다. Swap 을 많이 사용해도 문제(Disk 에 부하유발)이고 너무 사용하지 못하게 해도 문제가 됩니다.
Hardware Scale-Up
올바른 선택도(Selectivity)로 디자인된 테이블 인덱스
인덱스의 최소화
- 인덱스를 1개 추가할때마다 DML 의 속도가 약 1.5~2배 정도 느려진다고 보면 됩니다.
최적화된 쿼리 - 개발자의 내공
물리서버에 최적화된 Configuration - 한번에 1개만 변경해가며 장기간 튜닝
기본적인 추천만 믿으면 X
수직샤딩 - 물리적으로 분리
example : Game Play DB 와 Log DB 를 물리적으로 나누듯이 업무성격에 따라 분류
, Billing 쪽 결제는 별도로 분류
수평샤딩 - 물리적으로 분리 (example : hashed 방식으로 회원번호를 기준으로 물리적으로 분리, 서버 프로그래밍
유지보수 비용증가, 관리비용 대폭증가)
MySQL/ MariaDB 의 M-M 솔루션들 대부분은 Storage 를 공유하지 않기 때문에 DML 을 높이는것에
회의적
상용제품 : MariaDB Clustrix
Hardware Scale-Up
올바른 선택도(Selectivity)로 디자인된 테이블 인덱스
인덱스의 최소화
- 인덱스를 1개 추가할때마다 DML 의 속도가 약 1.5~2배 정도 느려진다고 보면 됩니다.
최적화된 쿼리 - 개발자의 내공
물리서버에 최적화된 Configuration - 한번에 1개만 변경해가며 장기간 튜닝
기본적인 추천만 믿으면 X
수직샤딩 - 물리적으로 분리
example : Game Play DB 와 Log DB 를 물리적으로 나누듯이 업무성격에 따라 분류
, Billing 쪽 결제는 별도로 분류
수평샤딩 - 물리적으로 분리 (example : hashed 방식으로 회원번호를 기준으로 물리적으로 분리, 서버 프로그래밍
유지보수 비용증가, 관리비용 대폭증가)
MySQL/ MariaDB 의 M-M 솔루션들 대부분은 Storage 를 공유하지 않기 때문에 DML 을 높이는것에
회의적
상용제품 : MariaDB Clustrix
Hardware Scale-Up
올바른 선택도(Selectivity)로 디자인된 테이블 인덱스
인덱스의 최소화
- 인덱스를 1개 추가할때마다 DML 의 속도가 약 1.5~2배 정도 느려진다고 보면 됩니다.
최적화된 쿼리 - 개발자의 내공
물리서버에 최적화된 Configuration - 한번에 1개만 변경해가며 장기간 튜닝
기본적인 추천만 믿으면 X
수직샤딩 - 물리적으로 분리
example : Game Play DB 와 Log DB 를 물리적으로 나누듯이 업무성격에 따라 분류
, Billing 쪽 결제는 별도로 분류
수평샤딩 - 물리적으로 분리 (example : hashed 방식으로 회원번호를 기준으로 물리적으로 분리, 서버 프로그래밍
유지보수 비용증가, 관리비용 대폭증가)
MySQL/ MariaDB 의 M-M 솔루션들 대부분은 Storage 를 공유하지 않기 때문에 DML 을 높이는것에
회의적
상용제품 : MariaDB Clustrix
Hardware Scale-Up
올바른 선택도(Selectivity)로 디자인된 테이블 인덱스
인덱스의 최소화
- 인덱스를 1개 추가할때마다 DML 의 속도가 약 1.5~2배 정도 느려진다고 보면 됩니다.
최적화된 쿼리 - 개발자의 내공
물리서버에 최적화된 Configuration - 한번에 1개만 변경해가며 장기간 튜닝
기본적인 추천만 믿으면 X
수직샤딩 - 물리적으로 분리
example : Game Play DB 와 Log DB 를 물리적으로 나누듯이 업무성격에 따라 분류
, Billing 쪽 결제는 별도로 분류
수평샤딩 - 물리적으로 분리 (example : hashed 방식으로 회원번호를 기준으로 물리적으로 분리, 서버 프로그래밍
유지보수 비용증가, 관리비용 대폭증가)
MySQL/ MariaDB 의 M-M 솔루션들 대부분은 Storage 를 공유하지 않기 때문에 DML 을 높이는것에
회의적
상용제품 : MariaDB Clustrix
Hardware Scale-Up
올바른 선택도(Selectivity)로 디자인된 테이블 인덱스
인덱스의 최소화
- 인덱스를 1개 추가할때마다 DML 의 속도가 약 1.5~2배 정도 느려진다고 보면 됩니다.
최적화된 쿼리 - 개발자의 내공
물리서버에 최적화된 Configuration - 한번에 1개만 변경해가며 장기간 튜닝
기본적인 추천만 믿으면 X
수직샤딩 - 물리적으로 분리
example : Game Play DB 와 Log DB 를 물리적으로 나누듯이 업무성격에 따라 분류
, Billing 쪽 결제는 별도로 분류
수평샤딩 - 물리적으로 분리 (example : hashed 방식으로 회원번호를 기준으로 물리적으로 분리, 서버 프로그래밍
유지보수 비용증가, 관리비용 대폭증가)
MySQL/ MariaDB 의 M-M 솔루션들 대부분은 Storage 를 공유하지 않기 때문에 DML 을 높이는것에
회의적
상용제품 : MariaDB Clustrix
Topology
DB Master - 마스터 디비 게임데이터 전체 저장
DB Slave 1 : 1차 슬레이브, 마스터디비에서 부하가 많이 발생할경우 일부 샤드역할도 함.
DB Slave 2 : 2차 슬레이브, DW 로 넘기는 스케쥴링(Embulk 이용)
DB Slave 3 : 3차 슬레이브는 클라우드를 언제든지 옮길수 있도록 준비하기 위해 낮은 사양의 슬레이브를 둔것.
Hardware Scale-Up
올바른 선택도(Selectivity)로 디자인된 테이블 인덱스
인덱스의 최소화
- 인덱스를 1개 추가할때마다 DML 의 속도가 약 1.5~2배 정도 느려진다고 보면 됩니다.
최적화된 쿼리 - 개발자의 내공
물리서버에 최적화된 Configuration - 한번에 1개만 변경해가며 장기간 튜닝
기본적인 추천만 믿으면 X
수직샤딩 - 물리적으로 분리
example : Game Play DB 와 Log DB 를 물리적으로 나누듯이 업무성격에 따라 분류
, Billing 쪽 결제는 별도로 분류
수평샤딩 - 물리적으로 분리 (example : hashed 방식으로 회원번호를 기준으로 물리적으로 분리, 서버 프로그래밍
유지보수 비용증가, 관리비용 대폭증가)
MySQL/ MariaDB 의 M-M 솔루션들 대부분은 Storage 를 공유하지 않기 때문에 DML 을 높이는것에
회의적
상용제품 : MariaDB Clustrix
Hardware Scale-Up
올바른 선택도(Selectivity)로 디자인된 테이블 인덱스
인덱스의 최소화
- 인덱스를 1개 추가할때마다 DML 의 속도가 약 1.5~2배 정도 느려진다고 보면 됩니다.
최적화된 쿼리 - 개발자의 내공
물리서버에 최적화된 Configuration - 한번에 1개만 변경해가며 장기간 튜닝
기본적인 추천만 믿으면 X
수직샤딩 - 물리적으로 분리
example : Game Play DB 와 Log DB 를 물리적으로 나누듯이 업무성격에 따라 분류
, Billing 쪽 결제는 별도로 분류
수평샤딩 - 물리적으로 분리 (example : hashed 방식으로 회원번호를 기준으로 물리적으로 분리, 서버 프로그래밍
유지보수 비용증가, 관리비용 대폭증가)
MySQL/ MariaDB 의 M-M 솔루션들 대부분은 Storage 를 공유하지 않기 때문에 DML 을 높이는것에
회의적
상용제품 : MariaDB Clustrix
Hardware Scale-Up
올바른 선택도(Selectivity)로 디자인된 테이블 인덱스
인덱스의 최소화
- 인덱스를 1개 추가할때마다 DML 의 속도가 약 1.5~2배 정도 느려진다고 보면 됩니다.
최적화된 쿼리 - 개발자의 내공
물리서버에 최적화된 Configuration - 한번에 1개만 변경해가며 장기간 튜닝
기본적인 추천만 믿으면 X
수직샤딩 - 물리적으로 분리
example : Game Play DB 와 Log DB 를 물리적으로 나누듯이 업무성격에 따라 분류
, Billing 쪽 결제는 별도로 분류
수평샤딩 - 물리적으로 분리 (example : hashed 방식으로 회원번호를 기준으로 물리적으로 분리, 서버 프로그래밍
유지보수 비용증가, 관리비용 대폭증가)
MySQL/ MariaDB 의 M-M 솔루션들 대부분은 Storage 를 공유하지 않기 때문에 DML 을 높이는것에
회의적
상용제품 : MariaDB Clustrix
파티션테이블 ?
통테이블 ?
NoSQL ?
- Monthly 로 남겨서 쉽게 drop 시킬수 있도록. (테이블이 drop 되면 용량이 확보, 그냥 delete 를 하면 확보 안됨)
TokuDB, Columnstore
비용절감 효과
용량이 크지 않다면 논리백업(mysqldump)을 활용, 용량이 10GB 이상 넘어가면 그때부터는 물리백업(Mariadbbackup) 을 활용하는게 좋습니다. 특정 테이블만 별도로 백업하고 싶다면 mysqldump 를 활용해서 하면 효과적임.
log-bin = mysql-bin
expire_logs_days = 3
기본적으로 Log-bin 을 활성화 시켰다면 리두로그가 쌓이기 때문에
개발자들이 가장 자주 문의하는게 접속이 안되요 기본적인 클라우드 및 네트워크 지식 필요
개발자들이 가장 자주 문의하는게 접속이 안되요 기본적인 클라우드 및 네트워크 지식 필요
개발자들이 가장 자주 문의하는게 접속이 안되요 기본적인 클라우드 및 네트워크 지식 필요
개발자들이 가장 자주 문의하는게 접속이 안되요 기본적인 클라우드 및 네트워크 지식 필요
개발자들이 가장 자주 문의하는게 접속이 안되요 기본적인 클라우드 및 네트워크 지식 필요
처음엔 스팍으로 구현 > 빅쿼리로 구현 > 컬럼스토어로 구현 (약 10억건 200기가 정도 데이터 처리)
개발자들이 가장 자주 문의하는게 접속이 안되요 기본적인 클라우드 및 네트워크 지식 필요
스터디를 통해 데이터 크롤러를 만들고 이후 후속 분석을 통해 다면적 결과를 도출
같은 고객찾기
엘프 크롤링 이후 다면적 분석
엘프 크롤링 이후 다면적 분석
개발자들이 가장 자주 문의하는게 접속이 안되요 기본적인 클라우드 및 네트워크 지식 필요
라이브로 가능한 옵션을 별도로 정의해두고 유사시 사용하면 좋음.
라이브로 가능한 옵션을 별도로 정의해두고 유사시 사용하면 좋음.
시스템에 익숙해질수록 새벽전화를 막을수 있고 최대한 자동화 + 모니터링 철저. 새벽에 온 전화는 매우 크리티컬, 평소 체력관리 중요.
중요한 리포팅 우선순위, 반복되는 리포팅은 자동화처리, 최대한 신속 정확하게 요청자에게 제공하는것이 중요한데 신속보다는 정확이 더 중요.