2026年の個人的テーマ: 「計算機を燃やせ🔥」

AbemaTV, Inc. All Rights Reserved  AbemaTV, Inc. All Rights Reserved 
1 2026年の個人的テーマ: 「計算機を燃やせ🔥」 2026 January 5 株式会社AbemaTV 黒崎優太 @社内勉強会

AbemaTV, Inc. All Rights Reserved  黒崎優太 Kurosaki Yuta 株式会社AbemaTV
ビジネスディベロップメント本部株式会社サイバーエージェント CTO統括室サイバーエージェントインターネットゼミ 2 Proﬁle kuro_m88 kurochan

去年やり残したこと 3

去年やり残したこと 4 • おうちKubernetes • 未完成 • 完成してないので記事もかけない

去年やり残したこと 5 • なぜやる気をなくしたのか • 引越しによりIPv6が失われたから(30%) • 趣味なので余計なこだわりを入れたから(70%)

余計なこだわりによる失敗 6 • 作りたかったおうちk8s ◦ CPU: 32コア(8 x 4node) ◦ メモリ: 128GB(32GB x 4node) ◦ NVMe: 2TB(512GB x 4node) • 余計なこだわり ◦ root ZFS ◦ Kubernetes on LXD ◦ IPv4/IPv6 デュアルスタック

余計なこだわり 7 • 最後にぶちあたった問題 • VMはそこまで重要じゃなかったので無視しておけばよかった

年末年始に再チャレンジ 8 • ChatGPTによりだいぶトラブルシューティングが早くなった(事故るのも高速に) ◦ ChatGPT「「自分が座っている椅子を引き抜く」操作です。」 ◦ ChatGPT「養生シートが剥がれた瞬間に事故る設計は、インフラ屋は取りません。」 ◦ 色々事故りながらroot ZFS化に成功🎉 • VPNなどを活用してIPv6も自宅に引き込んだ

9 閑話休題

自宅クラスタを負荷試験していた時のこと 10 • CPU内部の温度センサのメトリクスを取得 • 負荷をかけるとCPU温度が一気に上がる🔥 ◦ 負荷をかけながらCPU触った人はわかる ◦ ファンの回転数が急に上がる感じ • 忘れかけていた気持ちを思い出す😴 ◦ 本日のテーマ

もやもやするグラフ 11 • ありがちなやつ(by nano banana🍌) • NodeのCPUキャパシティは埋まっているが実使用率が低すぎる ◦ コスト云々の問題が一般的には大きいが、個人的には気持ちの問題がデカい ◦ 持てるCPUの能力を使い切って(燃えるくらい🔥)CPUをアチアチにしたい🔥

もやもやするグラフ 12 • 何がいけないのか？ • 必要以上にrequestしている ◦ それはそうだけど、経験則上では下げれば解決とはなりにくい • 割り当てられたリソースを使い切りやすい設計になっていない ◦ 本題 • CPUに限った話でもない ◦ が、我々の開発するサーバの多くはweb APIであるから、メモリ、ディスク、ネットワークなどの帯域がボトルネックになることは少ないのと、そちらがボトルネックになるような I/Oヘビーなワークロードは何かしら特化したミドルウェアやマネージドサービスで済んでしまうことも多い (済まない用途も開発したい🔥) ◦ という背景のもと、今回は我々が実装するものは基本的に CPU intensiveになるように作るべきという前提にする

CPUを燃やす(比喩)には🔥 13 • 待たせない、とにかく仕事させる 🔥 • 数年前にビジメンバー向けに話したやつ ◦ アムダールの法則 ◦ 非同期処理 ◦ など https://speakerdeck.com/kurochan/what-does-it-mean-to-scalability

CPUを燃やす(比喩)には🔥 14 https://speakerdeck.com/kurochan/what-does-it-mean-to-scalability

並列度を高く保つためのプログラミングモデルの例 22 • ノンブロッキングI/O + I/O多重化 ◦ いわゆるC10K問題で出てくるやつ • GoにおけるCSP(Communicating Sequential Processes) ◦ 特にgoroutineとchannel ◦ CSPがあるからM:Nモデルが活かしやすい(実行単位とスレッド) • Actor Model • Reactive Streaming

Actor Model 23 • 状態を持つ独立したActor同士が共有メモリを使わず非同期メッセージでやりとりする

Reactive Streaming 24 • 非同期なデータの流れを背圧(backpressure)で制御しながら処理するモデル

並列度を高く保つためのプログラミングモデルたち 25 • それぞれ独立に存在しているわけでもない • プログラミング(同一プロセス)の世界だけでなく、アーキテクチャにも適用可能 • 例: Goのchannel / Cloud Pub/Sub / Amazon Kinesis • 同期処理と非同期処理を分離することを考えてみる ◦ できる限り小さな同期処理とそれ以外の非同期処理

広告計測サーバの例 26 • 極端なスパイクをする • 全てを処理しきろうと思うとピークに合わせて待機が必要 • 軽量なフロントエンド(Cloud Run)とそれ以外をworkerに分離するモデルの検証 ◦ 間をつなぐバッファとしてのPub/Sub

広告計測サーバの例 27 • 同期処理部分(Cloud Run)は軽量なのですぐにスケール ◦ 大量の状態(並列リクエスト)を処理する • 急激にXX万rps程度流しても受け止められた ◦ 一瞬で0から700コンテナ立ち上がってすぐに300程度に落ち着いた

カウンタの部分運用開始 28 • これのこと https://speakerdeck.com/hono0130/cloud-native-days-winter-2025-distributed-counter

カウンタの部分運用開始 29 https://speakerdeck.com/hono0130/cloud-native-days-winter-2025-distributed-counter

広告計測用カウンタの例 32 • リクエスト増に対して並列度の上昇によりスループット増、遅延増加ほぼなし ◦ 仮に処理が間に合わなくても遅延が増加するのみ、メモリ使用量も予測可能 ▪ Reactive Streamingっぽさがある？

遅延と引き換えに安定性とスループットを得る 33 • 基本的には同期処理と非同期処理の間のオーバーヘッドは増加するはず • 非同期処理は終了(deadline)の約束がないので処理が間に合わないと遅延が増加する ◦ その代わりスパイクしても遅延の形で吸収しやすい(面積のイメージ) • QueueではなくStack的な思考をすると…？ ◦ ベストエフォートなAPIの場合はStackもいい ◦ 広告のビジネス要件に照らすと…？

で、おうち Kubernetesの進捗は？ 34 • Underlayが出来上がっただけでまだこれからです󰢛 • 2026年も頑張って開発しましょう💪 ←全ノード起動したらキラキラしてた

2026年の個人的テーマ: 「計算機を燃やせ🔥」

2026年の個人的テーマ: 「計算機を燃やせ🔥」

More Decks by Kurochan

Other Decks in Technology

Featured

Transcript