SlideShare a Scribd company logo
1 of 123
산동네 게임DBA
홍병기
자기소개
차(茶)를 즐기는 DBA
자기소개
어썸피스 직원
자기소개
MariaDB 한국 사용자 모임 운영자
관심사 ? 차 ?
회사에서 무슨업무를 하나요 ?
주요업무 : 좀비고등학교 DBA
회사에서 무슨업무를 하나요 ?
주요업무 : AWS, GCP 와 사내 인프라 관리
회사에서 주로 무슨업무를 하나요 ?
그외 : 사내 HR용 비인공지능 봇(파이썬 공부하다 만듬. 출퇴근, 휴가, 증명서, 장비
관리 등등)
회사에서 무슨업무를 하나요 ?
그그외 : PC 수리
회사에서 주로 무슨업무를 하나요 ?
그그그외 : 산업기능요원관리업무(병역특례관리)
산동네 DBA 인 이유 ?
회사가 관악산 근처에 있습니다. 등산객들을 자주 볼수 있습니다.
제품 ?
좀비고등학교
오늘 발표할 내용
지난 5년간 좀비고등학교 DBA 업무를 하며 배운것들
오늘 발표할 내용
- 중요 Configuration
- 튜닝시 가장중요한건 ?
- 최소점검시간으로 IDC or Cloud 이
전
- 평소확인해야할것들
- NoSQL 에 대해
- 장애경험 및 조치
- CPU 가 100% 가까울때 긴급조치?
- OS 메모리 관리의 중요성
- 샤딩안하고 DML 성능 높이기 ?
- 샤딩적용은 ?
- 효율적인 로그관리요령
- 백업 및 복구
- 통계 및 머신러닝
- 회사에서 벌어지는 일들
- DBA 피드백
- 괜찮은 DBA ?
오늘 발표할 내용
어려운문제를 깊이 파기보다는 공감하는 자리
사용중인 데이터베이스는 ?
MariaDB & MySQL
디비의 부하는 어느정도인가요 ?
DML/s : 5,000~6,000
Queries/s : 약 30,000
Topology 가 궁금합니다.
Game Server
DB Master
Redis
DB Slave 2
DB Slave 1
DB Slave 3
(External)
DW
MariaDB 의 중요한 옵션은 무엇이고 왜 그런가요 ? (1)
MariaDB 의 중요한 옵션은 무엇이고 왜 그런가요 ? (1)
Innodb_flush_log_at_trx_commit
참고 : https://mariadb.com/kb/en/library/innodb-system-
variables/#innodb_flush_log_at_trx_commit
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
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
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
MariaDB 의 중요한 옵션은 무엇이고 왜 그런가요 ? (1)
Innodb_flush_log_at_trx_commit
1초 쯤이야.. 그정도는 괜찮지 않아 ?
MariaDB 의 중요한 옵션은 무엇이고 왜 그런가요 ? (1)
Innodb_flush_log_at_trx_commit
1초 쯤이야.. 그정도는 괜찮지 않아 ?
너무나 큰 디스크 성능차이
MariaDB 의 중요한 옵션은 무엇이고 왜 그런가요 ? (2)
Sync_binlog
참고 : https://mariadb.com/kb/en/library/binary-log/
MariaDB 의 중요한 옵션은 무엇이고 왜 그런가요 ? (2)
sync_binlog
평소엔 몰랐는데 DISK 부하가 많을땐 0 옵션이 많은 도움.
MariaDB 의 중요한 옵션은 무엇이고 왜 그런가요 ? (2)
sync_binlog
Sync_bin !=1 이 아닌경우 Master 가 Crash 되면 Slave 는 반드시 재구축해줘야함.
MariaDB 의 중요한 옵션은 무엇이고 왜 그런가요 ? (3)
Innodb_buffer_pool_size 와 Innodb_buffer_pool_instances
참고 : https://mariadb.com/kb/en/library/xtradbinnodb-buffer-pool/
MariaDB 의 중요한 옵션은 무엇이고 왜 그런가요 ? (3)
Innodb_buffer_pool_size 와 Innodb_buffer_pool_instances
5,000 file IO /s 10 file IO /s메모리에서 읽게
옵션외에 성능 튜닝시 가장 중요한건 뭔가요 ?
옵션외에 성능 튜닝시 가장 중요한건 뭔가요 ?
선택도라고 생각합니다.
옵션외에 성능 튜닝시 가장 중요한건 뭔가요 ?
옵션외에 성능 튜닝시 가장 중요한건 뭔가요 ?
라이브 상황에서 최소 점검시간만 갖고 물리적으로 다른곳
으로 디비를 이전하고 싶습니다. 어떻게 하면되나요 ?
라이브 상황에서 최소 점검시간만 갖고 물리적으로 다른곳
으로 디비를 이전하고 싶습니다. 어떻게 하면되나요 ?
Mariabackup or Innobackupex 를 활용 복제구성후 이전
Master Slave복제구성 Master Slave -> Master
평소 확인해야 할것 무엇이 있나요 ?
평소 확인해야 할것 무엇이 있나요 ?
Error Log
평소 확인해야 할것 무엇이 있나요 ?
Dead Lock
평소 확인해야 할것 무엇이 있나요 ?
Slave Status
평소 확인해야 할것 무엇이 있나요 ?
Table Condition
레코드수, Auto increment 값, 데이터타입, 통계업데이트상태
평소 확인해야 할것 무엇이 있나요 ?
올바른 Config 값들.
값이 변경되지 않게 시스템 점검
평소 확인해야 할것 무엇이 있나요 ?
Backup
1차 백업, 2차 백업, 복구방안 등등
평소 확인해야 할것 무엇이 있나요 ?
Disk Usage
평소 확인해야 할것 무엇이 있나요 ?
메모리 누수
평소 확인해야 할것 무엇이 있나요 ?
Errors and Warnings
NoSQL 은 고려해 본적없으신가요 ?
NoSQL 은 고려해 본적없으신가요 ?
NoSQL 은 고려해 본적없으신가요 ?
NoSQL 도입하는데 많이 고민했습니다.
NoSQL 은 고려해 본적없으신가요 ?
주변 지인들이 NoSQL 을 도입후 퇴근 못한다는 소식을 많이 들었습니다.
NoSQL 은 고려해 본적없으신가요 ?
추후 인수인계도 고려해야함(충분한 엔지니어풀).
서브스크립션 구매해서 사용해도 되지만 서포트가능한 엔지니어들이 대부분 외국
에서 원격으로 진행
장애 경험 및 조치에 대해서 들어보고 싶습니다.
장애 경험 및 조치에 대해서 들어보고 싶습니다.
Corruption
장애 경험 및 조치에 대해서 들어보고 싶습니다.
Deadlock
부하가 몰릴때 CPU 를 낮출 조치
부하가 몰릴때 CPU 를 낮출 조치
Didn’t expect that...
부하가 몰릴때 CPU 를 낮출 조치
SELECT * FROM INFORMATION_SCHEMA.PROCESSLIST WHERE
COMMAND != 'Sleep'
부하가 몰릴때 CPU 를 낮출 조치
Slow_query_log 를 확인
부하가 몰릴때 CPU 를 낮출 조치
Performance Schema 적극활용
부하가 몰릴때 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/
부하가 몰릴때 CPU 를 낮출 조치
Stop Slave
OS 메모리 관리 주의사항
OS 메모리 관리 주의사항
OS 가 적절히 여유있게 사용가능한 메모리 영역을 남겨놔야함.
OS 메모리 관리 주의사항
공포의 OOM Kill
OS 메모리 관리 주의사항
Free
OS 메모리 관리 주의사항
MariaDB (MySQL) 에서 메모리 누수여부를 지속적으로 탐지
OS 메모리 관리 주의사항
OS 가 적절히 여유있게 사용가능한 메모리 영역을 남겨놔야함.
OS 메모리 관리 주의사항
Swappiness 를 이용 적절한 스왑비율 유지
샤딩안하고 DML 을 스케일업할 방법 ?
샤딩안하고 DML 을 스케일업할 방법 ?
하드웨어 스케일업 (성능좋은 SSD)
샤딩안하고 DML 을 스케일업할 방법 ?
올바른 선택도(Selectivity)로 디자인된 테이블 인덱스
Secondary Index 1개 추가시마다 DML 속도는 1.3~2배 가까이 느려짐
샤딩안하고 DML 을 스케일업할 방법 ?
최적화된 쿼리
개발자의 내공
샤딩안하고 DML 을 스케일업할 방법 ?
물리서버에 최적화된 Configuration - 한번에 1개만 변경
서비스 환경에 맞춰 변경 - 어느정도 모니터링 시간필수
샤딩은 ?
수평샤딩을 하기전에 수직샤딩을 먼저 고려
Topology 가 궁금합니다. 다시보기 !
Game Server
DB Master
Redis
DB Slave 2
DB Slave 1
DB Slave 3
(External)
DW
샤딩은 ?
수직샤딩으로 감당이 안될것 같을때 수평샤딩을 고려 ?
샤딩은 ?
수평샤딩은 유지보수비용이 매우 높음. (서버개발도 그에 맞춰서 해야함)
샤딩안하고 DML 을 스케일업할 상용제품 ?
To be continue (제이콥님)
?
로그관리 요령
로그관리 요령
파티션 테이블로 관리 ?
통테이블 ?
NoSQL ?
로그관리 요령
Innodb Engine 이외에 압축률이 높은 다른 엔진을 고려
로그관리 요령
가능하면 별도의 디비에 둬서 Write 를 분산하는걸 추천하며 Monthly 혹은 Daily
로
Table 을 생성해서 언제든 Drop 시켜 용량도 간단히 확보할수 있는 형태를 추천
백업 및 복구
백업 및 복구
논리백업과 물리백업 ?
백업 및 복구
Mysqldump, Mariadbbackup(Innobackupex)
백업 및 복구
Log-bin 옵션(바이너리로그)
통계 및 머신러닝
통계 및 머신러닝
1. Adhoc - Query 로 결과 도출
2. Scheduled Table (새벽시간 or 1시간 간격)
3. Hadoop
4. Hadoop Ecosystems
5. Columnstore
통계 및 머신러닝
우연히 스터디 할수 있는 기회가 주어짐.
시맨틱, 자연어, 의미분석, 머신러닝.
통계 및 머신러닝
Pointwise mutual information
참고 : https://en.wikipedia.org/wiki/Pointwise_mutual_information
통계 및 머신러닝
Word vectors from PMI
참고 : https://www.kaggle.com/gabrielaltay/word-vectors-from-pmi-matrix
통계 및 머신러닝
통계 및 머신러닝
통계 및 머신러닝
통계 및 머신러닝
용도에 맞게 사용하는것이지만 왠만한건 컬럼스토어로 충분히 처리가능
통계 및 머신러닝
MariaDB Columnstore
Vs
Google Bigquery
통계 및 머신러닝
MariaDB Columnstore
Vs
Google Bigquery
1TB(10억건) PMI 구현
컬럼스토어가 더 빨랐
음
통계 및 머신러닝 (대기업 홈쇼핑 반품사유 자동
분류)
까슬거려,따가워,좀무거워,간지러워,졸려,가렵네,헐떡거려,화끈거려,어벙해 cl_310
--------------------cl-------------------------
디자인과재질,색상과재질,색상과디자인,옷감재질,옷재질,상품재질,재질과색상,디자인과색상,제질,바지핏,사
이즈와디자인,사이즈와색상,색감,색깔,향,원단재질,다자인,소재와핏,재질과디자인,사이즈와재질,어깨라인,디
쟌,버건디색상,재질과핏,김치냉장고와규격,가죽질,인형,실물디자인,구성품,상품구성,모습,옷감등품질 cl_35
실물,실제상품,실제색상,실제디자인,달리색상,달리재질,목라인,달리디자인,달리옷,실물색상,전체기장 cl_546
--------------------cl-------------------------
딸,아들,신랑,남편,지인,선물받는분,선물받을사람 cl_241
동생,딸아이,아이,어머님께 cl_273
--------------------cl-------------------------
바지통,소매통,팔통,다리통,종아리부분,바지폭,몸통,허벅지부분,엉덩이부분,힙,발볼,발목부분,신청힙,힙부분,
암홀부분,옷품,바지품,요청힙,어깨품,종아리쪽,제발볼,그부분 cl_175
--------------------cl-------------------------
사진과색상,화면과색상,화면과느낌,사진과느낌,사진과디자인,화면과실물,방송과색상,방송과이미지,화면과실
제색상,사진과실재색상 cl_156
생각하고,화면과좀,방송하고,화면상과,화면과조금,화면과달리,사진과좀 cl_261
통계 및 머신러닝 (대기업 홈쇼핑 반품사유 자동
분류)
--------------------cl-------------------------
다른사이트,타사이트,다른곳,타홈쇼핑,다른부분,타쇼핑몰,타싸이트,더저렴한곳,이번상품들 cl_86
방송이미지,책자,보기,이미지,카다로그,화면이미지,광고,방송볼때,침대사이즈,TV-에서볼때
--------------------cl------------------------
디자인,색상,색,핏 cl_500
스타일,스탈,카멜색 cl_524
--------------------cl-------------------------
아버지,어머니,엄마,부모님,어머님,아빠,언니,조카,와이프,아기,친구,어른들,간절기용 cl_112
아버님,친정엄마,시어머니 cl_605
--------------------cl-------------------------
사이즈선택,색상선택,색상주문,옵션선택,사이즈판단,사이즈주문,사이즈기재,쇼호스트방송 cl_26
보정력,커버력,쿠션감,스판,스판성,세정력,머리결,머릿결,상품정보 cl_134
양,용량,효능,촉촉함 cl_288
기종,옵션 cl_785
사이즈신청,사이즈측정 cl_1119
통계 및 머신러닝 (대기업 전자회사 유사고객찾
기)
통계 및 머신러닝 (맛집 다면적 분석)
요약해줘
음식에 대한 얘기들
요약해줘
분위기에 대한 얘기들
통계 및 머신러닝
시멘틱 자연어관련 추가문의 : space@quryon.com
회사에서 벌어지는 일들-1
디비 접속이 안됩니다.
회사에서 벌어지는 일들-2
이거 라이브로 가능할까요 ?
회사에서 벌어지는 일들-2
이거 라이브로 가능할까요 ?
“50만명에게 아이템 지급이 가능할까요 ? “
“지난 한달간 접속했던 유저들에게 잘못지급된 아이템을 회수하고 그에 대한 보상
이 점검없이 가능할까요 ? “
회사에서 벌어지는 일들-3
새벽전화
회사에서 벌어지는 일들-4
리포팅 요청
DBA 피드백 -1
개발자들에게 피드백 제공
“그건 디비 문제가 아닌것으로 보입니다. 증거제시“
“현재 디비는 컨디션이 좋습니다.”
“푸시를 날리면 안될것 같습니다.”
“쿼리가 느립니다. 튜닝 가능할까요 ? “
DBA 피드백 -2
라이브 서비스중 버그로인한 여러가지 유형의 유저보상
개발팀 - 게임운영팀 - DBA 간의 빠른 커뮤니케이션
DBA 피드백 -3
권한관리 - 누가 어떤걸 변경했는지 모두 알고 있어야함.
Update, Insert, Delete 는 가능하면 DBA 가 수행하는 것도 방법
DBA 피드백 -4
다양한 리포팅
실시간, Ad-hoc, 통계
제가 만나본 괜찮은 선배 DBA
제가 만나본 괜찮은 선배 DBA의 좋았던점.
겸손함
제가 만나본 괜찮은 선배 DBA의 좋았던점.
커뮤니케이션 능력
제가 만나본 괜찮은 선배 DBA의 좋았던점.
경험 및 지식
제가 만나본 괜찮은 선배 DBA의 좋았던점
겸손함> 커뮤니케이션능력 > 경험 및 지식
Generalist or Specialist ?
Generalist or Specialist ?
나는 모르는것에
크게 연연하지 않
아.
중요한거 4~5가
지면 충분해
페이스북 그룹소개 - MariaDB 한국사용자모임
https://www.facebook.com/groups/mariadbkorea
페이스북 그룹소개 - MariaDB 한국사용자모임
https://www.facebook.com/groups/mariadbkorea
Sponsored by
페이스북 그룹소개 - MariaDB 한국사용자모임
https://www.facebook.com/groups/mariadbkorea
마리아디비 한국지사의 적극적인 지원
MariaDB Exclusive 세미나 진행
MariaDB 대규모 컨퍼런스 커뮤니티 부스지원
페이스북 그룹소개 - MariaDB 한국사용자모임
감사합니다.
홍병기
Facebook MariaDB : https://www.facebook.com/groups/mariadbkorea/
Linkedin : https://www.linkedin.com/in/byungkeehong/
Email : byungkeehong@hotmail.com

