Linux カーネル 6.x：ホスティングサーバーに関連する新機能

カーネルのバージョンを正しく把握する

「Linux 6.x」という呼称は、多くのメジャーリリースを総称するものであり、統一された機能レベルを指すものではありません。メインラインとは、Linus Torvalds がメンテナンスを行う主要なブランチを指します。マージウィンドウ終了後、通常はリリース候補版が続き、最終的なメジャーリリースに至ります。 これとは区別されるのが、Stable（安定版）およびLTS（長期サポート）ブランチであり、これらは公開済みのカーネルに厳選された修正を加えて維持管理しています。一方、ディストリビューションのカーネルは、独自のパッケージの状態、サポート方針、および統合に関する決定に従っています。.

特にホスティングサーバーにおいては、 バックポート 重要な点：ディストリビューションは、個々の機能、ドライバの改善、あるいはセキュリティ修正を、長期にわたりメンテナンスされている古いカーネルに組み込むことができます。逆に、機能を無効にしたり、パッチを修正したり、設定によって制限したりすることも可能です。 したがって、バージョン番号だけでは、完全な機能範囲も具体的な動作上の影響も推測することはできません。.

コマンド uname -r 現在のリリース文字列を特定するものであり、インベントリ作成やパッケージの照合を行う上で有用な出発点となります。しかし、これだけでは、ある機能がコンパイルされていること、実行時に有効化されていること、あるいはアプリケーションから利用可能であることを証明するものではありません。また、新しいカーネルバージョンであっても、ディストリビューターが提供する設定やドキュメントの確認に代わるものではありません。.

確実な分類を行うには、いくつかのレベルを確認する必要があります。具体的には、ディストリビューションとパッケージの状態、カーネルの設定、ブートパラメータ、および既存のランタイムインターフェースです。 さらに、ストレージや仮想化などの場合、ハードウェア、ファームウェア、ドライバも検討対象となります。結局のところ、導入されたアプリケーションが実際にそのインターフェースを利用している必要があります。既存のカーネル関数があっても、それだけでWebサーバーが自動的に変更されるわけではないからです。.

したがって、この記事では完全なリリース履歴を網羅するものではありません。現在の 6.x カーネルの運用に関連する機能に焦点を当てています。 それらのすべてが6.xシリーズで初めて導入されたわけではありません。重要なのは、具体的なカーネルで利用可能な機能の状態、可能な拡張、およびメモリ動作、CPU競合、プロセスの分離、メンテナンスへの影響です。.

ホスティングの4つのサービス分野

ホスティングサーバーに関しては、以下の4つの運用領域が特に重要です： ストレージの圧力, 、CPU競合、追加のプロセス分離、およびメンテナンス。ここで重要なのは、カーネル機能をできるだけ多く有効にすることではなく、観察された問題に適したツールを選ぶことです。 PHP-FPMプール、データベース、キャッシュ、バッチジョブ、および特殊なワーカーは、それぞれ異なる要件を持ち、それらはカーネルバージョンだけでは判断できません。.

cgroup v2 これは横断的なテーマですが、6.x シリーズにおける新機能ではありません。この階層構造は、サービス、コンテナ、または顧客グループ向けのメモリおよび CPU リソースを整理するものです。どのコントローラーが利用可能で、どのサブ階層で有効化されているかは、それぞれの cgroup-v2 マウントで確認する必要があります。 そのため、専用Webサーバーは、コンテナやVMホストとは異なる評価が必要となります。.

この表では、ビルド構成、ブート時の有効化、実行時インターフェース、および実際の使用状況を意図的に区別しています。 ある機能はカーネルに含まれていても、無効化されていたり、そのアプリケーションにとっては無意味であったりする場合があります。同様に、ディストリビューションによっては機能を以前のバージョンにロールバックすることもあります。したがって、変更を評価する際は、利用可能な最高バージョン番号ではなく、負荷の推移、cgroupの構成、ハードウェア、およびアプリケーションの測定値に基づいて行うようにしてください。.

ストレージ圧力とページ回収

