PostgreSQL 장애 대응

http://postgresql.kr/blog/postgresql_incident_response.html

PostgreSQL 장애 대응

이 글은 IT 운영 관점에서 본 장애 Incident 대응에 대한 글입니다. IT 운영 업무에서 장애라는 단어는 응용프로그램 개발자들이 생각하는 장애와는 전혀 다른 의미입니다. 극단적으로 이야기하면, 장애가 발생했을 경우 운영자는 그 장애원인을 해결하는 것이 첫번째 일이 아니라, 그 서버를 사용하는 이용자들에게 장애 발생 이전 상태와 같은 서비스를 최대한 빨리 제공하는 것이 첫번째 일입니다.

장애 원인 종류

장애는 단순히 서비스가 정상적이지 않다는 것을 뜻하지만, 그 원인은 IT 전체 환경에 다양하게 걸쳐 있습니다.

하드웨어 장애

영원한 건 절대 없어

특히나 장비는 그렇습니다. 세월이 흘러가면 언젠가는 고장이 납니다. 단지 해당 호스트가 운영 되고 있는 물리적 장비가 오류를 일으킨 것이기 때문에, 해결 방법 또한 그 물리적 장비를 바꾸는 것 뿐입니다. 왜냐하면 그 장비를 수리해서 다시 서비스를 하겠다는 것은 그 기간 만큼 장애 시간이 길어질 것을 의미하기 때문입니다. 이 때문에, 운영자는 반드시 물리적 장비 장애에 대한 장애 대응책을 세워두어야 합니다.

일반적으로 고가용성이라는 개념으로 운영 되고 있는 장비와 똑같은 한 개 이상의 다른 장비를 준비해 둡니다.

고가용성을 지원할 수 없는 환경이라면, 당연히 데이터베이스의 백업본을 꼭 준비해 두어야 합니다.

하드웨어 장애의 제일 골치 아픈 부분은 OS, 데이터베이스 시각에서 봤을 때 전혀 이상 징후를 찾을 수 없는 경우입니다. 대표적인 예가 이더넷 카드나 스토리지 카드의 오동작인 경우인데, 장애 대응 시각에서는 이 또한 장비 교체가 답입니다. 장애 원인은 장비 교체 후 원인 분석을 해야합니다.

OS 장애

OS 장애는 장비의 각 장치 장애와 밀접하게 연관되어 있습니다. 일반적으로 운영 환경인 상태에서 OS의 환경을 잘 바꾸지 않기 때문에, OS에 문제가 있다고 판단되는 경우라면, 대부분 OS 로그에 그 원인이 남아있고, 이 경우는 그에 따른 적절한 조치를 취하면 됩니다.

그 외 OS 정기 작업으로 인한 OS 패치, 환경 설정 변경에 의한 장애가 발생한 경우라면, 이 부분은 대부분 테스트 장비에서 미리 진행하고, 사전 영향도 분석을 철저히 하는 것으로 대부분 장애가 예방되기 때문에, 이 부분은 운영 업무의 표준화가 제일 중요하겠죠.

이 장애는 요즘들어 가상 호스트 환경에서 OS가 실행되기 때문에, OS 문제로 보이면 새로운 OS를 준비하고, 기존 데이터베이스 영역을 그곳으로 마운트할 수 있는 방법만 준비해 두면 충분합니다. 고가용성에서 이야기하는 OS 두개에 디스크는 하나 (공유디스크방식) 형태의 설계로 이 장애 대응시간을 최소화 할 수 있습니다.

적절하지 못한 서버 환경 설정 매개 변수

여기서부터 데이터베이스 장애로 분류됩니다. 데이터베이스 서버 환경 설정 매개 변수를 잘못 설정해서 발생하는 장애는 다양합니다.

가장 대표적인 예로 pg_hba.conf 파일에서 지정하는 호스트 기반 접근제어는 그 파일의 내용 가운데 먼저 있는 내용이 우선 적용됩니다.   한편 postgresql.conf 내용은 나중에 있는 내용이 최종 반영됩니다. 이 사실을 모르고 관리자가 똑같은 부분을 각기 다른 값으로 중복지정해서 장애를 일으키는 경우가 있습니다.

예를 들어 pg_hba.conf 에서 같은 클라이언트에 대해서 윗줄에는 reject를 다음 줄에는 trust를 지정한다면, 그 클라이언트는 접속할 수 없게 됩니다.  또한 postgresql.conf 파일에서 checkpoint_segments 매개 변수 값을 위에서는 8개 아래에서는 32개 라고 지정했다면, 서버는 32개로 지정합니다.

서버 운영 환경에 영향을 많이 미치는 환경 변수들

  • autovacuum_max_workers
  • checkpoint_segments
  • listen_addresses
  • maintenance_work_mem & work_mem
  • max_connections
  • max_prepared_transactions
  • shared_buffers

의도하지 않은 실행 계획

운영환경에서 가장 많이 발생하는 장애입니다. 장애 원인이 큰 시각으로 보면 너무도 명확하기 때문에 대응 방법 또한 이론상으로는 너무도 간단합니다. 그럼에도 불구하고, 가장 많이 발생하고 데이터베이스 운영자는 이 문제 때문에 고생을 제일 많이 합니다. 또한 데이터베이스 관리자라는 직업이 존재하는 이유 가운데 하나이기도 합니다.

대응방법은

  • 악성 쿼리에 의한 장애인지 판단하고,
  • 악성 쿼리를 찾고
  • 쿼리를 수정할 것인지, 서버 환경 설정 변경으로 처리가 가능한지 판단하고,
  • 적용 한다.

유지 관리 소홀로 발생하는 장애

데이터베이스 시스템은 그것을 이용하는 시스템의 생명 주기와 일치합니다. 그래서, 그 주기의 전환시점에 예상치 못한 장애가 발생할 수 있습니다.

  • 운영 전환 시점
    • 개발 환경과 운영 환경이 다른 부분 미확인
  • 자료 급속 증가 시점
    • 개발 환경에서 놓친 악성 쿼리
  • 안정기
    • 자료 누적으로 발생하는 장애

사용자 실수

데이터베이스를 운영 하면서 발생하는 장애 가운데, 앞에서 언급한 장애 보다는 덜 빈번하지면, 그 장애 파장이 훨씬 클 수도 있는 경우입니다.

  • table exclusive lock을 유발하는 쿼리들
  • idle in transaction
  • where 빠진 update, delete
  • 스토리지 증가량을 예상 못한 DML

크래킹

보안, 보안, 보안