데이터베이스 운용의 어려움을 알자문제 예방잘 알고 있는 기술을 사용입증된 기술을 사용새로운 기술이 더 문제가 많다1년 후에는 또 다른 새로운 기술이 등장아키텍처를 복잡하게 하지 않기문제 인지모니터링해야 할 항목문제 해결
데이터베이스 운용의 어려움을 알자
- 적절한 운용을 위해서는 먼저 문제를 미연에 방지(예방)하는 것이 중요함
- 문제가 별로 발생하지 않도록 하려면 주변에서 많이 사용되어 잘 알려진 기술을 사용하는 등 자연스럽게 품질이 높아지도록 유도하는 것이 중요함
- 문제를 조기에 인지하기 위해서는 모니터링과 같은 구조가 중요함. 문제를 얼마나 빨리 복구시킬 것 인가를 생각하는 데 있어 중요한 것은 그 문제가 일어난 것을 얼마나 빨리 인식하는가 라는 것임
문제 예방
잘 알고 있는 기술을 사용
- 문제를 방지하는 데 중요한 것은 자신과 팀이 잘 알고 있는 기술을 사용해야 한다는 것임
- 잘 알고 있는 기술을 사용하는 것은 문제를 방지하는 데도, 발생한 문제를 신속하게 해결하는 데도 중요함
입증된 기술을 사용
- 데이터베이스든 웹 서버든 사용 제품을 선택할 때 가장 중요한 기준 중 하나가 세상에서 충분히 검증된 제품을 사용하는 것임
- 제품 공급 업체는 기존 제품의 구 버전을 내놔도 팔리지 않기 때문에 새로운 제품이 기존 제품의 문제점을 완벽히 극복했다고 선전할 것임. 그러나 여기에는 아래와 같은 함정이 있음
새로운 기술이 더 문제가 많다
- 실적이 있다라는 것은 그만큼 오랫동안 다양한 환경에서 테스트 되었다는 것임
- 이 테스트는 내부 품질테스트 뿐 아니라 사용자의 실제 환경에서 오랫동안 사용됨으로써 버그가 점차 수정되어 품질이 좋아졌다는 점도 있음
1년 후에는 또 다른 새로운 기술이 등장
- 소프트웨어 기술에서든 하드웨어 기술에서든 진화는 빠르게 진행되고 있음
- 지금 시점에서 새로운 기술이라고 해도 또 1년 후에는 더 새로운 기술이 등장할 것
- 단지 새로운 기술을 시험해 보고 싶은 것 뿐이라면 그러한 이유만으로 새로운 기술로 갈아탈 것인가?
- 새로운 시스템을 개발하는 것에 비해 실행 중인 서비스에서 새로운 제품으로의 대체는 쉽지 않음. 서비스를 멈추지 않도록 하면서 이식을 고려해 나가지 않으면 안 되기 때문
- 대부분 새 버전으로 높이기 위해서는 미들웨어의 재시작(정지 → 새 버전으로 교체 → 시작)이 필요하므로 짧은 시간에도 다운 타임은 발생하게 됨
- 중요한 것은 새로운 기술과 기존 기술의 효과를 파악!!!
아키텍처를 복잡하게 하지 않기
- 시스템 구성을 가능한 한 단순하게
- 한 사람에게 지나치게 의존하지 않고 어느 정도는 다른 사람이 대신해서 역임할 수 있도록 해야 하는데, 시스템 구성이 너무 복잡하게 되어 있으면 이해하는 것만으로 대단한 노역이 필요함
- 예를 들어, 사용 데이터베이스가 한 가지가 아닌 다섯 종류의 DB를 사용한다면 모든 제품에 정통한 사람을 찾는 것은 거의 불가능함
- 여기에서 제품의 보급도가 중요한 지표가 됨. 대중적인 제품이라면 잘 알고 있는 사람을 찾는 것이 그다지 어렵지 않다.
개발 시보다 운용 시의 문제가 심각해질 때가 많음
문제가 표면화된 때에 긴급한 대응이 요구되는 것은 개발할 때가 아니라 운용할 때임. 1분이라도 멈추면 때로는 상당한 금액의 단위로 금전적인 손실이 발생하기 때문
실험대가 되는 환경도 제공하기
새로운 기술은 기존 기술의 단점을 극복하는 것이므로 그것이 얼마나 매력적인지 피부로 느끼기 위해서는 검증 뿐 아니라 실제 서비스 투입도 중요함. 실험대가 되는 프로젝트를 해보기
문제 인지
- 대처를 촉구하는 타이밍으로서는 즉시 대응해야 하는 긴급한 상황(
ERROR
/FATAL
) 도 당연히 대응이 필요하지만, 그보다 전 단계에서 경고(WARN
)로서 통지하게 하는 것이 중요함
모니터링해야 할 항목
응답시간
— 사용자의 사이트에 대한 이미지에 직결되기 때문에 매우 중요함
- 웹 서버의 액세스 로그를 분석하거나 테스트용의 HTTP 클라이언트에서 웹 서버의 특정 URL을 계속 접속 요구하는 등의 형태로 응답 시간의 추이를 분석
- 응답시간은 일반적으로 대부분의 접속 요구가 몇 ms~수십ms 정도에 머무르고, 극히 일부의 접속 요구가 3~5초
CPU 사용률
로 모니터링해야 할 주요항목은 아래 세가지임
디스크 I/O (%iowait
)
디스크 I/O가 병목현상이 발생하는 경우는 이 값이 크게 튀어 오름
시스템 공간 사용률(%system
)
- OS 내의 처리(시스템 호출)에서 사용하는 것이기 때문에 일반적으로 병목현상이 발생할 수 없다
- 그러나 스왑이 높은 빈도로 발생하는 경우나 네트워크 쪽에서 문제가 발생하는 경우는
%system
이 튀어 오를 수 있음
- 심한 경우 한 개 이상의 CPU 코어에서
%system
사용률이 100%가 되기도 하는데, 이러한 상태가 되면 아무것도 할 수 없게 됨 (연결 수가 매우 많은 웹 서버에 문제가 될 수 있음)
- 잊어서 안되는 점이 네트워크 전송 상태의 감시. 네트워크 전송량이 처리 능력의 한계에 도달하면 더는 처리할 수 없게 되고, 웹 서버 측에서도 처리가 쌓여 프로세스 수가 늘어나기 때문에 응답 시간 또한 악화되는 것. 네트워크 부하 상황은
mpstat
로%irq
와%soft
를 살펴봄으로써 확인이 가능함
사용자 공간 사용률(%user)
I/O 병목현상이 나타나기 쉬운 DB 서버에서는 문제가 되는 일은 적지만, 이 값이 큰 경우는 작은 테이블에 대해서 이루어지는 테이블 스캔을 연발하는 등 무언가 불건전한 상황이 발생하고 있는 가능성이 높기에 주의가 필요
동시접속 수 및 스톨
- 모든 클라이언트가 일정 시간(1초 미만 ~ 몇 초) 아무것도 할 수 없는 경우가 있음. 여러 스레드가 데이터베이스 내부의 크리티컬 섹션(동시에 하나의 스레드밖에 실행할 수 없는 처리) 안에 일제히 들어가려고 할 때 나머지 스레드는 기다려야 함
- 이런 경우 많은 클라이언트가 작업을 기다리게 되어 전체적으로 시스템이 일시적으로 멈춘 것처럼 보이는 현상을
스톨
이라고 함
- 스톨이 발생하게 되면 동시 접속 수가 급증하게 됨. 초당 5,000대의 클라이언트로 부터 요청이 들어오는 어플리케이션이라 생각할 때, 스톨이 발생하여 2초간 서비스가 멈추게 되면 동시 접속 수가 10,000명이 되는 것
- 스톨의 대부분은 RDBMS의 구현에 기인함
- 오픈 소스 제품의 경우에는 스톨이 발생한 순간에 gdb 같은 디버거를 사용하여 프로세스의 스택 트레이스를 취함으로써 그 원인을 잡을 수 있음
초당 SQL 문의 실행 횟수
- 프런트의 캐쉬(memcached)가 멈추어 버려 모든 쿼리가 RDBMS로 오는 것과 같은 경우와 새로 추가된 기능에 버그 등이 있는 경우 SQL 문 실행 횟수가 갑자기 극적으로 늘어날 수 있음
- 돌발적으로 실행 횟수가 늘어나면 성능 면에서 문제가 되기 때문에 신속하게 해결할 필요가 있음
접속 여부 및 데이터베이스 내부 상태
- 해당 서버에 접속할 수 있는지 없는지 등의 상태 감시
- 데이터베이스의 경우 접속할 수 있는지의 여부 확인과 복제 구성이라면 지연이 되고 있진 않는지에 대해 감시
하드웨어 장애
- RAID 컨트롤러의 배터리 소멸 상황
- 디스크의 고장 상태나 블록 오류
- SSD의 블록 고장상황
- 네트워크 카드(NIC)의 고장 상황
빈 공간
OS에서 본 빈 공간(df 명령) — 백업 등에서 영향을 받음
데이터베이스에서 본 테이블의 빈 영역 - 평소의 처리에서 영향을 받음
일상적인 작업의 수고 줄이기
많은 서버를 관리하기 위해서는 고장률이 낮은 검증된 하드웨어를 사용하는 것도 중요하지만, 일상적인 작업을 가능한 한 자동화하는 것이 매우 중요함!
문제 해결
애플리케이션 수정
상당수의 성능 문제는 애플리케이션 측에서 비효율적인 처리가 행해지고 있기에 발생함. 예로, 인덱스가 제대로 사용되지 않은 쿼리를 찾아 인덱스를 추가하는 방법
- 웹 서버 증설
- 캐시 서버 증설
- 슬레이브 서버 증설
- 보다 스펙이 높은 서버로의 마이그레이션 및 서버 분할