1.
안정적인 서비스 운영
설계에서 모니터링까지
cybaek.com
2015.02-rev4

2.
스케일링
“Replacing all components of a car
while driving it at 100mph”
- Instagram

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

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

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

6.
세 대의 서버
로드밸런싱
| 두 서버에 트래픽을 ‘분배’
웹 웹
분배기
웹 웹
분배기

7.
세 대의 서버
고가용성
| 디비 구성의 예
장애 시에 대기 서버를 활용
트래픽을 분배하지는 않음
액티브 스탠바이
클라이언트
액티브 스탠바이
클라이언트

8.
세 대의 서버
로드밸런싱과 고가용성
| 가장 흔한 것이 L4
L7 헬스체크
| HAProxy
http://
helloworld.naver.com/
helloworld/284659
웹
디비
웹
L4
W W W
R R R
R R R

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

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

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

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

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

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

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

16.
L4에 대해 조금만 더
대용량 파일 업로드
| 두 단계로 나눠 동작
웹 #1 웹 #2
L4
1.
GET http://L4-IP/who
2.
web-1 public IP
3.
POST http://web-1/upload
웹 #3

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

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

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

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

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

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

23.
디비 파티셔닝/샤딩
데이터를 특정 속성 중심으로 물리적 분할
| 예, 메일
디비
To
cybaek
milk012
cybaek
From
steve
bill
jonny
Subject
아이패드 어때?
주말에 시간 있나요?
[요청] 디자인 좀 봐줘요.
cybaek milk012
웹웹

24.
디비 파티셔닝/샤딩
데이터를 특정 속성 중심으로 물리적 분할
| 사용자(군)별로 데이터를 분리
디비
To
cybaek
milk012
cybaek
From
steve
bill
jonny
Subject
아이패드 어때?
주말에 시간 있나요?
[요청] 디자인 좀 봐줘요.
cybaek milk012
웹웹
디비
cybaek milk012
To
cybaek
cybaek
From
steve
jonny
Subject
아이패드 어때?
[요청] 디자인 좀 봐줘요.
To
milk012
From
bill
Subject
주말에 시간 있나요?
웹웹

25.
디비 파티셔닝/샤딩
데이터를 특정 속성 중심으로 물리적 분할
| 테이블 분리를 디비 분리까지
디비
cybaek milk012
To
cybaek
cybaek
From
steve
jonny
Subject
아이패드 어때?
[요청] 디자인 좀 봐줘요.
디비
To
milk012
From
bill
Subject
주말에 시간 있나요?
웹 웹

26.
디비 파티셔닝/샤딩
데이터를 특정 속성 중심으로 물리적 분할
| 어떤 디비를 봐야할지 판단해야함
사용자별
디비 위치
디비
cybaek milk012
To
cybaek
cybaek
From
steve
jonny
Subject
아이패드 어때?
[요청] 디자인 좀 봐줘요.
디비
To
milk012
From
bill
Subject
주말에 시간 있나요?
세
웹

27.
사용자별
디비 위치
디비
cybaek milk012
To
cybaek
cybaek
From
steve
jonny
Subject
아이패드 어때?
[요청] 디자인 좀 봐줘요.
디비
To
milk012
From
bill
Subject
주말에 시간 있나요?
세
웹
디비 파티셔닝/샤딩
데이터를 특정 속성 중심으로 물리적 분할
| 어떤 디비를 봐야할지 판단해야함
매핑 디비 서버
.데이터 이동이 유연하지만, 별도 서버 운영 필요
해쉬 함수 이용
.별도 서버 없이 찾을 수 있으나, 데이터 분할 시 많은 데
이터를 이동해야할 수 있음

28.
셀 아키텍처
데이터를 특정 속성 중심으로 물리적 분할
| 웹과 디비 서버를 함께 사용자(군)별로 분리할 수도
디비
cybaek milk012
To
cybaek
cybaek
From
steve
jonny
Subject
아이패드 어때?
[요청] 디자인 좀 봐줘요.
디비
To
milk012
From
bill
Subject
주말에 시간 있나요?
웹 웹

29.
셀 아키텍처
데이터를 특정 속성 중심으로 물리적 분할
| 웹, 디비 서버 이중화
cybaek milk012
세
웹
웹
웹
웹
디비
cybaek 웹
디비
milk012

30.
셀 아키텍처
데이터를 특정 속성 중심으로 물리적 분할
| 사용자(군)별 어느 디비에 있는지 정보 보관
cybaek milk012
세
웹
웹
웹
웹
디비
cybaek 웹
디비
milk012
cybaek milk012
웹
웹
웹
웹
웹
디비
cybaek 웹
디비
milk012
웹
사용자별
디비 위치

31.
셀 아키텍처
데이터를 특정 속성 중심으로 물리적 분할
| 셀(Cell)!
cybaek milk012
웹
웹
웹
웹
웹
디비
cybaek 웹
디비
milk012
웹
셀 디비
셀 셀

32.
셀 아키텍처
웹
디비
마스터
웹
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

33.
웹
디비
마스터
웹
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
셀 디비
| 분할된 데이터가 어디에 속하는지 참조
전체 사용자가 공통으로 참조
셀 디비, 로케이션 디비, 유저 디스커버리 서비스 등등
의 용어 사용
셀 아키텍처

