長期サポートリリースの再考

伝統的に、長期サポートのオペレーティングシステムリリースはエンタープライズ展開の要でした。これはIBM、Oracle、Microsoft、Suse、Red Hatが採用しているモデルであり、数十年前にサポート提供が始まって以来、オペレーティングシステムに関する従来の考え方となってきました。

過去には、サーバーとデスクトップの両方のオペレーティングシステムリリースがこのモデルに従うことが一般的でしたが、Linux空間では特に、より非公式な製品がより急速な、サポートなしの、または単純に構造化されていないリリースを試みる自由があり、この状況が変化し始めました。主要製品の空間では、openSuse、Fedora、Ubuntuがすべて短期サポートのリリースまたは急速リリースのサービスを提供しました。年単位で測られるリリースサイクルと10年近くに迫るサポートサイクルの代わりに、リリースサイクルを数ヶ月に短縮し、サポートも数ヶ月から数年程度に短縮しました。

デスクトップ空間では、サーバーで一般的だった安定性を主に重視するのではなく、新しい機能やアプリケーションをより早く入手することが合理的であることが多く、新技術やアプローチを長期サポートのサーバー製品に統合する前に、より速いリリースサイクルの製品でテストできるという追加の利点ももたらしました。たとえば、FedoraはRed Hat Enterprise Linuxのリリースに自らを証明した後に取り込まれる技術の実証の場です。Fedoraを使用することで、エンドユーザーはより早く機能を入手し、RHELの技術をより早く学ぶことができ、Red Hatは重要なサーバーに展開する前に大規模に製品をテストすることができます。

時間が経つにつれて、短期リリースの安定性は劇的に向上し、これらのシステムはサーバーシステムの有力な選択肢と見なされるようになっています。これらのシステムは新しい機能強化、機能、アップグレードをより早く入手できることが多く、これはしばしば有益と見なされます。

あらゆるオペレーティングシステムの主要な利点の一つは、ベースオペレーティングシステムの一部としてサポートされ提供されるパッケージやライブラリを含むサポートエコシステムです。長期リリースでは、リリースの寿命にわたって重要なパッケージが大幅に古くなることがよく見られ、これは極端な場合にはパフォーマンス、互換性、さらにはセキュリティの問題を引き起こす可能性があります。これは明らかに、長期リリースのオペレーティングシステムのユーザーに、古いコンポーネントの制限の中で生き続けることと、自分で新しいコンポーネントを統合すること（これはしばしば長期リリース製品の根本的な価値を壊します）のどちらかを選択させることになります。

長期リリースの目標が安定性と統合テストにあるため、LTSの制限を「回避する」ために製品内のコンポーネントを置き換えることは、それらのコンポーネントがLTS方式で扱われていないことを意味し、ベンダーからの統合テストがもはや行われていない、または少なくとも同程度には行われていない可能性が高いことを意味します。実質的に何が起こるかというと、これはレガシーのコアコンポーネントと監視の減少を持つ自己構築の短期リリース製品になるということです。

現実には、ほとんどの面で、これは短期リリース製品に直接移行するよりも悪い結果をもたらします。短期または急速リリース製品を使用することで、ベンダーは想定されるテストと統合を維持でき、ただリリースとサポートのサイクルが速くなるだけで、長期リリースの概念の一般的な価値が維持され、一部のコンポーネントだけでなくオペレーティングシステムのすべてのコンポーネントが更新されます。これにより、部分的なLTSモデルよりも多くの標準化、業界テスト、共有知識と統合が可能になります。

オペレーティングシステムの長期サポートの価値を再考する時期が来たのかもしれません。長い間、このアプローチの価値は単純に仮定され踏襲されてきたようです。確かにそれは持っており今でも持っているメリットがありますが、オペレーティングシステムの世界はこのアプローチが最初に導入されたときから変わりました。更新の必要性は増加しながら、カーネルやライブラリなどの変化率は大幅に低下しました。より強力なサーバーが互換性をスタックの上位に移動させ、ソフトウェアはOSに合わせて書かれるのではなく、しばしば特定バージョンの言語やランタイムまたは他の抽象化レイヤーに向けて書かれるようになっています。

より短いリリースサイクルは、システムがトップから底まで機能をより頻繁に入手することを意味します。「メジャー」リリース間の更新はより小さく、影響が少なくなります。更新による変化はより増分的であり、より自然な学習と適応の曲線を提供します。そして最も重要なことは、慎重にテストされ統合されたシステムコンポーネントをサードパーティ提供のバージョンに置き換える必要性が事実上なくなることです。

ソフトウェアベンダーにとっての安定性は長期リリースの価値であり続け、長期にわたって長期リリースを使用する必要があり続けます。しかしシステム管理者にとっては、このアプローチの価値は低下しているように見え、個人的には近年転換点を迎えたと感じています。以前は2年や3年パッケージの更新を待つことが当然で普通に思えましたが、今日これは不必要に煩わしく感じられます。上位レベルのコンポーネントがより新しい基盤コンポーネントを必要とするように構築されることがますます一般的になっています。オペレーティングシステムがより最新であるか、OSの一部がOSの残りの部分とは別に更新されることを期待するものです。

コンテナ化技術への大きな依存は、この傾向をある意味で逆転させるかもしれませんが、常に同時に長期リリースの価値を低下させる方法で行われます。コンテナ化はベースオペレーティングシステムの広範な機能の必要性を減らし、改善されたカーネル、ファイルシステム、ドライバー、コンテナサポートのためにより頻繁に更新することをより容易で効果的にし、コンテナ内のライブラリやその他の依存関係はそのままにして、長期サポートの依存関係を必要とするアプリケーションがその方法で満たされ、新しいコンポーネントから恩恵を受けられるアプリケーションはその方法で対処できるようにします。

もちろん仮想化は、システムの迅速な回復と複製を簡単にすることで長期サポートモデルの価値を低下させる役割を果たしてきました。長期サポートリリースで対処する必要があった安定性は、部分的に仮想化レイヤーによって対処されています。ハードウェアの抽象化は非常に重要な方法でドライバーの安定性を向上させます。同様に、DevOpsスタイルのサポートモデルも長期サポートの必要性を減らし、サーバーエコシステムをよりアジャイルで柔軟にします。システム管理のパラダイムのトレンドは、より現代的なオペレーティングシステムを好む方向に傾いています。

トレンドが現在向かっている方向に続くかどうかは時間が経てばわかるでしょう。私自身にとって、この過去1年は非常に目を開かせるものであり、10年間の非常に長い長期サポート製品への強力な支持から急速リリース製品への移行を行い、その変化に非常に満足していると言えます。