대규모 서비스를 지태하는 기술 13장. 다중성 확보, 시스템 안정화

1. 다중성 확보, 시스템 안정화
choong

2. AP 서버
• 서버가 멈추는 요인
• 사람의 실수.
• 물리적인 고장.
• 메모리 장애.
• 장애 발생 시 자동으로 failover, 복구 시
failback
• failover : 고장난 서버를 자동적으로 분리.
• failback : 서버가 복구 되면 원상태로 복귀.

3. 다중성 확보 – AP 서버
로드 밸런서 로드 밸런서
AP 서버 1 AP 서버 2 AP 서버 1 AP 서버 2
X
failover
failback

4. DB 서버
• 마스터의 다중화는 어려움.
• 멀티 마스터 구성
• 마스터간의 레플리케이션. (서로간의 슬레이브구성)
• 데이터 간 일치하지 않는 부분 발생.
• 동기화 처리 ( slave에서 쓰여진것을 확인 하고 client
에게 응답).
• 성능면에서 리스크.

5. 멀티 마스터
• 기본적으로 Active/Standby 2대로 구성
• failover 발생 시 (standby 서버 기준)
• VRRP(Virtual Router Redundancy Protocol)라는 프
로토콜을 이용하여 Active 마스터 감시.
• 장애 발생을 발견하면 자신이 Active 마스터로 승격.

6. 멀티 마스터 구성
LVS
마스터 DB
(Active)
마스터 DB
(Standby)
10.0.0.1(real ip)
10.0.0.3(VIP) 10.0.0.2(real ip)
상호간
레플리케이션
감시(VRRP)
LVS
마스터 DB
(Standby)
마스터 DB
(Active)
10.0.0.1(real ip)
10.0.0.2(real ip)
10.0.0.3(VIP)
상호간
레플리케이션
감시(VRRP)
장애 발생

7. 스토리지
• 애플리케이션 데이터를 영속적, 일시적 저장하는
기능.
• 스토리지 선택 고려사항 (액세스 패턴)
• 평균크기, 최대크기, 신규추가빈도, 갱신빈도, 삭제빈
도, 참조빈도.
• 용량이 큰 HDD 사용 시, 저장된 파일 수가 많아
져서 I/O 병목 현상에 원인.

8. 스토리지 종류
• RDBMS
• MySQL, PostgreSQL
• 분산 key-value 스토어
• memcached, TokyoTyrant
• 분산 파일 시스템
• MogileFS, GlusterFS, Lustre
• 기타
• NFS 계 분산 파일 시스템, DRBD, HDFS

9. MogileFS
• 작은 대량의 파일을 다룰 목적으로 Perl로 구현
된 분산 파일 시스템.
• KB~MB 크기의 파일
• 파일 추가에 적합
• 추가 후 갱신 되지 않고 참조용.
• 하나의 파일은 3중으로 다중화.
• 일부 스토리지 서버가 고장 나도 서비스는 정상적으로
가능.
• Client Server간 Http 통신 사용
• PUT, GET

10. MogileFS 구성
• 애플리케이션(클라이언트)
• 파일을 저장하고 로드하는 주체.
• 구현 필요.
• Tracker
• 클라이언트 요청에 대한 처리를 관리.
• DB
• 메타데이터 정보를 관리.
• 스토리지
• 파일을 저장하는 장소.

11. MogileFS 동작(GET)
Client
(API:Perl)
trakers Storage
nodes
database
domain,
key
Host,
Port
filename
HTTP GET
request
File

12. 자원 효율 상반관계
• 한계에 이를 때까지 메모리 튜닝
• 안정성 <-> 자원 효율
• 메모리 소비 올라가면 ->성능 저하(스왑) -> 장애
• 메모리는 7할 정도 까지만 사용
• 한계에 이를 때까지 CPU 사용
• 안정성 <-> 속도
• 서버 1대 다운 -> 처리 능력 초과 -> 장애
• CPU를 7할 정도까지만 사용.

13. 시스템 불안정 요인
• 애플리케이션/서비스 레벨 -> 부하증가
• 기능 추가
• 메모리 누수
• 지뢰
• 사용자의 액세스 패턴
• 데이터량 증가
• 위부연계 추가
• 하드웨어 -> 처리능력 저하
• 메모리, HDD 장애
• NIC 장애

14. 애플리케이션/서비스 레벨
• 기능 추가 / 메모리 누수
• 새로운 기능으로 인한 부하증가.
• Perl 은 메모리 누수를 완전 배제 하기 어려움(스왑 발생).
• 지뢰
• 특정 URL 호출 메모리 누수 및 무한 루프 발생.
• 사용자의 액세스 패턴
• 특정 URL 에 트래픽이 몰려 서비스 다운.
• 데이터량 증가
• 당초 예상했던 데이터량 보다 늘어나서 부하의 증가.
• 데이터 설계 미흡으로 인한 테이블 레코드 증가.
• 외부연계 추가
• 외부 시스템 장애로 서비스 장애

15. 하드웨어 레벨
• 메모리, HDD, NIC 장애
• 일상적으로 발생하는 장애
• 로드밸런서 에서 적절한 항목에 대해 헬스체크.

16. 시스템 안정화 대책
• 적절한 버퍼 유지
• 메모리량, CPU 사용 7할 유지
• 불안정 요인 제거
• 부하가 높아질 것 같은 SQL은 다른 DB 이용해서 처
리.
• 이상 동작 시의 자율제어
• 자동 DoS 판정
• 자동 재 시작
• 자동 쿼리제거