低レイヤの学び、どうします？

この記事は、2024年1月17日(水)に行われた「さくらの夕べ in 福岡」における発表を編集部にて記事化したものです。

はじめに

ビットスターの小岩です。

ビットスターは札幌に本社がある会社で、僕はそこでインフラストラクチャ、サーバとかネットワークとかその辺のテックリードをやっています。あとは一般社団法人LOCALの運営委員をやっていて、札幌とか北海道を中心にITコミュニティ活動の支援などをやっています。

今回の発表はJANOG53に応募したものなんですが見事に落選したので、さくらの夕べで皆に聞いてもらうことで供養というかお焚き上げというか、そんな感じで発表します。よろしくお願いします。

最近のエンジニアリング

最近のエンジニアリング、特にネットワークとかサーバとか、そういうインフラ系のエンジニアリングの実情として、物理的な物を触らないことが多くなってると思います。ネットワーク機器はまだしも、サーバは特に物理の物を触らなくなっていて、下手するとそこにサーバもないっていうこともあります。サーバレスであったりとか、コンテナをデプロイして実行したりとか、もしくはコードそのものをデプロイして、それが何らかの条件でキックされて実行されたりってことがあります。

で、やらなくなったこととしては、例えば物理サーバのキッティングですね。物理サーバを持ってきて、それを組み立ててラックに突っ込んだりとか。あとはそこにVMwareとかKVMなどを入れて仮想化基盤を構築するようなこともあまりやらなくなってきてるかなと思ってます。一方で引き続きやってるのは、いわゆるネットワーク系のセットアップですね。例えばオフィスからクラウドにつなぐにはオフィスのネットワークを作らなきゃいけないんで、そこでスイッチやルーターのセットアップとか、無線アクセスポイントのセットアップとか、そういうことは引き続きまだ仕事をしてあるかなという感じがしています。

こういう状況下ではおそらく必要なさそうな知識としては、例えばOS、特にカーネル周りのチューニングとかパラメータ、それからネットワークがどう動いてるか、TCPとかUDPの話とか、ラックの中のケーブルの配線をどうすればいいんだとか、そういった知識は現在では必要なさそうな気がしています。要は知らなくてもモノが動いたりサービスは継続できたりするのかなと思っています。

しかしそうは言っても、サーバはあるんですよね。サーバレスってちょっとカッコよく言ってますが、サーバはあるんですよ。ただ見えなくなっただけ、意識しなくなっただけなんですね。サーバとかの面倒を見るのがイヤな人たちがサーバレスとか言いながらやってるんですけど、そこにサーバは依然としてあるわけです。でも、ちゃんと動いててサービスが提供できてる間は低レイヤーの知識は必要はないんですけど、これ動かなくなったときってどうなるんだろう？っていうことも僕らエンジニアは意識しなきゃいけないと思っています。

低レイヤの知識が必要になる事例

ここで、ビットスターや自分が経験した、低レイヤの知識が必要になった事例をお話しします。

ウェブサイトへのアクセス集中

1つ目の例は、とあるお客様のウェブサイトです。細部は公にできないので省きますが、前提条件としては以下のようになります。

• 基盤はさくらのクラウドを使用
• システム構成は、ウェブサーバがあって100Mbpsの共有セグメントにつながっ
  ていて、サーバではWordPressが動いているというシンプルなもの(図参照)
• サーバのroot権限やクラウドの操作権限は提供されている
• DNSはお客様が管理していて我々は操作できない

ここで、お客様との連絡が取れない状況下で、このサーバに集中的なアクセスがやってきました。

このような高アクセスのさばき方としては、CDNを入れるのが今どきの対応かなと思います。さくらのサービスだとウェブアクセラレータですね。しかしCDNを入れるにはDNSの設定変更が必要で、そのDNSは我々には操作できず、さらにお客様と連絡がつかないのでこの方法が使えません。

こうなるとサーバ1台でなんとかしようということになります。クラウドならサーバのスペックは随時変えられるので、とりあえずCPUを20コア、メモリを32GBに増設し、さらにサーバで稼働しているApacheのMaxClientsを4096まで増やしたら処理能力がある程度は向上し、トラフィックが70〜80Mbpsぐらいまで伸びました。

