しんぶんぶん

しんぶんぶんのブログ

強迫観念駆動人生へ愛を込めて

はじめに

自分は最近までかなり強迫観念に囚われて生きてきたのですが、最近それが薄れてきて今までの生き方を俯瞰的に見れるようになったので、いったん文章をしたためてアウトプットしておきます。かなり雑多な文なので読みにくいかもしれません。

共感を呼ぶような生き方ではないので、こんな人もいるんだなくらいで読んでください。共感してくれる人がいたら頑張って生きていこうなという気持ちです。

強迫観念駆動人生

自分は以下のような強迫観念を最近まで抱いていました。

  • 何者かにならないといけない
  • 何か大きいことを成し遂げないといけない
  • 常に手を動かし続けないといけない
  • 無駄なことをやっている暇はない
  • 技術をやらないと死ぬ
  • 技術的に価値のない自分に生きている価値がない

強迫観念はどこからきたのか

そもそも強迫観念には、環境や人などの外的要因と、自ら植え付ける内的要因があると思っています。

外的要因

まず自分の外的要因として一番大きかったのは筑波大学のAC入試に落ちてしまったことです。今は会津大学にいるのですが、会津に来てしまったからには入試の失敗を取り返さないといけない、何か成果を出さなくてはいけない、何者かにならなくてはいけないと思っていました。

また、増幅させる原因として自分の観測範囲に強い人がいすぎたという問題があります。特に一番悪影響だったのはTwitterで、TLを見ればすごい人ばかり流れてきます。全人類未踏採択されてる、全人類セキュリティキャンプ受かってる、全人類ラボユース採択されてる、全人類起業して資金調達してるし、全人類暖色コーダーのような錯覚をしてしまうのです。

基本的に大学1年からはずっとこのような劣等感に苛まれて生きてきました。

ただ、一般的な人間はこのような劣等感だけでは前述のような強い強迫観念は生まれないと思います。ここまで増幅させた一番の原因は以下の内的要因です。

内的要因

とりあえず「強くならないといけない」程度の強迫観念を外的要因により植え付けられた自分は、強くなるためにもっと強迫観念を増幅すれば良いのではと考えました。そこで、入学した会津大学で実力に見合わないポジションを取り「しんぶんぶん」という虚像を作れば、実体とのギャップを埋めるために死ぬ気で努力するから強くなれるという手法を試します。

自分の手札には「ハッカソン受賞歴」「高校生ながらインターンに行っていた経験」「共著で商業誌を執筆した経験」などがあったため、これらをうまく使いながら本来の自分より数倍も実力があるようなふりをし、「イキリ力」で「技術的にめちゃめちゃ強い人」というポジションを取りました。

もちろん自分より技術のできる人なんて大学にたくさんいるので、下手なムーブをするとすぐボロが出ます。ボロが出て周りに失望される前に自分の実力を上げてそのギャップを埋める必要があるため、死ぬ気で頑張らなければいけないのです。失望される恐怖はとても強い燃料になります。

自分はこのような状況を作り出すことにより、とても強い強迫観念を自分に植え付けることができました。

自分のアイデンティティ

強迫観念を増幅させるもう1つの要因としてあったのが、自分のアイデンティティがコンピュータにあったことです。

中高生の頃からコンピュータをずっとやり続けていると、だんだん自分のアイデンティティがコンピュータに寄ってきます。特に自分は高校生の頃からコミュニティに出て色々な大人に褒められて承認欲求を満たすという経験をしていたので、自分に関する価値はコンピュータに依拠する部分がかなり大きいと思っていました。

前述の通り、Twitterには(外から見ると)天才(に見える人)がたくさんいます。そういう人たちをみると自分はこいつらに勝たなければいけないという強迫観念が生まれてきます。なぜなら、そいつらに負けると自分のアイデンティティが揺らいでしまうから。

強迫観念が増大すると何が起こるか

自分は1日15~20時間くらいずっとコンピュータを触り続けている生活になりました。大学のオープンスペースの一角を占有して、朝起きてから寝るまでコンピュータをやり続け、限界に達したら寮に帰る or 大学のソファーで寝るといった具合です。

最初の方はアドレナリンが出続けどうにかなったのですが、半年くらいたってだんだんキツくなってきて、ちょっとセーブしつつそれでも1年半くらい続けていたら精神がぶっ壊れました。

周りへ与える影響

