#きょうのsystemd : 大きな神話

大きな神話

(原文: http://0pointer.de/blog/projects/the-biggest-myths.html *1はきれいに分割されており、これらは systemd の外でも非常に使い勝手の良いものである。

69の別個のバイナリーを必要とする1つのパッケージというのはモノリシックとはほとんど呼べないかもしれない。 しかしながら、それまでのソリューションと異なるのは、1つの tarball でより多くのコンポーネントを提供しており、上流では単一のリリースサイクルで、1つのレポジトリでこれらをメンテナンスしている点にある。

2. 神話: systemd はスピードが命である

systemd が速い(900msまででユーザースペースが完璧に起動し切る。他にある?)のはそうだが、これは主に物事を正しくおこなった副作用に過ぎない。 事実、我々はじっと腰を落ち着けて、 systemd の最後のほんのわずかなパフォーマンスを最適化したことはない。 代わりにやっていたのは、コードをより読みやすくするために、頻繁に、わずかに遅いコードパスを抜け目なくつまみ出すことだ。 これは、速いということが我々と無関係だったということを意味するのではないが、スピードのために systemd を軽量化することは、かなり間違ったことだ。 というのも、このことが我々の目標のリストの上らへんに来ることはなかったのだ。

3. 神話: systemd の高速なブートはサーバーには関係ない

これはまったく真実ではない。 多くの管理者はメンテナンスウィンドウでのダウンタイムの時間を減らすことに熱心だ。 HAのセットアップでは、フェイルしたマシンが本当に素早く戻ってくるなら、それは素敵なことだ。 クラウドのセットアップでは、VMやコンテナが多ければ、ブートが遅いゆえの価格はインスタンスの数だけ倍加される。 CPUおよびIOの時間が数百のVMやコンテナの遅いブートに費やされるなら、システムの集約度は劇的に落ちるし、費用もエネルギーもかかってしまう。 遅いブートは費用面で高く付くかもしれない。 そのため、コンテナの高速なブートはソケットアクティベートなコンテナのような実装を可能にする。 これは、クラウドシステムの集約度を劇的に控除させるものである。

もちろん、多くのサーバーのセットアップではブートアップはあまり関係ないかもしれない。 だけど、 systemd はすべての領域をカバーするように考えられている。 そして、そう、ブートアップ時にほとんどの時間を費やしているのはサーバーのファームウェアであることは私も気づいているし、OSはいつだって、それに比べたら速いのも知っている。 だけど、 systemd はすべての領域をカバーするように考えられているし、すべてのサーバーに良くないファームウェアが載っているわけではないし、サーバーの一種である、VMやコンテナもそうじゃない((また、我々はこれをより良くするかもしれないと思って、ちょっとしたことをやろうとしている。ファームウェアのブートタイムパフォーマンスが、 systemd のブートの結果でより明らかになって、ファームウェアのライターたちが恥ずかしがって、彼らの作ったものをきれいにしてくれるんじゃないかと期待している。)))。

4. 神話: systemdはシェルスクリプトと互換性がない

これも真っ赤な嘘だ。我々はシェルスクリプトをブートプロセスでは使わない。というのも、特定の目的にとって、シェルスクリプトはベストなツールとは言えないと思っているからだ。 だけど、このことと systemd がシェルスクリプトと互換性がないというのは違う。 シェルスクリプトを簡単に systemd のサービスとして動かすことはできるし、いかなる言語で書かれたスクリプトであっても、 systemd のサービスとして動かすことができる。 systemd は用意された実行可能ファイルの中身がなんであるかなんて、一切気にしない。 さらに言えば、我々は自分たちの目的のために、シェルスクリプトをヘビーに使っている。systemd のインストールやビルド、テストにだ。 さらに、自分で作ったスクリプトをブートプロセスの初期に挟み込んだり、それを通常のサービスに使ったり、シャットダウンの最後に使ったりと、事実上、制限はない。

5. 神話: systemd は難しい