ここまではうちの若いエンジニアがやったんですが、これ以上の方策を思いつかないということで僕にバトンタッチされました。ここでじゃあ低レイヤをいじろうかってことでLinuxカーネルのTCP周りのチューニングをしたら処理能力がさらに向上し、トラフィックが150Mbpsぐらいになりました。ウェブサイトもときどき表示されるぐらいにまでなりました。最終的にはネットワークの帯域を増やしてもらって問題を回避しましたが、トラフィックは最大350Mbpsまで上昇したようです。

ここからの学びは、チューニングをすると性能が引き出せるっていうことです。ただそのためには当然、カーネル周りやネットワーク周りの知識、TCPやUDPの知識が必要です。普段はカーネルをいじったりとかTCPスタックをいじるようなことは僕の仕事ではやらないんですけど、ときにはそういう知識が必要になったり、その上で動くミドルウェアの設定をどうすればよいかといった知識が必要になることがあります。

極寒地における光ファイバーの例

もう1つの事例を紹介します。

すごく寒い冬の朝、とある拠点からデータセンターにネットワーク接続ができないっていう連絡が来ました。パケットロスが70％前後ぐらい出ていて、でもIPsecのインターネットVPNは接続されているっていう状態です。パケットロスが70%もあるので、VPNはつながってるけどほぼ使い物にならないぞっていう状況ですね。

で、ルーターなどを調査したんですが特に異常がなくて原因がわからないので回線業者に調査を依頼したところ調査結果が出てきて、なんと「寒すぎて光ファイバーの特性が変わってました」って言われました。要は光ファイバーの被覆のゴムが寒くて硬くなってファイバーの径が変わっちゃって、そこで屈折率が変わってパケットロスが出るということです(場内「ほ〜」という驚嘆の声)。皆さんいま「は〜〜」みたいな反応してますが、この話を聞いたときの僕のリアクションも同じでした。

ここで得た学びとしては、極端に寒い状況だと光ファイバーの特性が変わるっていうことなんですが、役に立つ場面が少なそうな知識ではありますね。対策としては業者さんにお願いをして、寒さに強い光ファイバーに張り替えてもらいました。

巨人の肩の上に乗っていても降ろされることも

ここでちょっと話題を変えます。

「巨人の肩の上に乗る」っていう言葉があります。要は僕たちは過去のエンジニアの先輩方の遺産の上で仕事をさせてもらってることが多くて、いろんな巨人の肩に乗って仕事をしたりとかITエンジニアリングをしていることが多いです。乗ってる巨人っていうのは何かっていうと、先輩方が作ってくれたフリーソフトウェアや、クラウドのサービスやSaaSのサービスなどです。そういったいろんな巨人の肩の上に乗ってビジネスや活動をすることが多いです。

ただ一方で、この巨人から降ろされる可能性もすごくあると思っています。フリーソフトウェアに乗ってる分にはあまり問題ないと思うんですが、クラウドとかサービスの上に乗っている場合に、この巨人から降ろされる可能性がすごく高いなと思っています。例えば、トランプ氏の支持者が集まるSNS「Parler」の基盤として使われていたAWSが、Parlerへのサービス提供を停止しちゃったという例があります(出典)。このSNSの是非は置いといて、クラウドサービス事業者の都合でサービス提供を打ち切る、つまり巨人の肩から降ろされてしまうという例です。あとは最近だと、Skebが利用しているHerokuで大きな障害が起きて損失を被ったという例(出典)や、BOOTHを利用している人がアカウントをBANされて売上が振り込まれなくなったという話もあります(出典)。

このように、巨人の肩の上に乗ることでビジネスがやりやすくなったりとか、BOOTHで出展すればその瞬間にワールドワイドで商売ができたりとかってすごく便利になってるんですけど、一方でその肩から急に降ろされちゃうっていうリスクもあるんじゃないかなっていう話です。要は今、僕たちはすごく、巨人に生殺与奪を握られている感じになっているんですね。巨人たちを便利に使ってる分にはいいんですけど、急に肩から降ろされて踏み潰される可能性もすごくあるなと思っています。この巨人から降ろされる覚悟を持ってサービスやクラウドを使ってるのか？という話があると思っていて、そこでそれに対抗するために、もしかしたら僕たちエンジニアは低レイヤーの知識も必要なのかもしれないなと思っています。

現実を見る

