Google: UbuntuからDebianへの移行後、デスクトップLinuxリリースを展開するまでの経緯はこちらです。

Googleは「ビッグバン」OSアップグレードからローリングリリースに移行する利点を詳述しています。それはエンジニアの疲れ切るのを防ぎました。

数年前、GoogleはUbuntuベースのLinuxデスクトップからDebianへの移行を完了しました。現在、Googleはこの変更がLinuxデスクトップにおけるローリングリリースをもたらし、より迅速でスムーズなアップグレードや迅速なセキュリティパッチの適用に繋がったことを詳述しています。

Googleは内部デバイスのベースとして15年以上Ubuntuを使用した後、主要なOSアップグレードを2年ごとに回避し、アップグレード作業の負担を時間をかけて分散させるためにDebianに切り替えました。

グーグルは、ZDNetが当時報じたように、2018年に移行が完了したと発表しました。グーグルのエンジニア、マーガリータ・マンテロラは、グーグル独自のUbuntuであるGoobuntuから、Debian Testingに基づくローリングリリースのgLinuxに移行していると説明しました。これは、次の安定版Debianのベータ版です。

見よ：オープンソースの仕事はそこにある

Goobuntuからの移行に関与したデバイスの数を考えると大きな変化でしたが、UbuntuがDebianに基づいているため、パッケージ更新プロセスのいくつかの側面が似ているため、驚くべきことではありませんでした。

マンテローラ氏とグーグルの同僚エンジニア、コルディアン・ブルック氏とスヴェン・ミューラー氏は、同社がデスクトップ向けのローリングリリースをどのように実現したかを説明し、他の大企業がどのように同様のアップグレードシステムをデスクトップに実装できるかを詳述したブログ記事を発表しました。

彼らが指摘しているように、ローリングリリースに切り替える前は、すべてのOSサイクルで主要なパッケージに「かなり大きなバージョンのジャンプ」が発生し、それによりソフトウェアの設定に重要な変更が必要になることがありました。Googleは、アップグレードプロセスのほとんどを自動化しましたが、すべてではありませんでした。

Goobuntu艦隊のアップグレードにはほぼ1年を要し、OSサイクルのタイミングのため、大規模なプロセスはアップグレード後に「燃え尽きる寸前」のコアチームにとって終わりのないものでした。

「2年間のサポート期間があったため、次のLTSのために再び同じプロセスを繰り返さなければならないまで、あと1年しか残っていなかった。このプロセス全体は、私たちのチームにとって大きなストレス要因でした。コーナーケースの支援を求める数百のバグが寄せられました」と彼らは記述しています。

「一度アップグレードが完了すると、チームには『バーンアウトの手前』という一般的な感覚があり、次のアップデートが来るまでほとんど回復できませんでした。LTSバージョンを使用することは、私たちのディストリビューションのユーザーによって発見されたバグがすでに上流で修正されている可能性を意味しましたが、それらの改善はLTSバージョンにバックポートされていないこともありました。」

Googleは、エンジニアへの負担を軽減するために、2年ごとのアップグレードサイクルを廃止し、徐々に展開することを目指してgLinux Rodete（ロールデビアンテスティング）を設計しました。

彼らが指摘するように、ソフトウェア業界がCI/CD（継続的インテグレーション/継続的デリバリー）に一般的に移行していることは、小さなインクリメンタルな変更が制御しやすく、ロールバックしやすいことを示しています。同様の理由から、Arch LinuxやNixOSなどのLinuxディストリビューションもローリングリリースを実装しています。ローリングリリースのLinuxは、ユーザーと開発者が最新の更新やパッチを創造されるに従って提供されることで最も恩恵を受けるという考えのもと、常に更新されています。

Googleは、パッケージの利用可能性、大きなコミュニティ、そしてDebian形式の既存の内部パッケージとツールがあるため、Debianを選びました。Googleは、なぜStableではなくDebianのベータ版を選んだのかを説明しています。

「DebianのStableトラックはおおよそ2年ごとのリリースの間隔に従いますが、DebianのTestingトラックはローリングリリースとして機能します。これは、次のStableリリースが行われるのを待って、上流から取り込まれ、ビルドされたすべてのパッケージのプールだからです。」とGoogleのエンジニアたちは書いています。

Googleは最終的にOSアップデートの週次リリースに決定しましたが、当初はもっと頻繁にリリースする意図がありました。

新しいリリースが今日始まると、更新チームはその時点でDebianから取り込まれたパッケージのスナップショットを取得します。その後、Googleはそれを実行し、受け入れ、テストし、その後「慎重に」専用のテスト用と1％の全艦隊における「カナリア」に更新を展開します。カナリアは、DebianパッケージやGoogle内部パッケージの問題を検出するために数日間の猶予を与え、その後全艦隊に展開されます。

Googleは、ソースからの上流パッケージのビルドを管理するためにSieveというワークフローシステムも構築しています。Sieveには、ビルドプロセスやテストが失敗した場合にビルドを再試行するためのツールがあります。

Googleが得たセキュリティの利点の一つは、上流のDebianに置く「信頼の封筒」が減少したことです。

例えば、セキュリティインシデントの際に、私たちは迅速に再構築し、一時的なパッチで動作することに自信を持つことができます。なぜなら、私たちは以前にすべてのパッケージをビルドしており、それが私たちの配布に加わっているからです。

さらに、我々は上流のDebianに置かなければならない信頼のエンベロープと、彼らのインフラストラクチャによって生成されたバイナリビルドアーティファクトを削減しています。代わりに、ソースコードが取り込まれ、バイナリが検証可能にビルドされると、私たちはそのバイナリが正確にそのソースコードから由来していることを暗号的に証明できるようになります。

Googleは、「私たちの艦隊を上流のリリースにより近くで運用することによって、私たちのセキュリティの立場を劇的に改善した」とも述べています。

「Debianは安定版と旧安定版のトラックに対して良いセキュリティパッチを提供していますが、パッチがあるすべてのセキュリティホールに必ずしもDebianセキュリティアドバイザリー（DSA）やCVE番号があるとは限らないことに気付きました」とエンジニアたちは述べています。

私たちのローリングリリーススケジュールは、安定性を損なうことなく、迅速に全体のシステムのセキュリティホールを修正できるようにしています。一方で、以前はセキュリティエンジニアが各DSAを慎重にレビューし、修正が私たちのシステムに反映されていることを確認する必要がありました。

参照：ChromebookでLinuxを有効にする方法（およびその理由）

Googleは、上流のDebianとより密接に協力し、自社の内部パッチの多くを提供してDebianパッケージエコシステムを維持する計画があると述べています。

その会社は、ローリングリリースの導入を考えている他の企業にも「会社のニーズとアップグレードの柔軟性をバランスさせる」よう促しています。この変化がGoogleに確認させたのは、漸進的な変更がビッグバンリリースに勝るということです。

自分たちの動くターゲットとベースラインをコントロールすることが、問題が多すぎるときにスローダウンするのに役立ち、チームのサービスレベル目標を破らないようにしました。私たちの旅は、大規模なリリースよりも段階的な変更の方が管理しやすいという信念を確固たるものにしました。