ClickCease 서버를 지금 재부팅할까요, 나중에 재부팅할까요? (둘 다, 감사합니다) - TuxCare

인기 뉴스레터 구독하기

4,500명 이상의 Linux 및 오픈소스 전문가와 함께하세요!

한 달에 두 번. 스팸이 없습니다.

서버를 지금 재부팅할까요, 나중에 재부팅할까요? (둘 다 안 함, 감사합니다)

2019년 12월 18일 TuxCare 홍보팀

BANNER--01

에 참석하셨습니까? AWS 리인벤트 2019?

저는 그랬고, 그것은 계시였습니다.

"향후 30일 이내에 Linux 서버를 재부팅하시겠습니까?"

KernelCare 부스를 찾은 거의 모든 사람들에게 물어본 질문입니다.

3분의 1이 그렇다고 답했습니다. 주된 이유는 무엇일까요? 규정 준수.

이는 당연한 일입니다. 대부분의 규정 준수 정책에 따르면 기업은 문제 발생 후 30일 이내에 보안 패치를 설치해야 합니다. 문제는 Linux에서 Kernel 패치를 적용하려면 서버를 재부팅해야 하는데, 이를 우회할 방법이 없다는 것입니다. (아니면 방법이 있을까요?)

약 2000명에게 물어봤을 겁니다. 각자가 관리하는 서버가 몇 대인지 생각해 보세요. 그런 다음 재부팅하는 데 걸리는 시간뿐만 아니라 계획하고 조율하는 데 걸리는 시간까지 곱해 보세요. 이 작은 샘플을 가지고도 놀랄 만큼 많은 사람의 노력이 필요하다는 것을 알 수 있습니다. 그리고 돈도요.

재부팅: 불편한 필요성

Linux 패치 관리는 "최신 소프트웨어를 설치하여 서버를 최신 상태로 유지"한다는 멋진 말입니다. 그 소프트웨어가 Linux Kernel인 경우, 시스템 재부팅의 가장 흔한 원인이 됩니다. 대기업의 경우 보안 패치 적용은 선택이 아니라 의무입니다.

일반적인 IT 보안 규정 준수 정책에는 다음과 같은 조항이 있습니다:

 

"...보안 패치는 공급업체에서 배포한 후 X일 이내에 시스템에 적용해야 합니다..."

 

X는 보통 30일입니다. 그렇기 때문에 실제로는 시스템 관리자가 패치를 일괄적으로 일괄 설치하여 미리 계획된 유지 보수 기간, 즉 시스템이 잠시 다운되어도 괜찮다는 데 모두가 동의한 시간에 작업을 수행합니다. (안타깝게도 이 시간은 고객에게 미치는 영향이 가장 적은 토요일 밤/일요일 아침인 경우가 많습니다.)

그 기간을 계획하려면 회의에서 보내는 시간, 이메일에 흘린 말, 타협으로 상처받은 마음 등 많은 노력이 필요합니다. 주말에 차가운 커피와 오래된 피자를 먹으며 시간을 허비하는 것은 말할 것도 없습니다. AWS re:Invent에서 근무하면서 Linux 시스템 관리자의 30%가 불필요한 고통을 겪고 있다는 느낌을 받았습니다.

계속 읽어보세요: KernelCare를 통한 라이브 패치의 10가지 이점

자동화: 자동화: 절대적인 필요성

누구도 수동으로 패치를 관리해서는 안 됩니다. 서버 한 대를 최신 상태로 유지하려면 엄청난 노력이 필요합니다.

기술 전문가인 시스템 관리자는 특히 대규모 서버를 관리하는 경우 이러한 일상적인 작업을 자동화하는 것을 좋아합니다. 자동화하는 작업이 자동화되는 작업보다 더 재미있는 경우가 많습니다. 다른 이점도 있습니다:

  • 더 안전하고 사람의 실수 가능성이 적습니다.
  • 프로세스를 기록하고 감사할 수 있습니다.
  • 업무와 책임을 더 쉽게 공유할 수 있습니다.