34.
웹
디비
마스터
웹
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
장점
| 셀 단위 스케일링
| 장애를 특정 셀로 고립 가능
| 프론트+백엔드 점진적 배포
일부 웹 서버만 선적용하는 것은 흔하고 쉽지만
디비가 변경되었을 때, 일부 웹 서버만 적용하는 것은
쉽지 않지만, 셀 아키텍처에서는 가능
셀 아키텍처

35.
웹
디비
마스터
웹
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: 셀!
가장 심각한 문제
하지만 거의 정적인 데이터
| 많은 장비 필요
| 제공하는 기능에 따라 셀간 데이터를 조합해야할 수
도
예, 페이스북의 현 계정 친구 정보를 스트림에 추가
셀 아키텍처

36.
웹
디비
마스터
웹
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대로 분
할
또 차면 또 분할
셀 아키텍처

37.
웹
디비
마스터
웹
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
프로토콜상 어느 셀에서나 모든 사용자 서비스 가능해
야함
셀 아키텍처

38.
웹
디비
마스터
웹
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개?
정책!
셀 아키텍처

39.
웹
디비
마스터
웹
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개?
역시 정책!
셀 아키텍처

40.
디비 샤딩
Service
DB #1 DB #2
1. 기존과 동일하게 서비스에 접속
http://mail.com/2. 해당 데이터가 어느 디비에
속해 있는지 질의
3. 속한 디비에 질의
Location Service
DB #1 DB #2
1. 기존과 동일하게 서비스에 접속
http://mail.com/2. 해당 데이터가 어느 디비에
속해 있는지 계산
3. 속한 디비에 질의

41.
셀 아키텍처
Cell #1
Service
(샤딩한) 디비
Location
Cell #2
Service
(샤딩한) 디비
IntroService
1. 비로그인 상태에서 접속
http://mail.com/
2. 로그인 후 접속을 받음
3. 어떤 셀에 속한지 물어봄
5. 해당 셀로 접속
http://cell1.mail.com/
4. 어디로 redirect 할지 돌려줌

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

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

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

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

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

47.
이제 속도!

48.
속도
두 배 빨라진다면
| 50% 하드웨어로 커버

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

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

51.
속도 개선
해결책
| 캐쉬: 지역성!을 고려해서 설계
시간적 지역성
.한번 읽은 데이터를 곧 다시 읽을 수 있다.
.LRU
공간적 지역성
.읽은 곳 근처의 데이터를 접근하는 경우가 있다.
.프리페치(prefetch)

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

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

54.
속도 개선
해결책
| 정책변경
조회 수 캐쉬(Write back)
번호
1023
글쓴이
cybaek
제목
steve가 보고 싶어요…
조회수
56
Key
1023
디비에 기록한 시각
2014/04/30 09:05:34
조회수
56
Value
1023번 글을 읽음
1023 cybaek steve가 보고 싶어요… 561023 2014/04/30 09:05:34 571분 뒤에 다시 읽음
지금 - 09:05:34 > 5분 초과?
캐쉬 디비
1023 cybaek steve가 보고 싶어요… 561023 2014/04/30 09:05:34 583분 뒤에 다시 읽음
지금 - 09:05:34 > 5분 초과?
1023 cybaek steve가 보고 싶어요… 591023 2014/04/30 09:11:06 592분 뒤에 다시 읽음
지금 - 09:05:34 > 5분 초과!

55.
속도 개선
해결책
| 정책변경
WWDC, GoogleIO 티켓 구매
.최근 몇 년 초단시간에 매진을 기록
.하지만 사이트는 먹통
.결국, 추첨해서 티켓 구매 기회를 주는 것으로 변경

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

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

58.
품질 관리
read list write
search delete

59.
운영
서비스 오픈은 끝이 아니라 시작.
- ?

60.
메일 발송
생각보다 관리할 것이 많음
| 한 통 발송은 쉽지만,
책 예제 따라하면 됨
| 다량 발송은 손이 많이 감
코드의 문제가 아니라 운영 문제
.KISA 화이트IP 등록
.(업계가 21세기답게 돌아가지는 않음…)

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

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

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

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

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

66.
품질 관리
백엔드 서버간 처리
| 각 서버 구간별 처리 속도 관리
한 요청이 여러 서버를 활용할 때, 각 서버별 응답 속도
관리
.PINPOINT: https://github.com/naver/pinpoint

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

68.
모니터링
경고와 장애 수준 분리
| 대부분 장애 수준이 되고 나서야 알람을 받음
디스크 사용률 90%일 때 알람
.“이제 장애 납니다”라는 문자 받는 것
.평상 시 사용률 20%를 유지하고 있다면, 90%가 아니라
50% 수준에서 경고 알람을 받아야함

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

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

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

72.
시스템 유틸리티
필수
| vmstat, mpstat, iostat, netstat, free, top, sar,
ping

73.
HTTP 에러 페이지 설정
50x
| 사용자들은 무의식적으로 새로 고침을 반복
별도 (정적) 서버로 리다이렉트 하도록 설정

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

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

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

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

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

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

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

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

82.
장애 대응
전파
| 메일링 리스트를 이용하여 유관자에게 전파
처리
| Case By Case
에러 로그
롤백이 가능하면 롤백 우선
에러의 원인이 내 서비스가 아닌 연관 API 서버에 있을
수도

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

84.
http://www.slideshare.net/cybaek/201403