Linuxは、空きメモリをファイルキャッシュとして活用するのが一般的です。したがって、RAMの使用率が高いこと自体は問題ではなく、メモリの無駄遣いを示すものでもありません。キャッシュされたファイルページは、必要に応じて解放されるからです。 診断においては、むしろ負荷の推移やその結果、例えば応答時間、スワップの活動状況、エラーログ、プロセスの異常終了などが重要となります。.

貯蔵圧力によって決まる ページ回収 , 、どのページをキャッシュから削除するか、あるいは必要に応じてスワップアウトできるか。カーネルはこの処理を非同期的に kswapd 処理する。メモリ要求の際にプロセスが自らページを回収しなければならない場合、カーネルのドキュメントではこれを「ダイレクト・リクレイム」と呼ぶ。これは、要求元となるワークロードに影響を与え、ひいては観測されるレイテンシに悪影響を及ぼす可能性がある。.

警告サインは通常、複数の要因が組み合わさって発生します。継続的なスワップの読み込みや書き込み、OOMイベント、待ち時間の増加、アプリケーションレベルのエラーなどは、共通のタイムライン上で把握する必要があります。 一方、一度限りの急激な変動は、予定されたバッチジョブによるものである可能性があります。また、RAM使用率の高いキャッシュサービスであっても、そのcgroupおよびその他のプロセスが十分に正常に動作し続けている限り、必ずしも原因とは限りません。.

cgroup v2 は、グローバルな視点にサービスやコンテナの境界を追加します。ストレージコントローラはイベントカウンタを提供します；; memory.events は階層的であるのに対し、 memory.events.local 各cgroupのローカルなイベントのみを表示します。これにより、問題が自身のサービス制限によるものか、それとも上位の構造における負荷によるものかを区別することができます。.

これらの基本事項だけでは、まだチューニングを行う根拠にはなりません。リミット、スワップ戦略、あるいはカーネルインターフェースを変更する前に、負荷の原因、cgroupの割り当て、および時間的な相関関係を整理しておく必要があります。 特に厳しいメモリ制限を設定すると、根本的な処理負荷のピークを解消するどころか、サービスを早期にダウンさせてしまう可能性があります。変更が技術的に適切な調整手段となるかどうかは、診断を行って初めて判明するものです。.

Multi-Gen LRUを重点的に検査する

Multi-Gen LRU は、以下の代替実装です。 ページ回収 これは、ここで取り上げるカーネルドキュメントにおいて、Linux 6.1以降で説明されています。メモリ不足の状況下では、カーネルはどのファイルキャッシュや匿名メモリページを回収できるかを判断する必要があります。 Multi-Gen LRUは、このためにページをアクセス経過時間に基づいて世代に分類し、アクセスパターンを考慮することで、頻繁にアクセスされるページがリクレイムの対象として選択される可能性を低減します。.

これは、PHP-FPMプール、データベース、キャッシュサービスが同時にRAMを消費している、負荷の高いWebホスティングサーバーにおいて重要な点です。 この機能は「Reclaim」時の選択を変更することはできますが、メモリの拡張でもなければ、応答時間の短縮を保証するものでもありません。処理負荷、RAM容量、スワップ、ストレージ容量、および各サービスのcgroup制限によって、効果が現れるかどうか、またその程度は依然として決まります。.

評価を行う前には、まずランタイムインターフェースが存在し、読み取り可能かどうかを確認してください。最新のカーネルドキュメントでは、このために以下の設定オプションが挙げられています。 CONFIG_LRU_GEN そして CONFIG_LRU_GEN_ENABLED および以下のパス /sys/kernel/mm/lru_gen/. ディストリビューションカーネルは、機能の状態を遡って移植したり、別の設定にしたりすることができるため、バージョン番号だけでは確かな証拠とはならない。.

test -r /sys/kernel/mm/lru_gen/enabled && cat /sys/kernel/mm/lru_gen/enabled

ある出力は、まず、文書化された sysfs インターフェースが存在し、読み取り可能であることを示すだけです。有効状態については、ビット値が重要です： 0x0001 これはMulti-Gen LRUのメインスイッチです。このビットが欠落している場合、インターフェースが利用可能であっても、ファイルにはメインスイッチがオフと表示されることがあります。その他のビットは追加コンポーネントに関するものです。また、メインビットがセットされている場合でも、本番環境で値を変更することを一般的に推奨するものではありません。.

