교육 : 안정적인 서비스 운영

호밀빵 굽는 쿼카·2022년 3월 7일
0

NHN Cloud 인턴

목록 보기
29/48

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

배포

  1. 배포하는 중 UI 깨지는 현상
  • css, 이미지를 선배포하고 웹 응용 파일을 배포
  • ex > 구서버,신서버가 존재했을 시 삭제되거나 생성된 이미지에 접근했을 때 깨지게 된는
  1. 설정관리
  • 모든 장비의 설정 내용이 같은가
    -설정 값을 바꿔가며 테스트한 다음 그대로 방치하는 경우가 있음
  • 배포
    -바이너리 배포 시 함께?
    -설정은 따로 리포지토리 관리?

속도

  1. 제일 첫번 째 작업은 프로파일링
  • 절대로 감에 의존하지 말고 어디가 느린지 파악해서 개선
  • 빠른부분을 개선하는 것보다 느린부분을 개선하는 것이 우선
  1. 해결책

1) 캐쉬

  • 각 레이어별 적용 가능
    -db,was,웹 서버 에서 각각 캐쉬 가능
  • 저장방식
    -사용할 결과를 그대로 저장 -> 빠르나 많은 메모리
    -구조화해 저장 -> 조금 느리지만 보다 효율적인 메모리
  • 시간적지역성
    -한 번 읽은 데이터 곧 다시 읽을 수 있음
    -LRU
  • 공간적 지역성

2) 증설

  • 사용자가 늘었거나,기능이 추가돼 정말 증설이 필요할 수 있음
  • 증설은 죄가 아님!
  • 정책 변경
    -예) 조회수가 꼭 정확해야하나?
    - 단점 -> 58,59일때 장애가 나면 DB에 내용 갱신 안됐으므로 문제,,이정도를 감수할 것인지? 아닌지 고민해봐야함

3) 스토리지 속도

  • 메모리
  • 디스크 개수
  • RAID 컨트롤러

4) 품질관리

  • 웹, WAS
    -URI의 빈도와 각 URI별 응답속도 관리
    -최소한 평균과 표준편차 두 지표를 관리
    -표준편차가 큰(출렁이는) 부분을 찾아서 해결해야함
    -3초 전에는 잘되다가, 3초 이후에는 잘 안됐을 경우 잠재 장애 가능성이 있었을 것
    -https://zipkin.io/

운영

서비스 오픈은 끝이 아니라 시작

  1. 생각보다 관리할 것이 많음
  • 한통 발송은 쉽지만,
  • 다량 발송은 손이 많이 감
    -코드의 문제가 아니라 운영 문제
    -장애: COS발송 장애 등
  1. 자동화
  • 신규 서버 설치
    -장비 받아,10분 내에 설치할 수 있도록
    -방화벽 오픈등이 빠른 대응에 걸림돌
  • 일상적인 응용 배포
  • 자동복구
    -장애 시 루틴하게 하는 작업
    -예) 프로세스 재구동 등을 특정 조건일 때 자동으로 수행하도록
  1. 배치 작업
  1. 수집
  • 주기는?
    -실시간
    -시간단위
  1. 백업
  • 어떤 전략으로
    -주기는?
    -전체?증분?
  • 어떻게 복구
    -복구에 얼마나 걸리나
    -복구하는 동안 서비스는 유지?정지?읽기만?
  1. 로그
  • 보관
    -얼마나 오래 보관해야 하나
    -정책의 문제:전금법 관련 로그 12개월, 그 외 6개월
  • 조회
    -얼마나 많은 범위의 데이터를,얼마나 빠르게
  • 보안
    -개인 정보 저장하지 않도록
    -개인정보보호법과 관련해서 주의해야 할 부분 많음
  1. 품질 관리
  • JAVA APM
    -PINPOINT
    -SCOUTER
    -NewRELIC
    -DataDog

  • 디비
    -ORM을 쓰지 않는다면, DBA의 쿼리 검수 필요
    -동적 쿼리를 없애도록(1개의 동적쿼리는 생각보다 적은 N개의 정적 쿼리로 변경 가능)->서비스 면에서 더 좋을 수 있음
    -동적 쿼리를 사용하면, 특정환경에서 속도가 확 느려지게 될 수 있음->균일한 속도를 유지해야하는 부분에서 좋지 않을 수 있음
    -슬로우 쿼리 자동 검출(DBA기준과 개발자기준이 다를 수 있음.반드시 협의!)

  • 로깅
    -에러 로그 수집에 Log&Crash 활용

  1. 모니터링
  • 경고와 장애 수준 분리
    -대부분 장애 수준이 되고 나서야 알람을 받음
    -디스크 사용률 90%일 때 알람받음
    -평상 시 사용률 20%를 유지하고 있다면, 90%가 아니라 50%수준에서 경고 알람을 받아야함
  • 최저 값 모니터링
    -보통 데몬 개수가 N개를 넘을 때만 알람을 받음
  • 주기적으로 수치 점검
    -시스템의 기능과 사용자 수는 계속 변함
    -경고,장애,최저 값 세 수치는 주기적으로 리뷰해야함
  • 테스트 활용해 기능 체크
    -사용자 인터페이스 레벨의 테스트 모듈을 주기적으로 돌려, 서비스 상태 체크
    -무의미한 알람 받지 않도록 무시해도 되는 알람이라면 받지 않도록 설정
  • 연동 서비스/서버 모니터링
    외부 API를 이용할 경우, 해당 API를 빠르게 체크
  1. 알람
  • Dooray Messenger로도 가능
  • 사례 : API 게이트웨이 오류
    -알람:False 알람이 많아 간과
  1. 시스템 유틸리티
  • 필수
    -vmstat,mpstat,iostat,netstat,free,top,sar,ping
  1. HTTP 에러 페이지 설정
  • 50x
    -사용자들은 무의식적으로 새로 고침을 반복
    -별도(정적)서버로 리다이렉트 하도록 설정
  • 에러가 아닌척
    -쇼핑몰,결제를 처리하는 서버에서 오류가 났다면
    -일단 OK 메시지 보냄
    -결제가 안됐지만 정상 처리하고, 추후 로그나 기타 정보로 후 결제 처리
  1. 흔한 장애
  • 로그
    -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 재구동하기 전까지 캐슁 결과 변경 불가

  1. 기본 설정
  • NGiNX
  • ulimit
  1. 대규모 장애 대응(서비스 평행화)

