안정적인 서비스 운영 2013.08
81 likes9,380 views
- 신입사원 대상으로 강의한 내용입니다. - 장비 1대에서 시작해서 셀 아키텍처까지 확장하는 내용과(LiveJournal의 발표를 참조) - 서비스 운영에 필요한 백업, 로그, 모니터링 내용을 담았습니다.
안정적인 서비스 운영 2013.08
- 1. 안정적인 서비스 운영 설계에서 모니터링까지 [email protected] [email protected] [email protected] 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. 장애 후 대응 회고 | 해당 장애를 사용자가 인지하기 전에 미리 알 수 는 없었는지 미리 알 수 있는 방법을 찾아내면 모니터링 항목으로 등록 | 장애 원인을 아는데 왜 오래 걸렸는지, 자동으로 알 수는 없었는지 자동으로 알 수 있게 됐다면 스크립트화 .해당 스크립트 묶음을 장애 시 활용하면 원인 진단을 빠 르게 할 수 있음