これも全くのナンセンスだ。 systemd のプラットフォームというものは、伝統的なLinuxよりも実際、非常にシンプルなものだ。 というのも、 systemd はシステムのオブジェクトおよび依存関係を systemd のユニットとして統一するものであるからだ。 設定ファイルの言語は非常にシンプルだし、冗長な設定ファイルは我々が取り除いた。 我々が提供するのはシステムの多くの設定に使える、統一的なツールである。 このシステムは伝統的なLinuxよりも非常に礫岩性の低いものだ。 また、我々は非常に包括的なドキュメント(すべてホームページからリンクされている)を systemd の非常に詳細な部分についても提供している。 これは、管理者やユーザーが触れるインターフェイスのみではなく、開発者のAPIについてもカバーしている。

systemd はもちろん、ある学習曲線を伴うものだ。何でもそうだ。 だけど、殆どの人間にとって、シェルスクリプトベースのブートよりも、 systemd を理解することのほうが実際には簡単であると我々は思っている。 こう言ったら驚くんだろうか? さて、 systemd が追い出したように、シェルスクリプトは学ぶには良い言語とは言えない。分布はわかりにくいし、複雑だ。 systemd のユニットファイルは実質的によりわかりやすいし、プログラミング言語が出てくるのではなく、本来より、シンプルで declarative である。 すべて言ったが、シェルの経験があるなら、そう systemd を受け入れるにはちょっと勉強するだけでいいだろう。

学習を簡単にするため、我々は以前のソリューションに対して、最大限の互換性を与えるよう努力してきた。 だけど、このことだけじゃなく、多くのディストリビューションで、いくつかの伝統的なツールが -- 要求に応じて実行されている一方で -- ひょっとしたらよりよい方法で、より新しいツールをかわりに使う方法を伝えてきさえすることに気づくだろう。 ((訳者注: なんか翻訳が厳しい。原文は "But not only that, on many distributions you'll find that some of the traditional tools will now even tell you -- while executing what you are asking for -- how you could do it with the newer tools instead, in a possibly nicer way." イメージとしては、service your_service stop が systemctl stop your_service にリダイレクトされる感じだと思った。))

ともかく、持ち帰れるのはたぶん、 systemd は可能な限りシンプルであろうこと、そして、我々は systemd を学習しやすいようにするため努力しているということだ。 だけど、もし sysvinit を知っているなら、 systemd を受け入れるのに、ちょっと学習が必要だろうが、本当に率直に言うと、 sysvinit をマスターしているなら、 systemd は簡単なはずだ。

6. 神話: systemd はモジュラーではない

これもまったく違う。 コンパイル時には数多くの configure のスイッチがあり、何をビルドして、何をビルドしたくないかを選べる。 そして我々がドキュメントに記していることだが、我々の configure スイッチを超えて、より詳細に、必要なものを選ぶことができる。

このモジュラリティはLinuxカーネルのものとは全然違うということはない。Linuxカーネルの場合は、コンパイル時に多くの機能を個別に選ぶことができる。 もし、カーネルがあなたにとって十分にモジュラ―であるならば、systemdもそれに近いはずである。

7. 神話: systemd はデスクトップのためだけにある

これは事実ではない。 systemd で我々はLinux自体がカバーしているのと同じだけの範囲をカバーしようとしている。 デスクトップユーザーを気にする一方、同じだけ、サーバー用途や組み込み用途も同じように気にしている。 systemd がサーバー上のサービスを管理するのにベストなオプションじゃないなら Red Hat が RHEL7 の中心のピースに systemd を据えることはないと読者は賭けても良いだろう。

数多くの会社の人々が systemd に取り組んでいる。 自動車制作会社は systemd をビルドして車へ、 Red Hat は systemd をサーバーオペレーティングシステムに使っており、 GNOME はデスクトップを改善するために systemd のインターフェイスの多くを使っている。 読者は systemd をおもちゃや、天体望遠鏡や風力タービンで見ることができるだろう。

私がもっとも最近取り組んでいる昨日の殆どは、主にサーバーに関係してくるであろうものである。 コンテナサポートやリソースマネジメント、そして、セキュリティ機能だ。 我々はすでにデスクトップについてはかなりカバーしており、 systemd の開発を組み込み向けにおこなう会社は数多くあり、いくつかは systemd にコンサルティングサービスをオファーしているところすらある。