強迫観念に囚われているとまわりにもそれを振り撒いてしまうことが起こります。技術をエンジョイしている人をみると、「俺は命をかけてやっているのにこいつらはなんなんだ、カスなのか?」という気持ちになってくるのです。命をかけて技術をやっていない人間がだんだんゴミに見えてくるし、自分の信じている評価軸が技術一辺倒になるため、技術でしか人を判断できなくなります。そのような調子でまわりにも命を削ることを強要すると、友達がいなくなります。

実力に見合わないポジションを取ることの危うさ

前述の通り失望に対する恐怖は強迫観念の燃料になるのですが、やはり気付く人は本当の私の実力がわかってしまいます。このやり方をすると本当の実力者から嫌われる危険性があります。

また、当たり前ですがまわりの評価に対して自分の実力が見合っていない状態はとても精神的負荷がかかります。やってる間はずっと精神的に辛いし、やり続けると結果的に精神が壊れます。

強迫観念駆動人生で得たもの

マイナスのことばかり綴ってきましたが、リスクを取る分やはり得るものはかなり大きいです。当たり前ですが毎日十数時間コンピュータを触り続ければかなりできるようになります。最初はただのイキリ野郎でしたが(まぁ今もそうなんですが)、とったポジションに見合うとまではいかなくとも、大学生にしてはそこそこできる方なんじゃないかというレベルの実力はつきました。

ただ、逆に言えばこれだけやってもこの程度の実力しかつかなかっため、とったリスクに大して十分なリターンがあったとは言えないなと思っています。

強迫観念を薄れさせるには

自分と同種の強迫観念を持っている場合は、ある程度現状の自分に満足することが一番の近道です。自分の場合は、作り上げた虚像と現実のギャップがある程度埋まり、他者の評価軸でもある程度戦っていける実力や実績がついた時に強迫観念がだんだん薄れてきました。結局、一度強迫観念を持ってやり始めてしまったら、どれだけ苦しくても満足いくまでやり切るしかないと思っています。精神がぶっ壊れるのか自分が満足するのか、どっちが早いかのチキンレースです。

ただ、薄れさせることはできても完全に無くすことは難しいです。自分も薄れた時期はありましたが、周りの環境がちょっと変化するとすぐに再燃しました。今の自分は安定していますが、自分の精神が未熟な限りずっと付き纏われるんだろうなと思っています。ただ、結局厨二病を拗らせているだけなので精神が成熟したらなくなっていくものなんじゃないかという希望的観測もあります。

それでもコンピュータは嫌いになれなかった

どれだけ苦しくてもコンピュータのことだけは絶対嫌いになれませんでした。結局どこまでいっても自分はコンピュータが本当に好きなんだろうなという確信は持てました。好きだからこそ苦しくてもここまで続いた部分はかなりあると思います。

死人に口なし

ここまで色々かいたものの、結局これは全部生存バイアスです。死人に口なしなのです。自分はたまたまある程度ものになりましたが、間違っても真似はしない方が良いと思います。ただ、人生いろいろあるので、自分の命をかけてでも成長しないといけない場面があるかもしれません。そのような場面にぶち当たった時にこのブログを思い出して「そういや1人同志がいたな」と思ってもらえると僕も嬉しいです。

おわりに

適度な強迫観念を持つことは効果的ですが、いきすぎるとこうなるという一つの事例でした。やっぱりコンピュータは適度に楽しむのが一番良いと思うのです。みなさんは適切な摂取量で素敵なコンピュータライフを送ってください。

学生エンジニアコミュニティに対するお気持ち

学生エンジニアコミュニティに対するお気持ち

はじめに

Twitterで「就活エージェントがバックについてる学生コミュニティってどうなんだ?(意訳)」みたいな話題が上がっており、学生エンジニアコミュニティについていくつか思うところがあったのでつらつらと書いていきます。かなり雑多な文章なので「はぇ〜そんな考えの人もいるのか」くらいのノリで読んでください。

全体を通して言いたいことは「一括りに学生エンジニアといえどみんな向いてる方向は違うから、自分に合ったコミュニティが見つかると良いよね」という話です。

みんな向いている方向が違う

これは学生云々関係ない話ですが、そもそもお金稼ぎのために技術をやっている人もいれば好きでやっている人もいます。同じように学生にも、就活のために実績を作っている人もいれば、就活とは全く関係ない技術ばっかりを好きでやってる人もいれば、自分が好きでやったことが就活につながれば嬉しいなぁというスタンスの人もいますよね。

