大学生活振り返り
香川県で大学生をしており、この度工学の修士を修了したので、 大学生活6年間の振り返りをしたいと思います。
大まかな経歴
- 2013年4月 島根県立出雲工業高等学校電気科 入学
- 2016年3月 島根県立出雲工業高等学校電気科 卒業
- 2016年4月 香川大学工学部 電子・情報工学科 入学
- 2018年2月 GMOペパボ株式会社 福岡支社 インターンシップ
- 2018年8月 株式会社はてな インターンシップ
- 2020年3月 香川大学工学部 電子・情報工学科 卒業
- 2020年4月 香川大学大学院工学研究科 信頼性情報システム工学専攻 入学
- 2020年8月 サイボウズ株式会社 インターンシップ
- 2020年9月 ヤフー株式会社 インターンシップ
- 2022年3月 香川大学大学院工学研究科 信頼性情報システム工学専攻 修了
B1-B3
プログラミングサークル
B3まではSLP というプログラミングサークルに所属していました。 poulenc.eng.kagawa-u.ac.jp
研究室に配属されるまではプログラミングサークルでWebアプリを作ったり、 サーバ構築の勉強したり、MacBook ProにLinux入れて遊んだりしてました。
サークルに所属するまでは、Linuxに触れたこともなく、ちょっとプログラミング言語に何個か触れたことがある程度でした。 Webやネットワークに関する知識もありませんでしたが、サークルの活動などを通して多くのことを学ぶことができました。
インターンシップ
B2の2月、B3の8月-9月にインターンシップに参加させていただきました。 多くの技術を学ぶことができましたが、ふわっとしていた自分の目指したいエンジニア像や、 企業で働くということについてより具体的になっていったと思います。 そして、インフラ系のソフトウェアエンジニアがやりたいと思うようになりました。
その他の体外活動
B4
卒業論文
卒論シーズンなので卒論に集中してました。 当時は1年を通してシステムを開発することがこんなに難しいのかと思っていました。 自動テストやCIの導入を行い、継続的な改善活動を行うことの大切さを実感できました。
テックカンファレンスへの参加
テックカンファレンスを見に行くために福岡や東京に行ったりしました。 技術的な知見を多く得られました。 また、僕自身こういったカンファレンスで発表できることに憧れ、 就職するときにはこういったカンファレンスに参加している企業を見てみようと思うようになりました。
2019年に参加したカンファレンス
- Ruby会議
- CloudNative Days Fukuoka 2019
- CloudNative Days Tokyo 2019
M1
基本的には大学院の講義、インターンシップ、就職活動、研究システムのプロトタイプの開発に追われた一年間だったと思います。 また、コロナ対策にドタバタして遅れをとってしまった年でもありました。
リモートワーク環境の整備
大学院の講義はリモートになったばかりで色々と慣れるのも大変でした。 デスクトップPCの性能を盛って、4Kディスプレイを買って自宅の環境を強化していました。
メインPCはこんな感じの構成になりました。
- CPU: Intel Core i9 10900K
- GPU: NVIDIA GTX 1050Ti
- RAM: CORSAIR DDR4-3200MHz CMK32GX4M2D3200C16 16GBx4
- SSD: WD SSD SATA 1TB WDS100T2B0A-EC
- マザーボード: ASUS PRIME Z490-A
- 電源: CORSAIR CP-9020196-JP
- CPUクーラー: CORSAIR CW-9060044-WW [簡易水冷CPUクーラーiCUE H115i RGB PRO XT]
- Display: Dell U2720QM 27インチ 4K モニタ
- OS: Windows 10 Pro
研究活動、研究室のアレコレ
研究については、COVID-19対策のため、リモート環境の整備にドタバタしてあまり進まなかった気がします。 就活もあるので、プロトタイプの開発と評価実験を軽くやる程度で論文はかけそうもないということで指導教員の先生とも合意していました。 基本的に大学に行くことはほぼありませんでしたし、研究室に関することはほぼ何もやっていなかったと思います。 唯一やっていたのは、研究室でVagrant、Ansible、Docker に関する勉強会をやっていました。
進路
進路に一番悩んだ1年間だったと思います。
インターンシップには2社参加させていただきました。 どちらもオンプレミスの自社インフラを持っている企業でした(Cybozu, Yahoo)。 インターンシップではOSSをやったり、チーム開発の経験を積むことができたりで大満足でした。
就活の軸としては、 「オンプレミスの大規模なインフラを持っていて、ソフトウェアによってスケールするインフラストラクチャを必要とする企業でソフトウェアエンジニアをやりたい」 という感じで働ける企業を探していました。
3社受けて2社内定をいただけたので、無事就職活動を終えることができました。 それまでに多くの企業の方々や大学の先輩方に進路の相談に乗っていただきました。 おかげさまで無事就職することができました。ありがとうございました!!
M2
M2になって、コロナもそこそこ落ち着き、大学にも行くようになりました。 本格的に修論のテーマに取り組んでいくために大学に行くようになりました。
研究室内の勉強会
M2になっても研究室で勉強会を行っていました。 Infrastracture as Code, 自動テスト, CI, コンテナといったテーマを扱いました。
研究室のサーバ管理
研究室のサーバの管理をやるようになりました。 現状、物理サーバの管理に関する知見が更新されないままになっていたので、 誰も使っていないけど、誰も手を出せないサーバたちとなっていました。 そのため、研究室でサーバ管理チームを作って知見の共有と一括で管理する仕組みの導入を行っていました。
詳しくは今後ブログにまとめようと思います。
副指導教員との出会い
今年大学に来られた講師の先生が副指導教員になってくださいました。 Linux カーネル、ストレージ、システムパフォーマンス、クラウドコンピューティングなど多くの技術的な知見が得られました。
研究活動
研究会と、国際会議で1本ずつ論文を執筆しました。 コンテナのセキュリティポリシーに関する研究テーマでした。 国際会議の論文を書いているときには自信やモチベーションが低下して、いろんなやる気が無くなっていましたが、 最後にはやってよかったと自信を持って言えます。
今後も続けていきたいという気持ちが大きいので、 なにか成果が出たら公開したいです。
OSS活動
OSS活動もたまにやっていました。 インターンでRookというOSSにコントリビューションをしたのがきっかけで、興味があるプロダクト、自分が使っているプロダクトの開発に関わりたいと思うようになりました。
実際にyoukiやkubesprayにコントリビューションしました。 ライブラリの更新やバグフィックスなどが主でしたが、良い経験になりました。 時間ができたので、再開しようと思います。
大まかな振り返り
やってよかったこと
やっておけばよかったこと
- 英会話
- 海外旅行
- IT企業で長期インターンやアルバイト
謝辞
この大学生活6年間で多くの方々にお世話になりました。 指導教員、副指導教員の先生方には研究の方針の相談、 技術的な情報交換の数々、論文の指導などなど数え切れないほどお世話になりました。 大学の先輩方には、進路に関するアドバイス、技術の話などなど多くのことを相談させていただきました。
他にも大学や研究活動で出会った方々、 インターン先でお世話になった方々、 Twitter でいつも絡んでくれた方々、 勉強会やカンファレンスでお話をさせて頂いた方々などなど、 多くの出会いのおかげで、多くのことを学ぶことができた6年間でした。
最後に、6年間もの大学生活のサポートをしてくれた家族には頭が上がらない気持ちです。 おかげで熱中できるものが見つかったので、これからも精進していきます。 皆様、本当にお世話になりました!
今後
今年度から東京でソフトウェアエンジニアになります。 自分のスキルが通用するのか、不安ですが頑張ってやっていこうと思います。 しばらくは社会に慣れるのに時間がかかると思いますが今後ともよろしくお願いいたします。
2021年振り返り
なかなか尾更新頻度が上がらないことが悩みの今日このごろ 毎年書いてる振り返り記事だけは書いておくことにしました.
今年は僕にとっては最後の大学院生活でした. そのため今後の将来を決めるイベントが多い年だったと思います.
1-3月
就職活動と研究で潰れていたような気がします. 無事に内定も頂いて来年から東京でソフトウェアエンジニアをやることになりました.
研究に関しては,この時期に修士論文で取り組むテーマをほとんど決めてPoCを作っていました. また,研究室内でコンテナの勉強会を行っていました. コンテナ型仮想化の概論と,Docker周りの How to を教えたりしていました. 今年もやりますが,もうちょっとHack的なことも書こうと思っているので,大幅に改定する予定です
また,研究室のサーバ管理者として本格的に動き出しました. ちょうど Ubuntu 16.04 LTSのEOL の時期が近かったので管理体制を変えたりしていました. 具体的には,チーム体制でサーバ管理をするようになったこと,AnsibleによるHypervisorの構成管理,GitHubベースでのドキュメンテーション及びコンフィグレーションなどです. そのため,今年はチームでやることを意識することも多かったです.
4-6月
この時期は就職活動がほぼ終わり,研究室周りのコミットが多かったと思います.
システムソフトウェアとオペレーティングシステム研究会への論文投稿を行いました. システムコールフィルタのルール生成に関する研究について投稿しました.
また,この時期は研究室のインフラ基盤の技術検証を行っていました. OpenStack などのOSSの検証しましたが,フルタイムで管理できる人間が複数人いないとしんどそうということ, 規模の割に管理コストが高すぎるということでやめました.
7-9月
修士論文の中間発表に向けて研究成果をまとめたり, 国際会議に出すために英語論文を書いている時期でした. この頃は1番研究へのモチベーションが低下していたので,論文の進みが悪かったです.
また utam0kさんが開発しているRust製コンテナランタイムの開発をお手伝いさせていただきました. github.com
10-12月
ようやく重い腰をあげて英語論文を投稿しました. 発表のためにラスベガスに行きたかったのですが,COVID-19の関係で断念しました. 英語で話すことが普段無いので,色々ハードルが高かったのですが今ではやってよかったと思っています.
あと勉強会で初登壇しました. めっちゃ反応もらえて楽しかったです.
まとめ
英語論文書いたり,サーバ管理したり,OSSにパッチ投げたり,今までないことをたくさん経験できた一年でした. 大学生活も残り少なくなりましたが,修士論文というラスボスが残っているのでやっていきたいと思います.
来年は東京で働くことになるので楽しみです. みなさま良いお年を
Okteto Cloudの検証メモ
開発環境向けにクラウド上にKubernetes Clusterを提供するOkteto Cloud
の検証を行った.
モチベ
- 研究室内の勉強会用の Kubernetes の開発環境がほしい
- 自宅のステージング環境がほしい
- 研究の関係でマルチテナンシーの Kubernetes as a Service のセキュリティが気になった.
Pricing, Plan
- GitHubアカウントがあれば無料で以下のリソースが使用可能(Developper Plan)
- namespaceを5個まで作成可能
- 1namespaceあたり10個までpodを作成可能
- 1namespaceあたり5GBのStorageが利用可能
- Developper Pro Planもある
RBAC(Role-Based Access Control) やPSP(Pod Security Policy) の検証
- Pod Security PolicyやRBACのルールが公開されている https://okteto.com/docs/cloud/multitenancy/#pod-security-policies
- kube-systemなどクラスタ自体を構成するためのnamespaceへのアクセス権は与えられていない
hostNetwork
,hostIPC
,hostPID
,privilege
などホストの権限を得るオプションは使用不可- CRD(Custom Resource Definition)は作成不可
その他機能面
- Kubernetes 1.20.x系が固定で使用可能
- GitHub連携でリソースを適用することができる
okteto-pipeline.yml
をリポジトリに入れてpushすることで自動デプロイ- pipeline内で使用可能なツール https://okteto.com/docs/cloud/okteto-pipeline/index.html#built-in-tools
- 外部公開も可能, マネージドSSL証明書の発行も可能
- Ingress (L7 LB)も作成可能
- Self Hostもできる(今回未検証)
備考
- 簡単に利用できる公開用のKubernetes Clusterとしてはめちゃめちゃ良い
- ここまでしっかりCluster内部の権限を絞っているということは,マルチクラスタではなくマルチテナントでクラスタをユーザに提供している可能性が高い.
- そもそもクラスタの用意にさほど時間がかからなかった(Clusterを作成するなら普通は15分ぐらいは要する
- Kubernetesにアプリケーションをdeployするためのテストサーバ程度に良さそう
- Pull Requestごとにdeployして検証するみたいな
- 逆に本番環境の複製として構築しようと思ったらCRDが作成できなかったり,権限が足りないといった問題が出てくる
- 実際flux2のdeployに失敗した
- namespaceの作成が
kubectl create ns XXX
でできず,okteto-cliかWeb UI経由でないとできないのがちょっと不便 - Kubernetes勉強会のintroductionには良さそう
2020年振り返り
今年の記憶がコロナで掻き消える前に,今年あった出来事を振り返ろうと思う. そして,来年の抱負を書いておく.
1月
- IPSJ全国大会の論文の執筆
- 卒論の執筆
2月
- 卒論の発表
3月
4月
- 香川大学大学院 工学研究科 信頼性情報システム工学専攻 入学
5月 - 7月
- ひたすら大学院の講義
- インターンシップに応募
- 新しいメインPCを組んだ
8月
9月
- Yahoo インターンシップの参加
10月 - 12月
- バイト(ヘルプデスク)を辞めた
- 研究,講義,就活の3つに苦しめられる
2020年 まとめ
思ったより就活に体力と時間を使った一年だった. まだ選考中の企業があるため,どこに就職するかは確定していないが,基盤系のソフトウェアエンジニアをやりたいと考えている.
大学院生になって思ったことは講義が予想以上に忙しかった. それで研究,講義,就活を同時進行して生活が大変なことになってしまった.
新しいマシンを組んでその上で好きなだけKubernetesで遊べるようになった. 研究システムのデプロイや,いろんな検証環境に使っている. あとはストレージ周りをいい感じにしたいので,色々思案中.
2021年の抱負
研究,講義,就活をある程度やったおかげか,単位もなんとか取れそうで,内定も頂いたので,来年度は研究に集中することができそう. 他にも勉強したいことは山程あるので,大学にいるうちにいろんなことを勉強しようと思う.
あと,今年こそブログの更新頻度をあげようと思う. ゼミの自分の週間報告にブログにしたら面白そうな技術系の話がいくつかあるので,これらをパブリックにする癖をつけたらいい感じに更新頻度も上がるんじゃないかなあ.
来年勉強していきたいこと
- Kubernetes
- 大学みたいなあまりスケールしない環境では必要に迫られにくく,家で細々とやっている.
- 業務では使うだろうから,How toだけでなくアーキテクチャへの理解を深めたい
- eBPF
- 今はトレースツールを書いて,研究のベンチマークとかで使ったりしている程度
- libebpfやCO-REが気になっている
- OS
- x86 OS自作本を途中まで読んで積んでいる…
- RustでOSを作ってみたいと思っている
- Network
- CNI(Container Network Interface) あたりを追っていくのにもうちょっと基礎的な知識をつけたいかなあ.
- XDPとか触ってみたい
- 英語
- Reading やListeningだけじゃなくてWritingを鍛えたい
- 英語論文かけたら良いなあ
コンテナイメージ(の依存)はどの程度小さくすべきか?という話
全国のDockerfile職人の方々,コンテナイメージのダイエットはどのようにやっていますか? 今回はコンテナイメージの容量というよりは,依存を小さくするという意味で, コンテナイメージ内にシェルやcoreutilなどを入れるかどうかといった話について,議論したのでその内容をまとめていきたいと思います.
コンテナイメージを小さくすると何が嬉しいのか
コンテナイメージの容量を小さくするという観点だと,デプロイが高速になるため,スケールアウトするのが速くなります. また,依存を減らすという観点でいうと,脆弱性を利用した攻撃対象領域(attack surface)が少なくなります.
(余談) 後述するようなscratchにバイナリを配置するだけのコンテナイメージなら,アプリケーションしか実行しないので, Linuxのセキュリティ機構であるseccompやAppArmorの設定もアプリケーションにフィットした設定を用いる事ができると思います.
どうやってコンテナイメージの容量を小さくするのか
コンテナイメージをダイエットさせる方法としてaptなどのパッケージマネージャのcacheを消す,マルチステージビルドを使う,Alpine Linux, Scratchなどの容量の小さいイメージをベースに使うなどのテクニックを使います. ここではあまりそれらについて深く言及はしません.
これらのテクニックを用いて,コンテナイメージの容量を小さくするのは良いのですが, どこまでコンテナイメージを小さくさせるべきなのでしょう. 極端な話,コンテナ上で動くアプリケーションがGoの静的リンクされたバイナリであれば,以下のようなコンパイルしたあとscratchに配置するだけで軽量なイメージが作れると思います.
FROM golang:1.15-alpine3.12 as builder WORKDIR /src RUN apk add --no-cache make COPY go.mod . COPY go.sum . RUN go mod download COPY . /src RUN make build FROM scratch COPY --from=builder /src/bin/hello /hello ENTRYPOINT ["/hello"]
Kubernetesなどで使われているCoreDNSの公式イメージなどはまさにそのように提供されています.
しかし,ベースにscratchを用いるとシェルも無ければlsもcatもありません.
そのためコンテナ内で docker exec
や kubectl exec
でシェルを実行したり,デバッグ用のコマンドを使うことができません.
これは運用時つらいからベースをalpineやubuntuにしているという人が自分の観測範囲では多い気がしています. 検証などでシェルで入るのが手っ取り早いから,catでコンテナ内部のファイルの状態を見たいからなどの理由だと思います.
コンテナイメージにシェルやcoreutilって必要なのか?
そもそもcatやls,bashがコンテナイメージになくてもデバッグや検証とかできるんじゃないか?という仮説を考えてみます. 一応,ここではコンテナ内部に入ってアプリケーション自体に変更を加えるということは除外します. シェルやcoreutilなどが必要のない,アプリケーションだけが入ったコンテナイメージを運用する上で障害になることをいくつか考えました.
- Q1. そもそもメトリクスやログを適切に吐いていればシェルがなくても問題ないのでは
- ログやメトリクスを適切に吐くことが一番難しい
- 必要なメトリクスがなかったらコンテナホストか,コンテナ内にツールを入れたり,メトリクスツールに変更を加える必要がある.
- Q2. コンテナの中にシェルで入る必要はなくて,コンテナホストからプロセスが見えるんだからホストから見れば良くないか?
- Q3. コンテナの中にログファイルがあるけどシェルがなかったら読めないよね?
- ログはstdout, stderrに吐いてたりしてください
- Q4. そもそもアプリケーションがシェルに依存しているんだが?
- それはシェル入りのコンテナ使ってください
- Q5. 開発ではシェルが入ったコンテナを使っているが,本番環境と開発環境で違うコンテナイメージを使うというのはアンチパターンじゃないか?
- 環境ごとに違うイメージを使うのはアンチパターンだと思うけど,ビルド引数とかでビルドステージを切り替えて,ビルドステージ,実行ステージで分けて使えばいいんではないだろうか.
コンテナイメージ内に検証などでシェルやcatなどのコマンドを使ってデバッグしたかったら十分にOveservabilityの仕組みを導入することとが必要で,コンテナ内に状態を持たせないことが必要かなと. また,外部コマンドに依存したアプリケーションはその外部コマンドの脆弱性を定期的にスキャンしながら同梱したイメージを使えばよいのではなかろうかと.
まあ,PythonやRubyみたいな言語はそもそも言語処理系をアプリケーションのコンテナイメージに入れる必要があるので,今回の話はシングルバイナリを吐ける言語が前提なんてですけどね….
まとめ
コンテナイメージをどこまで小さくするかはワークロード次第ですが,シングルバイナリのアプリケーションに限って言えば,十分にOveservabilityが確保できていて,開発にも支障がなければscratchベースだったり,シェルや他の依存が全く無くても良いと考えています. でもそれでも心理的にシェルがあったほうが安心だという気持ちはとても良くわかります.しかしマニュアル運用をできないようにシェルをコンテナイメージから無くすべきなのかもなあと思う今日このごろです.
もうちょっと運用サイドのエンジニアの方々の意見も聞いてみたいと思います. 実際,自社でscratchベースのコンテナイメージを自分たちで作ってホストしている方々ってどれぐらいいらっしゃるんでしょうね.
シェルなどが入っていないコンテナイメージをデバッグ,検証したかったら,KubernetesのEphemeral Containerあたりを使ってデバッグするのも良いと思います. 次回あたりにKubernetesのEphemeral Containerの機能を深堀りして使ってみたときのアレコレを書いていきます.
2019年振り返り
お久しぶりです。毎年恒例の振り返り記事です。
今年の取り組み
1. 初のISUCON予選参加
大学の先輩2人とチームを組んで出場しました。自分はNginxのHTTP/2化や静的ファイルのサーブなどをやってました。来年ははじめに計測をシュッとできるようにツール群を用意できるようにしたいですね。APMの計測をしなかったために気づけなかったボトルネックがあったので。本戦にいつか出たいので、精進します。来年組んでくれる人を募集しています。
2. Cloud Nativeへの取り組み
CNDT(Cloud Native Days Tokyo), CNDF(Cloud Native Days Fukuoka)などのイベントに参加し、Kubernetesなどの技術を中心にCloud Nativeに関する取り組みを学びました。
自分や周囲を見ているとKubernetesを導入することより、CI/CDや自動テスト、ステートレスアプリケーションの実装などに注力していくことがCloud Nativeへの近道なのかなあという印象です。
研究や業務等で分散システムの設計を行うときなどに活かせるようにやっていこうと思います。
3. 卒業研究本格始動
研究室に配属されたのは去年の10月で、研究テーマを決めたのが今年の4月からでした。 論文を読んだり、研究システムの実装をするのはとても楽しかったです。 研究システムの開発にも、インターンや個人開発で学んだことを活かすことができてよかったと思います。自動テスト、CI/CDの導入など、システムの保守を行いやすくするための取り組みで、実装はストレスなくできたと思います。
最近の関心事は、ContainerやBPF、WebAssembly Runtimeなど、Sandboxを構成するための要素についてです。
来年度に向けて
そろそろ自分の方向性を決めねばならないと思っています。自分は運用がしたいのか、開発がしたいのかまだはっきり決められていないのが現状です。ただ、どちらかというと基盤開発がしたいという気持ちはあるので、Software Engineerを目指しています。
就職活動
来年は就活なので、企業の方々はよろしくお願いいたします。
- 希望職種: Software Engineer, Site Reliability Engineer
- 分散システムの基盤となる技術、システムの開発を行いたい
- 勤務地: 東京or福岡希望
- OSS活動もしたい
- RustやGoを書くようなお仕事がしたい
自分の技術スタック
正直どれも浅い感じはしますが、ちょくちょく触ってるのは以下
- Language: C, Rust, Go, Python, Ruby, JavaScript
- Platform: Kubernetes, Docker, KVM, AWS, GCP
- Web: acitix-web, tonic, echo, Ruby on Rails, Vue.js, gRPC
- Monitoring: Elastic Stack, Prometheus, Grafana
- Database: MySQL, PostgreSQL
- Research: Container, Linux system calls, BPF(eBPF)
- Other: Nginx, Apache
詳しくはWantedlyで
CloudNative Days Tokyo 2019にスカラシップで参加した話
遅くなりました 7/22, 23のCloudNative Days Tokyo 2019に参加してきました。 人生初東京なのでいろいろ戸惑いながらの参加です。 CNTD2019の学生スカラーシップ枠で参加させていただきました。
参加理由については、KubernetesやOpenStackについての企業の取り組みなどを知ることができる良い機会だと思い、参加しました。 また、企業の課題感を知ることで、研究の方向性などに活かして行きたいです。
CNDT2019のテーマ: 「+Native」
今までよりもっとクラウドにネイティブに、クラウドにのせただけではなく、
よりクラウドに適した形にというものでした。
CNCF landscapeのロードマップや、自分たちのプロダクトが抱えている課題に向き合って、
システムの基盤を変えていきたいと思うようになりました。
各セッションについて
以下、自分が聴講したセッションについていくつか抜粋して紹介します。
How Kata protects containers
Kata Containerのアーキテクチャの話。 VMで使用するカーネルの変更、QEMUの代わりにIntelのnemuを使うことも可能とのこと。 資料はあげられてないっぽい?
OCIv2?!軽量高速なイケてる次世代イメージ仕様の最新動向を抑えよう!
今後のOCIの標準化仕様についての話 。 Runtime, Image, Distributionの中で、Image, Distributionの話が多かった気がする。
OCIv2?!軽量高速なイケてる次世代イメージ仕様の最新動向を抑えよう!
Prometheus setup with long term storage
サーバ監視ツールであるPrometheusのメトリクスなどをどう保持するか、どう冗長化するかという話
Prometheus setup with long term storage - Speaker Deck
実録!CloudNativeを目指した230日
GMOペパボのOpenStack上でのアプリケーションの運用から、 OpenStack上にKubernetesを構築し、 その上でアプリケーションを稼働させるようになるまでの話。
実録!CloudNativeを 目指した230日 / cloud-native-days-tokyo-2019 - Speaker Deck
最近のDockerの新機能
セッション当日に発表されたDockerの新機能についての紹介。 GPU対応、非特権モード、Buildkitによる高速なビルド、その他プラグインなど。
How cgroup-v2 and PSI Impacts Cloud Native?
Cgroup v2とCgroup単位での負荷を見るPSIというカーネルの機能についての話。 Cgroup v2へのOCI対応状況についてや使用方法について。OCIで規格が定まるのはまだ先の印象。 また、PSIはプロセス単位で、ロードアベレージのように負荷状況を取得できるカーネルの機能。 Linux 4.20から使用可能。
How cgroup-v2 and PSI Impacts Cloud Native? - Speaker Deck
まとめ
実際にKubernetesで運用を行う知見や、企業の課題感を知ることができました。 クラウドにのせることを目的とするのではなく、回復性、管理力、可観測性を意識しながら、 課題を解決するためにシステムの基盤を改善できるエンジニアになりたいと思うようになりました。 また、自分の研究がコンテナランタイムについてなので、周りに色々聞いてみると、 「Kubernetesを使いこなすのに精一杯でRuntimeまで手が回ってない」 という反応がぼちぼちあったので、色々課題感の乖離を感じました。 今後、Kubernetesが成熟してもRuntimeまで手を入れて、クラスタを組むのはクラウドベンダと、ごく一部の企業ではないかという印象を受けました。
余談と後日談
人生初東京の感想
- 人がいっぱい
- 電車の頻度すごい
- 店の中とか基本的に狭い
福岡のほうが好きかも…。ご飯美味しいし
香川に戻って風邪ひきました。4日ぐらい布団で寝込んでました。 ちゃんとした栄養とってなかったのと、空気が悪かったのと、室内と外との温度差、旅行による疲労っぽいです。