低レイヤ技術を間接的に仕事で生かしてきた経験の共有。元Linuxカーネル開発技術者の場合

はじめに

ITの世界で「低レイヤ技術」と呼ばれるものがあります。明確に定義されているわけではありませんが、アプリケーションのような直接エンドユーザに触れる部分ではなく、しかもなるべく生のコンピュータに近い部分、たとえばOSカーネルやコンパイラ、CPUを開発する技術などがあります。これらの技術に明るい人はそうそういないのですが、「やってみたい」という根強い人気があります。

学生のかたでもセキュリティキャンプなどで実際にある程度身につけてしまうような人もいます。そしてますますこの手の技術に趣味としてのめり込んでいって楽しくなる…というところまではいいのですが、「ではこの技術を会得した先に何があるのか」と不安になる人も多いようです。とくに学生さんの場合は「低レイヤ技術を使って今後なんらかの仕事をして生きていけるのか？」といったことが気になるようです。今日もそのような話を少し耳にしたので、自分の経験を共有する記事を書くことにしました。

わたしはかつて低レイヤ技術のうち、OSカーネル、もっと具体的にいうとLinuxカーネルの開発に15年ほど従事してきました。Webサービスを提供する会社のインフラ技術者として働いています。Linuxカーネル開発をしていたころの話は以下の記事ですでに書いたので*1、本記事では「低レイヤ技術(Linuxカーネル開発技術)を他の仕事でどうやって生かしてきたか」ということを書きます。

satoru-takeuchi.hatenablog.com

対象読者はこの手の技術を身に着けたいと思っている、すでにある程度身に着けている人です。社会人のかたでも役立つとは思いますが、とくに学生さん向けに書いています。

前提

昔の仕事で得たスキルセットをもう少し具体化すると次のようになります。

  1. Linuxカーネルの全体構造の概要がわかる。 一部サブシステムについてはソースコードレベルで理解して、必要に応じて変更もできる: 主にはプロセススケジューラ、CPU online/offline、ブロック層、一部ファイルシステムなど
  2. 上記サブシステムへの変更をupstreamのLinuxカーネルにマージするためのLinuxカーネルコミュニティでの活動ができる。上記サブシステムについてのGitHub issue対応のようなことができる*2

今の仕事をインフラ技術者と表現しましたが、インフラ技術者といっても幅が広いので、こちらももう少し詳しく書いておきます。わたしは自社Webサービスを動かす基盤となるべく開発中のオンプレK8sクラスタのストレージシステムの開発に従事しています。以前もLinuxカーネルのブロック層やファイルシステムなどの開発にかかわってきたので、少しレイヤが上がりましたが依然としてストレージという分野で仕事をしているといえます。

bについては上述の記事で触れているので割愛して、このような仕事にaのスキルがどのように役立っているのかを具体例を紹介しながら書きます。

具体例

コンピュータシステムを開発、運用していると、「アプリやミドルウェアの世界では説明がつかない挙動をしている」「システムコールの発行先で何かが起きているがよくわからない」ということはザラです。そういうときに迷宮入りさせずに根本原因を追究して対策を打てるのは大きなアドバンテージとなります*3。Linux上で動くソフトウェアは結局のところLinuxカーネルの上で動くので、アプリケーションの開発者になろうとミドルウェアの開発者になろうと、前述のような「なんだかよくわからない挙動をしているときに「これはカーネルやハードウェアのレイヤの話かもしれない」「カーネルがこういう挙動をしているのであれば説明がつく」「こうやれば直せる/回避できる」といえる機会はいくらでもあるのです。以下に、世の中に公開されている2つの例を上げます。

1つめは「インフラシステムを開発していたらあるプロセスが特定の設定をすると起動しなくなった。原因はカーネルのビルド設定」という話でした。

blog.cybozu.io

この件はそれほど難しい話ではないので、専門外でも熟練の技術者であれば専門外のことでも時間をかければ、いずれは解決していたでしょう。しかし既にやったことがあって慣れていると、何をすればいいかという型を知っているので作業が早いのです。上述の通りわたしはLinuxカーネルのスケジューラはソースコードレベルで把握しているので、上記のことは事象が発生してすぐにだいたい原因のあたりがつけられて、ソースのどこを見ればその仮説があっているかどうかわかるという状態だったので1～2時間ほど解決しました。

この例はとくに緊急というわけではなかったのですが、一刻を争うというような場合にこういうことがプラスアルファとしてできる技術者がいるというのは組織にとってプラスでしょう。「プラスアルファ」と書いたのは、「Linuxカーネルにだけは詳しいけど与えられた職務で主に使う技術が全然ダメなら辛い」ということです。

2つめは「分散ストレージシステムから切り出したブロックボリュームのI/Oが止まることがあった。原因はボリューム上のファイルシステムがXFSだったらカーネルがハングすることがあった」という話でした。

blog.cybozu.io

この話は社内で発生したわけではなくRookというOSSのslackを眺めていたら偶然見つけたものでした。深刻な問題だったもののRookコミュニティでは原因がわからずお手上げ状態でしたが、Linuxカーネルに明るければログを見ただけで「おそらく原因はカーネルであろう」とわかるので、Linuxカーネルコミュニティにはたらきかけて原因究明までこぎつけられました。本件にかかわっていなければ将来的に自社サービス運用中にこのバグを踏んで悲惨なことになっていたかもしれません。こちらもLinuxカーネル開発技術者時代の経験が大きく生きたと言えるでしょう。今後も本件とは別ながら似たようなことが起きた場合もおそらく役に立てるでしょう。

おわりに

わたしは低レイヤ技術の中でLinuxカーネル開発しかやったことがないので他の技術を使って働くにはどうすればというのは正直言ってわかりません。しかしながら「その技術がまわりまわってどのように世の中につながっているのか。事業会社であるならば、どのようにお金になっているのか」「その技術の隣には別のどんな技術があるのか」「募集が多い技術と自分の好きな技術がどうつながっているのか」などと普段から考えておくとよいとは言えるかと思います。

本記事で書いたような低レイヤ技術を「間接的に」生かすというときは、自分が持っている低レイヤ技術はあくまでプラスアルファであり、雇用主に求められている主たる技術の習得を第一とするという認識を持っておくのもよいでしょう。低レイヤ技術はレアなので持っているとチヤホヤされがちなのですが、「俺は低レイヤの人だから」などという考えでいると、たまには役に立つけど普段はいなくていい使いどころに困る人になってしまいます。

なんやかんやと書きましたが、一番いいのは経験者に聞くことです。もし他の技術について「この技術で食っていくにはどうすればいいんだ」と気になっているかたがいれば、それぞれ実践している人を見つけて聞いてみてください。また、もし実践しているかたがこの記事を見た場合は、この記事のようなものを書いてくださると誰かに役立つかもしれません。し、わたしもそういう記事を見たいです。実は「あの人とかあの人とか書いてくれないかな～」という思いもあります。というわけで他の人に話をぶん投げて終わりにします。

*1:今の仕事の話も少し出ていますが

*2:LinuxカーネルはGitHubで開発していませんので、あくまで「のようなこと」です

*3:もちろんそういうときに、あえて根本原因を深掘りしないという手段もあります