アダプティブLinuxプラットフォームでLinuxディストリビューションに革命を起こす
Linuxディストリビューションの最適なライフサイクル
Linuxディストリビューションの現状に挑戦し、業界における課題に対応する新バージョンを発表する時がきました。SUSEのAdaptable Linux Platform(ALP)テクノロジーをベースにした、クラウドネイティブのワークロード向けに設計されたコンテナLinuxディストリビューションです。
DebianとSlackwareは30年前に、そして、SUSE Linuxはその直後の1994年に誕生しました。この間、いくつかの企業がサポート付きバージョンのLinuxを提供してきましたが、その他のディストリビューションには、どのような目的でも無料で利用できるものもありました。Linuxを使用している企業であれ、問題が発生したときに電話できる相手がいることは有益(または必要)です。さらに証明書があれば、使用するハードウェアとソフトウェアが大きな問題なく正しく動作するという合理的な自信を与えてくれます。
S.u.S.E.
何十年もの間、アプリケーションはこのようなシステム上で動いてきました。簡単に解決できるような問題はほとんどなかったのです。今日の技術革新の多くは、エンジニアの努力なしには実現しなかったでしょう。エンジニアは、非常に安定した環境を提供し、多くの場合、新しいバージョンのコードを見て、あなたが実行しているバージョンに移植もしてくれました。
現在、イノベーションにはこれまでとは異なるスピードが求められています。例えば、Kubernetesのリリースはおよそ4カ月ごとに作成され、1年間サポートされます。すべてを実現するには、基盤となるOSのコンポーネントやバージョンを含む非常に複雑なサポートマトリックスが必要となります。
OSとは?
TannenbaumによるOSの定義を見てみましょう。
「OSとは、接続されているハードウェアを管理し、アプリケーションプログラムに対してそれらのリソースをきれいに抽象化したものを提供するコンポーネントである」。
しかし、Linuxディストリビューションはそれ以上のものです。もちろん、ハードウェアを有効にし、最新バージョンのカーネルやglibc(LinuxなどのPOSIX標準に従うユーザーに提供されるAPI)と互換性を持たせるタスクは多いです。しかし、APIにアクセスできるようにするツールは他にもあります。例えば、APIを直接呼び出すことなくネットワークカードを設定できるようにすることです。
その上、Linuxディストリビューションは、インターネットが今日ほど発達していなかった時代に作られたため(今日、64Kモデムを使ってウェブに接続してみてください)、メールクライアントからフォトエディターまで、多くのアプリケーションが含まれています。何かをダウンロードするのに何日もかかるような時代にはありがたいことですが、もちろん、数ヶ月後に再インストールしたときに最新のアップデートやバージョンが提供されるわけではないので、インストール後の最初のアクションは通常、(インターネットに接続していれば)フルアップデートです。エンタープライズ向けディストリビューションも実際には同じモデルを使用しているので、たとえ誰も使用していなくても、多くのアプリケーションを提供していました。
何が問題なのか?
広範なアプリケーション(CRM、ERP、データウェアハウスなど)のインストールには、カスタマイズや統合だけでなく、慎重な計画を練る必要があります。デプロイされるすべての部分が認証され、互換性があることを確認する必要があります。つまり、ベンダーはオペレーティングシステムやデータベースなどの異なるバージョンに対してアプリケーションをテストする必要があります。
こうしたアプリケーションを頻繁に変更することはありません。(例えば、最新の課金システムに移行するリスクが高すぎるため、10種類の課金システムを持つ電話会社を私は知っています) また、業界によっては規制が厳しく、どのようなソフトウェアでもサポート契約が必要な場合もあります。このような理由から、多くのベンダーは、数年間の標準サポートの後に長期サポートを提供しています。このサポートでは、基本的にドキュメントを読んでアドバイスを求めたり、影響度の高い脆弱性の修正を提供したりすることができますが、製品への投資は大きく制限され、チケットを開いて修正やバックポートを取得できるケースは少なくなります。
なぜバックポートなのか?通常、パッチはリファクタリングやコードの更新とともに、まず最新バージョン用にオープンソースで開発されます。最新バージョンにアップグレードできなければ、必要なパッチを手に入れることはできません。ベンダーは、最新バージョンを調べることで、現行バージョンのバグに対する解決策を見つけようとします。もしそこに修正があれば、古いコードベースで動くようにパッチをアップグレードすることが可能かどうかを確認します。適切なパッチがあったとしても、このプロセスには入念な調査とテストが必要で、コストがかかり、うまくいかないこともあります(コードのリエンジニアリング後にバグが消えた場合など)。
Linuxディストリビューションの主な価値の1つは、こうしたアプリケーションに必要な安定性を提供することですが、そのためには(適切に行われた場合)、同じパッケージの異なるバージョンを維持するために多くのリソースが必要になります。その上、ディストリビューションの中には、セキュリティ認証、つまりコードが安全であることを第三者が検証するものもあり、Common CriteriaやFIPS認証(クレジットカード取引のPCI-DSSなど)が必要な場合でも、ワークロードを実行できることを保証してくれます。
数十年にわたるLinuxディストリビューションのサポート契約には、次のようなものが含まれます:
ハードウェアのサポートと認証: オペレーティングシステム(OS)は主に、ハードウェアの抽象化を促進し、ハードウェアコンポーネントをソフトウェアとシームレスに連携させることと、システムリソースを効率的に管理することの2つの重要な機能を果たします。OSのリリース時には、さまざまなハードウェア構成に対して大規模なテストや認証が行われます。互換性リストは、ハードウェアメーカーとOSベンダーの関係が影響します。互換性は、LinuxカーネルのバージョンやOSに含まれるライブラリなどの要素にも大きく依存します。時間の経過とともに、ハードウェアとソフトウェアの組み合わせが互換性を保つことを保証することは、特に新しいハードウェアコンポーネントの導入に伴い、ますます難しくなっています。
バグの解決:すべてのコードにはバグがあり、アプリケーションの新しいバージョンは、新機能の追加やバグの修正のために常にリリースされます。ほとんどの場合、パッチは後にアップストリームにも配信され、標準コードの一部になります。
アップデート: ソフトウェアが安全な場所からダウンロードされていることを確認したいですか?ディストリビューションには、セキュアなワークフローで作成・公開されたパッケージのセレクションが含まれています。
セキュリティ修正:コードには常にバグがありますが、セキュリティの問題はあなたのマシンを危険にさらします。セキュリティコードに欠陥があると、システムに不正アクセスされ、本来は不可能なはずの情報を取得されたり変更されたりする可能性があります。
技術サポート:問題を特定し、解決策を見つけ、問題解決に必要なパッチをインストールして設定するための知識を提供します。
ドキュメンテーション:ソフトウェアのインストールやアップグレードに必要なドキュメントを見つけることが問題になることがあります。
問題なさそうですが…
当時、顧客のアプリケーション開発には何年もかかり、とにかく完全な安定性が必要でした。しかし今、スクラムとアジャイルは、自動化されたビルド、テスト、デプロイメントによって、1日に数回新しいバージョンを作成し、できるだけ頻繁に本番環境にデプロイできるようになりました。テクノロジーは更新され、環境を作るのに何週間も何ヶ月もかかってましたが、数分でVMを作成し、すべての作業の準備を整えることができる自動化されたシステムや、gitリポジトリで公開されるとすぐに自動的にデプロイされたコードを更新することができるようになりました。
では、何が問題なのか?それは、”依存性地獄 “と呼ばれるほど大きな問題です。
- 時には、テストもアップデートもされていない、つまりコアセットに含まれていないバージョンのパッケージが必要になることがあります。OSの新バージョンがリリースされるまで待つこともできますが、それには何ヶ月もかかりますし、古いバージョンを使えるようにX機能を書き換えることは技術的負債を生むので、選択肢には入りません。
- 多くの場合、アップストリームプロジェクトのスピードで安全にパッケージをアップデートする現実的な方法はありません。特に、要件にパッチ作成が含まれている場合はより難しくなります。
- 競合する依存関係が見つかる可能性があります。依存関係は、ライブラリやパッケージのバージョンを必要とします。 別のバージョン2.一緒にインストールすることができないので、どのバージョンが必要かを決定し、依存関係ツリーを修正することを余儀なくされます。
- 場合によっては、依存関係を作ったプロジェクトが放棄されたり、適切にメンテナンスされなかったりします。そのような依存関係を使ったアプリケーションは壊れたり、セキュリティ問題を引き起こしたりします。
私たちはこの問題を簡単に解決できるでしょうか?パッケージの「セマンティックバージョニング」でバージョン番号をつけ、依存関係を適切に解決できるスマートなパッケージ管理システムを使うことで、これまで行われてきたように問題を軽減することができます。ディストリビューションの一部であるパッケージには、他のすべてのパッケージと互換性を持たせるために多くの努力が払われており、あるバージョンから別のバージョンへのパッチのバックポートさえ行われています。
より良い方法
ディストリビューションに含まれるパッケージの数を減らし、アプリケーションをどこかでダウンロードする必要があるようにし、(MacOSがそうであるように)開発者にアップデートの責任を負わせることで、依存性の問題を減らすことができます。数年後、開発者が活動していなければ、運がなかったことになりますが。しかし、それではディストリビューションの価値も下がってしまいます。
コンテナによって、新しいソリューションが登場しました。コンテナを使えば、依存関係をアプリケーション自体と一緒にパッケージすることができます。ライブラリや依存関係が他のすべてのアプリケーションと互換性を持つ必要がなくなれば、各アプリケーションがそれらの依存関係を独自のバージョンに含めることができる限り、適切な依存関係ツリーに到達するのはずっと簡単になります。
しかし、コンテナを大規模に使用するには無料ではできません。今日、ほとんどの企業はKubernetesを使用しており、アプリケーションをデプロイするために新たな抽象化を必要としています。Kubernetesは複雑で、スケーラブルに設計されたマイクロサービスを使っていない多くのアプリケーションにとっては、やりすぎになる可能性があります。しかし、従来のLinuxで行われてきた方法ではなく、コンテナでアプリケーションをパッケージ化して提供できるとしたらどうでしょうか?
- ハードウェアの抽象化レイヤーを最小限に減らすことができます。コアレイヤーの認証と安定性を維持し、ハードウェアが動作していることを確認します。
- そして、アプリケーションとライブラリをコンテナとして提供します。依存関係を減らすことで、コンテナ内にインストールされる依存関係の異なるバージョンを、競合する要件なしに利用できるようになります。問題を管理可能なまで、縮小します。
- そのため、異なるバージョンのアプリケーションを提供し、必要なバージョンの依存関係に対してのみテストとサポートを行うことができます。依存性地獄がなくなり、バックポートの必要性が非常に制限されるため、すべてを簡単に提供できるようになります。
- 自動化とセルフヒーリングによって、アプリケーションの作業中にOSのことを考える必要がないほど簡単に管理できるようにすることができます。
新しいライフサイクル
新しいOSは、コアとアプリケーションのライフサイクルを明確にし、戦略的最適化の機会を提供します:
コアコンポーネントの俊敏性の向上:
- OSのコアコンポーネントをアプリケーションとの依存関係から解放することで、ハードウェアと連動するコンポーネントやライブラリの頻繁な更新が可能になります。最大18ヶ月に及ぶ認証スケジュールと、様々なアーキテクチャ(ARM、Intel、AMP、IBMなど)の新しいハードウェア機能を統合する必要性とのバランスを取ることが重要になります。また、リーズナブルなコストでソリューションを提供することが簡単になります。
- OSにとっては、ワークロードのAPI互換性を維持することで、アップデートのたびにシームレスな移行を保証することが不可欠です。現在では、OSコンポーネントへのハードな依存がないため、より簡単かつ迅速に移行できます。
柔軟なアプリケーションサポート:
- コンテンツをOSから切り離すことで、異なるコンポーネントに異なるサポートを提供することができます。複数のバージョンを同時に利用できます。限定的なサポートで開発用に必要であれば、ベータ版であっても最新バージョンを使用することができ、一方で、より安定したバージョンで古いバージョンのアプリケーションをサポートすることができます。
長期サポートの延長オプション:
- コミュニティが提供する長期サポートにとどまらず、OSプロバイダーは重要なコンポーネントのサポートを必要な限り延長することができます。これにより、重要なシステムの安定性を強化しながらも、同時にすべてのコンポーネントやライブラリにそれを強制することなく、長期的な安定性を必要とするアプリケーションが信頼できるプラットフォームを利用できるようになります。
コンパートメント化されたソリューション:
- OSのモジュール性により、特定のユースケースに合わせたソリューションの構築が可能になります。新しいハイパーバイザーを導入する場合でも、機密性の高いAIワークロード用の最先端コンポーネントを新しいチップセットに統合する場合でも、この区分化により、独自の要件を満たすための的確なカスタマイズが可能になります。
- 特定のユースケースへの対応は、OSが進化する技術的要求に適応可能な汎用性の高い基盤として機能することで、より俊敏かつ効率的になります。
では、これを利用できますか?
はい、利用可能です。このソリューションは、SUSEが開発したAdaptable Linux Platformであり、何年も前から開発が進められてきた新しいプラットフォームとコードベースです。
いくつかの部分は現在利用可能で、何年も前から製品化されています(SLE Microなど)が、SUSEはデータセンター向けの包括的なソリューションから一歩進んでいます。この包括的なソリューションには、OSと、OSフレームワーク内で認証済みコンテナを構築・実行するための必須ツールが含まれています。
目立たないOSとして機能するように設計されており、楽に管理でき、使いやすく、展開しやすいように設計されています。この新しいプラットフォームは、dhcpdデーモンやApache httpサーバーなど、利用可能であることが期待されているおなじみのLinuxサーバーコンポーネントをシームレスに統合しています。私たちの使命は、サポートと俊敏性を同時に具現化するプラットフォームを提供することです。私たちは、お客様が必要とするコンポーネントを提供することを目指しています。お客様がバージョンをカスタマイズできるようにします。そのため、SUSEに基盤となるOSのセキュリティとサポートを任せながら、収益創出に専念することができます。
今すぐソリューションをダウンロードしてください。そして、ぜひフィードバックをお寄せください。オープンソースを使用し、このプラットフォームをさらに強化する方法を共に探求しましょう。皆様の洞察と経験は、真に皆様のニーズに沿った製品を形作る上で非常に貴重です。
ALP: Adaptable Linux Platform
SUSE’s Adaptable Linux Platform allow developers focus on the workloads while keeping independent from the hardware an…susealp.io
https://adaptablelinuxplatform.io/
引用
Modern Operating Systems. Andrew S. Tanenbaum et all.
https://www.pearson.com/en-us/subject-catalog/p/modern-operating-systems/P200000003311/9780133591620?tab=title-overview
SUSEサポートポリシー
Product Lifecycle Support Policies | SUSE
Choose a product from the list below to read more about its unique support policies.www.suse.com
TSANet has 25+ years experience creating collaborative platforms for 100’s of Vendor…tsanet.org
Related Articles
1月 19th, 2024
OWASP Kubernetesのセキュリティ管理、トップ10
11月 17th, 2024
エンタープライズグレードの可観測性をAIワークロードへ
7月 31st, 2024
RKEが2025年7月にサポート終了 – RKE2またはK3Sへの移行について
5月 19th, 2023