8. 神話: systemdはNIHシンドロームの結果としてつくられた

これは真実ではない。 我々は systemd に取り組み始める前は、我々は Canonical の Upstart が幅広く受容されるよう後押ししていた(そして、Fedora/RHEL は Upstart をしばらくの間、使ってもいた)。 しかし、我々は Upstart のデザインは内在的に、そのコアに欠点を抱えているという結論に至った(少なくとも我々の目には、である。もっとも根本的には Upstart は依存関係の管理を管理者や開発者に残したのだ。コードでこの難しい問題を解決する代わりに)。 そして、そのコアに誤ったものがあるのなら、それを直すのではなく、置き換えてしまうのがベターだ。 これが唯一の理由というわけではなく、それ以外のものも現れだした感じだ。ライセンスやコントリビューションの合意といったそのへんの systemd にまつわるものだ。 NIHは1つの理由というわけではないんだ((原文注: そして、 "libnih" というライブラリーが含まれているプロジェクトは何か考えてほしい。 Upstart or systemd のどっちだ?(ヒント: systemd ではない!)))。

9. 神話: systemd は freedesktop.org のプロジェクトである

ああ、たしかに systemd は fdo でホストされているが、 freedesktop.org はコードとドキュメントのレポジトリ以外のほとんどなにものでもない。 ほとんど誰でも、コーダーはそこにレポジトリをリクエストして、作ったものを置くことができる(作ったものが、フリーなシステムのインフラに関係がある限り)。 関わっている派閥もないし、「標準化」のスキーマもない、審査もなければ、何もない。 fdo は優れた、フリーで、頼りになる、レポジトリを持てる場所である。 それに関していえば、 fdo は SourceForge や github 、 kernel.org と、ちょうど、商用向けじゃなく、常軌を逸した要件もなく、そのため、自分の作ったものを置くのに良い場所という点で同じだ。

なので、そう、我々は自分たちの成果物を fdo でホストしているが、この、人々の集まりがあり、その人々が話し合っては、将来のフリーシステムがどうあるべきかについて合意しているという、神話の暗黙の推定はまったくの嘘である。

10. 神話: systemd は UNIX ではない

確かにこれにはいくつかの真実が含まれている。 systemd のソースはオリジナルの UNIX を起源とするコードは1行も含まれていない。 しかし、我々は UNIX からインスピレーションを受けているし、その結果、 systemd にはたくさんの UNIX がある。 例えば、 UNIX の考え方である「すべてはファイルである」というのは、 systemd ではすべてのサービスは実行時にはカーネルのファイルシステムの cgroupfs に晒されるという形で反映されている。 そして、 UNIX のオリジナルの機能の1つである、ビルトインターミナルサポートをベースとする multi-seat サポートがある。 とはいえ、テキストターミナルは、今日、コンピューターとインターフェイスでどうつながるかの最先端技術水準とは言い難いだろう。 systemd では我々はネイティブな multi-seat サポートを連れ戻したが、今回は、グラフィックやマウス、オーディオ、ウェブカム、その他をカバーする今日のハードウェアをフルにサポートし、それらがすべて、完全に自動的、ホットプラグ対応で、設定が不要な状態にしている。 事実、 systemd のデザインはそれぞれが個別の目的を持っているが、組み合わせて使われたときに、単に部分を集めた以上のものになるという、一連の統合的なツールであり、これは、ほとんど UNIX の哲学のコアの部分である。 そして、我々のプロジェクトのハンドルのされ方(例えば、単一の git レポジトリでコアの OS のほとんどをメンテすること)は Linuxのやってきたこととと違って BSD (Linux と違って BSD は真の UNIX だ)のもののやり方(BSD ではコアの OSの は単一の CSV/SVN レポジトリで維持されている))のモデルにかなり近い。

究極的には、 UNIX はみんなにとって違ったものだ。 我々 systemd のメンテナーにとっては、それは、インスピレーションを得た何かである。 その他の人にとっては、宗教であり、他の世界宗教と同じように様々な読み方や理解がある。 UNIX を特定のコードの遺産に基づくものと定義する人もいるし、単なる考え方のセットだと見る人もいて、コマンドやAPIのセットであるとする人もいる。さらには、ふるまいの定義であると考える人もいる。 もちろん、これらすべての人をハッピーにすることなんてできやしない。