向いている方向が違う人たちが相容れないのは当たり前の話なので、棲み分けかなと思っています。

学生エンジニアコミュニティを分類してみよう

じゃあ指向性はどのように分類できるのでしょうか?僕が今まで所属していたコミュニティを例に挙げていくつかに分類してみます。

100%好きでやっている人たち

SGG(すごくなりたいがくせいぐるーぷ)

僕が高校生の時に友達と一緒に立ち上げた、高校生エンジニア中心のコミュニティです。

このコミュニティは高校生が主体で運営しているため、お金稼ぎとか就活とかが介在する余地がありません(まだそのフェーズではないので)。そのため、ほぼほぼ100%好きでやっている人たちが集まっている印象でした。

TOGATTA SERVER

僕が最近立ち上げたコミュニティです。社会人も入れるので厳密には学生コミュニティではないのですが、一応例として挙げておきます。

このコミュニティは加入条件が「アクティブな技術オタク」なので、技術オタクじゃない人はそもそも入れないようになっています。また、ほぼ内輪だけでやっているので好きなことをいくらでも話せます(とはいえある程度外に開いていいないと新しい人が入ってこないので、参加登録すれば毎回のLTは誰でも聞ける形にしていますが)。

少し就活色のあるコミュニティ

Zli

僕が代表をやっていた会津大学の技術系サークルです。

Zliは基本的には技術が好きな人とか興味ある人が集まる形になっているのですが、「就職のために大学に入ってきた人」もたくさんいるので、「就職のために技術を学びたい」人もたくさんいます。そういう意味では、Zliは2つのタイプが入り混じっているコミュニティになります。

また、企業を呼んで合同LT会を開いたりもしています。これは、協賛金をもらって活動資金を得るため、学生の企業に対するアピールの場にするため、企業のことを知るためなどの目的があります。総じて、参加学生の主目的はやはり「就活につなげるため」というところが大きいでしょう。

就活色が色濃いコミュニティ

就活エージェントなどがバックについているタイプのコミュニティですね。 運営側としては採用につなげるのが目的で、入ってくる人も就活に繋げるのが目的なので、必然的に就活職は色濃くなります。

学生エンジニアコミュニティの持続性について

最初は好きでやっている人が集まっていたのにだんだん就活色が出てきてしまったというパターンは割とあるんじゃないかと思います。個人的には、コミュニティの持続性を考えると就活色を出すのが一番手っ取り早いのではと考えているので、まぁ仕方がない側面が大きいのかなと。色々理由はありますが、大きいところで言うと「運営費の問題が解決する」「利害関係者が増えるからちゃんと運営せざるを得なくなり、結果的に持続する」「さらに運営元自体が企業になれば投入できるリソースの量が違うのでさらに持続性が増す」などかなと。

とはいえ企業が絡んでくると色々デメリットもあります。「しがらみが増えて好きなことがやりにくくなる」「就活目的の人ばかり集まってきて元のコミュニティの色がなくなっていく」などですね。

これは完全にトレードオフなので、特に大学のサークルなどのコミュニティは良い距離感で企業と付き合っていくのが重要かなと思っています。

総括して個人的なお気持ち

結局僕は早口技術オタクニチャニチャコミュニティが好きなのであった(終)という話になってしまうのですが、とはいえ僕はZliの代表をやって企業さんと色々イベントをやったりしていたわけです。

Zliがあったから企業とのつながりもたくさん作れたし、インターンに繋がったりしたのでそれはそれでよかったと思っています。これは、「僕は技術が好きだしオタク同士でずっとニチャニチャしていたいけど、現実問題としていつか就活する必要もあるのであった」という話であり、Zliで活動していたことでそこはうまくいったので、次のフェーズとしてオタクニチャニチャコミュニティを作って、就職してからも仕事とは別にオタクだけでずっとニチャニチャしていたいということです。

所属するコミュニティは1つに絞る必要はないですし、フェーズによって必要なコミュニティも変わってくると思います。

みんな自分の指向性に合ったコミュニティを見つけていければとても良いと思いますし、なかったら作れば良いだけなので。

もし指向性のあわない人たちと相容れないのだとしても、それは仕方がないことです。そこは棲み分けだと思いましょう。

僕が言いたいことは大体書けました、それでは。

セキュリティ・キャンプ全国大会2023 参加記

セキュリティ・キャンプ全国大会2023 参加記

はじめに

