Metaが大規模にLinuxへパッチを適用する方法

 (thenewstack.io)
8 ポイント 投稿者 GN⁺ 2023-12-05 | 1件のコメント | WhatsAppで共有
  • Linuxサーバーへのパッチ適用は簡単だが、数万台のサーバーにダウンタイムなしでパッチを当てるのは容易ではない
  • Metaは数百万台のLinuxサーバーにパッチを適用するために、Red HatのKpatchとKLP（Kernel Live Patching）を利用している
    • KLPは再起動せずにLinuxカーネルへ最新のセキュリティアップデートを適用できる

ライブカーネルパッチ

  • ライブカーネルパッチは、メインのカーネルパッケージとは別に、修正済みコードを含むパッケージとして提供される
  • ライブパッチは累積型で、最新パッチには以前のすべての修正が含まれる
  • ライブパッチはあらゆるものに適用できるわけではなく、データや構造はパッチできず、ライブパッチ作成には追加のエンジニアリング作業が必要になる

Kpatch

  • Kpatchは、元のカーネルとパッチ適用後のカーネルを比較し、カスタムカーネルモジュールを使って実行中のカーネルに新しいコードをパッチする仕組みで動作する
  • その後、Kpatchプロセスはftraceを使って既存プロセスのスタックを監視し、有害な影響なしにパッチを適用できるかどうかを確認する
  • 安全だと判断されれば、実行中のコードをパッチ済み関数へリダイレクトし、その後古いコードを削除する
  • これでサーバーにパッチが適用され、ダウンタイムは発生しない

Meta の場合

  • もちろん、実際にはそれほど単純ではない
  • Metaではライブパッチ適用時、通常ホストにパッチを当てるのに1〜2秒かかる
  • 1台のホストに対する1〜2秒という時間は、新しいカーネルを起動するLinuxカーネルの仕組みであるkexecと比べると非常に高速だ
  • ダウンタイムやワークロードの移行は不要で、ライブパッチを適用するだけですぐ利用できる

数百万台のマシンにパッチを適用する方法

  • 数百万台のマシンにパッチを適用する場合、これだけでは済まない
  • Metaでは、パッチのロールアウト中にバグが見つかる可能性があるため、管理者はまずリリース候補ティアからパッチを適用する
  • RPMベースのパッチを配布するパッケージローラーは、サーバーの健全性も自動で確認する
  • Metaは新しいカーネルでのクラッシュ、重大アラート、アプリケーションの問題、性能を監視しており、エラー率がサーバー1000台あたりクラッシュ1件を超えると、パッチは中止されて以前のカーネルへ戻される
  • MetaはKpatchを使用しているが、他にも代替手段がある
    • SUSEはkGraftを提供し、OracleはKspliceを使用し、CanonicalはLivepatchをサポートしている
    • コードベースに関係なく、いずれもおおむね同様の結果を提供する

GN⁺の見解

この記事で最も重要なのは、Metaが世界中の数百万台のサーバーに対して、ダウンタイムのない効率的なパッチ手法を適用している点です。これは初級ソフトウェアエンジニアにとっても興味深いテーマであり、Linuxシステムの保守とセキュリティの重要性を強調しています。また、この記事はライブパッチ技術の複雑さと必要性を理解する助けにもなります。

関連記事

1件のコメント

 
GN⁺ 2023-12-05
Hacker Newsの意見
  • Ksplice は、Oracle に買収された後、私が在籍していた間にユーザー空間プログラムへと拡張された、元祖のライブパッチ技術だ。クラウドへの移行にもかかわらず、大規模環境でもシステム全体の再起動を必要としないため、時代遅れにならない非常に優れた技術だ。
  • Meta がこの方法を使って全体展開にどれくらい時間がかかるのかに触れていないのは、重要な詳細が欠けているように思える。ライブパッチを使えば、サーバー、データセンター、クラウドでダウンタイムなしに運用できる。
  • Meta の規模で運用しているならライブパッチには意味があるかもしれないが、たいていの適切に設計されたサービスやアプリケーションは、サーバーの完全な再起動に十分耐えられるべきだ。何百万台ものサーバーを管理する複雑さは想像しがたい。
  • KernelCare は、ほとんどの Linux ディストリビューションをサポートするカーネルのライブパッチ用サービスだ。
  • 多くの仮想マシンで Kpatch を使ってきたが、かなりうまく動作している。
  • 現在およそ 1,300 万台のサーバーを運用しており、2023 年には新しいデータセンター設備に 200 億ドル、2024 年にはさらに 200 億ドルを支出する予定だ。現在は CentOS 8 Stream を使っており、まもなく 9 に移行する予定だ。
  • ホストのドレインとアンドレインは難しいという。これは事実上、ホストをサービスからドレインして再び復旧させるのが簡単ではないことを意味しており、Linux カーネルがライブパッチ向けに設計されていないこと、そしてそれを試みることは常に不確実性の源であり、エンジニアリング作業の面で高コストで、常に破綻の危険が迫っていることを意味する。一方で、ホストのサービスドレインと復旧システムを改修して非常に堅牢で信頼できるものにすれば、信頼性の面で大きな利益が得られるはずだ。このアプローチは、組織の機能不全を覆い隠しているように見える。あるチームがすべてのカーネルにパッチを当てることはできても、すべてのホストがサービスドレインと復旧をサポートするようにするのは不可能で、しかもそれを直す実際のインセンティブがないため、誰も修正しようとしない。きちんと報われるのは、気の利いたハックや新しいプロジェクトだけだ。
  • ほとんどの組織は Meta をまねても利益は得られず、そうする必要もない。
  • 「ハイパースケール」という概念を初めて聞いた。これが単なるスケーリングとどう違うのか気になる。