したがって、sysfs への書き込みアクセスは標準的なチューニング手法ではありません。まず、Reclaim、スワップ、レイテンシ、cgroup イベントに関する時系列データを収集し、正当な理由に基づいて変更を行う場合は初期値を記録し、元に戻す方法を明確に定めておいてください。 そうすることで、観察された問題が実際に変化したのか、それとも単に複数の制御変数が同時に変動しただけなのかを、追跡可能にすることができます。.

特に、メモリ制限が厳しい上にサービスが過負荷になっている場合は、細心の注意を払う必要があります。リクレイムアルゴリズムを変更しても、PHPワーカープールのサイズが大きすぎる問題、不適切なデータベースキャッシュ、あるいは競合する顧客間の分離が不十分な状態は是正されません。 適切な手順は次の通りです。まず原因と影響を受けるcgroupを特定し、負荷を制限または分散させてから、利用可能なカーネル関数を影響要因として評価します。.

メモリの問題を確実に特定する

RAMの使用率は、それ自体ではエラーではありません。Linuxは空きメモリをファイルキャッシュとして意図的に利用しています。むしろ、要求が 直接リクレイム 実行中、スワップ活動が増加し、OOMイベントが発生したり、リクエストの処理速度が同時に低下したりします。非同期リクレイムによる kswapd バックグラウンドで実行されます。一方、直接的なリクレイムは、メモリを要求するタスクのコンテキスト内で実行されるため、そのタスクの実行を遅延させる可能性があります。.

イベントファイル memory.events イベントを階層的にカウントします。つまり、下位の cgroups も含みます。純粋にローカルなビューについては、 memory.events.local 準備はできている。 high は、以下の値を超えた場合の流量制限および即時リクレイムを表します。 memory.high, 、一方で oom cgroupの制限により割り当てに失敗しそうになったケースもカウントされます。. oom_kill 一方、このcgroupに属するプロセスで、何らかのOOMキラーによって終了させられたものはカウントされます。.

診断は、明確な特定から始めましょう。どのサービスやコンテナが問題のあるcgroupに属しているか、いつイベントが発生したか、そしてその際にどのようなアプリケーションのシグナルが見られたかを確認します。 その後、ローカルカウンターと階層型カウンター、システムログ、スワップ履歴、およびHTTPレイテンシ、データベースの待ち時間、エラー率などを比較してください。OOMが発生した場合は、データがcgroupに関連する現象を示しているのか、それともグローバルなメモリ不足の可能性を示唆しているのかをさらに明確にする必要があります。.

その価値 memory.max これは厳しいcgroup制限であり、最初の標準的な対策ではありません。制限値を厳しくするとクライアントを保護できますが、アプリケーションがOOM状態に陥る時期を早める可能性もあります。一方、制限値を高くすると、隣接するサービスでのリソース競合が激化する恐れがあります。 したがって、まずはワーカー数、キャッシュサイズ、負荷のピーク、およびcgroupの構造を確認してください。その後、根拠のある設定項目のみを、監視期間とロールバック計画を定めた上で変更してください。.

EEVDFとCPUの競合関係を理解する

最新の公式カーネルドキュメントでは、移行の開始時期を イーブイディーエフ Linux 6.6 では、「Earliest Eligible Virtual Deadline First」方式が採用され、通常かつ公平にスケジューリングされたタスクの選択方法が変更されました。この方式では、仮想実行時間、理想的な分布からの乖離であるラグ、および仮想期限が考慮されます。これにより、有効なタスクのうち、仮想期限が最も早いものが最初に CPU 時間を割り当てられるようになります。.

「移行」という表現は重要です。EEVDFは、フェアスケジューリングクラスの選択決定に取って代わるものではなく、歴史的にCFSと呼ばれてきたデータ構造、インターフェース、概念がすべて消滅するわけではありません。 現在のドキュメントでも、EEVDFは依然としてCFSと比較されています。したがって、具体的なディストリビューションカーネルについては、単に 6.6 あるいはそれ以上の場合、完全に一貫した挙動であると推測できる。.