しんぶんぶんです!

セキュリティ・キャンプ全国大会2023 Y3 分散合意ゼミに参加したので、参加記を書いていきます!

応募課題

応募課題はこちらです。

僕の回答は恥ずかしいので公開しませんが、色々検討はずれなことを書いていた気がします。

調べて回答する系が多いので、ランポート先生の論文などをありがたく拝読しながら回答しました。

事前課題

事前課題はこちらです。

僕が実装したリポジトリこちらです。

課題1はTCP通信でのEcho Serverの実装、課題2は課題1をRPCで再実装、課題3は課題2をベースにState Machineを実装といった形になっています。

課題4はレプリケーションの実装なのですが、普通にやり忘れてました、反省。

共通講義

こちらに掲載されています。

個人的にはハッカーの倫理が一番面白かったです。電車の話でした(違う)

キャンプ当日

1日目

遅刻せずに無事クロスウェーブ府中に辿り着けました。

到着したらまずお昼ご飯です。

そば

最初は開講式から始まりました。

近いゼミごとに席が分かれていたので、周りの人と早速名刺交換して交流しました。

開講式が終わった後は共通講義とLTを聞き、グループワークをしました。

グループワークのテーマは「セキュリティに関するコンテンツを作ろう」的なもので、5人ずつのグループに分かれてアイデア出しをしていく形になります。

僕達のグループは、アイデアはたくさんでたのですが全くまとまらずに初日のグループワークが終了しましたw

グループワーク後は夕食です。

夕食

めちゃめちゃ豪華ですね〜。美味しかったです。

夕食後はデザートタイム兼交流会で、色々な人と名刺交換しました。

その後は各ゼミに分かれて顔合わせ兼開発タイムです。

ClientからLogをLeaderに追加して、Leaderが他のノードにレプリケーションするという仕組みを作りました。

2日目

朝ご飯

朝ご飯です。普段朝食べないので少なめ。

2日目は1日開発デーです。

リーダー選挙を実装しました。

昼ごはんです。

かれー

夕飯です。

ゆうはん

2日目の最後には協賛企業イベントがありました。1人あたり4社の話を聞けるような形になっています。

僕は以下の企業さんのお話を聞かせていただきました。

どの会社もセキュリティ部署の担当者の方がいらっしゃっていて、どのようなセキュリティ業務を行っているかなどを中心にお話ししていただきました。

3日目

朝ご飯です。

あさ

そろそろ朝起きるのが辛くなってきます。

3日目は朝から楽しい社会見学で、バスに乗ってIPAに行きました。 詳しい内容は話しちゃいけないらしいので省きますが、施設を見学したり登大遊さんからお話を聞いたりできました。

帰ってきたら昼食です。

らーめん

食べ終わったらまた開発です。

3日目はログレプリケーションを実装しました。 

夕飯の写真は撮り忘れました...。

4日目

4日目は1日中開発です。

僕は3日目までにコア機能の開発が終わっていたので、発表資料の作成をしていました。

昼ごはんです。

pasutaaaaaaaaa

午後にはYトラック内で発表会があり、1人5分で成果発表を行いました。

5日目にも全体の成果発表があるのですが、Yトラックではそこで発表する人を1つのゼミあたり1人投票で選ぶ形になっていて、僕は投票で選ばれたので5日目にも発表することになりました。

発表資料を作っていて、デモ動画や実演がめちゃめちゃやりづらい(CUIの画面見せても何やってるかよくわからない)のに気づき、急遽Vue.jsでビジュアライザを作ることにしました。

ちょっと遅くまでカタカタしてたおかげで無事5日目の発表には間に合いました。

あ、夕飯はこちらです。

おにく

夕飯後はLT会があり、僕も1本しゃべりました。 資料はこちらです。

LT会の後にはグループワークの続きがありました。

僕たちのグループはなんと「自作CPU+自作OS+自作Webサーバ」を作るという壮大なコンテンツをぶち上げました。

これ実はキャンプ後も継続するらしいのでとても楽しみです。

夜に突発的に有志による名刺交換会が実施されて、いろいろな人と名刺交換しました。暑かった(物理的に)。

5日目

朝ご飯です(昼ごはんは撮り忘れました)

あさ

5日目は発表会と閉講式がありました。

発表会、いろいろなゼミでやってることを聞けてとても楽しかったです。

自分の発表資料も貼っておきます。

ビジュアライザのデモ動画です。

