ITエンジニアのキャリアに本気で向き合うメディア
ITエンジニアのキャリアに本気で向き合うメディア
目次
■クラウド＆インフラストラクチャ
2022.06.02 2024.03.12 約8分
Forkwell が主催する技術イベント「Infra Study」。今回のテーマは「202X年のインフラ技術」です（開催日：2021年 1月26日）。
Infra Study Meetup シリーズで登壇していただいたうづらさん、P山さん、もりたこさん、まつもとりーさんをお招きし、主に以下の話題についてディスカッションしていただきました。
・2020年を振り返り、変化したと感じることや面白いと感じた技術
・登壇者が取り組んでいる新しい技術や仕組み
・注目の集まる eBPF 周りの技術
・今後の動向
松本 亮介（まつもとりー）（さくらインターネット株式会社）
さくらインターネット研究所の上級研究員、京都大学博士(情報学)、複数社の技術顧問。インターネット技術に関するミドルウェアからOS辺りの研究開発やエンジニアリング、組織整備や組織文化醸成、EM、PdMも専門。2018年 Forkwell技術顧問就任。
まつもとりー：Infra Study Meetup 最終回はこれまでの振り返りをしていきます。これまで4月から10回にわたり、インフラ技術のトレンドや技術の移り変わりを体系的に連載してきました。
今回は Infra Study Meetupシリーズ後半で具体的な技術を話してくださった皆様と一緒に、踏み込んだ技術はどういうもので、今後はどういう技術が必要になってくるのかを掘り下げたいと思います。
まつもとりー：今回はInfra Study Meetup #4、5、6で「インフラの面白い技術」担当のうづらさん、「企業に必要とされているインフラ技術とこれから」を担当のP山さん、「インフラとセキュリティのこれから」担当のもりたこさんにご参加いただいています。
うづら：GMOペパボの技術基盤チームに所属している近藤 宇智朗と申します。大体うづらと呼ばれています。
P山：うづらさんと同じくGMOペパボの技術基盤チームで働いている山下と申します。主にP山と呼ばれてます。
もりたこ：森田と申します。周りからは「もりたこ」と呼ばれてます。
まつもとりー：ではパネルディスカッションに移ります。
うづら：最終的には何かにつながると思い、2020年を過ごしました。仕事ではデータ基盤の構築に奔走し、事業部を横断して用件を聞き、使いやすい基盤の設計をおこないました。2020年後半からはデータチームが再起動をしたので、スクラムなどを導入して、チーム作りもおこなっていました。
一方、業務外でも結構コードを書いたと思います。2020年はそれまで出てきた技術に新しいシーンが見られた年だと感じているため、今年とは言わないですが、2、3年後にすごい技術につながる技術の種を見つけた気がします。
P山：僕はよく、会社の課題と自分の興味を重ねて、深ぼるスタイルを実践しています。例えば Go はここ10年で流行りだしたと思いますが、自分も当時取り入れたいと思っていたため、当時の会社の課題を Go を使って解決し、会社の課題と自分の興味をうまく重ねました。
会社で起きている課題と興味のバランスを保ちながら仕事をしつつ、成長するスタイルが社会からも評価されているので、自分のなかではうまくやれていると思います。
もりたこ：インフラの話でいうと、コンテナイメージのスキャンを会社で力を入れてやった時期がありました。基本的に自分が興味のある分野と会社でやっている部分はかなりマッチしていると思います。自分が興味のある分野は kubernetes コンテナのセキュリティで、最近は防御側のほうもリサーチしています。
まつもとりー：共通するバックグラウンドとして、2020年はコンテナやそれらをオーケストレイトする話題が多く、その中でも三者三様、それぞれの専門的な目線での課題があると思います。2020年を振り返り、特にどの部分が変化したと感じますか？
P山：違う角度の話になるかもしれませんが、2020年は僕の中ではさまざまなものが停滞した印象があります。インフラ面では、kubernetes が当たり前に語られるようになりましたが、意外とそれは2019年の話だと感じていて、2020年は kubernetes を使ってどうするかを1年間だらっと考えていただけになっていた気がします。もしかしたら、コロナ禍のおかげで全世界的に生産性がなかっただけかもしれないですが、僕は全体的にあまり新しいものがなかった印象を持ちました。
まつもとりー：他の皆さんはこの辺りどうですか？
うづら：同意見です。コロナにより、世の中全体にすごいシフトが起こったのは間違いないと思います。ただその内容は、リモートで働けるプラットフォーム作りや仕組み作りだったと思います。
個人的にはコンテナオーケストレーションやサービスの方面に、あまりリソースがこなかったと感じているので、その意味では2020年にすごい変化はなかったと思います。ただ、地味な変化はいくつかあるので、そういった変化が2021年や2022年につながるのかもしれません。
P山：ゼロトラストネットワークなどの技術が今の時代にはすごく必要だと思います。ゼロトラストは一つの技術だけではないため、少し語弊があるかもしれませんが、社外から安全にアクセスできる技術が思っていたよりも出てこなかったと思います。時代背景として、そういった技術が出てきたら跳ねる印象を持ちますが、2020年はなかった印象を受けますね。
うづら：基本的にゼロトラストは既存の技術の応用例である印象ですが、この認識は皆さんそうですか？
P山：同意見です。何かソリューション化した感じですね。
もりたこ：ゼロトラストの文脈でいうと、元々 Google が IAP（Identity-Aware Proxy） として持っているので、ソリューションが出てきていないという意見には同意ですが、ツールとしての進歩は結構あったと思います。例えば Pomerium などのツールは結構進化している印象があります。ただ、ゼロトラストが劇的に浸透したかどうかは僕の観測範囲からはあまりない印象でした。
P山：そうですね。時代に求められる技術なのに来なかった感じがします。
まつもとりー：例えばリモートワークの文脈で、働くための仕組みを実現したいと思ったときに、今あるもので十分それが実現できそうな場合、新しい技術を工夫すること自体でてこないと思います。
実際にゼロトラストの文脈では、新しい技術を積極的に導入していく動きがあたりまえに進んだのでしょうか？もりたこさんは自分の観測範囲では導入があまり進んでいない印象でしたが、うづらさんとP山さんはいかがですか？
うづら：所属企業のペパボでも導入はまだまだだと思っているので、多くの一般企業はもっと進んでいないのかもしれません。ある程度パターンは出てきましたが、考え方が普及する段階でもっとやるべきことがあると思います。考え方が普及していないと一歩進んだことに挑戦しにくいと感じます。
P山：僕はペパボで社外から安全にアクセスできるようなソフトウェアを開発したり、何かしらのツールをペパボにインストールする業務をおこなった1年でしたが、それだと仕事の抽象度がすごい低いんですよね。個別にはいろいろやってますが、全体としては抽象度の高いところでやれなかったと感じます。
まつもとりー：急にコロナのような自分たちには想像できないことが起きて、急遽新しい技術の導入に着手しないといけなくなるが、他にもやることがあるため、抽象化するところまではいけなかったと。
うづら：個別の問題はしっかり対応できると感じていて、実装力のある会社さんなら積極的に通せると思いますが、全体像は2、3年経って総括が出ないとわからないと思います。ですので、リアルタイムは結構難しいと思います。
まつもとりー：ゼロトラスト話でもりたこさんにもお聞きしますが、リモートワークを自宅でもやろうと思ったときに、ゼロトラストの導入は必要だと思いますか？
もりたこ：僕はゼロトラストの導入は必須ではないと思います。まず、安全に社内のサービスインフラにアクセスするためのアプローチの一つとして、ゼロトラストがあると考えています。そのためであれば VPN（Virtual Private Netwprk）でもいいですし、生産性を下げない形でセキュリティを担保できる仕組みを用意することが重要だと思います。
まつもとりー：やはり今年は技術の進歩というより、一気に状況が変わってしまったので、その対応に追われていた側面が大きかったのですね。
P山：今、まつもとりーさんが活動してるアカデミアの領域では、コロナ禍によってアウトプットの量や質が変わりましたか？
まつもとりー：アカデミア全体として、特にアウトプットは減っていない印象を受けます。ただ、個人的に感じることは、やはり国際会議はリモートでしか参加できませんし、本番で発表して質疑を受けることもできないため、今年は投稿者数が減っているかもしれません。
P山：なるほど、ありがとうございます。
まつもとりー：ちなみにゼロトラスト以外の技術で面白かった技術は何かありましたか？例えばうづらさんは、最初やっていたこととは別に、コンテナ技術に紐づいて eBPF（Extended Berkeley Packet Filter）の話やコンテナにまつわるカーネル技術の話に興味が移行したと思いますが、その辺りの技術の説明をお願いできますか？
うづら： eBPF は主に Linuxカーネルをターゲットとして、新しいカーネル内でプログラムを動かす仕組みを持ちます。特にフィルタリングに強く、pcap（packet caputure）や seccomp の中身、そしてカーネルの関数呼び出しやカーネル内のイベントをフィルタリングして、可視化をとても軽量にしてくれます。
用途は2つあり、1つはパケットのフィルタリングに使われます。パケットを物理的に受け取り、デバイスに渡すまでの間で、eBPF のプログラムをフックして高速にフィルタリングや宛先の付け替えをするような技術が存在しており、その中で eBPF が動いている感じです。
もう1つの用途はトレーサーです。一般的にトレーサーは今でも ftraceコマンドや poweroffコマンドなどありますが、それらはシステムコールの内部実装上、システムへの影響が無視できないぐらい大きいパターンが多いです。しかし eBPF を使えば、カーネル内のイベントをかき集め、高速にフィルタリングして集計できるため、システムに影響を与えず複雑なメトリックを取れるようになりました。
まつもとりー：ここ数年 eBPF が注目され、技術が工夫されだしている背景には、どのようなきっかけがあると思いますか？
もりたこ：背景はさまざまあると思いますが、一つはコンテナの普及だと思います。コンテキストはセキュリティの文脈になりますが、例えばこれまで VM の上で動いてるアプリケーションの監査ログは Linux に入ってる auditd などを使って取得していたと思います。
しかし、Pod の中のコンテナが複数動いていて、さらにライフタイムも短いとなると、 auditd でも取れる限界がきます。今だと auditd にコンテナの情報が入ってこないため、どのコンテナでどういうコマンドが実行されたか追えない課題があります。ですので、より詳細にトレーシングができるツールとして eBPF が普及していると考えています。
まつもとりー：セキュリティとは別の観点から eBPF が増えたことでやりやすくなった点は他にありますか？
うづら：一般的な実装だとコンテナは普通のプロセスに見えるので、普通のプロセスをマネジメントするノウハウでコンテナを運用してた部分があると思います。利用者としては、独立した VM として使えますが、運用上はプロセスを運用している場合と変わらないため、行き届いた設定や対応がしづらいと思います。
同じ Apache を乗せたコンテナが10個あり、1個だけ負荷が高い場合、既存のやり方だと、まずトップを見てからプロセスを突き止めて、危惧するといった形ですが、実際は一発でわかってほしいですね。既存のデーモンだと扱いにくい部分があったと思います。
P山：今まで、コンテナの情報を横断的に取ろうと思うと、カーネルレイヤーで取るのが主流だったと思いますし、その実践にはカーネルモジュールを書く必要がありました。ただ、eBPF の登場でレイヤーに任意の処理を仕込むことが可能になったので、その点はすごく便利になったと思います。
うづら：既存の運用だと、とにかくカーネルモジュールを書かないといけないパターンが、多かったと思います。カーネルモジュールを書いてしまえば、何でもありになってしまいますが、最悪のパターンはカーネルパニックを起こすことなので、何かと手を出しにくかったと思います。
P山：たしかに eBPF だと安全ですよね。
うづら：安全で逆に全然コンパイルが通らないこともありますね （笑）
P山：たしかコンパイルのときに、安全かどうかチェックするものがあるみたいですね。
うづら：そうですね。eBPF のプログラムはカーネルのさまざまな機能を使えるプログラムですが、例えば無限ループしないように事前に verifier がチェックし、それに引っかかると通さないようにしてくれますね。
まつもとりー：普通に使うだけなら、カーネル側でうまくコントロールしたいとはならないと思いますが、自分の専門分野で何か足りないと感じるため、カーネルの領域に踏み込んで、制御したり、セキュリティを高めたり、eBPF などの技術に注目してるように見受けられます。やはりそこには一定の課題感が出てきたのでしょうか？
P山：僕自身はまだ eBPF を使ってコンテナのトレーシングをするところまでいっていないので、他の皆さんの状況が気になります。
まつもとりー：自分の興味で進んでいる部分と、やっていくなかで課題が見つかり、そこを深堀る2パターンがあると思いますが、他の皆さんはどうですか？
もりたこ：僕は完全に興味から入りました。たしかに課題感はカーネル側で不足している部分もあるので、注目しています。
うづら：僕も基本的には興味から入っています。ただ、eBPF conf（eBPF Summit？）の発表のタイトルを見ている限りだと、海外の大きいインフラは割と使っている印象でした。サーバーの数がとんでもなく多くなるパターンだと eBPF を使い、メトリックを細かく取って徹底的に自動化しないといけない仕様があるのかもしれないですね。ただ、今でも perf や strace などで取れる値でもあるので、その辺が変わるとなるとコンテナとの絡みになるような気がします。
また、2020年に興味深い現象だと思ったのが、コンテナランタイムの cgroup v2 対応が地道に進んでいることです。cgroup v2 自体は以前から使えましたが、2019年の終わりから2020年にかけて、対応が一気に進んだ気がします。この背景も eBPF が影響していて、cgroup v2 になると、ID 単位でのコンテナのトレースが可能になります。
ですので、kubernetes で立ち上げたコンテナが cgroup v2 に対応していると、そのまま BPF のヘルパーで ID を取り、フィルタリングをかけて、特定のコンテナだけオープンの回数を拾い、コンテナ単位でレイテンシを図るプログラムが書けるようになります。おそらく2019年の段階では、v2 のヘルパーはありましたが、現実では使われてないイメージでした。ただ、今は新しい kubernetes を使うと当たり前にプログラムが書けるので、今後いろんなツールが出てくると思います。
もりたこ：ツールでいうと、Datadog ではエージェントとして eBPF を使ったモニタリングができる製品があるので、割と製品で出てきている印象があります。
まつもとりー：皆さんの話から開発運用の面で、現状差し迫った課題が、見つかっていない印象を受けますが、何か自分たちで取り組んでいる新しい技術や仕組みはありますか？
P山：僕が最近やってることはマルチクラウドといわれる領域です。コンテナオーケストレーションを使えば、ネットワークのレイヤーが抽象化されるため、サイトAからサイトBに移動しても、そのまま動く仕組みが今のコンテナオーケストレーションにはあり、そういった技術を最近やっています。
また、現状コンテナオーケストレーションの技術は、ものによって前の時代のよい仕組みをそのまま使っている場合が多いです。
一方で eBPF とよく並んで出される技術として XDP（eXpress Data Path） があります。ただ現状は、ビッグトラフィックをさばくサービスのロードバランサーとして独自に実装されている話が少しある程度で、まだ僕たちの身の回りに来ている話ではありません。そのため、コンテナや超ビッグトラフィックで使えるネットワーク技術を学んで次は何か作ろうと考えています。
うづら：XDP は絶対にくると思います。ネットワークは難しいなと思い、トレーシングばかりをやっていますが（笑）
まつもとりー：今聞いてて、XDP がどういう技術か再度お聞きしたくなりました。XDP 中のパケットの処理を eBPF でやっているのが XDP ですか？
P山：内包関係まではわからないです。
まつもとりー：DPDK（Data Plane Development Kit） はカーネルをバイパスするので、パケットの処理が早く、普通のカーネルの処理は TCPスタックなどを通りますよね。ただ XDP は、その TCPスタックを通るのではなく、eBPF のなかで書かれた実装を通ります。
P山：しかも、物理レイヤーまでサポートが必要ですよね？
うづら：物理デバイスごとにドライバーが一通り書かれているみたいな感じですね。
まつもとりー：高速で、ある程度動的な処理を簡単なプログラミングや、eBPF を介したスクリプティングで実装して達成する感じですかね。
うづら：一応 iptables などは今までありましたが、iptables ですとXDPと比べるとカーネルの中では上のレイヤーなので、より根本的な部分でパケットを積極的にフィルターできると思います。
基本的には eBPF のプログラムをそのままアタッチさせて動かすことができて、eBPF 全体のエコシステムの中で開発が進められるので、便利な認識を持っています。
もりたこ：eBPF の話とは別のレイヤーになりますが、僕は kubernetes のポリシーをどう作って運用していくかが、少し課題になっていると思います。
例えば kubernetes には Pod Security Policy と呼ばれる機能があり、マニフェストがセキュアでない場合は、Pod を起動させないとする仕組みがあります。しかしこれが非推奨になってしまったため、別の物で代用する必要が出てきました。
最近ですと、Open Policy Agent と呼ばれるものが出ており、事前に定義したポリシーに対してJSON を食わしてマッチしたらOKという実装をするようなものが出始めています。ただ、代替品を使う一方、Azure や AKS は Azure Policyと呼ばれる、独自のものを持っているケースがあるため、僕はその部分を今後追いかけていきたいです。
P山：kubernetes のポリシーは基本 YAML で書かれていて、宣言はされているが管理できていない部分が結構あると思います。どこに何が書かれてるかわからないことがよくあるので、課題に感じています。
もりたこ：テストもやりにくくなっている部分もあるので、そう考えるとやはりポリシーが積極的に使える時代になるのではないかと思います。
まつもとりー：うづらさんはその辺りどうですか？
うづら：とりあえず eBPF 周りは引き続きやっていきたいです。もしかしたら、2022年の4月、Ubuntu の次のLTS が出る頃には、かなり新しいツールが出ているのではないかと予想しています。その理由として、今まではその場で eBPF のもとになるコードを自動生成してコンパイルするやり方でしか動かなかったのが、スタティックにコンパイル済みの BPF を動かすような技術が出てきて、それに今年の後半ぐらいから移り変わる流れが出てきたんです。
つまり、吊るしのバイナリを落とした場合、そのツールが動かせるみたいな時代がようやく来ました。最近では Ubuntu 20.10 から有効になったカーネルが入りだしたので、次の LTS ではその辺りに対応していきたいのかなと勝手に予測しています。ですので、そういうツールの作り方を調べたりしてます。
P山：eBPF でいうと、strace みたいに気付いたら自分が使っている技術で、裏で eBPF が動いている場合があると思います。
うづら：それはありますね。
P山：ですので、うづらさんがいっていたように、今後は自分で eBPF のツールを作る側面と、身の回りのものが eBPF に置き換わっていく2つの側面が起こりそうですね。
うづら：ファイアウォールが勝手に変わるみたいな。そういうことが起きそうですよね。
うづら：また、まだ触りたてですが、最近 Rust をやっていて、いろんなことができるなと感じています。当然ツール系は強いですが、特に C の FFI がとても強く、不安全と安全な部分を切り分けられる点がすごく気に入ってます。そして、Wasm を出せる点もおもしろいですね。 Wasm はインフラにもくるような気がしていて、触らないといけないなと思っています。
まつもとりー：皆さんのお話を聞いて、コンテナなどを使って、素早くいろんなアプリケーションをデプロイする人たちにとって便利なインフラ技術とは対照に「そのレイヤーでこう動かしたい」ことがあったり、動かしやすい技術が増えているギャップは不思議に感じますが、どう思われますか？
うづら：大きなプラットフォームを持っている会社、こういう言い方はあまりしたくないですが GAFA的なパブリッククラウドのベンダーのインフラの人々が使っているような技術と、スタートアップで課題に集中するためにインフラを効率よく使っていくための技術はわかれていくと思います。ただ、両方をなんとなく知っておかないと、最新技術はすぐキャッチアップできないだろうと思います。もしかしたら eBPF や Wasm を使って、画期的なインフラ技術を生み出して SaaS として提供することが2021年から出てくるかも知れないですね。
まつもとりー：eBPF や Wasm などのキーワードがたくさん出ていますが、自分の興味のある領域から見て、今後この辺りが変化していくと思われる技術はありますか？
うづら：WASI と呼ばれる Wasm の上で UNIX的な一種の規格を作るものがありますが、個人的にそれが結構おもしろいと思っています。現状、CPU が x86 と Armでこのままわかれていく可能性があるので、実際にアーキテクチャが分断された場合、その中間として WASI が来ると思います。ただ、そういったことは今までいろんな言語で経験されているので、今回 Wasm が成功するかはまだわからないですね。
もりたこ：Wasm でいうと、Kubelet を Rust で書いた実装もありますし、Envoy のフィルター部分を Wasm で書けるものも出ているので、ブラウザ以外で Wasm が動く環境がすでにインフラに来ているのかもしれませんね。
まつもとりー：実際 Wasm をはさんで、インターフェースをいろんなスクリプト言語で操作するのはアプロキシの文脈でもそうですし、アカデミアの研究でも小さな OS はすぐに書いて、その上にアプリケーションを動かすものが出て来ているので、ブラウザからはずいぶんと飛び越えて開発や研究がされている印象を受けます。
P山：個人的に Wasm はインフラにコンテナが登場したときと感覚がとても似てい ると思います。コンテナ技術はざっくりといえば、今まで僕らが VM として扱ってたものを、ギュッ！としてパッ！と動かせるようにした技術だと思います。その点 Wasm はアプリケーションの文脈でその役割を果たしていると思います。要はどこでも動くバイナリフォーマットで作れるものが Wasm であると感じますね。
今まで主戦場だったものから技術が飛び越えてコンパクトに動く様子がコンテナと似ていると思います。「似たような技術は似たようなことをすると大体うまくいく」というのは世の常だと思うので、コンテナでうまくいったことは、Wasm でもうまくいくだろうと思っています。
まつもとりー：皆さんだいぶ eBPF が好きそうですが、eBPF はこれからどうなっていきそうですか？またこの辺りの知見はインフラエンジニアとしてどのくらい知る必要がありますか？
P山：今そういった技術が使われているのは、Netflix が主だと思いますが、現状はそのレベルまで行かないと可観測性は求められていないと思います。ただ、何か技術的に勝負したいと思う方や、世の中の真理をもっと知りたいと興味があるのなら、時代が変わろうとしているこの機会に、そういった技術に乗り込んでいくのはアリだと思います。
もりたこ：僕も同意見です。eBPF や Wasm は今のうちに手を出しておくと、先駆者として名前が出るかもしれません。ただ、少なくとも僕がお伝えしたポリシーの話は確実に波が来ると思います。
まつもとりー：もりたこさんは、セキュリティを専門にしているため、セキュリティエンジニアに対する考えなどあると思います。実際、セキュリティエンジニアの観点だと eBPF や Wasm の知識はどれぐらいセキュリティエンジニアに必要だと思いますか？
もりたこ：知っておいたら役立つかもね。くらいの温度感だと思います。セキュリティエンジニアでもやることはさまざまですが、例えば eBPF を知っていたらマルウェア解析の文脈でトレースとして十分役立てるので、学んでおいて損はないと思います。
うづら：システムの可観測性は、どんどん上がっていく方向にあるので、下手したら普通のインフラエンジニアでは扱いきれない情報量が取れる可能性があります。おそらく、サーバーから取れる特徴量が増えて、今までの CPU、メモリ、HDD、ネットワークの4軸にさらに何か増えたりする気がします。そこで私は ML がインフラに来る気がしていて、一応その辺も追いかけないとなと感じています。
P山：僕も似たような課題感がありまして、ディープラーニングなどやらなければと思っていますね。
うづら：最近は結構 ML のライブラリが Rust で増えてきたと感じています。今までは Pythonでしたが、今後は速度的な面から Rust のほうが有利になってくると思います。モデリングのスピードが上がると、下手したら、それぞれサーバーのエッジでモデルの検知が動くようなことも起こるかもしれませんね。
まつもとりー：クラウドの研究開発の文脈でも、システムのさまざまな情報量からどこに最適なデプロイをするかといった研究はとてもホットにされているため、まさにうづらさんが現場から感じた課題感は、研究でもホットに取り組んでいる内容です。
また、エッジでいろんな計算をさせる、エッジAI の研究もたくさん出ているため、現場からの課題感とアカデミアの研究している部分はずいぶんと重なり始めているのですね。
まつもとりー：皆さんのお話を聞いて、興味あるほうに進んでいくと徐々にストーリーがつながっていき、元々自分が思っていた課題感を解決できる技術になっているケースが多いと感じました。最後にそういう目線でも一言もらいたいと思います。
P山：2020年はコロナ禍によって、今まで自分が余暇としていた技術への取り組みがあまりできませんでした。そのため、2021年はマシンラーニングとインフラを組み合わせたものや、今までビッグプレーヤーにしか作れなかったネットワークレイヤーなどの取り組みをおこなっていきたいです。
もりたこ：クラウドネイティブの分野では新しいツールや仕組みがたくさん出ているので、新しい技術に手を出すと視野が広がり、持っている課題を解決できる仕組みに出会えると思います。ですので、そういった感じで今年もやっていきたいです。
うづら：一番大事なのは、自分が面白そうと感じたら、しっかり手を動かしてやってみることだと思います。仕事も自分の興味もしっかりやることでどこかつながる面があると思うので、今年もある意味、投資的に最新技術と現場の問題の両方を追いかけていこうと思います。
まつもとりー：ありがとうございます。ではパネルディスカッションはここで終わりにしたいと思います。パネリストとしてご登壇いただいたうづらさん、P山さん、もりたこさん、本日は大変興味深い話をありがとうございました。
Infra Study Meetupとは？
Forkwellは「成長し続けるエンジニアを支援する」をコンセプトに勉強会を開催しています。Infra Study Meetupは、インフラ技術の「これまで」と「これから」を網羅的に学ぶイベントです。インフラ技術の各分野に精通した講師を招いた講演や著名エンジニアによる発表を実施しています。
※注意事項
当記事に掲載されている全ての情報は、イベント実施日時点の情報であり、完全性、正確性、時間の経過、あるいは情報の使用に起因する結果について一切の責任を負わないものとします。
さくらインターネット研究所の上級研究員、京都大学博士(情報学)、複数社の技術顧問。インターネット技術に関するミドルウェアからOS辺りの研究開発やエンジニアリング、組織整備や組織文化醸成、EM、PdMも専門。2018年 Forkwell技術顧問就任。
;?>/images/ico/ico_blank.svg){kind=spacer}