More Related Content

Similar to 산동네 게임 DBA 이야기

Mongo db intro & tips
Mongo db intro & tipsMongo db intro & tips
Mongo db intro & tipsInBum Kim
 
Ndc14 분산 서버 구축의 ABC
Ndc14 분산 서버 구축의 ABCNdc14 분산 서버 구축의 ABC
Ndc14 분산 서버 구축의 ABCHo Gyu Lee
 
[PYCON Korea 2018] Python Application Server for Recommender System
[PYCON Korea 2018] Python Application Server for Recommender System [PYCON Korea 2018] Python Application Server for Recommender System
[PYCON Korea 2018] Python Application Server for Recommender System Kwangseob Kim
 
[PYCON Korea 2018] Python Application Server for Recommender System
[PYCON Korea 2018] Python Application Server for Recommender System [PYCON Korea 2018] Python Application Server for Recommender System
[PYCON Korea 2018] Python Application Server for Recommender System Kwangseob Kim
 
KGC 2014 가볍고 유연하게 데이터 분석하기 : 쿠키런 사례 중심 , 데브시스터즈
KGC 2014 가볍고 유연하게 데이터 분석하기 : 쿠키런 사례 중심 , 데브시스터즈KGC 2014 가볍고 유연하게 데이터 분석하기 : 쿠키런 사례 중심 , 데브시스터즈
KGC 2014 가볍고 유연하게 데이터 분석하기 : 쿠키런 사례 중심 , 데브시스터즈Minwoo Kim
 
