서버를 재부팅하는 이유

꽤 정기적으로 제기되는 질문은 서버를 주 1회와 같이 정기적으로 재부팅해야 하는지, 아니면 최대 “가동 시간”을 달성하기 위해 가능한 한 오래 실행해야 하는지 여부입니다. 제게 답은 간단합니다. 드문 예외를 제외하면 정기적인 재부팅이 서버에 가장 적합한 선택입니다.

어떤 규칙이든 마찬가지로, 적용되지 않는 경우가 있습니다. 예를 들어, 중요한 시스템을 운영하는 일부 비즈니스는 다운타임을 허용할 수 없어 24/7 가용성이 필요합니다. 물론 이런 시스템들은 단순히 정기적으로 재부팅할 수 없습니다. 그러나 시스템이 절대 다운되어서는 안 될 만큼 중요하다면, 이 상황은 이 시스템이 단일 장애점(SPOF)이라는 경고 신호를 발생시켜야 하며, 계획된 다운타임이든 비계획된 다운타임이든 다운타임을 어떻게 처리할지에 대한 고민을 시작해야 합니다.

또 다른 예외는 일부 AIX 시스템이 시스템이 자체 튜닝 방식으로 작동하며 사용 정보를 얻고 그에 맞게 조정하는 데 시간이 필요하기 때문에 최대 효율을 얻으려면 몇 주 이상의 상당한 가동 시간이 필요하다는 것입니다. 이것은 대규모의 거의 변경되지 않는 데이터베이스 서버 및 다른 플랫폼보다 덜 일반적인 유사 사용 시나리오로 제한되는 경향이 있습니다.

IT에서 우리는 종종 “가동 시간”이라는 개념을 숭배합니다. 즉, 시스템이 재시작 없이 얼마나 오래 실행될 수 있는지입니다. 그러나 “가동 시간”은 비즈니스에 가치를 가져다주는 개념이 아니며, IT는 인위적인 메트릭에 집중하는 것이 아니라 항상 비즈니스의 필요를 염두에 두어야 합니다. 비즈니스는 서버가 재부팅 없이 얼마나 오래 온라인 상태를 유지했는지에 관심이 없습니다. 비즈니스 처리를 위해 필요할 때 서버가 가용하고 준비되어 있는지에만 관심이 있습니다. 이것들은 매우 다른 개념입니다.

일반적인 비즈니스 서버의 대부분은 비즈니스 목적으로 서버가 가용해야 하는 시간대와 필요하지 않은 시간대가 있습니다. 이 시간대는 일별, 주별 또는 월별로 있을 수 있지만, 예외 없이 24시간 내내 실제로 사용 중인 서버는 드뭅니다.

운영 체제 X 대신 Y를 실행하기 때문에 더 이상 재부팅할 필요가 없다고 말하는 사람들의 이야기를 자주 듣습니다만, 이것은 단순히 사실이 아닙니다. 정기적으로 재부팅해야 하는 두 가지 주요 이유가 있습니다. 서버가 성공적으로 재부팅할 수 있는 능력을 검증하기 위해서와 재부팅 없이는 적용할 수 없는 패치를 적용하기 위해서입니다.

패치 적용이 대부분의 비즈니스가 재부팅하는 이유입니다. 거의 모든 운영 체제는 적용되려면 재부팅이 필요한 정기적인 업데이트를 받습니다. 대부분의 패치는 특히 재부팅이 필요한 패치는 보안 및 안정성 목적으로 배포되므로, 패치 적용의 중요성은 상당히 높습니다. 가동 시간을 유지하기 위해 서버를 불필요하게 취약한 상태로 두는 것은 현명하지 않습니다.

서버가 성공적으로 재부팅할 수 있는 능력을 테스트하는 것이 종종 간과됩니다. 대부분의 서버에는 정기적으로 변경 사항이 적용됩니다. 변경 사항에는 패치, 새로운 애플리케이션, 구성 변경, 업데이트 또는 유사한 것들이 포함될 수 있습니다. 모든 변경은 위험을 수반합니다. 변경 사항이 적용된 직후 서버가 정상이라고 해서, 재부팅 시 서버와 그 위에서 실행되는 애플리케이션이 예상대로 시작될 것이라는 의미는 아닙니다.

서버를 절대 재부팅하지 않는다면, 성공적으로 재부팅할 수 있는지 알 수 없습니다. 시간이 지남에 따라 마지막 재부팅 이후 적용된 변경 사항의 수가 증가합니다. 이것은 매우 위험합니다. 우리가 두려워하는 것은 많은 변경 사항이 적용되었고, 그 중 많은 것이 문서화되지 않았을 수 있는 상황에서 재부팅이 실패하는 것입니다. 그 시점에서 어떤 변경이 시스템 장애를 유발하는지 파악하는 것은 극복할 수 없는 과정일 수 있습니다. 롤백할 단일 변경 사항도 없고, 복구 가능성에 대한 알려진 경로도 없습니다. 이것이 패닉이 발생하는 순간입니다. 물론 의도적으로 재부팅되지 않은 서버는 비의도적으로 재부팅될 가능성이 더 높습니다. 즉, 재부팅 실패의 가능성이 더 높고, 활성 사용 중에 발생할 가능성도 더 높습니다.

정기적인 재부팅은 재부팅 실패의 빈도를 줄이기 위한 것이 아닙니다. 실제로 실패의 발생 빈도를 높이지만, 그 목적은 “알려진 변경” 관점에서 그러한 실패를 쉽게 관리 가능하게 만들고, 더 중요하게는 서버가 유지보수 가능 상태로 지정되어 비즈니스 영향 없이 문제를 발견할 수 있도록 스트레스 테스트를 받을 수 있는 시간에 재부팅이 발생하도록 제어하는 것입니다.

재부팅 후 서버가 다시 올라오지 않아 일요일에 작업해야 하는 것이 싫어서 주말 재부팅을 피한다는 시스템 관리자 이야기를 많이 들었습니다. 저도 재부팅 실패로 인해 일요일 아침에 여러 번 호출된 적이 있지만, 그 전화를 받을 때마다 안도감을 느낍니다. 비즈니스에 재정적 영향을 미치지 않는 시점에 문제를 발견했다는 것을 알기 때문입니다. 그 서버가 업무 외 시간에 재시작되지 않았다면, 활성 비즈니스 시간 동안 장애가 발생하여 매출 손실을 초래할 때까지 “부팅 불가” 상태임을 발견하지 못했을 수도 있습니다.

정기적인 주말 재부팅 덕분에 잠재적인 재해를 안전하게 포착할 수 있으며, 조사해야 할 변경 사항이 1주일치뿐임을 알기 때문에 대개 거의 노력을 들이지 않고, 장애 이전에 어떤 변경이 이루어졌는지 이해한다는 큰 확신을 가지고 문제를 해결할 수 있습니다.

정기적인 재부팅은 매우 간단하고 신뢰할 수 있는 프로세스를 통해 완화할 수 있는 중단 및 다운타임으로부터 비즈니스를 보호하기 위한 것입니다.