ホスティングにおいて、この変更はとりわけ混合負荷の場合に重要となります。例えば、Webリクエスト、データベース処理、モニタリングが、インポート、圧縮、バックアップなどとリソースを競合させることになります。 カーネルバージョン間でレイテンシのプロファイルが異なる可能性はありますが、それが必ずしも総スループットの向上につながるわけではありません。常にフル稼働しているコア、ブロックされたプロセス、I/Oの待ち時間、不適切なアプリケーション設定といった問題は、スケジューラでは解決できません。.

運用上の分離は、引き続きサービスおよびプラットフォームの境界に基づいて行われます。CPUウェイトは競合時の相対的な配分に影響を与える一方、割り当て量によって利用可能な計算時間が制限される場合があります。 レイテンシが重要なWebトラフィックを大規模なバッチジョブから確実に分離する必要がある場合は、専用のVMや別のホストを用意することも適切である。EEVDFはこれらに取って代わるものである。 リソース計画 ではない。.

から取得する前に cgroup.controllers cgroup v2 がマウントされているかどうか、またどこにマウントされているかを確認する必要があります。以下の読み取り専用プロセスでは、通常のパスではなく、cgroup v2 のマウントポイントを検索します。 /sys/fs/cgroup と想定する。純粋な cgroup-v1 システムでは、この変数は空のままとなる。ハイブリッド階層の場合、この変数には検出された v2 マウントのみが表示される。.

uname -r
findmnt -t cgroup2 -o TARGET,FSTYPE,OPTIONS
CG2=$(findmnt -n -t cgroup2 -o TARGET | head -n 1)
if [ -n "$CG2" ] && [ -r "$CG2/cgroup.controllers" ]; then
    printf 'cgroup-v2 mount: %s\n' "$CG2"
    cat "$CG2/cgroup.controllers"
    test -r "$CG2/cgroup.subtree_control" && cat "$CG2/cgroup.subtree_control"
fi
systemd-cgtop

uname -r 現在のリリース文字列のみを指します。. cgroup.controllers この特定のcgroupで有効化可能なコントローラーを一覧表示します。ただし、それらが関連するサブ階層で有効化されていることを保証するものではありません。その確認には、とりわけ cgroup.subtree_control 各階層レベルで確認する必要があります。コントローラーはトップダウン方式で承認されるため、子cgroupは親ノードから提供されたコントローラーのみを引き継ぐことができます。.

systemd-cgtop これもあくまでその時点の状況を示すに過ぎず、原因分析にはなりません。サービスグループごとのCPU使用率、リクエストのレイテンシ、バッチジョブの実行時間、および必要に応じてI/Oの待機時間を、複数の同等の負荷局面にわたって収集してください。 遅延がバックアップ中にのみ発生する場合は、その実行時間枠、CPU使用率、または割り当て量を調整する方が、スケジューラのチューニングを推測するよりも、多くの場合、より具体的な最初の対策となります。.

専門職向けのランドロック

LandlockはLinux 5.13で初めて導入されたため、6.xシリーズの独自の機能というわけではありません。6.xカーネルでは、リリースやディストリビューションのカーネルによって、さまざまな拡張ABIレベルが利用可能です。 この機能は、プロセスが自らをさらに制限できるようにする、補完的なセキュリティメカニズムです。.

Landlockは、積み重ね可能なLinuxセキュリティモジュールとして、既存のアクセス制御に加え機能します。Unixのファイル権限やSELinux、AppArmor、ネームスペース、コンテナに取って代わるものではありません。ルールは、ファイルシステムへのアクセスを制限するなどすることができ、その後起動される子プロセスにも引き継がれます。 実際に利用可能な機能の範囲は、利用可能なABIおよびカーネルの設定によって異なります。.

理にかなっているのは 内陸国 とりわけ、自社開発または意図的に選定された個別のプロセスにおいて。顧客からのアップロード用コンバーターは、入力フォルダからのみファイルを読み取り、結果は出力フォルダにのみ書き込むように制限できます。 たとえサービスの処理に不具合が生じたとしても、SSHキーやアプリケーションの機密情報、一般的なシステムパスを読み取ることができないようにする必要があります。この制限は、慎重な権限付与を補完するものであり、それを不要にするものではありません。.