MySQL_SQL_Tunning_v0.1.3.docx
MySQL_SQL_Tunning_v0.1.3.docxMySQL_SQL_Tunning_v0.1.3.docx
MySQL_SQL_Tunning_v0.1.3.docxNeoClova
 
Sua 정보보호관리체계 cissp_bcp&drp_강의교안
Sua 정보보호관리체계 cissp_bcp&drp_강의교안Sua 정보보호관리체계 cissp_bcp&drp_강의교안
Sua 정보보호관리체계 cissp_bcp&drp_강의교안Lee Chanwoo
 
Chap1. 개발환경구성 3주차 20130329
Chap1. 개발환경구성 3주차 20130329Chap1. 개발환경구성 3주차 20130329
Chap1. 개발환경구성 3주차 20130329광명 우
 
Hadoop engineering v1.0 for dataconference.io
Hadoop engineering v1.0 for dataconference.ioHadoop engineering v1.0 for dataconference.io
Hadoop engineering v1.0 for dataconference.iodaumkakao
 
[AI & DevOps] BigData Scale Production AI 서비스를 위한 최상의 플랫폼 아키텍처
[AI & DevOps] BigData Scale Production AI 서비스를 위한 최상의 플랫폼 아키텍처[AI & DevOps] BigData Scale Production AI 서비스를 위한 최상의 플랫폼 아키텍처
[AI & DevOps] BigData Scale Production AI 서비스를 위한 최상의 플랫폼 아키텍처hoondong kim
 
