- 신입사원 대상으로 강의한 내용입니다. - 장비 1대에서 시작해서 셀 아키텍처까지 확장하는 내용과(LiveJournal의 발표를 참조) - 서비스 운영에 필요한 백업, 로그, 모니터링 내용을 담았습니다.

1. 안정적인 서비스 운영
설계에서 모니터링까지
cybaek@me.com
cybaek@naver.com
cybaek@sk.com
2013.08-rev3.1

2. 서버 한 대에서 시작
웹과 디비를 한 대에서 운영
| 쉽게 시작할 수 있지만,
| 원만한 운영 어려움
웹, 디비

3. 두 대의 서버
웹 서버 1대, 디비 서버 1대
| SPOF: 웹, 디비 뭐든 하나만 죽으면
웹
디비
W W W
R R R
R R R

4. 세 대의 서버
웹 서버를 2대로 늘려서
웹
디비
웹
W W W
R R R
R R R

5. 세 대의 서버
로드밸런싱과 고가용성
| 가장 흔한 것이 L4
L7 헬스체크
| 리버스프락시
웹
디비
웹
L4
W W W
R R R
R R R

6. 세 대의 서버
로드밸런싱과 고가용성
| DNS RR을 이용
웹
디비
웹
DNS
W W W
R R R
R R R

7. 세 대의 서버
로드밸런싱과 고가용성
| 세션 공유
로그인 정보 등을 공유해야함
쿠키를 이용할 수도
.데이터 양에 제한 웹
디비
웹
L4
세션
W W W
R R R
R R R

8. 웹
디비
웹
L4
세션
W W W
R R R
R R R
로드밸런싱과 고가용성
| 웹 서버 로컬 디스크에 공유 정보를 저장할 수 없
음
구글 앱엔진과 같은 자동 스케일링을 해주는 인프라의
중요 제한 사항
세 대의 서버

9. 세 대의 서버
로드밸런싱과 고가용성
| 두 서버간 컨텐트를 공유하려면,
DB
NAS/NFS
memcached, Redis ... 웹
디비
웹
L4
세션
공유 데이터
W W W
R R R
R R R

10. L4에 대해 조금만 더
DSR(Direct Server Return) 모드
| L4가 양방향 프락시라면
모든 웹 서버가 받는 트래픽을
L4가 다 받아야함
웹
디비
웹
L4
세션
공유 데이터
W W W
R R R
R R R

11. 웹
디비
웹
L4
세션
공유 데이터
W W W
R R R
R R R
DSR(Direct Server Return) 모드
| 적당한 예
요청 패킷이 적은 케이스
.일반적인 웹 요청
.파일 다운로드
L4에 대해 조금만 더

12. 웹
디비
웹
L4
세션
공유 데이터
W W W
R R R
R R R
DSR(Direct Server Return) 모드
| 적합하지 않은 예
요청 패킷이 많은 케이스
.파일 업로드와 같은 웹 요청
업로드 할 때는 L4를 거치지 않도록 예외처리
.SMTP
L4에 대해 조금만 더

13. 네 대의 서버
디비 서버를 한 대 더
| 마스터/슬레이브
웹
디비
마스터
웹
L4
세션
공유 데이터
디비
슬레이브
W W W
R R
R
W W W
R
R R

