GN⁺: Meta가 리눅스를 대규모로 패치하는 방법
(thenewstack.io)- 리눅스 서버 패치는 간단하지만, 수만 대의 서버를 다운타임 없이 패치하는 것은 쉽지 않음
- Meta는 수백만대의 리눅스 서버 패치를 위해 Red Hat의 Kpatch 와 KLP(Kernel Live Patching)을 이용함
- KLP는 재부팅하지 않고도 Linux 커널에 최신 보안 업데이트를 적용할 수 있음
라이브 커널 패치
- 라이브 커널 패치는 메인 커널 패키지와 별개로 수정된 코드가 포함된 패키지로 제공됨
- 라이브 패치는 누적되어 최신 패치에는 이전 패치의 모든 수정 사항이 포함
- 라이브 패치는 모든 것에 적용되지 않으며, 데이터나 구조를 패치할 수 없고, 라이브 패치를 만드는 데 추가 엔지니어링 작업이 필요함
Kpatch
- Kpatch는 원본 커널과 패치된 커널을 비교한 다음 사용자 정의 커널 모듈을 사용하여 실행 중인 커널에 새 코드를 패치하는 방식으로 작동
- 그런 다음 Kpatch 프로세스는 ftrace를 사용하여 기존 프로세스의 스택을 감시하여 유해한 영향 없이 패치를 수행할 수 있는지 확인
- 안전하다고 판단되면 실행 중인 코드를 패치된 함수로 리디렉션한 다음 이제 오래된 코드를 제거
- 이제 서버에 패치가 적용되어 다운타임이 발생하지 않음
Meta 의 경우
- 물론 실제로는 그렇게 간단하지 않음
- 메타에서는 라이브 패치를 적용할 때 호스트에 패치를 적용하는 데 보통 1~2초가 걸림
- 호스트 한 대에 1~2초라는 시간은 새로운 커널을 부팅하는 Linux 커널 메커니즘인 kexec과 비교하면 정말 빠른 속도
- 다운타임이나 워크로드 마이그레이션이 필요하지 않으며, 라이브 패치를 적용하기만 하면 바로 사용할 수 있음
수백만 대의 기계 패치 방법
- 수백만 대의 기계를 패치할 때는 이게 전부가 아님
- 메타에선 패치 롤아웃 중 버그를 발견하게 될 수 있으므로, 관리자는 릴리스 후보 티어부터 먼저 패치함
- RPM 기반 패치를 제공하는 패키지 롤러는 서버의 건강도 자동으로 확인함
- 메타는 새 커널에서 충돌, 주요 경보, 애플리케이션 문제 및 성능을 모니터링하며, 오류율이 1000 대의 서버 당 크래시 1건을 넘으면 패치가 중단되고 이전 커널로 복원됨
- Meta는 Kpatch를 사용하지만 다른 대안도 있음
- SUSE는 kGraft를 제공하고, Oracle은 Ksplice를 사용하며, Canonical은 Livepatch를 지원
- 코드에 관계없이 모두 비슷한 결과를 제공
GN⁺의 의견
이 기사에서 가장 중요한 것은 메타가 전 세계 수백만 대의 서버에 대한 다운타임 없는 효율적인 패치 방법을 적용했다는 점입니다. 이는 초급 소프트웨어 엔지니어에게도 흥미로운 주제이며, 리눅스 시스템의 유지 관리와 보안에 대한 중요성을 강조합니다. 또한, 이 기사는 라이브 패치 기술의 복잡성과 필요성을 이해하는 데 도움을 줄 수 있습니다.
Hacker News 의견
- Ksplice는 오라클에 인수된 후 내가 근무하는 동안 사용자 공간 프로그램으로 확장된 원래의 실시간 패치 기술임. 클라우드로의 이동에도 불구하고 대규모로 전체 시스템을 재시작할 필요가 없기 때문에 구식이 되지 않는 매우 멋진 기술임.
- 메타가 이 방법을 사용하여 전체 배포에 얼마나 걸리는지 언급하지 않은 것은 중요한 세부사항을 빠뜨린 것 같음. 실시간 패치를 사용하면 서버, 데이터 센터, 클라우드의 다운타임 없이 운영할 수 있음.
- 메타의 규모에서 일한다면 실시간 패치가 의미가 있을 수 있지만, 대부분의 잘 설계된 서비스와 애플리케이션은 서버의 전체 재부팅을 잘 견딜 수 있어야 함. 수백만 대의 서버를 관리하는 복잡성은 상상하기 어려움.
- KernelCare는 대부분의 리눅스 배포판을 지원하는 커널 실시간 패치를 위한 서비스임.
- 많은 가상머신에 Kpatch를 사용해왔으며, 상당히 잘 작동함.
- 현재 약 1,300만 대의 서버를 운영 중이며, 2023년에 새로운 데이터센터 장비에 200억 달러, 2024년에 추가로 200억 달러를 지출할 예정임. 현재 CentOS 8 Stream을 사용 중이며, 곧 9로 이동할 예정임.
- 호스트의 드레이닝과 언드레이닝은 어렵다고 함. 이는 사실상 서비스에서 호스트를 드레이닝하고 다시 복구하는 것이 쉽지 않다는 것을 의미하며, 이는 리눅스 커널이 실시간 패치를 위해 설계되지 않았으며, 이를 시도하는 것은 항상 불확실성의 원천이며 엔지니어링 작업 측면에서 비용이 많이 들고 재앙이 항상 임박해 있음을 의미함. 반면, 호스트의 서비스 드레이닝과 복구 시스템을 수정하여 매우 견고하고 신뢰할 수 있게 만드는 것이 신뢰성 측면에서 큰 이득을 가져올 것임. 이 접근 방식은 조직의 기능 장애를 덮는 것으로 보임. 한 팀이 모든 커널을 패치할 수 있지만, 모든 호스트가 서비스 드레이닝과 복구를 지원하도록 만드는 것은 불가능하며, 이를 수정할 실제 인센티브가 없기 때문에 아무도 이를 고치려 하지 않음. 오직 멋진 해킹과 새로운 프로젝트만이 제대로 보상받음.
- 대부분의 조직은 메타를 모방하는 것에서 이득을 보지 못하며, 그렇게 할 필요도 없음.
- "하이퍼스케일"이라는 개념을 처음 들어봄. 이것이 단순한 확장과 어떻게 다른지 궁금함.