究極的には、何かが UNIX であるかないかという問題はほとんど問題にならない。 技術的に優れているということは、 UNIX に専用ということはほとんどない。 我々にとって、 UNIX は主要な有力者(もちろん、最大の勢力)だが、他の有力者も我々は持っている。 なので、いくつかの領域では systemd は非常に UNIX であるが、その他ではそうでもないのだ。

11. 神話: systemd は複雑である

これはちょっと正しいかもしれない。 現代のコンピューターは複雑なビーストであり、その上で動く OS も複雑に違いない。 だが、 systemd は同じコンポーネントのそれ以前の実装より複雑というわけではない。 むしろ、 systemd はよりシンプルで、(ここまでみてきたように)より冗長じゃない。 さらに言えば、 systemd をベースにシンプルなOSを作るには従来の Linux よりもかなり少ないパッケージで済むようになる。 パッケージがより少なければ少ないほど、システムをビルドするのがより簡単になるし、相互依存性やすべてのコンポーネントがバラバラの挙動をするということの多くを取り除くことができるようになる。

12. 神話: systemd は肥大化している

まぁ、肥大化というのにはきっと様々な定義がある。 だけど、たいていの定義でいえば、systemd はおそらく肥大化の反対に位置するだろう。 systemd のコンポーネントは共通のコードベースを共有しているため、共通のコードパスのコードをずっとより多く共有する傾向がある。

例えば: 従来の Linux のセットアップでは、 sysvinitに、 stop-start-daemon、 inetd、 cron、 dbus、といったすべてが様々な設定オプションを、あるうまくいけばクリーンな環境でプロセスを実行するためのスキームを実装している。 systemd では、このすべての、つまり、設定のパースのコードパスを、実際の実行とともに共有されている。 これは、より少ないコードで、ミスの発生する箇所をより少なくし、より少ないメモリとキャッシュプレッシャーを意味し、それは、非常に良いことである。 そして、副次的な効果として、それについて、非常に多くの機能性を利用者は得ることができる……。

前述の通り、systemd はかなりもジューラーでもある。 ビルドするときに、どのコンポーネントが必要で、どれが不要かを選ぶことができる。 人々は、したがって、自らが必要とするだけの「肥大化」のレベルを明確に選ぶことができる。

systemd をビルドする際、たった3つの依存関係が満たされていれば良い。 glibc と libcap、そして dubs だ。 これだけだ。 もっと多くの依存関係を使うこともできるが、これはまったくのオプションだ。

さて、これで、どういうふうに見たって、 systemd は本当に肥大化したとは言えないだろう。

(ぼちぼち訳します)

*1:誤字を指摘いただいた @henrich さんありがとうございます。)))

我々が最初ディストリビューションに systemd を入れることを提案してからというもの、多くのフォーラムやメーリングリスト、カンファレンスでこのことがしばしば論じられてきた。 これらのディスカッションでは、よく systemd に関するある神話を聞くことができた。 この神話は何度も何度も繰り返されているが、繰り返されているほどには真実を捉えていない。 では、時間をとって、そのいくつかを暴いてみよう。

1. 神話: systemd はモノリシックである

すべての設定オプションを有効にして systemd をビルドすると、69個のバラバラのバイナリーがビルドされる。 これらのバイナリーはすべて異なるタスクを提供するものであり、様々な理由できちんとわかれている。 例えば、我々はセキュリティを念頭に systemd を設計しているため、ほとんどのデーモンは最小限の特権(例えば、kernel capabilities)で実行され、これらは、セキュリティ上の表面とインパクトを最小化するため、非常にはっきりとしたタスクのみを担う。 また、 systemd はそれ以前のいかなるソリューションよりもブートをパラレル化している。 そのため、systemd が多くのバイナリーおよびプロセスにうまく分割されているというのは本質的なことなのである。 事実、これらの多くのバイナリー((原文注: 例えば、 systemd-detect-virt, systemd-tmpfiles, systemd-udevd がある。