生産的なルールは、現在のカーネルのみに基づいて策定してはならない。 LandlockにはABIバージョンが存在します。アプリケーションは実行時に利用可能なABIを照会し、そのABIがサポートするアクセス権や関数のみを要求する必要があります。これにより、利用できないインターフェースのために完全に動作不能になることなく、古いシステムでも段階的に動作させることができます。.

それとは別に、 handled_access_fs ルールセットがどのファイルシステムへのアクセスを処理し、該当するルールがない場合はデフォルトで拒否するかを明示的に規定します。アプリケーションとカーネル間のこの明確な契約により、システムの更新だけでサンドボックスの制限が知らぬ間に厳しくなり、その結果アプリケーションが動作しなくなることを防ぎます。 したがって、ABIクエリと明示的に扱われる権限は密接に関連していますが、それぞれ異なる互換性の課題を解決するものです。.

ファイルコンバーターについては、以下の段階的な導入手順が導き出されます。実際の処理フローから必要な読み取りディレクトリ、書き込みディレクトリ、および作業ディレクトリを特定し、エラー発生時の処理経路を考慮した上で、まずはステージング環境で検証を行います。 簡潔なポリシー例だけでは、堅牢な本番環境の構成にはなりません。一時ファイル、外部ライブラリ、起動されたユーティリティプログラムなどが、さらなるアクセスを必要とする可能性があるためです。サービスの分離に関するさらなる対策については、以下の記事でも取り上げられています。 ホスティングサーバー向けのカーネル強化.

特に注意が必要な場合は、 OverlayFS. オーバーレイ層のルールは、統合されたマウント階層を自動的に制限するわけではなく、その逆も同様です。 そのため、オーバーレイを使用するコンテナ環境やビルド環境では、具体的なマウントやアクセスパスについて個別に検証する必要があります。Landlockはそこで追加のレイヤーとして活用できる可能性がありますが、画一的なテナント分離ではなく、堅牢なコンテナや権限管理の仕組みの代わりとなるものではありません。.

DAMON：特別な場合にのみ

DAMONおよびそれに基づくReclaimメカニズムは、Linux 6.xで初めて導入された機能として一概に分類することはできません。 管理者にとって重要なのは、実際に導入されている6.xカーネルまたはディストリビューションカーネルの機能状態である。DAMONは、メモリアクセスを監視し、その使用状況に基づいて領域を分類することを目的としている。.

これを踏まえて、～を試みている DAMON_RECLAIM, 、長期間使用されていないメモリ領域を、わずかな負荷をかけることで能動的に回収する。この手法は、通常のLRUベースの回収を補完するものであり、それに取って代わるものではない。カーネルのドキュメントでは、これを一般的なオーバーブッキングされたメモリシステムに分類しており、例としてフリーページ・レポーティングに基づく仮想化を挙げている。.

この仮想化シナリオでは、レイヤーが鍵となります。ゲストはホストに対して空きメモリページを報告し、ホストはその空きページを他のゲストに割り当てることができます。ゲストが、長期間使用されていないページを保持しているにもかかわらず、空きメモリをほとんど報告しない場合、プロアクティブなリクレイムが有効になります。 ゲストとして ホストに対して空きページをより多く報告するのに役立つ。したがって、DAMON_RECLAIM は、それ自体だけでは、ゲストの未使用メモリに対するホスト側の解決策とはならない。.

したがって、単一のWebサーバーやデータベースサーバーに対しては、これは標準的な対策ではありません。 仮想化環境においても、まずどのレベルで負荷が発生しているのか、また実際に長期間未使用の領域が原因であるのかを確認する必要があります。CPUのボトルネック、ストレージの速度低下、不適切なcgroupの制限、あるいはアクティブなアプリケーションキャッシュなどが、同様の症状を引き起こす可能性があり、そのような場合には、プロアクティブなリクレイムが適切な解決策とは限りません。.

