데이터야놀자 2017

1. 데이터야 안전하게 놀아보자
한번쯤은 고민해봤어야할 데이터 이야기, by chan

2. 자기소개
절대 깨지지 않는 견고한 서비스를 지향
국내 최초(?) 은행 오픈소스 DB 엔지니어
우육빛깔 까칠행원
(KT하이텔 > 티몬 > 카카오 > 한국카카오은행)
성동찬 (Chris / Chan)
http://gywn.net
https://www.facebook.com/dongchan.sung

3. 저는 지금 실험 중입니다.

4. 무슨 실험을
하냐고요?
하나. 절대 깨지지 않는 서비스
둘. 극한의 퍼포먼스
셋. 99.99999999999999%

5. 이야기 순서
가용성 이야기
변경 로그 이야기
구조 변경 이야기

6. 사실 처음 시도한것 많아요.
무섭지만, 일단 질러보았지요. ㅋㅋㅋㅋㅋ;;
이제야 고백하지만..

7. 1. 가용성 이야기
(가장 진지할 이야기)

8. MySQL로 이중화를 한다면?
얘 혼자는 외로워요.

9. MySQL로 이중화를 한다면?
그래서 두 대 이상을 그룹지어주죠.

10. 스토리지 끼고 이중화
ACTIVE STAND-BY

11. 스토리지 끼고 이중화
ACTIVE

12. RHCS
DRBD
DRDB는 논리 블록 카피이기는 하나, 동일 데이터 본다는 관점에서 그냥 넘어갑시다.

13. 스토리지 비싸요.
스토리지 성능이 디비 성능을 결정해요.
디스크 의존도가 커요.
블록 깨질 때는 대응이 안돼요.

14. 데이터 복제로 이중화
master slave
“데이터 변경 로그”로 데이터 복사
(mysql에서는 이것을 “바이너리 로그” 라고 칭합니다.)

15. 데이터 복제로 이중화
master

16. 복제 상태 관리가 필요하다.
롤 체인지가 귀찮다.
장애 대응 자동화가 복잡하다.
비동기로 데이터가 복제된다.

17. 스토리지 끼고 이중화?
데이터 복제로 이중화?

18. 스토리지 끼고 이중화?
데이터 복제로 이중화?

19. 귀찮은 것은 자동화하자.
데이터 유실없게 고민해보자.

20. MHA 로 가용성 우선 확보
master slave
slave
MHA 프로세스

21. MHA 로 가용성 우선 확보
master slave
MHA 프로세스
master
페일오버 + 리플리케이션 재구성

22. MHA 에 필요한 양념
마스터 바이너리 로그
슬레이브(들)의 릴레이 로그

23. MHA로 자동화 달성
(장애 시 30초 이내 페일오버)

24. 비동기 복제 취약점은?
master slave
slave
async
async

25. SEMI-SYNC REPLICATION
Commit
OK
Write to Binary Log
Storage Commit
Send BinaryLog
ACK
master slave
AFTER_SYNC 이야기임

26. SEMI-SYNC REPLICATION
master slave
slave
async
async
1ms
50ms

27. 슬레이브 어딘가에 변경 이력 있음

28. MHA + SEMI-SYNC
클러스터 기준으로는 데이터 유실 없음
더이상 로컬 디스크에 의존하지 않아도 됨

29. 가용성 확보
비동기 같은
동기같은
비동기 데이터 복제
(데이터 유실 없는)

30. 2. 변경 로그 이야기
(꼭 알아야할 이야기)

31. 데이터 변경하기
1 100 TEXT1_ABCDEFGHI
2 200 TEXT2_ABCDEFGHI
PK COL1 COL2
UPDATE TBL SET COL1 = COL1 + 10;

32. 데이터 변경하기
1 110 TEXT1_ABCDEFGHI
2 210 TEXT2_ABCDEFGHI
PK COL1 COL2

33. 데이터 변경 로그(binary log)
트랜잭션이 커밋되면 변경 내용이 기록
STATEMENT(SQL)
ROW : FULL, MINIMAL

34. STATEMENT
대화를 글로 쭈~욱 적은 역사서

35. STATEMENT
2017.10.13 10:40:00
UPDATE TBL SET COL1 = COL1 + 10;
Binary Log

36. STATEMENT
쿼리가 그대로 기록된다.
락 수위가 높아진다. (>= repeatable read)
쿼리 제약이 꽤 있다. (UUID, RAND..)
쿼리만 정상이면, 복제 이슈 없다.

37. ROW
전/후 사진을 모아놓은 그림 기록서