おわりに

いかがでしたか!?

セキュキャンに参加すればこんなに美味しいご飯が無料で食べられます! みんな参加しよう!!

おわりに(まじめ)

僕の身の回りにはアプリケーションレイヤーをやっている人間が多いので、低レイヤー(システムソフトウェアなど)のことをやっている方々と仲良くできてとても良い刺激になりました(特にYトラックの方々)。

開発ももちろん楽しかったのですが、それ以上に受講生同士や講師・チューターの方々との交流がとても楽しかったなと思っています。

オフライン開催をしてくださった運営の方々には頭が上がりません、本当に。

キャンプでお世話になったみなさま、本当にありがとうございました!

来年も何らかの形で参加したいなと思っています!!

MIXIのインターン参加してきた

はじめに

会津大学学部三年のしんぶんぶんです!2023/3/15~4/5までの約3週間MIXIインターンに参加したので、やったことや感想など書いていきます!

端的にまとめると

全部読むのめんどくさいよ!という方のために簡潔にまとめると、

  • RustとかGoとかgRPCとかAgonesとか色々触ったよ
  • 過去一楽しいインターンだったよ
  • オフィスめっちゃ綺麗で最高の環境だったよ

というような話です。

インターンに参加した経緯

最初にMIXIインターンを知ったのは学部1年のころで、みんな大好き魔法のスプレッドシートを見て面白そうだなーと思っていました。

そんなこんなで学部2年になり、12月ごろに春インターンを探していて、本当はサイバーエージェントインターンに行こうと思っていました。なのですが、年末年始だからなのか応募フォームがなぜか閉じていて応募できなかったので、そういえばMIXIインターン面白そうだったなということを思い出して応募してみることにしました。

僕は認証に興味があったしMIXIには認証界隈で有名な某氏もいらっしゃるので楽しそうだなーと思い、最初はMIXI Mの部署を希望していました。

ところが時期的にタスクがなくて受け入れが難しいということで、改めてどこの部署が良いかなーと探していたところ、部署横断でRustやElixirが書けて高い専門性を持ったエンジニアが多く在籍しているという「開発本部CTO室たんぽぽグループ」という部署を見つけ、これは面白そうだぞ!!ということでこの部署に希望を出しました。

選考フローは書類→人事さんと面接→エンジニア面接→人事さんと希望の部署について面談→受け入れ希望先部署との面接で決定という流れでした。

人事さんとの面接はわりとちゃんと"面接"という感じがする面接でした。 エンジニア面接は結構雑談感が強くて話しやすかったです。 受け入れ希望先部署との面接は、タスクと僕のやりたいことがマッチしているかの最終確認だけという感じで、枠は1時間あったのに15分くらいで終わったような覚えがありますw

その後、電話で合格の連絡が来て無事インターンに行けることになりました。

オフィスについて

インターンはリモートでも出社してもどちらでも大丈夫だったのですが、僕はせっかくだから出社したかったのでインターン期間中は毎日出社しました。

場所は渋谷スクランブルスクエアで、地下鉄の渋谷駅から直結してるので一切外に出ずにオフィスまで行けます。

オフィスの机は電動昇降式デスクで、椅子はアーロンチェア。 コーヒーマシンやウォーターサーバー、お湯が用意されていて味噌汁やスープなども無料で飲めます。

35階にある社食はビュッフェ形式になっていて、1g1円でお昼が食べられます。めちゃめちゃ美味しいです。 ローソンやバイロンベイコーヒーも入っていて、めちゃめちゃ設備が整っている印象でした。

社食

インターンでやったこと

いよいよ本題のインターンでやったことについてです。

今回僕が触ったのは、「Agones上に作るQUICを使った音声通信機能」です。 詳細はMIXI TECH CONFERENCEで発表されているこちらの資料を読んでいただければ理解できるかなと思います。

要するに、「WebTransportを使って実装した音声通信機能をAgones上に載せたもの」という感じです。

登場人物と構成

  • aria-server
    • RustとElixirで書かれた音声用サーバ
    • 1ルーム1podが割り当てられる
    • Agonesに乗っている
  • aria-allocator-proxy
    • aria-serverはマルチクラスター構成になっているため、サービスから来たリクエストを元にどれを使うかをここで決める
    • Cloud Runに乗っている
    • GoでgRPC
  • aria-allocator
    • 実際にaria-serverをAllocateし、接続用のtokenを生成する
    • GKEに乗っている
    • GoでgRPC
  • aria-server-lite
    • aria-serverをRustだけで書き直したもの
  • aria-cui-client
    • aria-serverにリクエストを送れるクライアント
    • Rust製

