안정적인 서비스 운영설계에서 모니터링까지

cybaek@me.comcybaek@naver.com

cybaek@sk.com2013.08-rev3.1

서버 한 대에서 시작

웹과 디비를 한 대에서 운영

| 쉽게 시작할 수 있지만,

| 원만한 운영 어려움

웹, 디비

두 대의 서버

웹 서버 1대, 디비 서버 1대

| SPOF: 웹, 디비 뭐든 하나만 죽으면

웹

디비

W W W

R R R

R R R

세 대의 서버

웹 서버를 2대로 늘려서

웹

디비

웹

W W W

R R R

R R R

세 대의 서버

로드밸런싱과 고가용성

| 가장 흔한 것이 L4

L7 헬스체크

| 리버스프락시웹

디비

웹

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 ... 웹

디비

웹

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

세션

공유 데이터

디비슬레이브

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를 사용

디비 파티셔닝/샤딩

셀 아키텍처

웹

디비마스터

웹

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분이면 고칠 것 같아요”이런 말 믿지 말 것!

| 배포 전에, 롤백 때 필요한 작업 미리 준비

롤백 결정 후, 이런 저런 스크립트 만들면 때는 늦음

엔터 한 번으로 롤백이 되도록

장비가 늘면서 생각할 고민들

설정 관리

| 모든 장비의 설정 내용이 같은가

설정 값을 바꿔가며 테스트 한 다음 그대로 방치하는 경우가 있음

| 배포

바이너리 배포 시 함께?

설정은 따로 리포지토리 관리?

스케일링과 속도

두 개는 다른 이야기

스케일링

| 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”

스케일링과 속도

속도

| 두 배 빨라진다면, 50% 하드웨어로 커버

속도 개선

제일 첫 번째 작업은 프로파일링

| 감에 의존하지 말 것

| 어디가 느린지 파악하는 것이 우선

속도 개선

해결책

| 캐쉬: memcached, Redis...

각 레이어별 적용 가능.디비에서, WAS에서, 웹 서버에서 각각 캐쉬 가능

저장 방식.사용할 결과를 그대로 저장하거나

빠르나 많은 메모리.구조화하여 저장하거나

조금 느리지만 보다 효율적인 메모리 사용

속도 개선

해결책

| 정책변경

예, 조회수가 꼭 정확해야하나?.공유 저장소(memcached)에 기록하되, 일정 시간마다

디비에 기록.디비에 기록하기 전에 저장소가 비정상 종료된다면 일

부 조회수는 유실

이런 것을 정책으로 허용하느냐 마냐에 따라 구조가 달라짐.디비 기록 주기가 1분이고, 분당 1,000번 조회를 할 경우, 정책과 약간의 코드만으로 디비 UPDATE를 분당 1,000회에서 단 1회로 줄일 수 있음

속도 개선

해결책

| 증설

사용자가 늘었거나, 기능이 추가되어서 정말 증설이 필요할 수도 있음

증설은 죄가 아님

스토리지 속도

메모리

디스크 개수

| 1T x 1 vs 100G x 10

RAID 컨트롤러

| 정책

배터리 충전 중에는 디스크에 바로 쓰기(Battery Backup Write Cache).전원 공급이 갑자기 끊길 때 쓰기 유실을 최소화 하기

위한 드라이버 정책(조정 가능).하지만 이로 인해 디비 같은 경우 서비스 품질이 급락

백업

어떤 전략으로

| 주기는?

| 전체? 증분?

어떻게 복구

| 복구에 얼마나 걸리나

| 복구하는 동안 서비스는 유지? 정지? 읽기만?

로그 처리

보관

| 얼마나 오랫동안 보관해야하나

정책의 문제

조회

| 얼마나 많은 범위의 데이터를, 얼마나 빠르게

잘 구축하면 고객문의 처리를 비개발자에게 이관 가능

보안

| 개인 정보 저장하지 않도록

로그 처리

수집

| 주기는?

실시간. Scribe: https://github.com/facebook/scribe

시간 단위

메일 발송

생각보다 관리할 것이 많음

| 한 통 발송은 쉽지만,

책 예제 따라하면 됨

| 다량 발송은 손이 많이 감

코드의 문제가 아니라 운영 문제. KISA 화이트IP 등록

배치 작업

필요한 기본 인프라

| 실패시 알림

| 과거 작업 이력 조회

| 여러 서버 묶어서 실행

자동화

신규 서버 설치

| 장비를 받아, 10분 내에 설치할 수 있도록

| 방화벽 오픈 등이 빠른 대응에 걸림돌

애당초 C클래스 단위로 관리

일상적인 응용 배포

자동 복구

| 장애 시 루틴하게 하는 작업

예, 프로세스 재구동 등을 특정 조건일 때 자동으로 수행하도록

품질 관리

웹, WAS

| 각 URI별 응답속도 관리

평균과 표준편차 같이 관리

| 구간별 처리 속도 관리

주요 기능의 경우, URI 하나의 응답 속도를 더 쪼개서 내부 로직별 처리 속도를 기록

품질 관리

백엔드 서버간 처리

| 각 서버 구간별 처리 속도 관리

한 요청이 여러 서버를 활용할 때, 각 서버별 응답 속도 관리. Zipkin: https://blog.twitter.com/2012/distributed-

systems-tracing-zipkin

품질 관리

디비

| DBA의 검수 필수

| 동적 쿼리를 없애도록

1개의 동적 쿼리는 생각보다 적은 N개의 정적 쿼리로 변경 가능.쿼리 관리가 용이해지고.각 정적 쿼리마다 힌트를 정확하게 줄 수 있음

| 슬로우 쿼리 자동 검출

모니터링

경고와 장애 수준 분리

| 대부분 장애 수준이 되고 나서야 알람을 받음

디스크 사용률 90%일 때 알람.“이제 장애 납니다”라는 문자 받는 것. 60%를 유지하고 있다면 70%~80%일 때 경고 알람을 받

아야함

모니터링

최저 값 모니터링

| 데몬 개수가 N개를 넘을 때 알람을 받음

데몬이 죽었다면 알람 안 옴

주기적으로 수치 점검

| 시스템의 기능과 사용자 수는 계속 변함

경고, 장애, 최저 값 세 수치는 주기적으로 리뷰해야함

모니터링

테스트 활용하여 기능 체크

| 사용자 인터페이스 레벨의 테스트 모듈을 주기적으로 돌려, 서비스 상태 체크

무의미한 알람 받지 않도록

| 무시해도 되는 알람이라면 받지 않도록 설정

그런 알람 속에 진짜 경고 메시지가 묻힐 수 있음

모니터링

연동 서비스/서버 모니터링

| 외부 API를 이용할 경우, 해당 API를 직접 체크

연동 서비스쪽 원인으로 발생한 장애를 빠르게 검출할 수 있음.연동 서비스의 응답 속도는 담당 서비스의 품질에도 영

향을 줌

내가 직접 관리하는 서비스가 아니라고 방치해서는 안 됨

흔한 장애

로그

| 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/201308-25737111