一方で、ここで僕たちが今生きている現実を見ると、だいたいここにいる人たちはITのエンジニアリングでビジネスをしていて、それでお金をもらってると思うんですけど、そこには経済的合理性がどうしてもあって、早い話はタイパ(タイムパフォーマンス)が重要なわけですね。なのでそのタイパであるとかコストパフォーマンスとかを見ながら経済的合理性がある動きをしなきゃいけなくて、そうすると普段必要ない低レイヤの知識を学んだり使ったりする必要性はあるのかと。ここまでの話からすると低レイヤの知識も必要なんだろうなと思うんですけど、ただ普段は使わないわけですよ。普段は必要ないってことは、そもそも今そういう仕事や案件がないってことですし、案件や仕事がないと教える機会もありません。特に僕らのようなSIer的な立場の会社からいくと。

でもその一方で、神奈川県の高校入試の出願システムのような問題も起きています(出典)。特に最近、DNSとかメールってだいぶロストテクノロジー化してる感があって、僕らが最初にインターネットのエンジニアリングをやったときはこの辺は当然付随してくるシステムだったんですけど、今はこういうのを全然知らないエンジニアの人たちがやっぱり多くて、DNSやメールは自分たちからは遠く離れた世界で動いてるなという感じでやってる人たちが多いと思うんですけども、そういう人たちが急にこういうことをやらされると問題が発生しうるんですね。

で、こういった技術は、必要な気はするんですよ。インターネットで何かシステムを作って売るからにはやっぱり必要な気はするんですけど、普段は必要がないんですね。この矛盾をどう解消するか。我々は経済的合理性とかタイパを持っている仕事と向き合わなきゃいけないのに、その一方で必要だと思う技術だけど普段は必要ないっていうものもあって、この矛盾をどう解消してうまくエンジニアリングをやっていくのか、ここが考えていかなきゃいけないポイントなんじゃないかなと思ってます。

ビットスターでの取り組み

最後に、ビットスターではどうしているのかっていう話をちょっとしたいと思います。

ビットスターっていう会社が何をやってるかというと、主にシステム開発、ソフトウェア開発とかインフラの構築、あとはWebの制作デザインと、それらを含めてお客様に提供しているサービスがある場合はそれの24/365の有人運用監視をやったりしています。要するに、ITに関することでSES(エンジニア派遣)以外のことはほぼ全部やってる会社です。インフラの分野でいくと、主にクラウド(さくらやAWS)を使った構築ですね。あとはネットワークを引いたりとかそれの運用監視、さらにそれらをひっくるめたDX支援とかをやったりしています。

こういった仕事をしてる会社がどうやって低レイヤの学習をするかというと、年に1回ぐらい、それができそうなおいしい案件が来ることがあるんですね。主に行政系の仮想化基盤の構築という案件が来て、彼らはやっぱりなかなかクラウドに移行することができなかったりする事情があるのでオンプレミスで構築するってなると、物理サーバがあってファイバーストレージがあって共有ストレージがあってネットワークあって、みたいな構成になります。いまだにファイバーチャネルを使う話が来ることがあって、今の20代の子にWWN(World Wide Name)とか教えるのか俺…みたいな気持ちになることもあるんですけど、こういう案件が来ると若手を突っ込んで修行をしてもらってます。そうすると彼らも、仮想サーバってこういう感じでこういう基盤で動いているんだなってことをわかって戻ってくるんで、それを理解した上で仮想サーバの構築やクラウドの構築をやってもらうと、下部構造がわかってるので動いてる道理もわかってくるよねっていう感じでやってもらってます。

ただ一方でなかなかうまくいかないんですね。こういう案件がない年もありますし、仮想化基盤も徐々にクラウドにシフトしたりもしているのでこういう案件自体も少なくなっているのと、やっぱり発注者がいてそこからお仕事をもらってたりするので、そうすると理不尽なことやつらいことも多くて、どうしたらいいんだろうと思ったりしています。

その一方でビットスターはソフトウェア開発もやっています。システム開発でも課題があって、普通にLaravelなどのフレームワークを使って開発している分にはいいんですけど、例えばウェブアプリの動作改善だとかパフォーマンスチューニングとかやると急にメモリがどうのとかデータベースアクセスどうなるみたいな話が出てきて、そうすると今の若い人たちはそういう下の方まではわかってないんで手詰まりになっちゃうっていう話もあります。