클라우드 환경에서 알아야할 성능 이야기
클라우드 환경에서 알아야할 성능 이야기클라우드 환경에서 알아야할 성능 이야기
클라우드 환경에서 알아야할 성능 이야기YoungSu Son
 
Spark machine learning & deep learning
Spark machine learning & deep learningSpark machine learning & deep learning
Spark machine learning & deep learninghoondong kim
 
안드로이드 Oreo의 변화와 모바일 앱/플랫폼의 적합한 성능 측정 방법
안드로이드 Oreo의 변화와  모바일 앱/플랫폼의 적합한 성능 측정 방법안드로이드 Oreo의 변화와  모바일 앱/플랫폼의 적합한 성능 측정 방법
안드로이드 Oreo의 변화와 모바일 앱/플랫폼의 적합한 성능 측정 방법YoungSu Son
 
20130716 AWS Meister re:Generate - Amazon Redshift (Korean)
20130716 AWS Meister re:Generate - Amazon Redshift (Korean)20130716 AWS Meister re:Generate - Amazon Redshift (Korean)
20130716 AWS Meister re:Generate - Amazon Redshift (Korean)Amazon Web Services Korea
 
MySQL_MariaDB-성능개선-202201.pptx
MySQL_MariaDB-성능개선-202201.pptxMySQL_MariaDB-성능개선-202201.pptx
MySQL_MariaDB-성능개선-202201.pptxNeoClova
 