アーキテクチャ

※画像はAgones上に作るQUICを使った音声通信機能より引用

aria-serverとaria-server-liteの違い

今回重要になってくるのはaria-serverとaria-server-liteの違いです。

まずaria-serverは、Thread/MicroProcessをたくさん用意し、Queue(Channel)を通してイベントを投げていくメッセージパッシングになっています。複数のコアを有効活用して使い切る思想です。 クライアントは20msに1回音声パケットを送信するのですが、例えば4人部屋の場合、サーバは1回のrecvあたり、自分へのAck、他の3人へのブロードキャストで系4回のsendが発生します。 4人のメンバーが送信している場合はその4倍で、20msに4回のrecv、16回のsendが発生することになります。 それぞれのタイミングはずれるので、この方法だとコンテキストスイッチシステムコールが頻繁に発生します。

対してaria-server-liteは、コンテキストスイッチ、ロック、システムコールを極力減らすことが目的で作られています。 サーバは複数のバッファの配列を用意してrecvmmsgをします。そして、4つのバッファが全部埋められるか指定秒数経過するかどちらかの条件を満たすまで待ちます。 カーネルは受信したパケットを全部一発でアプリケーションに戻します。 アプリケーションは受け取った4つのパケットをループ処理していき、それぞれ送信すべきデータを宛先ごとにバッファします。 そうすると各ユーザーに送信すべきデータはそれぞれ4つのQUIC Frameになるため、それぞれ1つのQUICパケットにまとめて合計4つのパケットをsendmmsgに渡して一括送信します。 こうすることで、socket関連のシステムコールはresvmmsg, sendmmsg一回ずつに削減することができます。 また、一連の処理は一括で行われるため、コンテキストスイッチのポイントもありません。 Agones上で動かすことを考えた場合、同じマシンで稼働している別Podのプロセスがresvmmsgのバッファを満たした時 or タイムアウトした時プロセススケジューラにとって処理が移ります。 個々のプロセスは、最低限のシステムコール、thread間を移動しない一括処理によってさくっと処理を終えて、他のプロセスがすぐにCPUを使えるようにします。

今回僕がやったこと

aria-server-liteが実戦投入可能かを確かめるために、期待されていた性能改善ができているのかの検証と、Agonesへのデプロイをするのが今回のタスクでした。

細かいタスクは以下の通りです。

  1. aria-server, aria-server-lite, aria-cui-clientをスタンドアローンで動かす
  2. 性能検証の時にパケットロスが起きていると正しい測定ができないため、パケットロス率を確かめるプログラムをaria-cui-clientに実装する
  3. 1で立てたスタンドアローンの環境を使い、サーバのメトリクスをとって性能検証をする
  4. Agonesにaria-server-liteをデプロイする

ここからはそれぞれのタスクの詳細について書いていきます。

aria-server, aria-server-lite, aria-cui-clientをスタンドアローンで動かす

まずはaria-server, aria-server-lite, aria-cui-clientをスタンドアローンで動かすために、GCEのインスタンスを用意しました。

aria-server, aria-server-liteは本来Agones上で動かすものなのですが、今回は性能検証のためにスタンドアローンモードで動かしました。

パケットロスの検出

aria-cui-clientにパケットロス率を表示する機能を実装しました。

送信時のシーケンス番号をグローバル変数に保存しておき、受信時に抜けがないかを確認することでパケットロスを検出しています。

具体的な手法としては、

  1. once_cellを使って、グローバルに送信元クライアント番号とシーケンス番号を保管するHashMapを定義
  2. 500リクエストに一回HashMapの中身を確認してパケットロスがないかをチェック

といった形になります。

性能検証

性能検証は主に以下の方法で行いました。

vmstatの検証結果

まず、CPU使用率はaria-server-liteの方が圧倒的に低いです。9スピーカーで40%ほど違いが出ました。

コンテキストスイッチaria-server-liteの方が少ないという結果になりました。

コンテキストスイッチシステムコール、ロックを減らすのがaria-server-liteの目的なので、CPU使用率、コンテキストスイッチが減ったのは期待通りの結果です。

レイテンシー

クライアントを2つ使用し、片方のクライアントで送信してからもう片方のクライアントで受信するまでにどれくらいの時間がかかるかを計測しました。

