장비가 늘면서 생각할 고민들
배포
- 배포하는 중 UI 깨지는 현상
- css, 이미지를 선배포하고 웹 응용 파일을 배포
- ex > 구서버,신서버가 존재했을 시 삭제되거나 생성된 이미지에 접근했을 때 깨지게 된는
- 설정관리
- 모든 장비의 설정 내용이 같은가
-설정 값을 바꿔가며 테스트한 다음 그대로 방치하는 경우가 있음 - 배포
-바이너리 배포 시 함께?
-설정은 따로 리포지토리 관리?
속도
- 제일 첫번 째 작업은 프로파일링
- 절대로 감에 의존하지 말고 어디가 느린지 파악해서 개선
- 빠른부분을 개선하는 것보다 느린부분을 개선하는 것이 우선
- 해결책
1) 캐쉬
- 각 레이어별 적용 가능
-db,was,웹 서버 에서 각각 캐쉬 가능 - 저장방식
-사용할 결과를 그대로 저장 -> 빠르나 많은 메모리
-구조화해 저장 -> 조금 느리지만 보다 효율적인 메모리 - 시간적지역성
-한 번 읽은 데이터 곧 다시 읽을 수 있음
-LRU - 공간적 지역성
2) 증설
- 사용자가 늘었거나,기능이 추가돼 정말 증설이 필요할 수 있음
- 증설은 죄가 아님!
- 정책 변경
-예) 조회수가 꼭 정확해야하나?
- 단점 -> 58,59일때 장애가 나면 DB에 내용 갱신 안됐으므로 문제,,이정도를 감수할 것인지? 아닌지 고민해봐야함
3) 스토리지 속도
- 메모리
- 디스크 개수
- RAID 컨트롤러
4) 품질관리
- 웹, WAS
-URI의 빈도와 각 URI별 응답속도 관리
-최소한 평균과 표준편차 두 지표를 관리
-표준편차가 큰(출렁이는) 부분을 찾아서 해결해야함
-3초 전에는 잘되다가, 3초 이후에는 잘 안됐을 경우 잠재 장애 가능성이 있었을 것
-https://zipkin.io/
운영
서비스 오픈은 끝이 아니라 시작
- 생각보다 관리할 것이 많음
- 한통 발송은 쉽지만,
- 다량 발송은 손이 많이 감
-코드의 문제가 아니라 운영 문제
-장애: COS발송 장애 등
- 자동화
- 신규 서버 설치
-장비 받아,10분 내에 설치할 수 있도록
-방화벽 오픈등이 빠른 대응에 걸림돌 - 일상적인 응용 배포
- 자동복구
-장애 시 루틴하게 하는 작업
-예) 프로세스 재구동 등을 특정 조건일 때 자동으로 수행하도록
- 배치 작업
- 필요한 기본 인프라
-실패시알림
-과거작업 이력 조회
-여러 서버 묶어서 실행
-젠킨스에 관한 블로그 내용
- 수집
- 주기는?
-실시간
-시간단위
- 백업
- 어떤 전략으로
-주기는?
-전체?증분? - 어떻게 복구
-복구에 얼마나 걸리나
-복구하는 동안 서비스는 유지?정지?읽기만?
- 로그
- 보관
-얼마나 오래 보관해야 하나
-정책의 문제:전금법 관련 로그 12개월, 그 외 6개월 - 조회
-얼마나 많은 범위의 데이터를,얼마나 빠르게 - 보안
-개인 정보 저장하지 않도록
-개인정보보호법과 관련해서 주의해야 할 부분 많음
- 품질 관리
-
JAVA APM
-PINPOINT
-SCOUTER
-NewRELIC
-DataDog -
디비
-ORM을 쓰지 않는다면, DBA의 쿼리 검수 필요
-동적 쿼리를 없애도록(1개의 동적쿼리는 생각보다 적은 N개의 정적 쿼리로 변경 가능)->서비스 면에서 더 좋을 수 있음
-동적 쿼리를 사용하면, 특정환경에서 속도가 확 느려지게 될 수 있음->균일한 속도를 유지해야하는 부분에서 좋지 않을 수 있음
-슬로우 쿼리 자동 검출(DBA기준과 개발자기준이 다를 수 있음.반드시 협의!) -
로깅
-에러 로그 수집에 Log&Crash 활용
- 모니터링
- 경고와 장애 수준 분리
-대부분 장애 수준이 되고 나서야 알람을 받음
-디스크 사용률 90%일 때 알람받음
-평상 시 사용률 20%를 유지하고 있다면, 90%가 아니라 50%수준에서 경고 알람을 받아야함 - 최저 값 모니터링
-보통 데몬 개수가 N개를 넘을 때만 알람을 받음 - 주기적으로 수치 점검
-시스템의 기능과 사용자 수는 계속 변함
-경고,장애,최저 값 세 수치는 주기적으로 리뷰해야함 - 테스트 활용해 기능 체크
-사용자 인터페이스 레벨의 테스트 모듈을 주기적으로 돌려, 서비스 상태 체크
-무의미한 알람 받지 않도록 무시해도 되는 알람이라면 받지 않도록 설정 - 연동 서비스/서버 모니터링
외부 API를 이용할 경우, 해당 API를 빠르게 체크
- 알람
- Dooray Messenger로도 가능
- 사례 : API 게이트웨이 오류
-알람:False 알람이 많아 간과
- 시스템 유틸리티
- 필수
-vmstat,mpstat,iostat,netstat,free,top,sar,ping
- HTTP 에러 페이지 설정
- 50x
-사용자들은 무의식적으로 새로 고침을 반복
-별도(정적)서버로 리다이렉트 하도록 설정 - 에러가 아닌척
-쇼핑몰,결제를 처리하는 서버에서 오류가 났다면
-일단 OK 메시지 보냄
-결제가 안됐지만 정상 처리하고, 추후 로그나 기타 정보로 후 결제 처리
- 흔한 장애
-
로그
-DEBUG레벨의 로깅 -> 로그를 껐더니 속도가 10배 향상
-괜찮은에러(무의미한에러)는 에러가 아니니 에러 로그에 남기지 말것 -
타임아웃
-디폴트 값 사용 주의 -> 보통 10ms로 응답할떄, 응답이 1초 지연되면 동시 접속수는 100배가 됨
-평균 응답 속도에 상응하는 타임아웃 설정 -> 보통 5ms 이하로 응답할 떄, 타임아웃이 2초가 적당
-단위 확인 필요 -> ms,sec 등등 단위 확인 꼭! -
트래픽 변화
-
에러 핸들링
-소스코드에서 return값 제대로 확인하지 않는 경우
-실패인데 그 다음 코드를 계속 실행하는 경우
-성공이 아니지만 굳이 실행을 멈출 필요가 없는데 리턴하는 경우 -
파일/디스크 관련
-디스크 가용량이 부족하거나
-inode가 부족하거나 -> 작은 파일을 많이 저장하고 있을 때 (ex.메일)
-FD_MAX가 작거나 -
L4
-L4를 적용했는데도, 정상 동작하지 않는 -
디비
-갑자기 쿼리의 실행 계획이 바뀌어 슬로우 쿼리(즉 길어야 1~2초 걸리는 db 쿼리가 예상보다 오래걸리는 경우) 발생
-쿼리에 힌트를 주어 실행 계획을 고정!
-통계 쿼리 : 캐쉬 메모리가 지역성이 떨어지는 데이터로 채워져 성능 저하 초래
-집계 쿼리 : (ex.받은 메일함의 안 읽은 메일 통 수 관리) -
배포 후
-사용자 단에서 일괄 재구동
-DDos 같은 서버 요청 발생 -
DNS
-JVM은 DNS 쿼리 결과 캐슁
-기본 설정은 JVM 재구동하기 전까지 캐슁 결과 변경 불가
- 기본 설정
- NGiNX
- ulimit
- 대규모 장애 대응(서비스 평행화)
IMAP 이란?
- IMAP를 사용하면 어디서나 모든 장치에서 전자 메일에 액세스할 수 있습니다.
- IMAP를 사용하여 전자 메일 메시지를 읽을 때 실제로 컴퓨터에 다운로드하거나 저장하지 않습니다. 대신 전자 메일 서비스에서 읽습니다. 따라서 휴대폰, 컴퓨터, 친구의 컴퓨터 등 전 세계 어디서나 다양한 장치에서 전자 메일을 확인할 수 있습니다.
- IMAP는 클릭할 때만 메시지를 다운로드하고 첨부 파일은 자동으로 다운로드되지 않습니다. 이렇게 하면 POP보다 메시지를 훨씬 더 빠르게 확인할 수 있습니다.
POP이란?
- POP는 전자 메일 서비스에 문의하고 새 메시지를 모두 다운로드하여 작동합니다. PC 또는 Mac에 다운로드되면 전자 메일 서비스에서 삭제됩니다.
- 즉, 전자 메일을 다운로드한 후 동일한 컴퓨터 를 사용하여만 액세스할 수 있습니다.
- 다른 장치에서 전자 메일에 액세스하려는 경우 이전에 다운로드한 메시지를 사용할 수 없습니다. 보낸 메일은 전자 메일 서버가 아닌 PC 또는 Mac에 로컬로 저장됩니다. ISP(인터넷 서비스 공급자)는 POP를 사용하는 전자 메일 계정을 제공합니다.
- 장애 대응
- 전파 : 메일링 리스트를 이용해서 유관자에게 전파, 장애 처리 전에 일단 전파
- 처리
-Case by Case : 에러로그/롤백/모니터링 등등
-유용한 스크립트 : 특정 일시 N분간 접속한 IP를 빈도로 정렬 / 특정 일시 N분간 접속한 URI를 빈도로 정렬
- 장애 후 대응
- 회고
-기계적으로 할 일
-해서는 안되는것 : 누가 실수했는지, 장애 귀책 부서가 어디인지
-과거는 과거 : 원인을 찾아 재발을 막는 것에 집중
-빠른 장애 대처 : 장애 어떻게 알았는지? 원인을 아는데 왜 오래 걸렸는지? 자동으로 복구할 수는 없었는지? - 장애 예방
