ITエンジニアのキャリアに本気で向き合うメディア
ITエンジニアのキャリアに本気で向き合うメディア
目次
■クラウド＆インフラストラクチャ
2022.05.08 2023.12.14 約4分
近藤 宇智朗
GMOペパボ株式会社
技術部技術基盤チーム シニア・プリンシパルエンジニア
この回ではインフラで一番面白い世界について考えていきます。
皆さん、子どもの頃、中身が気になって時計を分解するようなことがありましたか？ 私はありませんでした。
にも関わらず今私が一番面白いと考えている世界はインフラの「中身」です。インフラエンジニアは、ともすれば与えられたOS、ミドルウェア、 マネージドサービスを上手に組み合わせることを求められますし、実際それらの要素を適材適所位配置できることは良いインフラエンジニア、アーキテクトの素養でしょう。
ところでそれらのOS、ミドル、サービスはいきなり無から出来上がったわけではなく、別の誰かが作ったものだったりします。 実は、世界に存在するソフトウェアは、100%が人間が作ったものであると考えられています（本当に？ 私が知らないあいだにAIが作ったソフトウェアが動いてるのかもしれませんが…）。 ということは、同じ人間である私たちにも、その中身のことは理解できるだろうということが想像されます。では、どのように理解していけばいいでしょうか？
今回は、私が比較的精通している分野であるコンテナの要素技術やミドルウェアを題材に、中身を「深追いする」方法や技術について少しでもお話しできればと思います。
インフラソフトウェアを「作る人」と「使う人」の境界を曖昧にすることはともすれば昨今の潮流の反対方向かもしれませんが、それでもインフラエンジニアにとって何かの役に立てればと思います。
本日は、インフラで私が一番面白いと考えている世界と題して発表します。
私は、GMOペパボ株式会社でエンジニアをしている近藤 宇智朗です。福岡市のエンジニアカフェという施設の関係者になったことからハッカーという役職がつきました。
上の図は2019年の Ruby会議のオーガナイザーをしているときの記念写真です。今までは Ruby やコンテナ系のコミュニティにいて、具体的な活動としては Ruby会議の2016年、2018年、2019年で発表しました。昨年度は青山さんもいる Cloud Native のコミュニティで 、Cloud Native Days 福岡開催のオーガナイザーとしてお手伝いしたり、東京で発表したりしていました。趣味は Duolingo で、スペイン語とフィンランド語を並行して学んでいます。
ここからは30分間でコンテナを自作するので、ほとんどターミナルを映しながらの発表となります。
※近藤さんが実際にコンテナを作成します。詳しくは下記動画をご参照ください。
こんな形で mruby や C言語を使って、コンテナ自作の実験をすることができます。今回は難しめのツールを自作してみました。
結局、僕がいいたかったのは「プログラミングは楽しいね」ってことです。冗談ではなく、半分真面目です（笑）インフラエンジニアや運用系のエンジニアの方は、「プログラミングするな」といわれたことがありませんか？僕はあります。
ソフトウェアを書くと基本的にバグが起こります。安定性を求める運用として、わざわざ自分でバグを入れにいく行為なので、プログラミングをして、自分でツールを作ってしまうと、現場によっては怒られるような歴史的経緯があります。
Infra Study Meetup #3 でSRE の話がありましたが、SRE はもともと Google ソフトウェアエンジニアの人がやり始めたように、ソフトウェアとしての開発職を大事にしてるポジションだと思います。Cloud や Cloud Native が出てきて、インフラとはいえ、変化を推していく前提があると思っていて、いろいろ流れはありますが、最終的にはソフトウェアを把握し、理解が必要です。
それをする1番の方法は、小さく実験的なソフトウェアを書くことです。私はある勉強会でコンテナの中身を知り、「これはおもしろい」と思ってコンテナを自作しました。さらに Linuxプログラミングインターフェイスという約1600 ページの本を読んだのが、今の自分になる大きなきっかけでした。
ソフトウェアで動いている以上、人間が書いた中身があるものなので、一度、同じ立場に立って、ミドルウェアを把握する方法もありだと思います。そのためにプログラミングをしているともいえます。
僕にとってインフラで1番おもしろい部分は、システムプログラムです。コードを書いて、現実を湾曲させていく。いま配信を637人が見ていますが、その1% の6人でも、そういうマインドを持ったら世界はだいぶ変わると思います。
ご静聴ありがとうございました。
近藤：インフラって何だ？となる気がしていて、サーバーレスになるとインフラエンジニアはプログラマーになると思います（笑）なので、アプリケーションを設計する力が必要になります。
オンプレでいえば、運用スキルが重要になると思います。だからこそ、運用の知識を持っている方が重宝されました。しかしクラウドやサーバーレスになると、領域分解点が変わり、運用などはクラウドベンダーのインフラエンジニアが任せられるようになります。
自分のやりたいことに、より集中しますが、一方でプログラミングでクラスを組み合わせて Rils のようなアプリケーションを作る形で、サーバーレスのパーツを組み合わせて、なおかつインフラ的な発想、それこそ負荷や監視、メトリックなどの知識を持った状態で安定したサーバーレスのものを作るようになると思います。いわゆるハイブリッドな形ですね。
まつもとりー：僕も同じ意見です。システムの組み方が多様になると、インフラに近い部分の要素技術を考慮しながら、よりいいシステムを組むにはどうすればいいかを考える必要があります。システムの組み方や設計、それを実現するためのプログラミングは必要になると思います。
近藤：最近 Kubernetes は重要視されていますが、 Kubernetes を触っている人は、「これ OS じゃん」という人もいます。しかし OS を理解すると、ある意味繰り返している面もありますし、スケジューラーなど類似した概念が出てくるので、つながりを持って理解できます。ある程度、低いレイヤーを学ぶことは、意外とサーバーレスにもつながってくると思います。
まつもとりー：今回のテーマでもある歴史や、なぜ変わってきたかを学ぶことで、似たところに当てはめて考えられそうですね。
まつもとりー：まず1行目の「若手がインフラに興味を持つきっかけが減った気がします」についてはいかがですか？
近藤：体感的に若い人が入っているかは、まだ判断できないと思います。私より若い方でも優秀なインフラエンジニアや SRE はたくさんいるので、むしろ減ったとしても、強い若手がどんどん増えて困ってます（笑）
最近話題のフィヨルドさんのお手伝いをしていますが、IT業界に入るきっかけは、アプリケーションエンジニアが多いと思います。逆にインフラ、ミドルウェア、ネットワーク、クラウドに関する教材が少ないので、興味はあるけど、学習する方法がわからない人も多いのだと思います。
まつもとりー：僕もシステム、プログラミングなどを勉強してきましたが、 C言語の言語使用を学ぶよりは、Linux のシステムコールの話を読んだほうが、自分の知りたい領域に合っていました。
適切に導いてくれる本が少ないと思っていて、そこをサポートできるものが出れば、興味を持つきっかけや、基盤好きの人を醸成していくようなきっかけにもなると思います。
近藤：基盤部分に近づくと問題が抽象的になってくるので、抽象的な問題を解くのがおもしろいことも、宣伝できたらと思います。
まつもとりー：コンテナを作るのも、抽象的な領域でプログラミングやソフトウェアを書くにしても、抽象的過ぎて何を書いていいかわからないところに、たとえば mruby でつないでコンテナは作れるみたいな。中間を担うものがあると、体験も簡単になりそうですね。
近藤：つよつよの人とそうでない人の壁を作るべきではないと思います。多分インフラエンジニアをされているので、インフラが好きで、サーバーをいじるのが好きで、ミドルウェアを設定したり、ログを眺めてるだけで、お酒が飲める感じの方を想像しているのではと思います。
まずは得意なこと、24時間触っていられる分野を見つけるといいと思います。
それは監視マスターでもいいですし、特定のミドルウェア、プロメテウスやパッチに詳しいでもいいので、自分の強みを探してみてください。そうすると、自分の強みを活かして活躍する感覚がつかめると思うので、徐々に壁がなくなると思います。
近藤：BPF には注目しています。ftrace、GDB、パワフルのような歴史があって、使い方も確立しているツールを勉強してるところです。ソフトウェアでソースコードは見れますが、実際動き始めると結構見えにくい面があります。
特にミドルウェアが該当します。多くのものはパッケージで入ってくるし、コンパイル済みのものなので、中身がどうなっているか、機械語を目grepできないとわからなくなってしまいます。
外側から観察して、中身を理解するためのツールはおもしろいので、インフラ系をやるのであれば、勉強してみてください。その書籍自体が少ないという問題もありますが、詳解 システム・パフォーマンスという本が出てるので読んでください。
あとは BPF Tracing Tool もブレンダーの人がおそらく日本語にしてくれると思うので、その辺りを読んでみて、なおかつ自分で触って単純な Apache や Redis をトレスしてみると全然違うと思います。
BPF だと少し事情が変わりますが、一般的な GDB や ftraceは、込み入った問題を解決するのによく使います。カーネルの特定のバージョンで、ミドルウェアが遅いとか、そういったレベルのコミット数や、セグメンテーション違反、セグフォール系のエラーなどにはよく使います。
BPF を使うとより楽になると思っています。システムコールや、どのぐらい呼んでるかは、既存の ftrace などを使うと、パフォーマンスへの影響が大きいです。ftrace のアーキテクチャ上、そうですが、一方で BPF は、ほとんど本番のアプリケーションにかけられるぐらい軽量になるので、ライブで動いているアプリケーションの分析により使えるようになると思います。
ただ、カーネルが新しくないと使いにくかったり、機能が制限されたりするので、ノウハウはこれから積み上げるしかないと思います。
