디비를 확장할 수 있으려면
스토리지 스케일링
분산 파일 시스템
- 복제본 수를 일률적으로 적용할 필요가 없음
ex) 요청이 많은 파일은 복제수를 늘리고 보존 시한이 얼마 남지 않은 파일은 줄인다. - 중복 파일 처리
그냥 두는 것 or 줄인다.
해당 서비스에 맞는 서비스를 잘 골라야 한다.
사용성에 따라
단위 디스크 크기와 서버의 디스크 베이 갯수
- 파일을 쌓아두기만 하는 아카이빙 용도인지
아카이빙 용도 - 큰 용량의 디스크
속도가 필요한 용도 - 작은 용량 디스크 여러개
버스가 더 많아지기 떄문에 속도면에서 유리함이 있다. - 거의 모든 파일에서 IO발생하면
SSD등을 많이 꽂는 것이 빠름 - 최근 파일만 주로 사용하면
최근 파일은 작은 디스크로 구성한 서버 사용
시간이 지난 파일은 용량이 큰 서버로 이전
장비가 늘면서 생각할 고민들
빠른 배포
배포가 번거로운 일이 되면 안됨
빠른 롤백
빠른 배포보다 중요하다.
롤백 기준 사전 정의는 필수
- 배포 전에, 롤백 때 필요한 작업 미리 준비
롤백 때 사용할 버전/패키지 미리 준비
- 롤백이 예상되는 배포의 경우
디비 변경이 있어도 롤백이 가능하도록 개발
QA를 정상 배포, 롤백 후 상태 두가지에 대해 진행
설정 관리
- 모든 장비의 설정 내용이 같은가
설정 값을 바꿔가며 테스트 한 다음 그대로 방치하는 경우가 있음
- 배포
바이너리 배포 시 함께 하는지
설정은 따로 관리하는 지
속도
속도가 두배 빨라진다면 - 50% 하드웨어로 커버할 수 있음
하지만 속도 개선을 위해
첫번째 작업은 프로파일링 -절대 감에 의존하지 말 것, 어디가 느린지 파악하는 것이 우선
해결책
- 캐쉬 : Redis
각 레이어별 적용 가능 - 디비에서 , WAS에서, 웹 서버에서 각각 캐쉬 가능
저장 방식
- 사용할 결과를 그대로 저장 (응답 메시지 자체 캐시) 빠르지만 메모리 많이 차지
- 구조화 하여 저장하면 조금 느리지만 효율적인 메모리
지역성을 고려해서 설계하기 - 시간적, 공간적 지역성 - 증설
사용자가 늘거나 기능이 추가되어 증설이 필요할 수 있음, 증설은 죄가 아님
정책 변경
ex) 조회수가 중요하지 않은 서비스의 경우 - 빠른 공유 저장소 (Redis에 기록, 일정시간 이후 디비에 기록)
스토리지 속도
메모리
디스크 개수 : 1T 1개 vs 100G 10개 등
상황에 따라 결정
RAID 컨트롤러
배터리 충전 중에는 디스크에 바로 쓰기
전원 공급이 끊길 때 쓰기 유실을 최소하기 위한 드라이버 정책 - 이로 인해 서비스 품질 급락
RAID 컨트롤러
Redundant Array of Inexpensive/Independent Disk
저장장치 여러 개를 묶어 고용량, 고성능인 저장 장치 한 개와 같은 효과를 얻기 위해 개발된 기법
웹, WAS
URI의 빈도와 각 응답속도 관리
구간별 처리 속도 관리 - 주요 기능의 경우, URI 하나의 응답 속도를 쪼개서 내부 로직별 처리 속도 기록
운영
ex) 메일 발송
생각보다 관리할 것이 많음
한 통 발송은 쉽지만 다량 발송은 손이 많이 감
코드의 문제가 아니라 운영의 문제
자동화
신규 서버 설치
장비를 받아, 10분 내에 설치할 수 있도록 (방화벽 오픈 등이 빠른 대응에 거림돌)
일상적인 응용 배포
자동 복구 - 장애 시 루틴하게 하는 작업
배치 작업
필요한 기본 인프라
- 실패시 알림
- 과거 작업 이력 조회
- 여러 서버 묶어서 실행
로그 처리
수집 주기 - 실시간 or 시간 단위
중앙에 로그 모으는 것 : 로그 어그리게이터
- 보관 : 얼마나 오래 보관하나
- 조회 : 얼마나 많은 범위의 데이터를, 얼마나 빠르게
- 보안 : 개인 정보 저장하지 않도록
백업
- 어떤 전략으로 - 주기는? 전체? 증분? DB는 보통 전체 백업
- 어떻게 복구 - 복구에 걸리는 시간은? 복구하는 동안 서비스 상태는? (유지, 정지, 읽기만 등)
품질 관리
JAVA APM (Application Performance Management)
- PINPOINT
- SCOUTER
- NewRelic
- DataDog
PINPOINT, SCOUTER 사용함
디비
ORM을 사용하지 않는다면, DBA의 쿼리 검수 필요
ORM (Object Relational Mapping)
동적 쿼리를 없애도록 - 1개의 동적 쿼리는 생각보다 적은 N개의 정적 쿼리로 변경 가능
슬로우 쿼리 자동 검출 - DBA와 개발자가 협의해야 함
ORM이란?
객체와 관계형 데이터베이스의 데이터를 자동으로 매핑해주는 것
로깅 (앱, 웹)
에러 로그 수집에 Log&Crash 활용
모니터링
경고와 장애 수준을 분리하기
대부분 장애 수준이 되어서야 알람을 받음
ex) 디스크 사용률 90% 이상이 될 때 알람
최저값 모니터링
보통 데몬 개수가 N개를 넘을 때만 알람을 받음 -> 데몬이 죽었다면 알람이 안 옴
주기적으로 수치 점검
테스트 활용해 기능 체크 - 사용자 인터페이스 레벨의 테스트 모듈을 주기적으로 돌려, 서비스 상태 체크
무의미한 알람 받지 않도록!! ( 진짜 경고 메시지가 묻힐 수 있음 )
연동 서비스/서버 모니터링
외부 API를 이용할 경우, 해당 API를 직접 체크
연동 서비스쪽 원인으로 발생한 장애를 빠르게 검출할 수 있음
알람
Dooray Messenger로 가능
시스템 유틸리티
필수 : vmstat, mpstat, iostat, netstat, free, top, sar, ping (사용법 숙지하기)
HTTP 에러 페이지 설정
50x - 사용자들은 무의식적으로 새로 고침을 반복 -> 별도 (정적) 서버로 리다이렉트 하도록 설정
에러가 아닌 척 - 쇼핑몰, 결제를 처리하는 서버에서 오류가 났다면 일단 OK 메시지를 보내고 추후 결제 처리
흔한 장애
1. 로그
DEBUG 레벨의 로깅 , 로그를 껐더니 속도 10배 향ㅅ아
에러 로그를 안봐서 키우는 장애 - 에러 로그의 크기는 0을 목표로 해야함.
괜찮은 에러는 에러가 아니니 에러 로그에 남기지 않기
2. 타임 아웃
디폴트 값 사용 주의 - 보통 디폴트가 얼마인지도 모르고 사용
평균 응답 속도에 상응하는 타임아웃 설정
단위 확인 필요
에러 핸들링
소스코드에서 return 값 제대로 확인하지 않는 경우
( 실패인데 그 다음 코드를 계속 실행하는 경우, 성공이 아니지만 굳이 실행을 멈출 필요가없는 경우)
3. 파일/디스크 관련
- 디스크 가용량이 부족 - 지우지 않고 쌓인 로그
- inode 부족 - 작은 파일을 많이 저장하고 있을 때 (df -i 로 확인 가능)
- FD_MAX가 작음
4. L4
L4를 적용했는데도, 정상 동작하지 않는 서버로 요청이 가는 경우
5. 디비
갑자기 쿼리의 실행 계획이 바뀌어 슬로우 쿼리 발생
통계 쿼리 - 캐쉬 메모리가 지역성이 떨어지는 데이터로 채워져 성능 저하 초래
집계 쿼리 - ex) 받은 메일함의 안 읽은 메일 통 수 관리
6. 배포 후
사용자 단에서 일괄 재구동 -DDoS와 같은 서버 요청 발생, 특히 집계 쿼리
클라이언트가 랜덤으로 재구동하도록 설계
7. DNS
JVM은 DNS 쿼리 결과 캐슁
기본 설정은 JVM 재구동하기 전까지 캐슁 결과 변경 불가
NGiNX - worker_connection
ulimit - 시스템에 따라 다름
대규모 장애 대응 (서비스 평행화)
중요 기능 우선
서비스 기능을 중요도로 정렬
장애시 중요 기능을 보호하는 대응 -우선 순위 떨어지는 기능을 포기해 상위 기능 사용성을 유지
기타
- 캐쉬 만료 기간 연장
- 색인 갱신 중단
- 서비스 마다 특성이 다름
장애 대응
전파
메일링 리스트를 이용하여 유관자에게 전파 - 장애 처리 전에 일단 전파
처리
유용한 스크립트
- 특정 일시 N분간 접속한 IP를 빈도로 설정
- 특정 일시 N분간 접속한 URI를 빈도로 설정
장애 후 대응
회고
기계적으로 할일 - 개발 TC 보강, QA TC 보강
빠른 장애 대처 - 장애를 어떻게 알았는가, 원인을 아는데 왜 오래 걸렸는지 자동으로 알 수는 없는지, 자동으로 복구할 수 있는지
서비스 자동 재구동
crontab 이용 -> 특정상황 등에서 Tomcat, apache, nginx 재구동
재구동시 알람 -> Dooray messenger hook 이용
