こんにちは。馬場（netmarkjp：Bluesky/X）です。
わたしは「#ばばさん通信ダイジェスト」として、BlueskyやThreadsに毎日少しずつ、賛否関わらず話題になった/なりそうなものを共有しています（Bluesky検索）。
これらをベースに、特にクラウド/インフラ/SRE/オブザーバビリティ/運用等のキーワードに関する話題を中心にお届けします。
物理サーバーの起動時間のチューニング
Cloudflareのテックブログで、物理サーバーの起動時間を短縮した事例が紹介されています。
なんらかの条件に合致したと思われる一部の物理サーバーが時に起動に4時間近くかかっていたところ、原因を分析して5分未満まで短縮した話です。読んでいて「わかる、こういうことある」という気持ちになりました。
電源ONからPOST、ネットワークブート（PXEやUEFI HTTPS）、OS起動と進む流れで、なかなかOS起動にたどり着かずに時間を食っていたそうです。
原因は、IPv6 HTTPSを利用したネットワークブート環境において、サーバー側はIPv4 HTTPS、IPv4 iPXE、IPv4 HTTPSのリトライ、IPv4 iPXEのリトライと4回試行したあとにようやくIPv6 HTTPSを試す挙動だったこと。それぞれの試行ごとに5分のタイムアウト待ちがあるため、1回のネットワークブートに入るだけで5分タイムアウト待ち×4回で約20分かかる状況でした。
さらに、ブートの過程で登場するUEFI・OpenBMC・HROT（Hardware Root of Trust）の更新やUEFI設定変更の反映に再起動が必要で、20分待ちが積み重なり、トータルで4時間近くとなっていたわけです。
解決策はエントリーを見ていただくとして、解決策はシンプルですが、古いUEFIバージョンはそれが実現できず、UEFIファームウェアをアップグレードすると設定値がリセットされてしまうなど、一筋縄ではいきません。最終的にはベンダーと協力して新しいBIOS/UEFIファームウェアを作るところまで踏み込んで完遂したとのこと。
「何時間もかかる」という事実から原因を分解していく過程が丁寧に書かれていて読み応えがあります。
足回りを理解する: Kubernetesを手元で継続運用する趣味
趣味のKubernetesクラスターを自宅で（気持ちは）本番さながらに継続運用している事例の紹介です。
著者の須田さんは、自宅クラスターを「盆栽」と表現しています。一度完成させて終わりではなく、日々少しずつ手を入れて育て続けるものです。
趣味だから壊れたら作り直せばいい、というスタンスではなく、あえて「本気で直す」プロセスを大切にしている点が肝で、ここに学びがあるという話です。本気の趣味として真に向き合う（というと少し大げさですが）からこその楽しみがあると思います。
そして、結果的に仕事にも役に立つことがある、というわけです。
パブリッククラウドのマネージドKubernetesをガッツリと展開すると、趣味としてはなかなかの費用がかかってきます。しかし現代の安価な実機を自宅に置くスタイルなら、初期投資は多少かかるものの、その後は比較的安心して運用できます。
それに、物があると愛着が湧きやすくなります。
メモリー価格高騰で少し購入価格は上がっていますが、6台と言わず3台くらいのクラスターから、それでもちょっとなということであれば1台からでも、取り組んでみてはいかがでしょうか？
足回りの足回りを理解する: データセンターのネットワークをシミュレートしてハンズオンで学ぶ
NTTドコモビジネスのクラウドNWオーケストレータ開発に携わる著者の堀岡さんが、入社からの1年間で学んだことをまるごとハンズオンにまとめた記事です。
Containerlab と Juniper の無償仮想イメージ vJunos を使用し、データセンターネットワーク（NW）の定番アーキテクチャ「Leaf-Spine 構成」をゼロから構築するハンズオン記事です。eBGP による Underlay 構成を皮切りに、EVPN/VXLAN によるテナント L2 拡張、ESI-LAG を用いた冗長化、VRF Route Leaking によるインターネット接続ゲートウェイ模擬まで、クラウド NW の中核技術をひと通り体験できます。ハードウェア不要・無償イメージのみで動く手順と全設定例を掲載しています。
多くのSREにとってKubernetesは避けて通れない話題になってきていると思いますが、実際の環境ではそのKubernetesを支えるレイヤーがあるわけです。
前項で紹介した趣味のKubernetesクラスターはネットワーク機器2台・サーバー6台構成でしたが、よりリアルな環境を想定すると、こういったネットワーク構成の話題が出てきます。
データセンターネットワークに詳しくない方はリード文の時点で知らない単語が並んで、かなり混乱しますよね。
正直なところ難しいなと思うこともあるでしょう。単語がわからなくて辞書が必要ということもあるでしょう。
でも大丈夫です。いまはAIがあるので、解説してもらいながら、読むことができます。
AIだけでいちから学ぶとハルシネーションでトンチンカンなことになるのが怖いですが、このようなしっかりしたコンテンツがあれば自分で軌道修正できるので安心です。
自動化バイアス（AIの回答が正しいと思いがちなバイアス）に流されず、エントリーで裏を取りながら読んでいきましょう。
実践環境があるから、自分の理解どおりにネットワークが動くかどうか、はっきり確かめられるのがいいですね。
Interop Tokyo 2026が開催されました
2026/6/10-12に幕張メッセで開催されました。
講演はアーカイブ配信が6/29〜7/24まであるそうなので、興味が湧いた方は覗いてみると良いでしょう。
わたしの理解では、Interopはネットワークやサーバーなど情報通信機器・技術のテクノロジーイベントであり、Interoperability（相互接続性）を実証する場でもあります。
あきみちさんの「Geekなぺーじ」では、今年のShowNetのポイントがいくつか紹介されています。
近年はAI需要が情報機器業界を牽引していて、メモリーやGPUだけでなく、冷却機構の強化やネットワークの広帯域化も進んでいます。
水冷（一般的には液冷）は、身近なところだと自動車等の冷却系を想起します。
空冷と比較した水冷の特徴は、冷却能力の高さと静音性です。記事によると水冷は「スイッチを入れて本当に起動しているのか不安になるレベル」とのことで、もし水冷がデファクトスタンダードになったとしたらデータセンターの爆音が解消ないし緩和する未来があるのかもしれません。
ところで冷やされる側の機材から見ると、液冷は液体に載せて熱を運んでもらうだけですが、冷却機構全体を考えると運んだ熱はどこかで発散せねばなりません。
最近ではAI需要も相まってこの液体による熱の伝搬の仕組みが、部品レベル、機器レベル、ラックレベル、データセンターレベルで取り組まれているそうです。
また、ネットワークの広帯域化、特にローカルネットワークの広帯域化はAIの需要が牽引している面が大きいそうです。
1.6Tbpsイーサネット（GbpsではなくTbps）とか、ちょっともう凄すぎてよくわからないですよね。AIの牽引力はすさまじいです。
ところで、わたしが思うInteropにおいてInteroperability（相互接続性）を象徴する最大の企画がShowNetです。
各社が最新の技術・機材・設備を持ち寄ってネットワークを構成し、相互接続性を実証します。
この巨大な構成図は毎回の名物とも言えます。
今回はバックボーンのルータがすべてリンクローカルIPv6アドレスで運用されていたそうで、「通常運用部分という視点では『バックボーンは全部IPv6』」なのはShowNet初とのこと。
こうして記事で解説してもらえると、図を眺めるだけでは気づかない設計の意図が見えてきて良いですね。
性能テストの第一歩に
フューチャー技術ブログで『はじめての性能テスト』が公開されました。性能テスト入門編の包括的なガイドラインです。
著者の武田さんも書いていますが、性能テストは難しいですよね。
技術的な視野の広さ、業務ドメインの理解、多くの関係者との調整の3つが重なるのが性能テストで、経験則や暗黙知に支えられできるひとが少ない。そしてできるひとが対応するからできるようになる機会が少なくできるひとが増えない…。というのがよくあるパターンです。
性能テスト / 負荷テスト / 負荷試験等いろいろな呼び方があり、現場ごとに指すものが微妙に違うことがままあります。しかしよく考えると、わたしたちは試験を完了させたいわけではなくて、信頼性・可用性・キャパシティ・パフォーマンス等の「保証」をしたいのですから、その中身が重要なのだと思います（この「保証」については拙著『バックエンドエンジニアのためのインフラ・クラウド大全』で解説しています）。
もちろん、そのために用語を適切に利用することも大事ですが、用語は広がりとともに意味が希薄化・変質するのが世の常です。現実を受け入れ、現場の用法も受け入れていかないとですね。
このガイドラインはオンライン処理だけでなくバッチ処理にも言及しているのもうれしいポイントです。
『はじめての性能テスト』のほかにも興味深いガイドラインが多数公開されているので、ぜひ見てみてください。わたしはいつも楽しく拝見しています。
ところで、性能テストの営みの中にはパフォーマンスチューニングも含まれます。パフォーマンスチューニングの実践に興味が出たり課題を感じたりしたら、わたしも執筆に参加しているISUCON本をぜひ手に取ってみてください。
OpenTelemetryがCNCF卒業生に
OpenTelemetryがCNCF（Cloud Native Computing Foundation）のGraduated Projectになりました。
このGraduation（卒業）は、ベンダーニュートラルなオブザーバビリティのフレームワークであるOpenTelemetryの、プロダクトとコミュニティの成熟を示すものです。
Graduated Projectだということは、プロジェクトが成熟し、イノベーター、アーリーアダプターに普及し、キャズムを超えて、アーリーマジョリティに届く段階にあることを示しています。
これから保守的なレイトマジョリティ層にも普及していくことが期待されますね。
わたしの周りではOpenTelemetryはトレースのために利用し始めることが多いのですが、今後はメトリクスやログでの活用も増えていきそうです。
ますますOpenTelemetryから目が離せませんね。
話題のzeroいろいろ
「Zero」を冠するトピックがたくさんあったのでまとめて紹介します。
あらかじめ断っておきますが、それぞれ完全に別の話です。
全然別の話題でZeroがたくさん登場するということは、もしかしてZeroの時代でしょうか。
ViteやVitest、Rolldown、Oxcといったフロントエンドツールチェーンの開発元である「VoidZero」がCloudflareに買収されました。
プロダクトが有名ですが、VoidZeroが社名です。
Cloudflareは、Astro、Vite、Honoと着々と布陣を固めていますね。
AIエージェントのためのプログラミング言語「Zero」が発表されました。開発元はVercelです。
執筆時点でexperimentalなまだ走り出しのプロジェクトです。コンパイル型言語で、特徴としてソースコードをもとにグラフ（図示の意味ではなく、点とそれらを接続する線のほう）を生成しそれをAIエージェントが活用します。広く普及している手続き型プログラミング言語の世界観とは一線を画しそうです。
piやopencodeインスパイアの、Rustで書かれたミニマルなOSSコーディングエージェント「zerostack」が話題になりました。ミニマルと言いつつマルチプロバイダーやサブエージェント、パーミッション、MCP、git worktreeなど多くの機能に対応しています。メモリーフットプリントが小さいそうなので、1台のマシンでたくさん並列実行できそうでうれしいですね。
Webサーバープログラム「zeroserve」が発表されました。ゼロコンフィグ（設定ファイル無し）志向で、io_uringやeBPFスクリプティングを活用した超高速動作を謳っています。
Webサーバーの競合としてnginxやCaddyを意識しているようです。
注目・期待の書籍
『ネットワークシステムについて語るときに我々の語ること – 技術書出版と販売のラムダノート』
Larry Peterson・Bruce Davie 著、進藤資訓 訳
原書: What We Talk About When We Talk About Systems: Essays on the Systems Approach
「インターネットのアーキテクチャってTCP/IPのことじゃないの？」「プロトコルの実装ってなんで無償で手に入るの？」「クラウドを自分たちで作る意味があるの？」「MPLSとかOpenFlowって結局どこにいったの？」「ルータなんかを仮想化して何がうれしいの？」「トランスポートプロトコルってTCPとUDPだけじゃなかったの？」「QUICって要するに第何層なの？」「なんでインターネットではセキュリティが後付けなの？」「モバイルネットワークって勝手に作れるの？」「ネットワーク管理ってルータのコンフィグでしょ？」「もうLLMに全部任せればいいのでは？」
インターネット成熟の過程を知る2人の著者が綴る珠玉のエッセイ集！
『セキュアAPI 設計・構築・実装を貫く原則｜翔泳社の本』（わたしは翻訳版のレビュアーとして関わっています）
José Haro Peralta 原著、 元内 柊也、 水元 恭平、 織茂 駿斗、 小栁 斉 翻訳
インターネットトラフィックの大部分を占めるAPIをいかにして安全に保つのか
本書は José Haro Peralta, "Secure APIs", Manning Publications 2025 の邦訳版です。
現代のITシステムにおいて、APIはもはや単なる「接続口」ではありません。インターネットトラフィックの大部分を占めるAPIは、今や攻撃者の最大の標的となっています。開発の最終段階で場当たり的にセキュリティテストを行う従来のアプローチでは、巧妙化する攻撃を防ぎきることは困難です。
本書『セキュアAPI』は、そんなAPIをめぐる課題に対し、「セキュリティ・バイ・デザイン」という回答を提示します。 設計段階からセキュリティを組み込む「シフトレフト」の重要性を説き、堅牢なAPIを構築するための具体的な戦略を網羅的に解説しています。
著者は、『実践マイクロサービスAPI』も手がけたAPIセキュリティのエキスパート、José Haro Peralta氏。何百ものAPIをレビューしてきた知見が、現場で役立つ実践的なテクニックとして凝縮されています。
おわりに
直近の話題から、わたしが気になったものを中心にお送りしました。
Blameless、Keep ConstructiveでHumility Respect Trust溢れるご意見・ご感想、誤りの指摘などいただけると幸いです。
さて、最近はこのコーナーで毎回トラコン（ICTSC: ICTトラブルシューティングコンテスト）の情報を紹介しています。
ICTSCは完全ボランティアの任意団体でして、今年度からわたしが会長を務めることになったので、一生懸命宣伝しています。
今年はまだ参加者募集を開始していませんが、予定では我が家の子どもたちの夏休みが始まる頃には参加者募集が始まることでしょう。
参加資格は『全国の専門学校、高等専修学校、高校、高専、大学、大学院 （博士後期課程修学者を除く）、短期大学に所属する生徒・学生』を満たす方になるはずなので、身近に該当する方がいたらぜひ声を掛けてあげてください。
このICTSCは参加者が学生、運営も学生という珍しいイベントです。運営する学生たちを社会人の実行委員が支える形で10年以上運営してきています。
若者や入門者を育て裾野を広げることは、業界の持続に不可欠だと思って続けております。
賛同いただける方・ご協力いただける方はぜひお声掛けくださいませ。
ではでは。