IMAP 이란?

  • IMAP를 사용하면 어디서나 모든 장치에서 전자 메일에 액세스할 수 있습니다.
  • IMAP를 사용하여 전자 메일 메시지를 읽을 때 실제로 컴퓨터에 다운로드하거나 저장하지 않습니다. 대신 전자 메일 서비스에서 읽습니다. 따라서 휴대폰, 컴퓨터, 친구의 컴퓨터 등 전 세계 어디서나 다양한 장치에서 전자 메일을 확인할 수 있습니다.
  • IMAP는 클릭할 때만 메시지를 다운로드하고 첨부 파일은 자동으로 다운로드되지 않습니다. 이렇게 하면 POP보다 메시지를 훨씬 더 빠르게 확인할 수 있습니다.

POP이란?

  • POP는 전자 메일 서비스에 문의하고 새 메시지를 모두 다운로드하여 작동합니다. PC 또는 Mac에 다운로드되면 전자 메일 서비스에서 삭제됩니다.
  • 즉, 전자 메일을 다운로드한 후 동일한 컴퓨터 를 사용하여만 액세스할 수 있습니다.
  • 다른 장치에서 전자 메일에 액세스하려는 경우 이전에 다운로드한 메시지를 사용할 수 없습니다. 보낸 메일은 전자 메일 서버가 아닌 PC 또는 Mac에 로컬로 저장됩니다. ISP(인터넷 서비스 공급자)는 POP를 사용하는 전자 메일 계정을 제공합니다.

  1. 장애 대응
  • 전파 : 메일링 리스트를 이용해서 유관자에게 전파, 장애 처리 전에 일단 전파
  • 처리
    -Case by Case : 에러로그/롤백/모니터링 등등
    -유용한 스크립트 : 특정 일시 N분간 접속한 IP를 빈도로 정렬 / 특정 일시 N분간 접속한 URI를 빈도로 정렬
  1. 장애 후 대응
  • 회고
    -기계적으로 할 일
    -해서는 안되는것 : 누가 실수했는지, 장애 귀책 부서가 어디인지
    -과거는 과거 : 원인을 찾아 재발을 막는 것에 집중
    -빠른 장애 대처 : 장애 어떻게 알았는지? 원인을 아는데 왜 오래 걸렸는지? 자동으로 복구할 수는 없었는지?
  • 장애 예방
profile
열심히 굽고 있어요🍞

0개의 댓글