Chap1. 개발환경구성 3주차 20130329
Chap1. 개발환경구성 3주차 20130329Chap1. 개발환경구성 3주차 20130329
Chap1. 개발환경구성 3주차 20130329광명 우
 
MongoDB in use(김인범, mongodb korea)
MongoDB in use(김인범, mongodb korea)MongoDB in use(김인범, mongodb korea)
MongoDB in use(김인범, mongodb korea)InBum Kim
 
FIFA 온라인 3의 MongoDB 사용기
FIFA 온라인 3의 MongoDB 사용기FIFA 온라인 3의 MongoDB 사용기
FIFA 온라인 3의 MongoDB 사용기Jongwon Kim
 
SAYAHAE - 상품평 분석 및 추천 서비스 (자연어 처리)
SAYAHAE - 상품평 분석 및 추천 서비스 (자연어 처리)SAYAHAE - 상품평 분석 및 추천 서비스 (자연어 처리)
SAYAHAE - 상품평 분석 및 추천 서비스 (자연어 처리)Eunchan Lee
 

Similar to 산동네 게임 DBA 이야기 (20)

Mongo db intro & tips
Mongo db intro & tipsMongo db intro & tips
Mongo db intro & tips
 
Ndc14 분산 서버 구축의 ABC
Ndc14 분산 서버 구축의 ABCNdc14 분산 서버 구축의 ABC
Ndc14 분산 서버 구축의 ABC
 
[PYCON Korea 2018] Python Application Server for Recommender System
[PYCON Korea 2018] Python Application Server for Recommender System [PYCON Korea 2018] Python Application Server for Recommender System
[PYCON Korea 2018] Python Application Server for Recommender System
 
[PYCON Korea 2018] Python Application Server for Recommender System
[PYCON Korea 2018] Python Application Server for Recommender System [PYCON Korea 2018] Python Application Server for Recommender System
[PYCON Korea 2018] Python Application Server for Recommender System
 
KGC 2014 가볍고 유연하게 데이터 분석하기 : 쿠키런 사례 중심 , 데브시스터즈
KGC 2014 가볍고 유연하게 데이터 분석하기 : 쿠키런 사례 중심 , 데브시스터즈KGC 2014 가볍고 유연하게 데이터 분석하기 : 쿠키런 사례 중심 , 데브시스터즈
KGC 2014 가볍고 유연하게 데이터 분석하기 : 쿠키런 사례 중심 , 데브시스터즈
 
MySQL_SQL_Tunning_v0.1.3.docx
MySQL_SQL_Tunning_v0.1.3.docxMySQL_SQL_Tunning_v0.1.3.docx
MySQL_SQL_Tunning_v0.1.3.docx
 
Sua 정보보호관리체계 cissp_bcp&drp_강의교안
Sua 정보보호관리체계 cissp_bcp&drp_강의교안Sua 정보보호관리체계 cissp_bcp&drp_강의교안
Sua 정보보호관리체계 cissp_bcp&drp_강의교안
 
Chap1. 개발환경구성 3주차 20130329
Chap1. 개발환경구성 3주차 20130329Chap1. 개발환경구성 3주차 20130329
Chap1. 개발환경구성 3주차 20130329
 
Hadoop engineering v1.0 for dataconference.io
Hadoop engineering v1.0 for dataconference.ioHadoop engineering v1.0 for dataconference.io
Hadoop engineering v1.0 for dataconference.io
 
[AI & DevOps] BigData Scale Production AI 서비스를 위한 최상의 플랫폼 아키텍처
[AI & DevOps] BigData Scale Production AI 서비스를 위한 최상의 플랫폼 아키텍처[AI & DevOps] BigData Scale Production AI 서비스를 위한 최상의 플랫폼 아키텍처
[AI & DevOps] BigData Scale Production AI 서비스를 위한 최상의 플랫폼 아키텍처
 