자동화하는 방법에는 여러 가지가 있습니다. 어떤 방법을 사용할지 결정하는 것 자체가 장애물이 될 수 있습니다. 예를 들어

  1. 나만의 자동화 도구를 구축하시나요? 선택할 수 있는 스크립팅 언어는 많지만 어떤 언어가 가장 적합하며 기술, 인내심, 시간이 있으신가요?
  2. 공급업체가 선호하는 지원 도구를 사용하시나요? Red Hat은 Satellite (및 이에 상응하는 오픈 소스인 Spacewalk)를, Canonical은 Landscape를 제공하지만 이는 자체 플랫폼용이며 지원 번들의 일부로만 제공됩니다.
  3. 서비스를 이용하시나요? Automox, GFI, Ivanti, Kaseya, ManageEngine, Pulseway 등 다양한 서비스 중에서 선택할 수 있습니다. 누군가는 이러한 서비스를 살펴보고, 어떤 기능을 하는지, 어떻게 작동하는지, 적합한지 파악해야 합니다. 그 와중에 패치는 계속 나오고 설치해야 합니다.
  4. 오케스트레이션 도구를 사용하시나요? Ansible, Chef 또는 Puppet이 몇 가지 옵션이 있지만, 이 역시 확인이 필요하며, 기능을 제대로 활용하려면 학습 곡선을 따라 올라가야 합니다.

가상화된 플랫폼을 대신 관리해주는(물론 유료) VMware Cloud on AWS와 같은 관리형 클라우드 서비스를 이용하는 것도 매력적인 옵션 중 하나입니다. 하지만 가상화가 재부팅을 없애는 것은 아닙니다. 클러스터링 및 기타 시스템 이중화 접근 방식을 통해 재부팅을 더 빠르고 덜 고통스럽게 만들어 그 영향을 줄일 수 있을 뿐입니다.

재부팅은 아무리 짧더라도 파일 핸들, 네트워크 연결, 사용자 세션을 닫고 모든 프로세스를 중지합니다. 많은 종류의 애플리케이션과 애플리케이션 사용자의 경우 세션이 복원되고 연결이 다시 설정되므로 눈에 띄지 않습니다. 그러나 다른 유형의 애플리케이션의 경우 중단은 치명적입니다. 장기간 실행되는 과학 계산, 실시간 분석, 라이브 게임 서버, IoT 디바이스 등을 생각해 보세요.

계속 읽어보세요: KernelCare로 재부팅 없는 업데이트를 구현한 Endurance

재부팅 증후군에 대한 치료법

라이브 패치는 재부팅 없이 자동으로 Linux Kernel 보안 패치를 설치하는 방법입니다. 이 기술은 2010년부터 사용되어 왔지만 Linux를 둘러싼 명성만큼 유명세를 얻지는 못했습니다.

그 이유는 이 작업이 어렵기 때문입니다. Kernel 소스 코드에 대한 깊은 이해와 빠르고 정확하게 패치를 코딩할 수 있는 능력이 필요합니다. 이 때문에 대형 Linux 공급업체만이 라이브 패치 솔루션을 제공할 수 있습니다: Oracle( Ksplice 포함), Red Hat( Kpatch 포함), SUSE( SUSE 라이브 패치, 일명 Kgraft 포함), Canonical( Livepatch 포함).

재부팅하지 않고 Linux Kernel을 패치하는 방법

KernelCare는 Ksplice, Kpatch 및 Kgraft와 동일한 방식으로 작동합니다. KernelCare와 이러한 도구의 차이점은 패치가 생성되는 방식에 있습니다. (또 다른 차이점은 이러한 제품은 공급업체의 서비스 계약의 일부인 반면, KernelCare 구독은 독립형이므로 훨씬 더 비용 효율적이고 유연하다는 점입니다.) 또한 KernelCare는 다른 모든 공급업체를 합친 것보다 훨씬 더 많은 Kernel 버전과 종류를 지원합니다.

다음은 KernelCare가 어떻게 작동하는지에 대한 간단한 개요입니다.

패치 프로세스 다이어그램 (1)

시스템 관리자가 KernelCare를 좋아하는 이유