クォータ、年齢制限、およびウォーターマークは、DAMON_RECLAIM がいつ、どの程度動作するかを制御します。これらは転用可能なデフォルト値ではありません。選択基準が厳しすぎると、有用なファイルキャッシュや繰り返し必要となるメモリページが早期に追い出されてしまう可能性があります。 その結果、名目上の空きメモリが増加しているにもかかわらず、追加のI/O操作が発生したり、再処理のためにCPU時間を消費したりする可能性があります。.

したがって、確固たる判断を下すには、ゲストが報告した空きストレージ容量、リクレイム活動、スワップ動作、ストレージのレイテンシ、アプリケーションの応答時間など、明確な比較基準を用いた測定が必要です。 変更内容はまず、同様のステージング環境でテストし、元に戻す手順を確立した上で、代表的な負荷フェーズにわたってその挙動を観察してください。これらの前提条件が満たされていない場合、またはストレージ負荷の原因が不明な場合は、DAMONは意図的に無効化されたままとなります。.

アップデート、ライブパッチ適用、再起動

カーネルのメンテナンスは、セキュリティ通知、インストール済みのパッケージ、および実際に実行中のカーネルを照合することから始まります。その後、使用しているディストリビューションの注意事項を確認し、そのカーネルブランチに対してどのような修正が提供されているか、また再起動が必要かどうかを確認してください。 6.x シリーズのバージョン番号が高いという事実だけでは、そのカーネルにパッチが適用されていることや、適切なライブパッチが利用可能であることを保証するものではありません。セキュリティ修正は、古いディストリビューションのカーネルにも遡及して適用される場合があります。.

また ライブパッチング この概念は、Linux 6.x で初めて導入されたものではありません。 6.xカーネルに関連するインフラストラクチャにより、特定のカーネル変更を実行時に適用することが可能になります。累積的なライブパッチでは、古いパッチを新しいパッチでアトミックに置き換えることができます。文書化されている制限事項には、状態の変化、コールバック、およびパッチ間の切り替えなどが含まれます。.

特定のディストリビューションカーネルに対して適切なライブパッチが用意されているかどうかは、各提供内容およびプロバイダーの承認状況に基づいて確認する必要があります。 一般的なカーネルインフラストラクチャの性質上、すべてのセキュリティ修正がライブで利用可能であるとは限らず、また、適用されたパッチがカーネルの完全なアップデートを恒久的に置き換えるわけでもありません。したがって、引き続き定期的なメンテナンス時間を確保するようにしてください。.

まず、アップデートの緊急度と影響度を評価し、次にパッケージの状態と現在実行中のカーネルを照合して、具体的なライブパッチの提案を確認してください。 通常のカーネル更新と再起動を行った後、期待通りのカーネルが稼働しているか、また重要なサービス、ネットワークパス、バックアップ、監視機能が正しく動作しているかを確認してください。この確認作業はメンテナンス手順の一部であり、単にサーバーにアクセスできるかどうかだけで判断すべきではありません。.

A 予定されている再起動 ライブパッチを適用しても、依然として必要となる場合があります。カーネルの起動パラメータの変更は、通常、次回の起動時に初めて有効になります。 一方、ドライバ、デバイスファームウェア、およびハードウェアについては、その対処方法はコンポーネントの種類、組み込み方法、およびメーカーの仕様によって異なります。モジュール、デバイス、またはサービスの再起動で済む場合もあれば、ホストの完全な再起動が必要な場合もあります。.

以下のテーマに関する補足記事 AlmaLinuxサーバーでのライブパッチ適用 ここでは、特定のディストリビューションに依存した実装について扱っています。このような手順を、検証せずに他のカーネルブランチやベンダーに適用しないでください。実際に使用しているプラットフォームのパッケージ、サポートされているカーネルバージョン、および運用上の注意事項が基準となります。.

• 観察された不具合について、まだ明確な原因が特定されていない場合は、意図的に何も変更しないこと。.
• 適切なステージングテストと、文書化されたロールバック手順が確立されていない限り、ライブパッチやカーネルの変更を計画してはならない。.
• 対象となるアプリケーションやプラットフォームがそのインターフェースを使用していない場合は、その機能を有効にしないでください。.
• メンテナンスウィンドウがないからといって、「ライブパッチングでカーネルの更新はすべて対応できる」という前提で代用してはならない。.