클라우드 환경에서 알아야할 성능 이야기
클라우드 환경에서 알아야할 성능 이야기클라우드 환경에서 알아야할 성능 이야기
클라우드 환경에서 알아야할 성능 이야기
 
Spark machine learning & deep learning
Spark machine learning & deep learningSpark machine learning & deep learning
Spark machine learning & deep learning
 
안드로이드 Oreo의 변화와 모바일 앱/플랫폼의 적합한 성능 측정 방법
안드로이드 Oreo의 변화와  모바일 앱/플랫폼의 적합한 성능 측정 방법안드로이드 Oreo의 변화와  모바일 앱/플랫폼의 적합한 성능 측정 방법
안드로이드 Oreo의 변화와 모바일 앱/플랫폼의 적합한 성능 측정 방법
 
Hadoop발표자료
Hadoop발표자료Hadoop발표자료
Hadoop발표자료
 
20130716 AWS Meister re:Generate - Amazon Redshift (Korean)
20130716 AWS Meister re:Generate - Amazon Redshift (Korean)20130716 AWS Meister re:Generate - Amazon Redshift (Korean)
20130716 AWS Meister re:Generate - Amazon Redshift (Korean)
 
MySQL_MariaDB-성능개선-202201.pptx
MySQL_MariaDB-성능개선-202201.pptxMySQL_MariaDB-성능개선-202201.pptx
MySQL_MariaDB-성능개선-202201.pptx
 
Chap1. 개발환경구성 3주차 20130329
Chap1. 개발환경구성 3주차 20130329Chap1. 개발환경구성 3주차 20130329
Chap1. 개발환경구성 3주차 20130329
 
MongoDB in use(김인범, mongodb korea)
MongoDB in use(김인범, mongodb korea)MongoDB in use(김인범, mongodb korea)
MongoDB in use(김인범, mongodb korea)
 
FIFA 온라인 3의 MongoDB 사용기
FIFA 온라인 3의 MongoDB 사용기FIFA 온라인 3의 MongoDB 사용기
FIFA 온라인 3의 MongoDB 사용기
 
SAYAHAE - 상품평 분석 및 추천 서비스 (자연어 처리)
SAYAHAE - 상품평 분석 및 추천 서비스 (자연어 처리)SAYAHAE - 상품평 분석 및 추천 서비스 (자연어 처리)
SAYAHAE - 상품평 분석 및 추천 서비스 (자연어 처리)
 

산동네 게임 DBA 이야기

