• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
안정적인 서비스 운영   2014.03
 

안정적인 서비스 운영 2014.03

on

  • 7,053 views

 

Statistics

Views

Total Views
7,053
Views on SlideShare
6,611
Embed Views
442

Actions

Likes
69
Downloads
226
Comments
10

11 Embeds 442

http://knight76.tistory.com 327
http://feedly.com 34
https://twitter.com 27
http://www.hanrss.com 19
http://mangastorytelling.tistory.com 15
http://elicie.kr 7
http://www.inoreader.com 6
http://www.slideee.com 3
http://www.samsung.net 2
http://eparchive.samsung.net 1
https://www.linkedin.com 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel

110 of 10 previous next Post a comment

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    안정적인 서비스 운영   2014.03 안정적인 서비스 운영 2014.03 Presentation Transcript

    • 안정적인 서비스 운영 설계에서 모니터링까지 ! cybaek@me.com cybaek@naver.com cybaek@sk.com 2014.03-rev3
    • 스케일링 “Replacing all components of a car while driving it at 100mph” - Instagram
    • 서버 한 대에서 시작 웹과 디비를 한 대에서 운영 | 쉽게 시작할 수 있지만, | 원만한 운영 어려움 웹, 디비
    • 두 대의 서버 웹 서버 1대, 디비 서버 1대 | SPOF: 웹, 디비 뭐든 하나만 죽으면 웹 디비 W W W R R R R R R
    • 세 대의 서버 웹 서버를 2대로 늘려서 웹 디비 웹 W W W R R R R R R
    • 세 대의 서버 로드밸런싱 | 두 서버에 트래픽을 ‘분배’ 웹 웹 분배기 웹 웹 분배기
    • 세 대의 서버 고가용성 | 디비 구성의 예 장애 시에 대기 서버를 활용 트래픽을 분배하지는 않음 액티브 스탠바이 클라이언트 액티브 스탠바이 클라이언트
    • 세 대의 서버 로드밸런싱과 고가용성 | 가장 흔한 것이 L4 L7 헬스체크 | HAProxy http:// helloworld.naver.com/ helloworld/284659 웹 디비 웹 L4 W W W R R R R R R
    • 세 대의 서버 로드밸런싱과 고가용성 | DNS RR을 이용 웹 디비 웹 DNS W W W R R R R R R
    • 세 대의 서버 로드밸런싱과 고가용성 | 세션 공유 로그인 정보 등을 공유해야함 쿠키를 이용할 수도 .데이터 양에 제한 웹 디비 웹 L4 세션 W W W R R R R R R
    • 웹 디비 웹 L4 세션 W W W R R R R R R 로드밸런싱과 고가용성 | 웹 서버 로컬 디스크에 공유 정보를 저장할 수 없음 구글 앱엔진과 같은 자동 스케일링을 해주는 인프라의 중요 제한 사항 세 대의 서버
    • 세 대의 서버 로드밸런싱과 고가용성 | 두 서버간 컨텐트를 공유하려면, DB NAS/NFS memcached, Redis ... arcus http://naver.github.io/arcus/ 웹 디비 웹 L4 세션 공유 데이터 W W W R R R R R R
    • L4에 대해 조금만 더 DSR(Direct Server Return) 모드 | L4가 양방향 프락시라면 모든 웹 서버가 받는 트래픽을 
 L4가 다 받아야함 웹 디비 웹 L4 세션 공유 데이터 W W W R R R R R R
    • 웹 디비 웹 L4 세션 공유 데이터 W W W R R R R R R DSR(Direct Server Return) 모드 | 적당한 예 요청 패킷이 적은 케이스 .일반적인 웹 요청 .파일 다운로드 L4에 대해 조금만 더
    • 웹 디비 웹 L4 세션 공유 데이터 W W W R R R R R R DSR(Direct Server Return) 모드 | 적합하지 않은 예 요청 패킷이 많은 케이스 .파일 업로드와 같은 웹 요청 업로드 할 때는 L4를 거치지 않도록 예외처리 .SMTP L4에 대해 조금만 더
    • L4에 대해 조금만 더 대용량 파일 업로드 | 두 단계로 나눠 동작 웹 #1 웹 #2 L4 1. GET http://L4-IP/who 2. web-1 public IP 3. POST http://web-1/upload 웹 #3
    • 네 대의 서버 디비 서버를 한 대 더 | 마스터/슬레이브 웹 디비 마스터 웹 L4 세션 공유 데이터 디비 슬레이브 W W W R R R W W W R R R
    • 웹 디비 마스터 웹 L4 세션 공유 데이터 디비 슬레이브 W W W R R R W W W R R R 쓰기는 마스터에, 읽기는 두 대 모두에서 | 읽기 처리는 두 배로 증가 ;-) | 써야할 양도 두 배로 증가 :-( 슬레이브 복제 트래픽 네 대의 서버
    • 디비를 계속 증설 마스터는 하나, 슬레이브는 +1... 웹 디비 마스터 웹 L4 세션 공유 데이터 디비 슬레이브 디비 슬레이브 W W W R R W W W R R W W W R R
    • 웹 디비 마스터 웹 L4 세션 공유 데이터 디비 슬레이브 디비 슬레이브 W W W R R W W W R R W W W R R 읽기 부하는 분산이 되나 복제 시간은 점점 늘어남 | 복제본이 늘어나 안정적이지만 낭비가 큼 | 복제 지연은 생각보다 심각 데이터 싱크 문제로 인해 정말 읽은 것이 맞는지 재차 확인하는 로직으로, 필요 이상의 조회 부하 발생 디비를 계속 증설
    • 클러스터링 | 데이터를 자동으로 분산 저장 | 노드간 재균형 작업 샤딩 | 데이터를 수동으로 분산 저장 | 분할된 데이터는 서로 연관관계가 없음 클러스터링과 샤딩
    • 웹 디비 마스터 웹 L4 세션 공유 데이터 디비 슬레이브 디비 슬레이브 W W W R R W W W R R W W W R R 데이터를 특정 속성 중심으로 물리적 분할 | 분할된 데이터는 서로 조인을 하거나 참조가 발생해 서는 안 됨 | 보통 userId, blogId, boardId 등을 사용 디비 파티셔닝/샤딩
    • 디비 파티셔닝/샤딩 데이터를 특정 속성 중심으로 물리적 분할 | 예, 메일 ! 디비 To cybaek milk012 cybaek From steve bill jonny Subject 아이패드 어때? 주말에 시간 있나요? [요청] 디자인 좀 봐줘요. cybaek milk012 웹웹
    • 디비 파티셔닝/샤딩 데이터를 특정 속성 중심으로 물리적 분할 | 사용자(군)별로 데이터를 분리 ! 디비 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 주말에 시간 있나요? 웹웹
    • 디비 파티셔닝/샤딩 데이터를 특정 속성 중심으로 물리적 분할 | 테이블 분리를 디비 분리까지 ! 디비 cybaek milk012 To cybaek cybaek From steve jonny Subject 아이패드 어때? [요청] 디자인 좀 봐줘요. 디비 To milk012 From bill Subject 주말에 시간 있나요? 웹 웹
    • 셀 아키텍처 데이터를 특정 속성 중심으로 물리적 분할 | 웹 서버도 사용자(군)별로 분리 디비 cybaek milk012 To cybaek cybaek From steve jonny Subject 아이패드 어때? [요청] 디자인 좀 봐줘요. 디비 To milk012 From bill Subject 주말에 시간 있나요? 웹 웹
    • 셀 아키텍처 데이터를 특정 속성 중심으로 물리적 분할 | 웹, 디비 서버 이중화 ! ! cybaek milk012 세 웹 웹 웹 웹 디비 cybaek 웹 디비 milk012
    • 셀 아키텍처 데이터를 특정 속성 중심으로 물리적 분할 | 사용자(군)별 어느 디비에 있는지 정보 보관 ! ! cybaek milk012 세 웹 웹 웹 웹 디비 cybaek 웹 디비 milk012 cybaek milk012 웹 웹 웹 웹 웹 디비 cybaek 웹 디비 milk012 웹 사용자별 디비 위치
    • 셀 아키텍처 데이터를 특정 속성 중심으로 물리적 분할 | 셀(Cell)! ! ! cybaek milk012 웹 웹 웹 웹 웹 디비 cybaek 웹 디비 milk012 웹 셀 디비 셀 셀
    • 셀 아키텍처 웹 디비 마스터 웹 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
    • 웹 디비 마스터 웹 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 셀 디비 | 분할된 데이터가 어디에 속하는지 참조 전체 사용자가 공통으로 참조 셀 디비, 로케이션 디비, 유저 디스커버리 서비스 등등 의 용어 사용 셀 아키텍처
    • 웹 디비 마스터 웹 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 장점 | 셀 단위 스케일링 | 장애를 특정 셀로 고립 가능 | 프론트+백엔드 점진적 배포 일부 웹 서버만 선적용하는 것은 흔하고 쉽지만 디비가 변경되었을 때, 일부 웹 서버만 적용하는 것은 쉽지 않지만, 셀 아키텍처에서는 가능 셀 아키텍처
    • 웹 디비 마스터 웹 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: 셀! 가장 심각한 문제 하지만 거의 정적인 데이터 | 많은 장비 필요 | 제공하는 기능에 따라 셀간 데이터를 조합해야할 수 도 예, 페이스북의 현 계정 친구 정보를 스트림에 추가 셀 아키텍처
    • 웹 디비 마스터 웹 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대로 분 할 또 차면 또 분할 셀 아키텍처
    • 웹 디비 마스터 웹 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 프로토콜상 어느 셀에서나 모든 사용자 서비스 가능해 야함 셀 아키텍처
    • 웹 디비 마스터 웹 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개? 정책! 셀 아키텍처
    • 웹 디비 마스터 웹 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개? 역시 정책! 셀 아키텍처
    • 스토리지 스케일링 분산파일시스템 | 복제본 수를 일률적으로 적용할 필요가 없음 요청이 많은 파일은 복제수 늘리고 보존 시한이 얼마 남지 않은 파일은 복제수 줄이고 | 중복 파일 처리 그냥 둘 것인가 줄일 것인가
    • 스토리지 스케일링 사용성에 따라 | 단위 디스크 크기와 서버의 디스크 베이 갯수 파일을 쌓아두기만 하는 아카이빙 용도인지 .용량이 큰 디스크를 거의 전 파일에 거쳐 IO가 발생하는지 .빠른 디스크(혹은 SSD)를 많이 꽂아서 최근 파일만 주로 사용하는지 .최근 파일은 작은 디스크(혹은 SSD)로 구성한 서버를 사용하고 .시간이 지난 파일은 용량이 큰 서버로 이전
    • 장비가 늘면서 생각할 고민들 빠른 배포 | 배포가 번거로운 일이 되면 안됨 페이스북 .BitTorrent 이용 .사이트 업데이트에 15~30분 소요 .마이너 업데이트는 매일 .메이저 업데이트는 매주 한 번
    • 장비가 늘면서 생각할 고민들 빠른 롤백 | 빠른 배포보다 중요! | 롤백 기준 사전 정의 필수 배포 장애시 우왕좌왕하면 안됨 즉각 해결을 못한다면 미련없이 롤백 .“10분이면 고칠 것 같아요”이런 말 믿지 말 것! | 배포 전에, 롤백 때 필요한 작업 미리 준비 롤백 결정 후, 이런 저런 스크립트 만들면 때는 늦음 엔터 한 번으로 롤백이 되도록
    • 장비가 늘면서 생각할 고민들 설정 관리 | 모든 장비의 설정 내용이 같은가 설정 값을 바꿔가며 테스트 한 다음 그대로 방치하는 경우가 있음 | 배포 바이너리 배포 시 함께? 설정은 따로 리포지토리 관리?
    • 이제 속도!
    • 속도 두 배 빨라진다면 | 50% 하드웨어로 커버
    • 속도 개선 제일 첫 번째 작업은 프로파일링 | 절대로 감에 의존하지 말 것 | 어디가 느린지 파악하는 것이 우선
    • 속도 개선 해결책 | 캐쉬: memcached, arcus, Redis… 각 레이어별 적용 가능 .디비에서, WAS에서, 웹 서버에서 각각 캐쉬 가능 저장 방식 .사용할 결과를 그대로 저장하거나 빠르나 많은 메모리 .구조화하여 저장하거나 조금 느리지만 보다 효율적인 메모리 사용
    • 속도 개선 해결책 | 캐쉬: 지역성!을 고려해서 설계 시간적 지역성 .한번 읽은 데이터를 곧 다시 읽을 수 있다. 공간적 지역성 .읽은 곳 근처의 데이터를 접근하는 경우가 있다.
    • 속도 개선 해결책 | 정책변경 예, 조회 수가 꼭 정확해야하나? .공유 저장소(memcached)에 기록하되, 일정 시간마다 디비에 기록 .디비에 기록하기 전에 저장소가 비정상 종료된다면 일 부 조회수는 유실 이런 것을 정책으로 허용하느냐 마냐에 따라 구조가 달라짐 .디비 기록 주기가 1분이고, 분당 1,000번 조회를 할 경 우, 정책과 약간의 코드만으로 디비 UPDATE를 분당 1,000회에서 단 1회로 줄일 수 있음
    • 속도 개선 해결책 | 정책변경 조회 수 캐쉬(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분 초과!
    • 속도 개선 해결책 | 정책변경 WWDC, GoogleIO 티켓 구매 .최근 몇 년 초단시간에 매진을 기록 .하지만 사이트는 먹통 .결국, 추첨해서 티켓 구매 기회를 주는 것으로 변경
    • 속도 개선 해결책 | 증설 사용자가 늘었거나, 기능이 추가되어서 정말 증설이 필 요할 수도 있음 증설은 죄가 아님
    • 스토리지 속도 메모리 디스크 개수 | 1T x 1 vs 100G x 10 RAID 컨트롤러 | 정책 배터리 충전 중에는 디스크에 바로 쓰기(Battery Backup Write Cache) .전원 공급이 갑자기 끊길 때 쓰기 유실을 최소화 하기 위한 드라이버 정책(조정 가능) .하지만 이로 인해 디비 같은 경우 서비스 품질이 급락
    • 품질 관리 웹, WAS | 각 URI별 응답속도 관리 평균과 표준편차 같이 관리 | 구간별 처리 속도 관리 주요 기능의 경우, URI 하나의 응답 속도를 더 쪼개서 내부 로직별 처리 속도를 기록
    • 운영 서비스 오픈은 끝이 아니라 시작. - ?
    • 메일 발송 생각보다 관리할 것이 많음 | 한 통 발송은 쉽지만, 책 예제 따라하면 됨 | 다량 발송은 손이 많이 감 코드의 문제가 아니라 운영 문제 .KISA 화이트IP 등록
    • 자동화 신규 서버 설치 | 장비를 받아, 10분 내에 설치할 수 있도록 | 방화벽 오픈 등이 빠른 대응에 걸림돌 애당초 C클래스 단위로 관리 일상적인 응용 배포 자동 복구 | 장애 시 루틴하게 하는 작업 예, 프로세스 재구동 등을 특정 조건일 때 자동으로 수 행하도록
    • 배치 작업 필요한 기본 인프라 | 실패시 알림 | 과거 작업 이력 조회 | 여러 서버 묶어서 실행
    • 로그 처리 수집 | 주기는? 실시간 .Scribe: https://github.com/facebook/scribe 시간 단위
    • 백업 어떤 전략으로 | 주기는? | 전체? 증분? 어떻게 복구 | 복구에 얼마나 걸리나 | 복구하는 동안 서비스는 유지? 정지? 읽기만?
    • 로그 처리 보관 | 얼마나 오랫동안 보관해야하나 정책의 문제 조회 | 얼마나 많은 범위의 데이터를, 얼마나 빠르게 잘 구축하면 고객문의 처리를 비개발자에게 이관 가능 보안 | 개인 정보 저장하지 않도록
    • 품질 관리 백엔드 서버간 처리 | 각 서버 구간별 처리 속도 관리 한 요청이 여러 서버를 활용할 때, 각 서버별 응답 속도 관리 .Zipkin: https://blog.twitter.com/2012/distributed- systems-tracing-zipkin
    • 품질 관리 디비 | DBA의 검수 필수 | 동적 쿼리를 없애도록 1개의 동적 쿼리는 생각보다 적은 N개의 정적 쿼리로 변경 가능 .쿼리 관리가 용이해지고 .각 정적 쿼리마다 힌트를 정확하게 줄 수 있음 | 슬로우 쿼리 자동 검출
    • 모니터링 경고와 장애 수준 분리 | 대부분 장애 수준이 되고 나서야 알람을 받음 디스크 사용률 90%일 때 알람 .“이제 장애 납니다”라는 문자 받는 것 .평상 시 사용률 20%를 유지하고 있다면, 90%가 아니라 50% 수준에서 경고 알람을 받아야함
    • 모니터링 최저 값 모니터링 | 보통 데몬 개수가 N개를 넘을 때만 알람을 받음 데몬이 죽었다면 알람 안 옴 주기적으로 수치 점검 | 시스템의 기능과 사용자 수는 계속 변함 경고, 장애, 최저 값 세 수치는 주기적으로 리뷰해야함
    • 모니터링 테스트 활용하여 기능 체크 | 사용자 인터페이스 레벨의 테스트 모듈을 주기적으 로 돌려, 서비스 상태 체크
 
 무의미한 알람 받지 않도록 | 무시해도 되는 알람이라면 받지 않도록 설정 그런 알람 속에 진짜 경고 메시지가 묻힐 수 있음
    • 모니터링 연동 서비스/서버 모니터링 | 외부 API를 이용할 경우, 해당 API를 직접 체크 연동 서비스쪽 원인으로 발생한 장애를 빠르게 검출할 수 있음 .연동 서비스의 응답 속도는 담당 서비스의 품질에도 영 향을 줌 내가 직접 관리하는 서비스가 아니라고 방치해서는 안 됨
    • 시스템 유틸리티 필수 | vmstat, mpstat, iostat, netstat, free, top, sar, ping
    • HTTP 에러 페이지 설정 50x | 사용자들은 무의식적으로 새로 고침을 반복 별도 (정적) 서버로 리다이렉트 하도록 설정
    • 흔한 장애 로그 | DEBUG 레벨의 로깅 예, 로그를 껐더니 속도가 10배 향상 | 에러 로그를 안 봐서 키우는 장애 에러 로그 크기는 0이 정상 ‘괜찮은 에러’는 에러가 아니니 에러 로그에 남기지 말 것
    • 흔한 장애 타임아웃 | 디폴트 값 사용 주의 보통 디폴트가 얼마인지도 모르고 사용 보통 10ms로 응답할 때, 응답이 1초 지연되면 동시 접 속수는 100배가 됨 | 평균 응답 속도에 상응하는 타임아웃 설정 보통 5ms 이하로 응답할 때, 타임아웃이 2초가 적당? | 단위 확인 필요 예, ms인 줄 알고 1000이라고 넘겼는데... sec
    • 흔한 장애 트래픽 | 한 달 전부터 늘고 있었는데 에러 핸들링 | 소스코드에서 return 값 제대로 확인하지 않고
    • 흔한 장애 파일/디스크 관련 | 디스크 가용량이 부족하거나 지우지 않고 쌓인 로그 | inode가 부족하거나 작은 파일을 많이 저장하고 있을 때 | FD_MAX가 작거나 ulimit -n
    • 흔한 장애 L4 | L4를 적용했는데도, 정상 동작하지 않는 서버로 계 속 요청이 가는 경우 HTTP라면 L7 헬스 체크 적용
    • 흔한 장애 디비 | 갑자기 쿼리의 실행 계획이 바뀌어 슬로우 쿼리 발 생 쿼리에 힌트를 주어 실행 계획을 고정 .동적으로 문자열을 만들어 쿼리를 생성할 경우 힌트 주 기가 어려움 동적 쿼리를 다수의 정적 쿼리로! | 통계 쿼리 캐쉬 메모리가 지역성이 떨어지는 데이터로 채워져 성 능 저하 초래
    • 대규모 장애 대응 중요 기능 우선 | 서비스 기능을 중요도로 정렬 .게시판: 읽기 > 쓰기 > 검색 .메일: 수신/읽기 > 목록 > ... > 쓰기 > ... > 검색 > 색인 .검색: 통합검색 > ... > ... > 색인 | 장애 시 중요 기능을 보호하는 대응 우선 순위 떨어지는 기능을 포기하여 상위 기능을 개선 .미들웨어에서 호출 컴포넌트 정보를 받아, 비중요 컴포 넌트로 부터의 호출을 실패 처리
    • 대규모 장애 대응 기타 | 캐쉬 만료 기간 연장 캐쉬를 2분간 보관한다면 임시로 10분 등으로 연장 .백엔드 호출이 그만큼 줄어들게 됨 | 색인 갱신 중단 색인 작업은 전반적인 데이터 패치를 수반 이를 잠시 멈춰, 내부 트래픽과 미들웨어 호출량을 줄 일 수 있음 | 서비스 마다 특성이 있음 고민! 고민! 고민!
    • 장애 후 대응 회고 | 해당 장애를 사용자가 인지하기 전에 미리 알 수는 없었는지 미리 알 수 있는 방법을 찾아내면 모니터링 항목으로 등록 | 장애 원인을 아는데 왜 오래 걸렸는지, 자동으로 알 수는 없었는지 자동으로 알 수 있게 됐다면 스크립트화 .해당 스크립트 묶음을 장애 시 활용하면 원인 진단을 빠 르게 할 수 있음
    • http://www.slideshare.net/cybaek/201403