14. 웹
디비
마스터
웹
L4
세션
공유 데이터
디비
슬레이브
W W W
R R
R
W W W
R
R R
쓰기는 마스터에, 읽기는 두 대 모두에서
| 읽기 처리는 두 배로 증가 ;-)
| 써야할 양도 두 배로 증가 :-(
슬레이브 복제 트래픽
네 대의 서버

15. 디비를 계속 증설
마스터는 하나, 슬레이브는 +1...
웹
디비
마스터
웹
L4
세션
공유 데이터
디비
슬레이브
디비
슬레이브
W W W
R
R
W W W
R
R
W W W
R
R

16. 웹
디비
마스터
웹
L4
세션
공유 데이터
디비
슬레이브
디비
슬레이브
W W W
R
R
W W W
R
R
W W W
R
R
읽기 부하는 분산이 되나
복제 시간은 점점 늘어남
| 복제본이 늘어나 안정적이지만 낭비가 큼
| 복제 지연은 생각보다 심각
데이터 싱크 문제로 인해
정말 읽은 것이 맞는지 재차 확인하는 로직으로, 필요
이상의 조회 부하 발생
디비를 계속 증설

17. 웹
디비
마스터
웹
L4
세션
공유 데이터
디비
슬레이브
디비
슬레이브
W W W
R
R
W W W
R
R
W W W
R
R
데이터를 특정 속성 중심으로 물리적 분할
| 분할된 데이터는 서로 조인을 하거나 참조가 발생
해서는 안 됨
| 보통 userId를 사용
디비 파티셔닝/샤딩

18. 셀 아키텍처
웹
디비
마스터
웹
L4
세션
공유 데이터
디비
슬레이브
디비
슬레이브
디비
(셀 정보)
#2
#3
#4
#1
W W W
R
R
W W W
R
R
W W W
R
R
W W W
R R R
R R R
W W W
R R R
R R R
W W W
R R R
R R R

19. 웹
디비
마스터
웹
L4
세션
공유 데이터
디비
슬레이브
디비
슬레이브
디비
(셀 정보)
#2
#3
#4
#1
W W W
R
R
W W W
R
R
W W W
R
R
W W W
R R R
R R R
W W W
R R R
R R R
W W W
R R R
R R R
셀 디비
| 분할된 데이터가 어디에 속하는지 참조
전체 사용자가 공통으로 참조
셀 디비, 로케이션 디비, 유저 디스커버리 서비스 등등
의 용어 사용
셀 아키텍처

20. 웹
디비
마스터
웹
L4
세션
공유 데이터
디비
슬레이브
디비
슬레이브
디비
(셀 정보)
#2
#3
#4
#1
W W W
R
R
W W W
R
R
W W W
R
R
W W W
R R R
R R R
W W W
R R R
R R R
W W W
R R R
R R R
장점
| 셀 단위 스케일링
| 장애를 특정 셀로 고립 가능
| 프론트+백엔드 점진적 배포
일부 웹 서버만 선적용하는 것은 흔하고 쉽지만
디비가 변경되었을 때, 일부 웹 서버만 적용하는 것은
쉽지 않지만, 셀 아키텍처에서는 가능
셀 아키텍처

21. 웹
디비
마스터
웹
L4
세션
공유 데이터
디비
슬레이브
디비
슬레이브
디비
(셀 정보)
#2
#3
#4
#1
W W W
R
R
W W W
R
R
W W W
R
R
W W W
R R R
R R R
W W W
R R R
R R R
W W W
R R R
R R R
단점
| SPOF: 셀!
가장 심각한 문제
하지만 거의 정적인 데이터
| 많은 장비 필요
| 제공하는 기능에 따라 셀간 데이터를 조합해야할
수도
예, 페이스북의 현 계정 친구 정보를 스트림에 추가
셀 아키텍처

22. 웹
디비
마스터
웹
L4
세션
공유 데이터
디비
슬레이브
디비
슬레이브
디비
(셀 정보)
#2
#3
#4
#1
W W W
R
R
W W W
R
R
W W W
R
R
W W W
R R R
R R R
W W W
R R R
R R R
W W W
R R R
R R R
워드프레스
| 2^n개의 버켓을 마련
가상의 버켓을 미리 많이 만들어 두고, 물리 버켓을 매
핑
| 하나의 서버에서 운영하다가 용량이 차면 2대로
분할
또 차면 또 분할
셀 아키텍처

23. 웹
디비
마스터
웹
L4
세션
공유 데이터
디비
슬레이브
디비
슬레이브
디비
(셀 정보)
#2
#3
#4
#1
W W W
R
R
W W W
R
R
W W W
R
R
W W W
R R R
R R R
W W W
R R R
R R R
W W W
R R R
R R R
메일
| 웹 인터페이스
HTTP 리다이렉트를 이용하여 속한 셀로 전환 가능
| IMAP, POP3
프로토콜상 어느 셀에서나 모든 사용자 서비스 가능해
야함
셀 아키텍처

24. 웹
디비
마스터
웹
L4
세션
공유 데이터
디비
슬레이브
디비
슬레이브
디비
(셀 정보)
#2
#3
#4
#1
W W W
R
R
W W W
R
R
W W W
R
R
W W W
R R R
R R R
W W W
R R R
R R R
W W W
R R R
R R R
몇 개의 셀이 적당
| 최소 2개
50:50? 10:90?!
.50:50 등분하면 점진적 배포를 적극 활용하기 어려움
위험이 있는 배포를 조금 선 배포하지 못하고 절반에 적용
하게 됨
.10:90과 같이 특정 셀을 작게 가져가면 점진적 배포에
유리
| 5개? 10개?
정책!
셀 아키텍처

25. 웹
디비
마스터
웹
L4
세션
공유 데이터
디비
슬레이브
디비
슬레이브
디비
(셀 정보)
#2
#3
#4
#1
W W W
R
R
W W W
R
R
W W W
R
R
W W W
R R R
R R R
W W W
R R R
R R R
W W W
R R R
R R R
IDC 분할
| 그렇게까지?
| 4개라면 IDC별 2개씩? 혹은 1개, 3개?
역시 정책!
셀 아키텍처

26. 클러스터링
| 데이터를 자동으로 분산 저장
| 노드간 재균형 작업
샤딩
| 데이터를 수동으로 분산 저장
| 분할된 데이터는 서로 연관관계가 없음
클러스터링과 샤딩

27. 스토리지 스케일링
분산파일시스템
| 복제본 수를 일률적으로 적용할 필요가 없음
요청이 많은 파일은 복제수 늘리고
보존 시한이 얼마 남지 않은 파일은 복제수 줄이고
| 중복 파일 처리
그냥 둘 것인가
줄일 것인가

28. 스토리지 스케일링
사용성에 따라
| 단위 디스크 크기와 서버의 디스크 베이 갯수
파일을 쌓아두기만 하는 아카이빙 용도인지
.용량이 큰 디스크를
거의 전 파일에 거쳐 IO가 발생하는지
.빠른 디스크(혹은 SSD)를 많이 꽂아서
최근 파일만 주로 사용하는지
.최근 파일은 작은 디스크(혹은 SSD)로 구성한 서버를
사용하고
.시간이 지난 파일은 용량이 큰 서버로 이전

29. 장비가 늘면서 생각할 고민들
빠른 배포
| 배포가 번거로운 일이 되면 안됨
페이스북
.BitTorrent 이용
.사이트 업데이트에 15~30분 소요
.마이너 업데이트는 매일
.메이저 업데이트는 매주 한 번

30. 장비가 늘면서 생각할 고민들
빠른 롤백
| 빠른 배포보다 중요!
| 롤백 기준 사전 정의 필수
배포 장애시 우왕좌왕하면 안됨
즉각 해결을 못한다면 미련없이 롤백
.“10분이면 고칠 것 같아요”이런 말 믿지 말 것!
| 배포 전에, 롤백 때 필요한 작업 미리 준비
롤백 결정 후, 이런 저런 스크립트 만들면 때는 늦음
엔터 한 번으로 롤백이 되도록

31. 장비가 늘면서 생각할 고민들
설정 관리
| 모든 장비의 설정 내용이 같은가
설정 값을 바꿔가며 테스트 한 다음 그대로 방치하는
경우가 있음
| 배포
바이너리 배포 시 함께?
설정은 따로 리포지토리 관리?

32. 스케일링과 속도
두 개는 다른 이야기
스케일링
| LiveJournal
“When you add twice as many servers, are you twice as
fast or have twice the capacity?”
| Instagram
“Replacing all components of a car while driving it at
100mph”

33. 스케일링과 속도
속도
| 두 배 빨라진다면, 50% 하드웨어로 커버

34. 속도 개선
제일 첫 번째 작업은 프로파일링
| 감에 의존하지 말 것
| 어디가 느린지 파악하는 것이 우선

35. 속도 개선
해결책
| 캐쉬: memcached, Redis...
각 레이어별 적용 가능
.디비에서, WAS에서, 웹 서버에서 각각 캐쉬 가능
저장 방식
.사용할 결과를 그대로 저장하거나
빠르나 많은 메모리
.구조화하여 저장하거나
조금 느리지만 보다 효율적인 메모리 사용

36. 속도 개선
해결책
| 정책변경
예, 조회수가 꼭 정확해야하나?
.공유 저장소(memcached)에 기록하되, 일정 시간마다
디비에 기록
.디비에 기록하기 전에 저장소가 비정상 종료된다면 일
부 조회수는 유실
이런 것을 정책으로 허용하느냐 마냐에 따라 구조가 달라짐
.디비 기록 주기가 1분이고, 분당 1,000번 조회를 할 경
우, 정책과 약간의 코드만으로 디비 UPDATE를 분당
1,000회에서 단 1회로 줄일 수 있음

37. 속도 개선
해결책
| 증설
사용자가 늘었거나, 기능이 추가되어서
정말 증설이 필요할 수도 있음
증설은 죄가 아님

38. 스토리지 속도
메모리
디스크 개수
| 1T x 1 vs 100G x 10
RAID 컨트롤러
| 정책
배터리 충전 중에는 디스크에 바로 쓰기(Battery
Backup Write Cache)
.전원 공급이 갑자기 끊길 때 쓰기 유실을 최소화 하기
위한 드라이버 정책(조정 가능)
.하지만 이로 인해 디비 같은 경우 서비스 품질이 급락

39. 백업
어떤 전략으로
| 주기는?
| 전체? 증분?
어떻게 복구
| 복구에 얼마나 걸리나
| 복구하는 동안 서비스는 유지? 정지? 읽기만?

40. 로그 처리
보관
| 얼마나 오랫동안 보관해야하나
정책의 문제
조회
| 얼마나 많은 범위의 데이터를, 얼마나 빠르게
잘 구축하면 고객문의 처리를 비개발자에게 이관 가능
보안
| 개인 정보 저장하지 않도록

41. 로그 처리
수집
| 주기는?
실시간
.Scribe: https://github.com/facebook/scribe
시간 단위

42. 메일 발송
생각보다 관리할 것이 많음
| 한 통 발송은 쉽지만,
책 예제 따라하면 됨
| 다량 발송은 손이 많이 감
코드의 문제가 아니라 운영 문제
.KISA 화이트IP 등록

43. 배치 작업
필요한 기본 인프라
| 실패시 알림
| 과거 작업 이력 조회
| 여러 서버 묶어서 실행

44. 자동화
신규 서버 설치
| 장비를 받아, 10분 내에 설치할 수 있도록
| 방화벽 오픈 등이 빠른 대응에 걸림돌
애당초 C클래스 단위로 관리
일상적인 응용 배포
자동 복구
| 장애 시 루틴하게 하는 작업
예, 프로세스 재구동 등을 특정 조건일 때 자동으로 수
행하도록

45. 품질 관리
웹, WAS
| 각 URI별 응답속도 관리
평균과 표준편차 같이 관리
| 구간별 처리 속도 관리
주요 기능의 경우, URI 하나의 응답 속도를 더 쪼개서
내부 로직별 처리 속도를 기록

46. 품질 관리
백엔드 서버간 처리
| 각 서버 구간별 처리 속도 관리
한 요청이 여러 서버를 활용할 때, 각 서버별 응답 속도
관리
.Zipkin: https://blog.twitter.com/2012/distributed-
systems-tracing-zipkin

47. 품질 관리
디비
| DBA의 검수 필수
| 동적 쿼리를 없애도록
1개의 동적 쿼리는 생각보다 적은 N개의 정적 쿼리로
변경 가능
.쿼리 관리가 용이해지고
.각 정적 쿼리마다 힌트를 정확하게 줄 수 있음
| 슬로우 쿼리 자동 검출

48. 모니터링
경고와 장애 수준 분리
| 대부분 장애 수준이 되고 나서야 알람을 받음
디스크 사용률 90%일 때 알람
.“이제 장애 납니다”라는 문자 받는 것
.60%를 유지하고 있다면 70%~80%일 때 경고 알람을 받
아야함

49. 모니터링
최저 값 모니터링
| 데몬 개수가 N개를 넘을 때 알람을 받음
데몬이 죽었다면 알람 안 옴
주기적으로 수치 점검
| 시스템의 기능과 사용자 수는 계속 변함
경고, 장애, 최저 값 세 수치는 주기적으로 리뷰해야함

50. 모니터링
테스트 활용하여 기능 체크
| 사용자 인터페이스 레벨의 테스트 모듈을 주기적
으로 돌려, 서비스 상태 체크
무의미한 알람 받지 않도록
| 무시해도 되는 알람이라면 받지 않도록 설정
그런 알람 속에 진짜 경고 메시지가 묻힐 수 있음

51. 모니터링
연동 서비스/서버 모니터링
| 외부 API를 이용할 경우, 해당 API를 직접 체크
연동 서비스쪽 원인으로 발생한 장애를 빠르게 검출할
수 있음
.연동 서비스의 응답 속도는 담당 서비스의 품질에도 영
향을 줌
내가 직접 관리하는 서비스가 아니라고 방치해서는 안 됨

52. 흔한 장애
로그
| DEBUG 레벨의 로깅
예, 로그를 껐더니 속도가 10배 향상
| 에러 로그를 안 봐서 키우는 장애
에러 로그 크기는 0이 정상
‘괜찮은 에러’는 에러가 아니니 에러 로그에 남기지
말 것

53. 흔한 장애
타임아웃
| 디폴트 값 사용 주의
보통 디폴트가 얼마인지도 모르고 사용
보통 10ms로 응답할 때, 응답이 1초 지연되면 동시 접
속수는 100배가 됨
| 평균 응답 속도에 상응하는 타임아웃 설정
보통 5ms 이하로 응답할 때, 타임아웃이 2초가 적당?
| 단위 확인 필요
예, ms인 줄 알고 1000이라고 넘겼는데... sec

54. 흔한 장애
트래픽
| 한 달 전부터 늘고 있었는데
에러 핸들링
| 소스코드에서 return 값 제대로 확인하지 않고

55. 흔한 장애
파일/디스크 관련
| 디스크 가용량이 부족하거나
지우지 않고 쌓인 로그
| inode가 부족하거나
작은 파일을 많이 저장하고 있을 때
| FD_MAX가 작거나
ulimit -n

56. 흔한 장애
L4
| L4를 적용했는데도, 정상 동작하지 않는 서버로
계속 요청이 가는 경우
HTTP라면 L7 헬스 체크 적용

57. 흔한 장애
디비
| 갑자기 쿼리의 실행 계획이 바뀌어 슬로우 쿼리
발생
쿼리에 힌트를 주어 실행 계획을 고정
.동적으로 문자열을 만들어 쿼리를 생성할 경우 힌트 주
기가 어려움
동적 쿼리를 다수의 정적 쿼리로!
| 통계 쿼리
캐쉬 메모리가 지역성이 떨어지는 데이터로 채워져 성
능 저하 초래

58. 대규모 장애 대응
중요 기능 우선
| 서비스 기능을 중요도로 정렬
.게시판: 읽기 > 쓰기 > 검색
.메일: 수신/읽기 > 목록 > ... > 쓰기 > ... > 검색 > 색인
.검색: 통합검색 > ... > ... > 색인
| 장애 시 중요 기능을 보호하는 대응
우선 순위 떨어지는 기능을 포기하여 상위 기능을 개선
.미들웨어에서 호출 컴포넌트 정보를 받아, 비중요 컴포
넌트로 부터의 호출을 실패 처리

59. 대규모 장애 대응
기타
| 캐쉬 만료 기간 연장
캐쉬를 2분간 보관한다면 임시로 10분 등으로 연장
.백엔드 호출이 그만큼 줄어들게 됨
| 색인 갱신 중단
색인 작업은 전반적인 데이터 패치를 수반
이를 잠시 멈춰, 내부 트래픽과 미들웨어 호출량을 줄
일 수 있음
| 서비스 마다 특성이 있음
고민! 고민! 고민!

60. 장애 후 대응
회고
| 해당 장애를 사용자가 인지하기 전에 미리 알 수
는 없었는지
미리 알 수 있는 방법을 찾아내면 모니터링 항목으로
등록
| 장애 원인을 아는데 왜 오래 걸렸는지, 자동으로
알 수는 없었는지
자동으로 알 수 있게 됐다면 스크립트화
.해당 스크립트 묶음을 장애 시 활용하면 원인 진단을 빠
르게 할 수 있음

61. http://www.slideshare.net/cybaek/201308-25737111