aria-server, aria-server-liteそれぞれのインスタンスからaria-cui-clientのインスタンスへのpingに有意な差がなかったためこの方法で計測しています。

結果はaria-server-liteの方が遅かったのですが、これも想定通りの結果です(aria-server-liteはコンテキストスイッチシステムコールを抑えるためにsendmmsg、recvmmsgを呼ぶ回数を4人分まとめて1回ずつに抑えているため、そのぶん待ち時間が発生します)。

perf, pprof-rs

フレームグラフを作ってボトルネック解析をしました。 aria-server-liteに関してはカーネル以外の部分でボトルネックになっているところが特になかったため、設計思想通りの動作になっていることがわかりました。

dhat

とりあえず計測してみたものの、あまり使えそうなデータは取れなかったです。

Agonesにaria-server-liteをデプロイ

すでにaria-serverがたっているクラスタaria-server-liteのpodを追加する形でデプロイしました。

やったことは以下の通りです。

  • DockerfileとCloud Buildの設定を書く
  • Terraformのアップデート
  • TerraformでCloud Buildのトリガーを書く
  • aria-server-liteのマニフェストを追加
  • aria-allocator(-proxy)を改造
  • aria-cui-clientを改造

まずはCloudBuildでビルドできるようにDockerfileとCloudBuildの設定ファイルを書きます。 その次にTerraformでCloudBuildのトリガーを書こうと思ったのですが、TerraformとHelmプロバイダバージョンが古くてarm64-darwinで実行できなかったので、アップデートの作業を行いました。 無事アップデートができたので、GitHubリポジトリにタグがpushされたらビルドが走るようなトリガーをTerraformで書きました。 さらにaria-server-lite用のHelmマニフェストを追加し、一旦デプロイ完了です。

ただ、この状態ではaria-allocator(-proxy)からからaria-server-liteをAllocateできません。そのため、aria-allocater(-proxy)のgRPCリクエストにUseLiteというフィールドを追加し、trueの場合はaria-server-liteをAllocateするような実装にしました。

これでいよいよ動くぞ!となったのですが、aria-cui-clientで接続の際に指定するアドレスがIPアドレスじゃないと動かないようになっていたため、こちらを名前解決できるように修正しました。

以上で無事今回のタスクは完遂となり、aria-cui-clientをAgones上で動かすことができるようになりました!

おまけタスク

前述の作業で動くようにはなったのですが、Goのプログラムを使ってaria-allocator(-proxy)を叩いて接続先情報を取ってくる&Allocateする→aria-cui-clientに接続先情報をわたして接続すると、2段階の手順を踏まないと接続できません。 そのため、aria-cui-clientからaria-allocator(-proxy)を叩けるようにして、一発で接続できるようにaria-cui-clientを改造しました。

aira-allocator-proxyはgRPCエンドポイントになっているため、tonicというgRPCライブラリを使用しました。 ただ、aria-allocator-proxyのエンドポイントにはGCPのサービスアカウントでの認証がかかっているため、https://www.googleapis.com/oauth2/v4/tokenを叩いてJWTを取得する処理を書き、それをgRPCリクエストのAuthorizationヘッダーに含める形で実装しています。 (JWT生成のリクエストを送る際のassersionのJWTにtarget_audienceというClaimを含める必要があり、そこに気づかなくてだいぶハマりました)

全体の感想

ちゃんとしたRustのプロダクションコードを読んだことがなかったのでとても勉強になりました。 また、比較的低レイヤーな部分もさわれて楽しかったです。

かなり色々な技術をさわれたのも楽しさポイントが高くて、Rust, Go, gRPC, WebTransport, perf, Agones, GKE, Terraform, CloudBuild, CloudRun etc… 色々な技術を触りました。 半分くらいは(ほとんど)触ったことがない技術でした。

新しい技術、自分の知らない技術を触ることが好きなので、自分のやりたいことにとてもマッチしているインターンでした。 メンターさんの技術力もめちゃめちゃ高くて、色々なお話が聞けて楽しかったです。 過去色々なインターンに行きましたが、過去一楽しかった気がします。

ただ、自分の技術力のなさを痛感する場面がかなり多かったので、これからも精進しようと思いました。 全体の仕組みを理解するのにもかなり時間がかかった気がします。

さいごに

メンターさんやチームの方には大変お世話になりました! また行く機会があればよろしくお願いします!!