Editor's Notes

  1. 저랑 편하게 차한잔 마신다고 생각하시고 오늘 발표 들어주시면 좋을것 같습니다.
  2. Help Desk 역할. 거의 할일은 신규입사자가 생길때만 하고 고장난경우는 재부팅을 요청하거나 어느정도 시간이 지나면 그냥 고쳐지기도 합니다.
  3. 아직 작은 스타트업같은 회사라 다양한 업무를 병행하고 있습니다. 많은 분들을 편입시켰습니다. 산업기능요원이 되고 싶으신 인재는 저희 회사에 지원해주세요. (보충역 상시채용)
  4. 장르는 FPS
  5. 누가 이런거 얘기좀 해줬으면 했는데 결국 다 겪게됨. 저는 원래 기존에 SQLServer DBA 를 약간 오랜기간 했었습니다.
  6. 누가 이런거 얘기좀 해줬으면 했는데 결국 다 겪게됨
  7. 누가 이런거 얘기좀 해줬으면 했는데 결국 겪으면서 알아냄. 어려운건 저도 잘 모릅니다. 구글링을 잘하면 여러가지 정보가 아주 잘 나옵니다. 암묵지는 존재하겠지만요.
  8. 부하가 많은 디비서버 1대, 최대동접 12만, DAU 50만, 다운로드수 약 1,000 천만.
  9. Topology DB Master - 마스터 디비 게임데이터 전체 저장 DB Slave 1 : 1차 슬레이브, 마스터디비에서 부하가 많이 발생할경우 일부 샤드역할도 함. DB Slave 2 : 2차 슬레이브, DW 로 넘기는 스케쥴링(Embulk 이용) DB Slave 3 : 3차 슬레이브는 클라우드를 언제든지 옮길수 있도록 준비하기 위해 낮은 사양의 슬레이브를 둔것.
  10. 결제 관련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 이후 버전에 존재 하는 옵션임.
  11. 결제 관련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 이후 버전에 존재 하는 옵션임.
  12. 결제 관련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 를 가장 많이 줄일수 있는 옵션
  13. 결제 관련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 를 가장 많이 줄일수 있는 옵션
  14. 결제 관련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 를 가장 많이 줄일수 있는 옵션
  15. 결제 관련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 를 가장 많이 줄일수 있는 옵션
  16. 결제 관련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 를 가장 많이 줄일수 있는 옵션
  17. 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
  18. 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
  19. 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
  20. Innodb_buffer_pool_size 와 Innodb_buffer_pool_instances 가 셋업중에서 제일 중요하며 이 수치는 물리머신을 기준으로 50%~80% 정도의 메모리 할당과 2GB 단위로 instance 값을 1개씩 늘려주는 형태로 하시면됩니다. 이걸 안해줬더니 디스크로부터 읽더군요. Innodb status 에 갯수만큼 메모리를 어떻게 사용하는지 나옵니다.
  21. Innodb_buffer_pool_size 와 Innodb_buffer_pool_instances 가 셋업중에서 제일 중요하며 이 수치는 물리머신을 기준으로 50% 이상의 메모리 할당과 2GB 단위로 instance 값을 1개씩 늘려주는 형태로 하시면됩니다. 이걸 안해줬더니 디스크로부터 읽더군요. Innodb status 에 갯수만큼 메모리를 어떻게 사용하는지 나옵니다. SSD  여서 초반에 눈치를 못챘습니다.
  22. 이렇게 옮겨야 하는경우가 많았습니다. IDC 의 문제, 클라우드업체의 문제등등 점검시간을 아주 짧게 가져가야하는데 알아야할 방법입니다.
  23. 이거 굉장히 여러번 해봤습니다. 복제 솔루션 굿 !
  24. error_log, deadlock, slave status, analyze table, right config, backup, disk usage, 이런 모든것들을 자동화 해서 알람기능을 갖추는걸 추천합니다.
  25. error_log, deadlock, slave status, analyze table, right config, backup, disk usage, 이런 모든것들을 자동화 해서 알람기능을 갖추는걸 추천합니다.
  26. error_log, deadlock, slave status, analyze table, right config, backup, disk usage, 이런 모든것들을 자동화 해서 알람기능을 갖추는걸 추천합니다.
  27. error_log, deadlock, slave status, analyze table, right config, backup, disk usage, 이런 모든것들을 자동화 해서 알람기능을 갖추는걸 추천합니다.
  28. error_log, deadlock, slave status, analyze table, right config, backup, disk usage, 이런 모든것들을 자동화 해서 알람기능을 갖추는걸 추천합니다.
  29. error_log, deadlock, slave status, analyze table, right config, backup, disk usage, 이런 모든것들을 자동화 해서 알람기능을 갖추는걸 추천합니다. 재부팅후에 config 값이 변동되는 경우가 있습니다.
  30. error_log, deadlock, slave status, analyze table, right config, backup, disk usage, 이런 모든것들을 자동화 해서 알람기능을 갖추는걸 추천합니다.
  31. error_log, deadlock, slave status, analyze table, right config, backup, disk usage, 이런 모든것들을 자동화 해서 알람기능을 갖추는걸 추천합니다.
  32. error_log, deadlock, slave status, analyze table, right config, backup, disk usage, 이런 모든것들을 자동화 해서 알람기능을 갖추는걸 추천합니다.
  33. 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 하거나 수행되는 쿼리문에 오류는 없는지 상호 확인합니다. )
  34. 공부하는건 좋은데 라이브 적용은 매우 신중 너무 여러가지 언어나 데이터베이스 활용은 엔지니어를 추후 엔지니어 구하기 힘듬. 복구해줘야할때, 롤백해야할때, 보상을 해줘야할때 이런걸 모두 미리 생각하고 진행해야함. RDB 라면 금방 해결할 문제들이 NoSQL 에서는 복구과정에서 큰 이슈가 될수 있음.
  35. Corruption, 하드웨어 문제, 클라우드선택의 중요성
  36. Corruption, 하드웨어 문제, 클라우드선택의 중요성 복제 구성이 있었기 때문에 Federated 구성을 통해 안전한 복구가 되었음. 이문제로 인해 여러차례 반복 커럽션이 났고 결국 하드웨어 문제임을 인식 다른 업체로 이전작업을 했습니다. Signal 6 Error
  37. Show engine innodb status 로 마지막 데드락만 확인가능 set global innodb_print_all_deadlocks=ON; 이 옵션을 이용하면 errorlog 에 계속 남음.
  38. 슬레이브 중지 (나중에 켜도 됨. innodb_flush_log_at_trx_commit =0 or 2 sync_bin=0 stop slave analyze to table (통계업데이트)
  39. Request 를 최대한 미리 예상해야하나 쉽지 않은 문제. 슬레이브 중지 (나중에 켜도 됨. innodb_flush_log_at_trx_commit =0 or 2 sync_bin=0 stop slave analyze to table (통계업데이트)
  40. 시간이 오래걸리는 쿼리문(일명 악성쿼리문)을 찾아서 옳바른 실행계획으로 실행이 되고 있는지 확인 및 조치
  41. 슬레이브 중지 (나중에 켜도 됨. innodb_flush_log_at_trx_commit =0 or 2 sync_bin=0 stop slave analyze to table (통계업데이트)
  42. 슬레이브 중지 (나중에 켜도 됨. innodb_flush_log_at_trx_commit =0 or 2 sync_bin=0 stop slave analyze to table (통계업데이트)
  43. 슬레이브 중지 (나중에 켜도 됨. innodb_flush_log_at_trx_commit =0 or 2 sync_bin=0 stop slave analyze to table (통계업데이트)
  44. 슬레이브 중지 (나중에 켜도 됨. innodb_flush_log_at_trx_commit =0 or 2 sync_bin=0 stop slave analyze to table (통계업데이트)
  45. Innodb buffer pool sizing 신중.
  46. Innodb buffer pool sizing 신중.
  47. Innodb buffer pool sizing 신중.
  48. 슬레이브 중지 (나중에 켜도 됨. innodb_flush_log_at_trx_commit =0 or 2 sync_bin=0 stop slave analyze to table (통계업데이트)
  49. 어제와 오늘 일주일전과 오늘 이런형태로 비교하면서 분석
  50. swappiness = 10 매우중요 , OOM kill 당하는 경우 (Out of memory kill) 기본수치는 60으로 되어 있음. 개인적으로 권장수치는 10입니다. 0 으로 운용해본결과 결과적으로 메모리가 부족해서 mysql 이 멈춘적 이 있습니다. 아래 차트를 보시면 swappiness=0 으로 해놨을 때 메모리부족으로 OOM Kill 을 당했었고 swappiness=10 은 정상적입니 다. Swap 을 많이 사용해도 문제(Disk 에 부하유발)이고 너무 사용하지 못하게 해도 문제가 됩니다.
  51. 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
  52. 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
  53. 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
  54. 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
  55. 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
  56. Topology DB Master - 마스터 디비 게임데이터 전체 저장 DB Slave 1 : 1차 슬레이브, 마스터디비에서 부하가 많이 발생할경우 일부 샤드역할도 함. DB Slave 2 : 2차 슬레이브, DW 로 넘기는 스케쥴링(Embulk 이용) DB Slave 3 : 3차 슬레이브는 클라우드를 언제든지 옮길수 있도록 준비하기 위해 낮은 사양의 슬레이브를 둔것.
  57. 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
  58. 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
  59. 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
  60. 파티션테이블 ? 통테이블 ? NoSQL ? - Monthly 로 남겨서 쉽게 drop 시킬수 있도록. (테이블이 drop 되면 용량이 확보, 그냥 delete 를 하면 확보 안됨)
  61. TokuDB, Columnstore
  62. 비용절감 효과
  63. 용량이 크지 않다면 논리백업(mysqldump)을 활용, 용량이 10GB 이상 넘어가면 그때부터는 물리백업(Mariadbbackup) 을 활용하는게 좋습니다. 특정 테이블만 별도로 백업하고 싶다면 mysqldump 를 활용해서 하면 효과적임.
  64. log-bin = mysql-bin expire_logs_days = 3 기본적으로 Log-bin 을 활성화 시켰다면 리두로그가 쌓이기 때문에
  65. 개발자들이 가장 자주 문의하는게 접속이 안되요 기본적인 클라우드 및 네트워크 지식 필요
  66. 개발자들이 가장 자주 문의하는게 접속이 안되요 기본적인 클라우드 및 네트워크 지식 필요
  67. 개발자들이 가장 자주 문의하는게 접속이 안되요 기본적인 클라우드 및 네트워크 지식 필요
  68. 개발자들이 가장 자주 문의하는게 접속이 안되요 기본적인 클라우드 및 네트워크 지식 필요
  69. 개발자들이 가장 자주 문의하는게 접속이 안되요 기본적인 클라우드 및 네트워크 지식 필요
  70. 처음엔 스팍으로 구현 > 빅쿼리로 구현 > 컬럼스토어로 구현 (약 10억건 200기가 정도 데이터 처리)
  71. 개발자들이 가장 자주 문의하는게 접속이 안되요 기본적인 클라우드 및 네트워크 지식 필요
  72. 스터디를 통해 데이터 크롤러를 만들고 이후 후속 분석을 통해 다면적 결과를 도출
  73. 같은 고객찾기
  74. 엘프 크롤링 이후 다면적 분석
  75. 엘프 크롤링 이후 다면적 분석
  76. 개발자들이 가장 자주 문의하는게 접속이 안되요 기본적인 클라우드 및 네트워크 지식 필요
  77. 라이브로 가능한 옵션을 별도로 정의해두고 유사시 사용하면 좋음.
  78. 라이브로 가능한 옵션을 별도로 정의해두고 유사시 사용하면 좋음.
  79. 시스템에 익숙해질수록 새벽전화를 막을수 있고 최대한 자동화 + 모니터링 철저. 새벽에 온 전화는 매우 크리티컬, 평소 체력관리 중요.
  80. 중요한 리포팅 우선순위, 반복되는 리포팅은 자동화처리, 최대한 신속 정확하게 요청자에게 제공하는것이 중요한데 신속보다는 정확이 더 중요.
  81. 개발자들에게 신뢰를 얻을만한 피드백 제공(그래도 끊임없이 시스템 모니터링을 통해 의심)
  82. 많은 부서의 다양한 요구 분석 리포팅
  83. 리더는 절대 뽐내면 안됨.
  84. 쉬운 기술들은 금방금방 습득이 가능.
  85. 커뮤니티 운영을 하고 있습니다.
  86. 커뮤니티 운영을 하고 있습니다.
  87. 커뮤니티 운영을 하고 있습니다.
  88. 커뮤니티 운영을 하고 있습니다.