서버 다운타임을 줄이는 5가지 방법(그리고 다운타임을 없애는 1가지 방법)

서버 재부팅은 비즈니스와 고객에게 피해를 줍니다. 서버 재부팅은 주로 서버가 트랜잭션을 덜 처리하는 사용량이 적은 시간대(주로 밤)에 수행되지만, 이 시간에 재부팅하는 경우에도 수천 시간의 다운타임이 발생합니다. 서버를 재부팅하는 데는 구성에 따라 몇 분에서 1시간 이상 걸릴 수 있으며, 서비스가 동기화되는 데 추가 시간이 소요될 수 있습니다. 실제로 조직의 25%가 보고서 다운타임으로 인해 서버를 사용할 수 없는 시간당 30만~40만 달러의 비용이 발생한다고 보고했습니다. 다운타임은 피할 수 있으며 패치로 인한 재부팅을 완전히 없앨 수 있습니다.

콘텐츠:

1. 서버 다운타임이란 무엇이며 언제 발생하나요?
2. 조직의 다운타임 비용
3. 다운타임 예약: 유지 보수 계획 및 실행
4. 서버 다운타임을 최소화하는 방법

서버 다운타임이란 무엇이며 언제 발생하나요?

서버는 다양한 이유로 장애가 발생하지만 서버 장애가 항상 다운타임을 의미하는 것은 아닙니다. 다운타임은 단일 장애 지점을 무시하거나 간과했거나 장애 조치 시스템이 원활하게 인계받지 못했음을 의미하므로 조직에 훨씬 더 중요합니다. Google은 서버 다운타임이 발생하는 서버 다운타임이 발생하는 10가지 이유. 아래에서 50분 분량의 동영상을 요약해 보겠습니다.

리소스 과부하

서버 요청이 사용 가능한 리소스를 초과하면 성능이 저하되고 결국 서버가 다운됩니다. 클라우드 서버는 리소스를 동적으로 확장할 수 있지만, 클라우드 서버를 담당하는 온프레미스 관리자는 항상 서버가 고객 애플리케이션과 리소스 확장을 지원할 수 있는지 확인해야 합니다.

시끄러운 이웃

"나쁜 이웃" 문제는 주로 공유 호스팅 서비스를 제공하는 클라우드 호스트가 우려하는 문제입니다. 한 클라이언트가 서버의 리소스를 너무 많이 사용하면 다른 클라이언트 사이트의 성능에 영향을 미칩니다. 대부분의 호스트는 문제를 제어하기 위해 '시끄러운 이웃'을 공유 서비스 밖으로 이동시키거나 문제가 있는 클라이언트에 사용 가능한 리소스를 제한합니다.

스파이크 재시도

서버에 과부하가 걸리든 애플리케이션이 고장 났든, 사용자가 서버에 연결할 수 없을 때 여러 번 시도하다가 포기하는 경우가 많습니다. 이제 수천 명의 사용자가 동일한 재시도를 여러 번 수행하면 재시도 급증으로 인해 서버가 다운될 수 있습니다. 관리자는 공격적인 재시도 연결을 거부하도록 서버를 구성하여 재시도 스파이크를 줄일 수 있습니다.

버기 종속성, 패치 또는 애플리케이션

잘못된 패치 적용 습관, 오래된 소프트웨어, 느린 종속성, 서버에서 실행 중인 애플리케이션과 관련된 수많은 기타 문제로 인해 다운타임이 발생할 수 있습니다. 관리자는 단순히 패치를 설치하고 무분별하게 재부팅할 수 없습니다. 패치와 업데이트를 예약하고 사용량이 많지 않은 시간대에 재부팅해야 합니다. 실시간 패치가 도움이 될 수 있습니다(자세한 내용은 나중에 설명).

타사 확장

서버는 확장할 수 있지만 애플리케이션 처리에 사용되는 타사 API는 확장하지 못할 수 있습니다. Google은 오버헤드를 줄이기 위해 일관된 대규모 프로세스를 청크로 분할하는 '샤딩'을 권장합니다.

비효율적인 샤딩

샤딩은 성능에 도움이 되지만 한 샤드가 다른 샤드에 비해 너무 크면 샤딩이 고르지 않게 됩니다. Google은 이 문제를 해결하기 위해 큰 샤드를 더 작은 샤드로 분할할 것을 권장합니다.

인간의 실수

일부 서버 절차에는 사람이 너무 많이 개입합니다. 자동화가 없으면 인적 오류가 발생할 수 있습니다. 예를 들어, IT 직원이 수동으로 서버를 패치하고 업그레이드하면 실수와 다운타임이 발생하는 경우가 많습니다. 패치 관리 및 자동화를 사용하면 문제가 발견되었을 때만 관리자가 개입하면 되므로 인적 오류를 크게 줄일 수 있습니다.