38. ROW : FULL
1 100 TEXT1_ABCDEFGHI
2 200 TEXT2_ABCDEFGHI
Binary Log
2 210 TEXT2_ABCDEFGHI
1 110 TEXT1_ABCDEFGHI
OLD
NEW
OLD
NEW

39. ROW : FULL
데이터 변경 전/후 이미지가 기록된다.
변경 데이터가 모두 있기에 연동이 수훨하다.
(안해봤지만) 타임머신도 구현 가능하다.
테이블과 트래픽에 따라 로그가 커질 수 있다.

40. ROW : MINIMAL
1
2
Binary Log
210
110
OLD
NEW
OLD
NEW
WHERE PK = 1
SET COL1 = 110
WHERE PK = 2
SET COL1 = 210

41. ROW : MINIMAL
변경된 칼럼 데이터만 저장된다.
타 시스템 연동 시 데이터 조회를 해봐야한다.
로그 사이즈를 예측할 수 있다.

42. FULL & MINIMAL
테이블에 PK가 없으면 효율이 떨어진다.
변경된 데이터 건 수가 사이즈를 좌우한다.

43. 짚어봐야할 질문1
STATEMENT는 작고,
ROW는 무조건 크다???
ROW 평균 사이즈가 작은 경우
INSERT 위주의 서비스

44. 짚어봐야할 질문2
ROW:FULL 시 커지는 케이스
게시판 카운트 업데이트
쿼리 하나 변경량이 많을 때

45. STATEMENT?
ROW:FULL?
ROW:MINIMAL?

46. STATEMENT?
ROW:FULL?
ROW:MINIMAL?

47. BINARY LOG는요.
STATEMENT가 절대적으로 작지 않습니다.
서비스 패턴에 따라 사이즈는 유동적입니다.
특성을 알고 잘~ 쓰면 삼대가 편안합니다.

48. BINARY LOG
메뉴얼 사이즈에 현혹되지 말
고, 지금 서비스 바라보고, 데이
터를 바라보고 결정합시데이.

49. 3. 구조 변경 이야기
(살떨리는 진짜 운영 이야기)

50. 스키마 변경 방법
온라인 ALTER
슬레이브 적용 후 롤 체인지
트리거 기반 유틸리티

51. 온라인 ALTER
>= MySQL 5.6 (InnoDB)
Binlog에 ALTER 한 줄만 기록
https://dev.mysql.com/doc/refman/5.7/
en/innodb-create-index-overview.html

52. master
온라인 ALTER
slave
ALTER .. (1hour)
여기도 1hour
REPLICATION LAG

53. 온라인 ALTER
인덱스를 각각 노드에서 별도 생성
(set session variable sql_log_bin = OFF)
오래 걸리지 않는 ALTER에 적합
(개인의 선택과 정책과 판단을 존중합니다.)

54. 슬레이브 적용 후 롤 체인지
대형 테이블 스키마 변경
온라인 ALTER 불가 상황

55. master
슬레이브 적용 후 롤 체인지
slave
PK1
COL1
COL2
PK1
PK2
COL2

56. 슬레이브 적용 후 롤 체인지
롤 체인지 시 기존 세션 강제 KILL
데이터 안정성 보장 여부 판단 필요
(이건 MHA로 충분히 가능합니다.)

57. 트리거 기반 유틸리티
pt-online-schema-change

58. 트리거 기반 유틸리티
http://gywn.net/2017/08/small-talk-pt-osc/

59. 트리거 기반 유틸리티
리플리케이션 지연 없음
롤체인지 필요 없음
그러나.. 로그 사이즈?

60. 트리거 기반 유틸리티
1 100
2 200
PK COL1
3 300
4 400
5 500
1 100
PK COL1
3 300
BULK INSERT
Trigger

61. 트리거 기반 유틸리티
1 100
2 200
PK COL1
3 300
4 400
5 500
1 100
PK COL1
3 300
BULK INSERT
STATEMENT 로 남기자

62. 트리거 기반 유틸리티
BULK INSERT : STATEMENT
set session tx_isolation='repeatable-read';
set session binlog_format='statement';
TRIGGER : ROW

63. 스키마 변경 방법
데이터
사이즈
복제 지연
로그 사이즈
ALTER
그때 그때 선택하세요

64. 구조 변경
그때 그때 달라요.

65. 가용성을 고민해보았고
(LOSSLESS Replication + MHA)

66. 로그 포멧도 고민해 봤으며
(STATEMENT / ROW:FULL / FOW:MINIMAL)

67. 구조 변경에도 고민했습니다.
(Online ALTER / Slave 변경 / pt-online-shema-change)

68. 내가 책임지는 나만의 실험실
가용성
안정성데이터

69. Q/A
아직 짤리면 안되니, 민감한 질문은 사양

70. 감사해유~!