ITエンジニアのキャリアに本気で向き合うメディア
ITエンジニアのキャリアに本気で向き合うメディア
目次
■クラウド＆インフラストラクチャ
2022.05.08 2024.03.06 約4分
山下 和彦
GMOペパボ株式会社
技術部 技術基盤チーム シニア・プリンシパル エンジニア
皆さんは小さい頃にミニ四駆を組み立てたことはありますか？僕はあります。ちなみにソニックセイバーよりはマグナムセイバーが好きです。いや、最悪、ビーダマンでもいいです。さて、昨今インフラと呼ばれる領域も広くなり、インフラエンジニア、ひいてはエンジニアに求められる技術、広義にはスキルも大きく変化してきました。前回の基調講演で @udzura が述べたような「コードを書く」ということもそうですし、それ以外のソフトスキルについても多く求められてきたように思います。僕の回ではこれまでの歴史に触れつつ、時代の変化を背中のレカロシートに感じながら、いかに自身の興味と企業の方向性を重ね合わせ、コードを書き、企業や社会に貢献していくかということについて考えたいと思います。
山下 和彦です。 GMOペパボ株式会社でシニア・プリンシパルとしてエンジニアをしています。所属は技術部・技術基盤チームで、ペパボ全体で使える技術基盤や、CI 、コンテナ基盤の開発運用、各サービスや事業部で何か技術的に困ったことがあれば乗り込んでいき、解決する仕事をしています。
当社は、大きくはホスティングと EC事業、あとはハンドメイドとその他で事業展開しています。
僕は1986年4月10日に鹿児島県出水市で生まれました。ロリポップなどのサービスが始まり、ジョインしたのは2014年です。会社としては、創業19年目になります。僕も9月くらいに入社したので、まる6年働いています。
個人では STNS というプロダクトを運用開発しています。
このプロダクトは、旧来 LDAP や MySQL 。もしくは /etc/pam.d で管理されていた Linux のユーザーや、グループのアカウント管理を Go で実装された httpサーバー、クライアントと JSON でやりとりして、名前解決するシステムです。
LDAP や MySQL だとユーザー登録の手間がありました。クエリを投げて登録する仕組みなどありましたが、僕が作っている STNS は、TOMLベースの設定ファイルですべて定義できます。
あとは DynamoDB や S3 と連携して、割と Cloud Native に名前解決ができます。便利に活用できるので、今だと国内の Web系の企業を中心に、あとは大学でも何個か入れていただいているプロダクトです。もし皆さんのなかで、Linux のユーザー管理ができてないとか、LDAP がツライと感じる方がいたら、ぜひとも活用してください。
今日話すことは大きく4つあります。インフラ技術の変遷を紹介したあとに、エンジニアのキャリアについて話します。
上記はインフラ技術基盤の変遷をざっくりとあらわした図です。元々は Webサービスをやる際、物理サーバーに Linux をインストールして、その上にミドルウェアなどをインストールして運用していました。
その後、仮想化というキーワードが出てきて、AWS をはじめとするクラウドサービスが台頭してきました。最近は、そのうえでコンテナを動かしたり、オンプレでコンテナを動かしています。
僕は高校を卒業して19歳からすぐエンジニアとして働き始めました。キャリアは約16年で、半生に近いぐらいエンジニアとして生きています。物理サーバーが現役だった時は、cobbler でキックスタートをかけて、Cactiで監視したりして、当時 ISP にいたので、ISC Bind などで DNS 作ったり、Postfix でメールを作ったり、Radius で FTTH の認証をしている時代もありました。
その後、仮想化というキーワードが流れてきて、当時は KVM と僕自身は VMware を担いでいる会社にいたので、ESXi とか vCenter などをやっていました。その後クラウド時代と呼ばれるものが到来し、AWS をはじめとする各種クラウドプロバイダで、オンプレでやっているところは OpenStack で担ぐ時代がありました。
インフラのレイヤーでいくと Kubernetes とか、僕は去年、一昨年にかけて、ロリポップマネージドクラウドと呼ばれるコンテナサービスを自社でローンチしていたので、そのときに同僚の宇智朗が作った Haconiwa というコンテナランタイムの開発をお手伝いをしたりとか、あとはバックエンドをやっていたので、コンテナは近年で深く踏み込んだ領域かと思います。
技術の変遷にともない、エンジニアに必要とされるスキルも変わりました。昨今はサーバーのラッキングは DC 勤務していないと、ほとんどやらなくなったと思います。僕は昔から1人が好きだったので、4Uサーバーも1人でラッキングしていました。そんなことをやっていたのも、牧歌的な時代だったなと思います。
あとは ISO のイメージから KVM を起動したりとか、VM のディスクファイルが壊れて、レスキューモードから起動するのも久しくやってません。最近は壊れたら作り直せばいいので、そういったこともやらなくなくなりました。
デプロイもだいぶ変わってきていて、昔だと Chefサーバーや Puppetサーバーからサーバーの設定をデプロイしていました。また、アプリケーションについても、コード資産をサーバーにデプロイしていたと思いますが、僕は主にそういった用途に Capistrano という Ruby の Rake を拡張したようなソフトウェアを使っていましたが、昨今では、そのレシピも新しく書き直すことはほとんどありません。コードを書いても、合わせて Kubernetes の manifest を書いて配布して終わりです。
企業に必要とされるインフラ技術に関して、フレーミングを変えて考えました。
企業に求められるインフラ技術は、企業でそのとき、もしくは今後発生しうる課題を解決するインフラ技術だと思います。逆に課題を解決しないインフラ技術は不必要です。
企業に求められるインフラ技術は、絶えず変化しています。理由は技術の進歩やビジネス要件が変化しているからです。
たとえばクラウドサービスを使うときに、よりダイナミックに技術を展開したい。グローバル化に向けて、海外に拠点があるクラウドサービスを使いたいなど、要件の変化も技術が移り変わる要因です。ここで終わりにせず、もう少しフレーミングを変えて踏み込んでいきましょう。
僕が考えるエンジニアの定義は、技術を行使して課題を解決することを生業とする職業だと考えています。エンジニア業界は、変化することだけが変化しないエンジニアリングの世界といわれていますが、課題解決に利用する技術も絶えず変化しています。
また技術を行使する立場として、僕たちも絶えず変化を求められます。先ほど紹介した、仮想化になるときには、 VMWare や KVM は使えなきゃいけないですし、今の時代でもコンテナ技術は、ネームスペースの技術や cgroup といったコンテナの基礎技術に対する理解も求められていく時代になっています。
今まではあたり前に思っていたことがルールチェンジされ、強制的に変化せざるを得ない局面もあると思います。
たとえば新型コロナウイルスの件で、多くの会社がリモートワークにシフトしました。強制的な変化を受けたときに、それを楽しめるかで差が生まれます。僕は変化を楽しんで取り組むのが得意なので、コツを3つ紹介します。
自分のスキルや能力だけで解決できない課題や問題は往々にあると思います。環境や自分の周りのせいにして逃げるのは簡単ですが、言い訳せず、自分に足りないものを考えれば差がわかります。その差に対して繰り返しファイトしてやりきること。そして、解決する課題に熱中するのが非常に大事です。
自分が入れたい技術を導入したときに、企業の利益になればいいですが、そのケースは少ないです。自分が取り組むことに対して、自分が所属している企業や共同体の利益が一致していないと、自分の評価にも結び付きません。
技術を選ぶときに、企業に対するメリットや方向性を決めておき、結果が出れば評価もついてきますし、自分の所得が上がることもあります。継続して変化に取り組むために、自分が所属している企業や共同体の利益、もしくは向かっている方向性を合わせて取り組んでいくのが大事だと思います。
熱中して取り組んだことは歴史として積み重なっていきます。歴史が積み重なっていくと、課題を解決するためのアイデアがポンと出てきます。Connecting The Dots の話に近いと思いますが、その時々で何かに一生懸命になっていれば、あとから大きなバリューを生むので、それを認識したうえで、ストーリーを持って取り組むのが大事です。
弊社は多くのサービスを抱えるポートフォリオ経営をしています。そのときにサービスごとにユーザー管理、Linux のアカウント管理をする LDAP が立っていて、情報の登録が非常に煩雑化していました。
弊社に入る前は、九州の電力系 ISP に所属していて、約200万アカウントあったメールシステムのリプレースを担当していました。メールシステムのバックデータ自体は LDAP と DB で管理されていて、データ移行は Perl で書かれた LDAP の Wrapper で夜間処理していました。
当時、Perl と LDAP の移行処理には、パートナー企業がいたので、その企業のエンジニアが書いていましたが、僕はバッシュくらいしか書けない人間だったので、エンジニアが書いてる Perl を見てプログラムはかっこいいと思いました。
それがプログラマーを目指すきっかけになった大きなでき事です。その Perlを見てから、自分でプログラミング Perl〈VOLUME1〉や、牧 大輔さんが書いたモダン Perl 入門を読んで勉強して、プログラマーになりました。
納品物に対して精査する必要があり、自分で LDAP コマンドを実行しようとか、 ldapsearch を実行してチェックしていたので、 LDAP に詳しくなりました。
その後、弊社に入社して、当初はドメインサービスの Webエンジニアとして PHP と Ruby を中心に開発していました。国内でいうと4〜5年前くらいから Go言語が活発になってきました。ペパボにはエンジニア職位制度があり、職位が立候補で定められていました。当時僕はシニアエンジニアになりたてでした。
シニア・エンジニアは自分が所属している事業部の課題を解決できればよかったのですが、プリンシパルは、自分の事業だけではなく、ペパボ全体の技術課題を解決できるエンジニアである必要がありました。
そのときに、LDAP の管理が煩雑化している問題があったので、取り組むことにしました。それがきっかけで STNS が生まれました。
初期実装は、サーバーサイドもクライアントサイドも、 Go言語で実装されていました。クライアントサイドが Linux の NSSモジュールなので CGO で実装して動いていましたが、うまくいかない部分もあったので、今は C言語で書き直しています。当時は自分が興味のあった Go言語で全部書きました。
もともと LDAP の知識があり、やり込んでいたので、自分でインターフェースを実装できるレベルまで詳しくなれました。また18〜20歳ぐらいにかけて、Oracle Master や ネットワーク系の資格など、たくさんの資格を取っていたので、サーバーや Linux のミドルウェアに知識がありました。あとはそこにシステムプログラミングの知識をインストールするだけで実現できました。
自社の課題を解決しましたが、同じような悩みを持っている方が多く、今だと国内企業や大学などで利用されていて、海外にも入れる予定の方がいるので、もう少し大きなプロジェクトになっていくと思います。自分が積み重ねてきたものが、キレイにつながると、思いもよらない価値を生めるのが、STNS のいい例でした。
「企業に必要とされているインフラ技術とこれから」は3部作に分かれています。続きはこちらからご覧ください。
3/3「企業に必要とされているインフラ技術とこれから」GMOペパボ株式会社 山下 和彦 × さくらインターネット研究所 松本 亮介
Forkwellは「成長し続けるエンジニアを支援する」をコンセプトに勉強会を開催しています。Infra Study Meetupは、インフラ技術の「これまで」と「これから」を網羅的に学ぶイベントです。インフラ技術の各分野に精通した講師を招いた講演や著名エンジニアによる発表を実施しています。
当記事に掲載されている全ての情報は、イベント実施日時点の情報であり、完全性、正確性、時間の経過、あるいは情報の使用に起因する結果について一切の責任を負わないものとします。