잘못된 코드 배포

사내 애플리케이션을 사용하는 조직의 경우 배포된 코드에 문제가 없는지 확인하기 위해 테스트가 매우 중요합니다. 엄격한 테스트 및 품질 보증(QA) 절차 외에도 항상 롤백 프로세스를 개발해야 합니다. 

모니터링 불량

대부분의 관리자는 모니터링이 필수적이라는 것을 알고 있습니다. 또한 모니터링은 규정 준수의 구성 요소이기도 합니다. 모니터링 전략에서 구성이나 서버가 하나만 누락되어도 조직은 모니터링 공백에 노출됩니다. 네트워크를 감사하여 모든 리소스가 모니터링 애플리케이션에 추가되었는지 확인하면 이러한 문제를 방지할 수 있습니다.

잘못 구성된 도메인 및 인프라

서버 리소스에 대한 연결이 항상 로컬 컴퓨터 문제로 인해 발생하는 것은 아닙니다. 도메인에 장애가 발생하면 클라이언트가 서버에 연결할 수 없기 때문에 서버 다운타임이 발생할 수 있습니다. 구성 변경 사항을 배포하기 전에 장애 조치 및 테스트를 수행하면 이 문제를 방지하는 데 도움이 됩니다.

조직의 다운타임 비용

근본 원인이 무엇이든 비즈니스의 주요 관심사는 다운타임 동안(그리고 그 이후) 손실되는 비용입니다. 장애 복구 시스템을 갖추지 않으면 트랜잭션을 처리할 수 없으며, 트랜잭션이 공백으로 사라질 수 있습니다. 고객 불만은 고객 손실로 인한 매출 손실과 다운타임이 평판에 영향을 미쳐 브랜드 손상을 초래할 수 있는 또 다른 주요 문제입니다.

최근 포네몬의 보고서에 따르면 패치 관리 부실과 취약점 패치 지연으로 인해 다운타임이 30% 더 많이 발생하는 것으로 나타났습니다. 설문조사에 참여한 기업 중 52%는 패치 및 운영 체제 업데이트로 인한 재부팅을 포함한 다운타임을 용납할 수 없다고 답했습니다. 소규모 기업은 취약점 패치를 처리할 리소스와 자동화를 갖추지 못해 다운타임이 증가하기 때문에 대기업보다 더 큰 어려움을 겪습니다.

앞서 언급한 모든 다운타임 원인 중 인적 오류와 잘못된 패치 배포는 패치 자동화를 통해 완전히 제거할 수 있습니다. 실시간 패치를 사용하면 재부팅을 완전히 없앨 수 있습니다. 조직의 지출 연간 140만 달러 취약성 관리에 지출하지만 패치 관리 및 자동화를 통해 직원 오버헤드, 다운타임 비용, 재부팅 문제까지 크게 줄일 수 있습니다.

다운타임 예약: 유지 보수 계획 및 실행

서버 수명의 어느 시점에 관리자는 다운타임을 예약해야 합니다. 코드 배포, 서버 하드웨어 변경, 구성 변경 또는 사용 중지된 서버를 새 서버로 전환하는 경우 등이 이에 해당할 수 있습니다. 예약된 유지 보수는 일반적으로 사용량이 많지 않은 시간에 실행되지만 다운타임을 줄이기 위해 취할 수 있는 몇 가지 단계가 있습니다.

• 백업이 최신 상태이고 작동하며 사용 가능한지 확인. 서비스를 중단시키는 중요한 롤백을 수행해야 하고 백업이 필요한 경우, 백업을 사용할 수 있는지 확인하여 백업을 더 빠르게 추출하고 배포할 수 있도록 하세요.
• 디스크 사용량 확인. 제한된 리소스를 사용하는 서버를 사용하는 소규모 비즈니스의 경우 항상 업데이트를 위해 디스크 스토리지를 사용할 수 있는지 확인하세요. 드라이브가 가득 차면 심각한 성능 저하와 함께 예기치 않은 결과가 발생할 수 있습니다.
• 서버 리소스 사용률 확인. 저장 공간을 확인하는 것 외에도 서버에 성공적인 업데이트 또는 구성 변경을 방해할 수 있는 CPU 또는 메모리 스파이크가 없는지 확인합니다.
• 변경 사항을 배포하기 전에 테스트. 이는 관리자의 상식처럼 보일 수 있지만, 많은 '빠르고 쉬운' 구성 변경이나 업데이트로 인해 다운타임이 발생하고 관리자는 사소한 변경에 대한 테스트를 건너뜁니다. 관리자는 사소한 변경으로 인해 문제가 발생할 가능성이 없다고 생각하지만, 그럴 가능성은 항상 존재합니다. 항상 스테이징 환경에서 프로덕션 서버에 대한 변경 사항을 먼저 테스트하세요.