KernelCare의 마케팅 매니저로 일하면서 많은 고객과 이야기를 나눴습니다. 고객들이 가장 좋아하는 혜택은 다음과 같습니다.

  1. 보고 업무 감소. 무엇을, 왜, 누가 수행했는지에 대한 관리 및 규정 준수 보고서의 필요성이 줄어듭니다.
  2. 이메일 감소. 재부팅 횟수가 줄어든다는 것은 다양한 부서의 수십 명의 이해관계자와의 커뮤니케이션 및 협상 횟수가 줄어든다는 것을 의미합니다.
  3. 더 많은 수면. 토요일 밤/일요일 아침에 재부팅하는 것은 다운타임의 영향을 받는 사람에게는 당연한 일입니다. 하지만 이 작업을 수행해야 하는 사람에게는 지옥과도 같습니다. 현장에 있든 원격에 있든 상관없이 누군가는 여전히 깨어 있어야 명령을 실행하고, 자동화가 원활하게 실행되는지 확인하고, 시스템이 정상적으로 작동하는지 점검할 수 있습니다. 이러한 상황에서는 위태로운 상황을 고려할 때 관리자의 편집증이 만연합니다.
  4. 생활이 더 간편해집니다. 예약된 재부팅 횟수가 줄어들면 방식에 관계없이 자동화 구성이 간소화됩니다. 시스템 플레이북이 더 간단하고 이해하기 쉬워집니다.

서비스 제공업체가 KernelCare를 선호하는 이유

KernelCare가 기술 전문가만을 위한 것이라고 생각한다면 오산입니다. 기본적인 Linux 콘솔 기술이 있는 사람이라면 누구나 몇 가지 명령어로 KernelCare를 설치할 수 있습니다. 이는 제가 서비스 제공자라고 부르는 계층의 사람들에게 희소식입니다. 이들은 실시간 패치의 기술적인 부분을 신경 쓸 수 없는 관리자와 임원 및 소규모 비즈니스 소유자입니다. 이들은 단순히 자신의 Linux 서버가 패치를 적용하고 규정을 준수하며 안전하게 유지되기를 원합니다. 이러한 분들과도 이야기를 나눠봤는데, 예상대로 다른 관점에서 KernelCare의 이점을 바라보고 있었습니다.

  1. 다운타임이 줄어듭니다. 즉, 고객의 업무 중단이 줄어들고 고객이 다른 곳으로 이동하거나 불만을 제기할 이유가 줄어듭니다.
  2. 재부팅 후 시스템이 이전과 같지 않을 위험이 적고, 비즈니스를 계속 운영하기 위해 모든 것을 롤백해야 할 가능성도 적습니다.
  3. 관리에 드는 비용이 줄어듭니다. 라이브 패치는 Linux Kernel 패치 관리에 대한 자급자족적인 접근 방식입니다.

(재부팅의) 끝

올해 AWS 리인벤트 2019는 저에게 첫 번째 행사였을 뿐만 아니라 Linux 서버 관리자가 성가신 재부팅을 처리하는 데 드는 노력과 비용의 규모를 직접 확인했다는 점에서 놀라운 행사였습니다. KernelCare 스탠드에서 목이 터져라 외쳐야겠다고 생각했습니다:

 

재부팅의 노예가 되지 마세요! 저희가 해답을 가지고 있습니다! 저희와 함께하세요!

 

하지만 물론 저는 그러지 않았습니다. 저는 브로셔, 스티커, 티셔츠를 나눠주며 보안 업데이트를 적용하기 위해 서버를 재부팅해야 하는 수백 명의 선량하고 열심히 일하는 사람들에게 미안한 마음을 전했을 뿐입니다.

F2C89C44-7062-40BA-AA31-B3B65001A902_1_201_a

 

계속 읽어보세요: Linux Kernel을 업데이트해야 하는 5가지 나쁜 이유

Kernel 재부팅, 시스템 다운타임 또는 예정된 유지 보수 기간 없이 취약성 패치를 자동화하고 싶으신가요?

TuxCare로 라이브 패치에 대해 알아보기

TuxCare 게스트 작가 되기

시작하기

메일

가입

4,500

Linux & 오픈 소스
전문가!


뉴스레터 구독하기