おはようございます、マイクです。
「zenncast」月曜の朝のお時間です。今日は二千二十六年六月二十二日、月曜日、朝七時になりました。
この時間は、テック系ナレッジ共有サービス Zenn から、いまホットなトレンド記事をご紹介していきます。
さて今日は、お便りはお休みということで、そのぶんたっぷりと記事を紹介していきたいと思います。
今日ご紹介する記事は、ぜんぶで五本です。フロントエンドとバックエンドの基本から、Linux カーネルのメモリダンプの読み方、AI エージェントのワークフロー、超低レイテンシ通信の RDMA、それから暗号化で変わりつつあるネットワーク監視の話まで、かなり幅広いラインナップになっています。
では、一つ目の記事からいきましょう。
一つ目は、これから Web アプリ開発を始めたい人に向けて、「全体像をどう捉えるか」を分かりやすく解説している記事です。
まず、Web アプリは大きく「フロントエンド、つまり画面」「バックエンド、つまり処理」「データベース、つまり保存」の三つから成り立っていて、その中で、ブラウザ側で動くプログラムとサーバー側で動くプログラム、この二種類が連携して動くのが最大の特徴だよ、というところから話が始まります。
フロントエンドでは、ブラウザというのは、エイチティーエムエル、シーエスエス、ジャバスクリプト、この三つを実行するための装置だと考えよう、という説明がされていて、そこに React とか Next.js がどう関わってくるかを解きほぐしてくれます。
React は「状態から画面を関数のように宣言的に描く」仕組みで、状態を変えたら React がいい感じに DOM を更新してくれる。その周りのルーティングとか、どのフォルダに何を置くかといったお作法を、Next.js がフォルダ構成のルールとして整えてくれる、という整理ですね。
ここで重要なのが、「サーバーで実行されるコード」と「ブラウザで実行されるコード」をきちんと頭の中で分けて考えることだ、と強調しています。
バックエンドは、いまっぽく Supabase のような BaaS、バックエンド・アズ・ア・サービスを使う前提で説明されています。Supabase は PostgreSQL ベースのデータベースに加えて、認証、リアルタイム通信などをまとめて提供してくれるので、開発者はアプリ固有のロジックに集中できるよ、という話です。
テーブル設計については、「テーブルはクラスの集合として捉える」と説明していて、オブジェクト指向のクラス図をイメージすると理解しやすい、というアプローチでした。
さらに安全性のところで、行レベルセキュリティ、RLS を使って、「誰がどの行を見られるか」というルールをデータベース側に持たせることの大事さに触れています。アプリ側で条件分岐するだけじゃなくて、DB にもきちんとルールを書いておくことで、抜け漏れを防げるよ、という考え方ですね。
React の状態管理の話も具体的で、コンポーネントの中で完結する状態は useState で持てばよくて、複数のコンポーネント間で共有したい状態だけ、Zustand のようなグローバル状態管理ライブラリを使おう、という切り分けになっています。
リアルタイム通信については、WebSocket を使ってサーバーとつなぎっぱなしにしておいて、「購読」と「解除」でイベントをサブスクライブする仕組みを説明しつつ、解除し忘れるとサーバー資源の無駄遣いになるから、ちゃんとクリーンアップしようね、と注意喚起もされています。
ログインの仕組みは、トークンというデータでユーザーを識別していて、その扱いは Supabase の Auth を使うとかなり簡単にできる、と紹介されています。このトークンの情報が、さきほどの RLS の auth.uid() と結びついて、「このユーザーはこの行を見ていい」という判定に使われる、という流れですね。
フォーム入力のバリデーションでは、Zod のようなライブラリを使ってスキーマを定義しておき、実行時に「この入力はスキーマに合っているか」をチェックするようにすると、安全かつ再利用性の高いフォームが作れるという話も出てきます。
最後にまとめとして、「どこで実行されるコードかを意識する」「BaaS に土台を任せて、全部自前で作ろうとしない」「状態をむやみにグローバルにしない」「RLS は最初からちゃんと設定する」「コンポーネントを『画面を描く関数』として考える」
こういった心構えを持っておくと、初めての Web アプリ開発でも、細かい実装に迷子にならずに全体像を保ったまま進めやすいよ、というメッセージで締めくくられています。これから React や Supabase でアプリ作ろうかな、という人には、かなり地図っぽい記事ですね。
。。.。。.。.
二つ目の記事は、がっつり低レイヤー、Linux カーネルの話です。
テーマは、Linux カーネルがクラッシュしたときに得られる「カーネルスタックのメモリダンプ」を、十六進数の羅列からどう読み解いていくか、という内容です。数字の羅列なんだけど、そこから「どの関数がどの順に呼ばれたか」「スタック上にどんなデータが置かれているか」を感じ取るための、感覚的なコツを教えてくれます。
具体例として取り上げられているのは、dd コマンドが write システムコールの最中に、ディー状態、つまりディスク待ちで止まっているケースです。
このときのカーネルスタックを題材に、スタックのいちばん下のほうには thread_info のポインタがあって、上のほうにはユーザ空間のレジスタが並んでいる構造、つまり pt_regs が上端近くに載っているという並びを押さえていきます。
関数呼び出しのたびに、「戻りアドレスが積まれて、そのすぐ下にひとつ前のフレームポインタがある」といった、コールスタックの規則も丁寧に追っています。
さらに、アドレス帯域ごとに、「ここはカーネルコードだな」とか、「ここは動的に確保したメモリの領域っぽいな」とか、「これはユーザ空間アドレスだな」といった見分けがつくようになるパターンを、図で「模様」として可視化しているのが面白いところです。
十六進数のダンプを、ただの文字列として読むんじゃなくて、「このへんにこういう模様が見えたら、pt_regs があって、ここから先がユーザ空間だな」みたいな、ちょっとした直感を鍛えていく感じですね。
もちろん、こういう模様を直接読み取れなくても、crash コマンドの bt とか、もっと高レベルなツールを使えば、コールスタックの解析自体はできると書かれています。ただ、生のダンプからパターンを感じ取れる人ほど、ツールが使えないようなイレギュラーな状況でも、原因調査を早く進められる、という経験則があるそうです。
最後は、hexdump や gdb でダンプをひたすら眺める「修行」を通じて、この経験に裏打ちされた直感的なパターン認識は、特別な才能じゃなくて、誰でもある程度までは身に付けられるし、できるようになるとけっこう楽しいよ、とポジティブに締めています。
カーネルデバッグに興味ある方には、ちょっとした筋トレみたいな記事ですね。
。。.。。.。.
三つ目の記事は、AI エージェントまわりの OSS、「TAKT」というツールの紹介です。
この TAKT は、複数の AI エージェントと人間がどう関わるかを、ヤムルファイルで「ワークフロー」として宣言しておいて、そのとおりに自動で進行させるサービスです。
たとえば、「計画を立てる」「実装する」「レビューする」「修正する」といった工程を、それぞれ一つの step として定義します。
その上で、「どんな条件を満たしたら次の step に進むか」「レビューで NG だったら、また実装の step に差し戻す」といったルールを、コードじゃなくて設定ファイルとして書いておくイメージですね。
これによって、毎回チャットで「じゃあ次はこれやって」「レビュー終わったらここ直して」と指示しなくても、ある程度決めた流れに沿って、AI が自律的に動いてくれるようになります。
各 step にはペルソナを設定できます。たとえば「planner」「coder」「reviewer」といった役割を割り当てたり、「この step ではファイル編集していい」「この step は読み取り専用」といったファイル編集の可否を決めたりします。
さらに、AI による判定ルールとか、「このループが何回続いたらおかしいから止める」といったループ監視も組み込めるので、人間が付きっきりで監督しなくても、タスクが完了するか、あるいは条件付きで中断されるまで、自律的に走ってくれるのが特徴です。
プロンプトの設計も工夫されていて、「役割」「禁止事項や品質基準」「そのステップ固有の指示」「関連知識」「出力フォーマット」という五つの要素に分けて組み立てる仕組みになっています。
これによって、たとえば品質基準だけ差し替えるとか、関連知識だけ入れ替えるといった再利用がしやすくなりますし、ひとつのプロンプトがむやみに肥大化して、コンテキスト長ギリギリになる、みたいな問題も避けやすくなります。
導入はシンプルで、グローバルインストール一発で入れられて、コマンドひとつでタスク定義、もうひとつのコマンドで自動実行、という流れです。
筆者は、自分で AI 開発の「進行役」をコードで作り込むのではなくて、「人間が都度やっていた確認作業」を、TAKT のワークフロー定義に置き換えていきたい、と書いています。
そうすることで、「このタスクを AI に丸投げしても、本当に大丈夫かな？」という不安を、事前に定義されたワークフローとチェックポイントでカバーして、安心して放置できる環境を作ろうとしている、という考え方ですね。
AI エージェントをチームメイトとして活かしたい人にとって、「どうやって段取りを YAML に落とすか」というヒントになる記事です。
。。.。。.。.
四つ目は、ハイパフォーマンスな通信技術 RDMA と、GPU 向けの GPUDirect RDMA、それを AWS の EFA 上でどう扱うか、というかなりコアな解説記事です。
まず RDMA は、「相手マシンのメモリに、ネットワークインターフェースカード、NIC が直接読み書きする」という仕組みです。CPU や OS をできるだけ介さないことで、カーネルバイパスとゼロコピーを実現して、往復のレイテンシを一桁マイクロ秒レベルまで下げられる通信方式だと説明されています。
操作としては、相手 CPU を一切使わずにメモリを読み書きする Write と Read、それから TCP に近い感覚で使える Send と Receive に分かれます。ただし、どれも事前に「メモリ登録」が必要になる、と。
メモリ登録というのは、その領域のページを固定して、アクセス用のキーを発行しておく処理ですね。これをやっておかないと、NIC が勝手にそのメモリに DMA できない、という仕組みです。
GPUDirect RDMA は、この RDMA を GPU メモリにまで拡張した技術として紹介されています。
BARワンと呼ばれる、「GPU メモリを PCIe 上に写し出す窓」を使うことで、NIC が GPU メモリに直接 DMA できるようになります。
これによって、従来必要だった「GPU から一度 CPU メモリにコピーして、それを NIC で送信する」という遠回りが不要になり、たとえば学習時の all_reduce のような GPU 間通信の効率を、大きく引き上げられるというわけです。
実装方式としては、古い peer-memory 方式と、新しい dma-buf 方式が整理されています。
前者は nvidia-peermem というカーネルモジュールに頼るやり方で、後者の dma-buf は Linux 標準のバッファ共有の仕組みを使うものです。
記事では、今後は標準的な dma-buf のほうへの移行が進んでいくだろう、と見通しが述べられていました。
さらに AWS の EFA、Elastic Fabric Adapter の話も詳しいです。EFA は InfiniBand そのものではなくて、SRD という独自プロトコルを使っています。
SRD は「信頼性はあるけれど、パケット順序は保証しない」プロトコルで、これを verbs 互換の API の上に載せています。パケット順序の復元は libfabric がやってくれる、という二層構造ですね。
これによって、巨大クラスタでもスケールする RDMA を実現していて、NVSHMEM や NCCL からは「順序付き RDMA 通信」ができているように見える、という整理でした。
後半では、「ほんとうに GPUDirect RDMA over EFA が動いているのか」をどう検証するかという手順が紹介されています。
まず fi_info で EFA が有効になっているかを確認して、fi_pingpong で RTT を測定して、さらに nccl-tests を使って all_reduce の実験を行います。
その結果を、ログと帯域値、busbw の値を見ながら、「これは GPU から直接飛んでいるね」と検証していく流れです。
あわせて、どのインスタンス世代なら機能が有効かとか、セキュリティグループの設定でハマりやすいポイントなど、運用上の注意点もまとめられています。
GPU クラスタを本気でチューニングしたい人向けの、実践的なガイドになっています。
。。.。。.。.
そして五つ目、最後の記事は、DNS 問い合わせや TLS の SNI が DoH や ECH によって暗号化されていくことで、「ネットワークの途中からホスト名を手がかりにした監視が効きにくくなっている」という話題です。
いま Web 全体としては、DNS の問い合わせも、TLS のサーバーネームインジケーション、SNI も、どんどん暗号化される方向に進んでいます。DNS over HTTPS や、Encrypted Client Hello ですね。
これはユーザーのプライバシーを守るという意味ではごく自然な流れなんですが、一方で、企業ネットワークや CI／CD 環境では、これまで DNS や SNI を見て通信先を判別していた前提が、崩れつつあるという問題意識が示されています。
DNS については、HTTPS レコードなどを通じて、ブラウザ側の接続戦略の一部になっていて、ブラウザ自身が DoH を使って独自に名前解決してしまうため、OS やネットワーク側からの制御がしにくくなっている、という指摘があります。
通信の相手を IP アドレスだけで見ても、CDN 配下のトラフィックだと、どのサービスに向かっているのか、ほとんど正体が分からないケースが多いですよね。
じゃあ昔みたいに TLS を中間で復号して、中身を見て可視性を取り戻そう、というやり方はどうかと言うと、そもそも Web が「中間者を信用しない」方向に進んでいるので、そこに逆行することになる、と述べています。
代わりのアプローチとしては、「どのジョブ、どのプロセスが、どのファイルやクレデンシャルにアクセスした直後に、どこへ通信したのか」といった文脈まで含めて、CI／CD の実行環境側で観測していく必要があるだろう、としています。
ただ、それをやろうとすると、ログの量も膨大になりますし、どこで線を引いて「これは怪しい」「これは正常」と判定するかも、とても難しい、という現実があります。
筆者自身も、現時点でこれだという明確な解決策を持っているわけではなくて、この大きな変化の中で、「どこを新しい観測点としていくべきか」を今後も追っていきたい、と問題提起で終わるかたちになっていました。
プライバシー保護と運用監視、そのバランスをどう取るか、というのは、これから数年の大きなテーマになりそうですね。
。。.。。.。.
というわけで、今日は五本の記事をご紹介しました。
ざっとおさらいすると、
最初は、フロントエンドとバックエンド、Supabase や React の役割を整理しながら、「どこでコードが実行されるか」「RLS や状態管理をどう考えるか」といった、初めての Web アプリ開発の地図になる記事。
二本目は、Linux カーネルのカーネルスタックダンプを、十六進数の「模様」として読み解くコツを解説した、低レイヤー好きにはたまらない記事。
三本目は、TAKT という OSS を使って、AI エージェントのワークフローを YAML で宣言し、「人間の都度確認」をワークフロー定義に置き換えていく試み。
四本目は、RDMA と GPUDirect RDMA、それを AWS EFA 上でどう検証するかまでまとめた、GPU クラスタのための超低レイテンシ通信解説。
そして最後は、DoH や ECH によってホスト名ベースの監視が効きにくくなる中で、どこを観測点にしていくか、というネットワーク監視のこれからを考える記事でした。
気になった記事があれば、ぜひショーノートから元の記事をチェックしてみてください。ここでは話しきれなかった図やコードの細かいところまで、じっくり読めると思います。
「zenncast」では、番組の感想や、こんなテーマを取り上げてほしい、といったリクエストもお待ちしています。
また次回、どんな記事をご紹介できるのか、マイクも楽しみにしています。
それでは、そろそろお別れの時間です。
お相手はマイクでした。
今日も良い一日をお過ごしください。