서버 다운타임을 줄이는 5가지 방법(그리고 다운타임을 없애는 1가지 방법)

예기치 않은 서버 다운타임은 예정된 유지보수보다 조직에 훨씬 더 큰 피해를 줍니다. 관리자는 백업 및 롤백 계획을 수립하고 예정된 유지 보수 중에 문제가 발생할 경우에 대비해야 하지만, 예기치 않은 다운타임은 근본 원인 분석과 서버를 다시 서비스할 수 있는 리소스가 필요합니다. 관리자는 서버의 다운타임을 최대한 줄이기 위해 예방 조치를 취해야 합니다. 다음은 다운타임을 줄이는 데 도움이 되는 몇 가지 모범 사례입니다:

보안

사이버 보안은 서버 안정성과 가동 시간을 위해 매우 중요합니다. 공용 서버를 다루는 관리자는 수많은 취약점 검사, 익스플로잇 시도, 의심스러운 트래픽을 모니터링해야 합니다. 보고된 모든 취약점은 공개적으로 서버에 대한 익스플로잇과 공격이 이어질 수 있으므로 관리자는 즉각적인 조치를 취하고 시스템을 패치해야 합니다. 데이터 유출로 인한 다운타임은 단순히 재부팅으로 인한 다운타임 비용보다 훨씬 더 큰 매출 손실과 기업 문제를 야기합니다.

서버 모니터링

수백 대의 서버를 보유한 조직의 경우 단 한 대의 서버도 놓치기 쉽습니다. 네트워크를 감사하고 모든 서버를 식별하면 충돌뿐만 아니라 느린 장애를 일으킬 수 있는 리소스 급증 및 비효율성(예: 냉각)에 대해서도 서버를 적절히 모니터링할 수 있습니다. 모든 문제는 중요한 오류에 대한 문자 메시지를 포함하여 관리자에게 메시지를 보내야 합니다. 사전 예방적 모니터링은 관리자에게 보류 중인 가상 및 물리적 충돌을 알려주므로 다운타임이 발생하기 전에 문제를 해결할 수 있습니다.

비효율적인 서버 폐기

오래된 서버는 장애가 발생하기 쉬우므로 결국에는 서버를 폐기해야 합니다. 관리자가 하드웨어를 업데이트하는 경우가 드물지 않지만, 결국 하드웨어를 항상 업그레이드하는 것은 비용 효율적이지 않습니다. 이러한 서버는 더 많은 전력을 소비하고 환경 성능에 연쇄적인 영향을 미칠 수 있습니다.

냉각 최적화

열과 습기는 서버 장비를 서서히 파괴합니다. 모니터링을 구현하면 이러한 환경 요인이 장비를 파괴하고 서버에 하드웨어 장애가 발생하기 전에 이를 감지할 수 있습니다. 모든 서버실에 적절한 냉각 장치를 설치해야 하며, 기본 냉각 장치에 장애가 발생할 경우를 대비해 백업 시스템을 마련해야 합니다.

부하 테스트 수행

로드 밸런서를 사용하여 여러 서버에 분산하면 성능에 도움이 되지만 두 대 이상의 서버에 장애가 발생하면 어떻게 될까요? 부하 테스트를 통해 일부 리소스에 장애가 발생한 후 서버의 성능을 파악할 수 있습니다. 이로 인해 추가 서버를 프로비저닝하거나 기존 서버에 리소스를 추가해야 할 수도 있습니다. 중요한 서버의 경우 항상 용량 제한을 초과 예측하여 확장 및 성장에 충분한 리소스를 사용할 수 있도록 하세요.

패치 자동화 및 라이브 패치

수동 패치는 인적 오류를 초래하고 중요한 취약성 경고를 놓칠 수 있습니다. 따라서 조직은 패치 자동화를 사용해야 합니다. 패치 자동화를 사용하더라도 지금까지는 Linux Kernel을 업데이트하려면 재부팅이 필요했습니다. 하지만 KernelCare 및 공유 라이브러리용 KernelCare +를 사용하면 관리자는 서버를 재부팅하지 않고도 시스템을 패치할 수 있습니다. 실시간 패치를 사용하면 Kernel 업데이트를 위한 정기 유지 보수 및 다운타임이 전혀 필요하지 않습니다. 예를 들어, HostUS는 KernelCare를 사용 중이며 최근 재부팅하지 않은 서버가 5.5년.

결론

서버 다운타임은 막대한 비용이 발생하지만 올바른 모범 사례를 통해 줄일 수 있습니다. 예기치 않은 오류로 인한 다운타임은 대부분 예방할 수 있지만, 패치로 인한 다운타임은 KernelCare의 실시간 패치를 통해 완전히 제거할 수 있습니다. KernelCare가 서버에 어떤 도움을 줄 수 있는지 알아보세요, 무료로 가입하고 가입하고 시작하세요.