まとめ

最後にまとめです。

最初に、低レイヤの知識が必要そうな事例として、ウェブサイトの話と光ファイバーの話をしました。その後ちょっと話を変えて、僕たちは巨人の肩の上に乗っているという話をさせていただいて、その一方で巨人から降ろされる可能性もあるよね、巨人に生殺与奪を握られてる部分もあるよねって話をしました。ただ一方で、それらを踏まえた上で現実を見てどうなんだという話と、なかなかつらい事案もあるよねっていう話をしました。最後にビットスターではどうやってるんだって話をさせていただいて、それらを踏まえた上で皆さんはどうしていますか？という問いかけを投げて、僕の話を終わりたいと思います。ありがとうございました。

質疑応答

質問者A：DNSOPS(日本DNSオペレーターズグループ)の方から来ました。DNSはみんな気付かないうちに使っていますよね。Kubernetesの中でもめっちゃ使われてるし。

それで、例えばbitstar.jpなどのドメインを自前のDNSサーバで運用するのはやめましょうというのをDNSOPSでもここ10年ぐらい言っていて、もう本当にBINDをビルドして使わないでくださいって言ってたんですけど、教育のためには必要なんだなっていうことを去年思いまして。みんな1回はやってみたらいい。1回やってみて、それでやめてほしい。

今日の小岩さんの話は、どうやって動いてるか、その仕組みをちゃんと理解して使うことが大事だっていう話だと理解しましたので、DNSがオワコンというわけではないので、そこだけよろしくお願いします。

小岩：僕らも商売で使ってるときは、自分でBINDを立ててどうこうってことはもうほとんどないですね。さくらのDNSを使ったりAWSのRoute 53を使ったりしています。僕の手元に残っているBINDは、自分が持っているドメインのDNSサーバだけです。それはなぜかというと、検証とかでたまにどうしても使いたいときがあるんですよ。それで残していますが、他はないですね。

ただ一方で、画面でポチポチしてなんとなくできた気分になっていると、メールが届かないとか、MXレコードにIPアドレスを付けて登録してしまうとか、そういう人が出てきますよね。やっぱり失敗も含めて経験を積んでいないと気づかないと思っていて、なかなか難しいなと思っています。

質問者B：質問なのか意見なのかちょっとよくわかんないんですけど、お話を伺っていて、低レイヤのところだけじゃなくて一般的に、最近使わない技術でもたまに使うことがあるから習得して知っておかなきゃいけませんよと。それは理解できました。

ただ、発表の中でご紹介いただいた事例を見ていても、そこになかなか値段がつきにくいですよね。そこがすごい難しいなと思うんですよ。お話の中であったように行政系で案件があるから若手が育つと言ったとしても、やっぱりそこにそれなりのコストがかかるんで、何年かに1回は必ずこれ来るはずなんだという話ができればいいんですけど、できなかったときの損失は結構きついものがあるなっていうのは思いました。

小岩：そうなんですよ。その一方で僕たちITエンジニアリングの業界って、ほっといてもやる人はやるんですよ。でもやらない人はやらないんです。これ何かいい呼び方ないかなって周囲と話していて「天然」と「養殖」という名前が付けられました。僕は割と天然ものなので自主的に学習して育つんですけど、養殖の人は勝手には育ってくれず、やっぱり何か仕事とか案件とか与えないと学習しないとか技術の習得をしなかったりします。

ビットスターもそれなりの規模なので、やっぱり天然もののエンジニアばかりを追っかけていても採用が足りなくて会社が回らなかったりするので、養殖ものをどううまくおいしく育て上げるんだみたいなのを試行錯誤しているところです。そこでインフラ関係だとやっぱりああいう仮想化基盤とかの構築の案件が来ると割とおいしいんだけど件数がそんなにないし、自社ではなかなかできないし、みたいなところをぐるぐる回ってる感じです。

発表を終えて

自分の中にあった危機感を動機として発表しましたが、参加者の皆さんも同じような危機感を持っていた、もしくは持っていただけて、自分だけじゃないんだなというのがわかってホッとしました。

そして、同じようにこれを解決できるような銀の弾丸は持ってないんだな、ということも再認識しました。読者の皆さんも考えてみていただければ幸いです。