毎回1つまたは複数のOSSを取り上げて、それについてエンジニアであるcatatsuyとへんてこで技術的なところも深掘りながら話をしていく番組です。
https://yaoyorozu-oss.henteko07.com/
番組の魅力・推薦
#16 CIに潜む「宝探し」を止めろ！cicd-sensorで挑むサプライチェーン攻撃検知の最前線 | rung
「たまたまCIを止めていたから助かった」──そんな偶然に頼ったサプライチェーン攻撃対策、そろそろ卒業しませんか？今回はゲストにcicd-sensor作者のrungさんを迎え、CI/CDジョブの中身を監視して攻撃を検知するというアプローチを深掘りします。前半はcicd-sensorの概要から。GitHub ActionsやGitLab CI/CDのジョブ上でeBPFを使ってプロセス・ネットワーク・ファイルアクセスを監視し、SSHキーやクラウドのアクセスキーを狙う「宝探し」型の攻撃を検知する仕組みを解説します。検知結果の表示やジョブの強制失敗に加え、実行時の挙動をログやattestationとして残して後から調査することもできます。後半は実装の深掘りで、cgroupによるジョブへのイベント仕分け、式言語CELで書かれた検知ルールとベースラインルールの設計思想、HTTPSで暗号化される前の情報をOpenSSLのuprobeで取得する、開発中のHTTPリクエスト監視機能の設計など、かなりディープな内容に。GitHubが攻撃データのアップロード先として悪用されると、`github.com`というドメイン名だけでは正常な通信と区別できない、という検知の難しさの話は必聴です。CIを回しているエンジニアなら他人事ではない一本。正式リリース前のいま、ぜひチェックしてみてください。## 関連リンク- cicd-sensor（公式サイト）: https://cicd-sensor.github.io/- cicd-sensor（GitHubリポジトリ）: https://github.com/cicd-sensor/cicd-sensor- cicd-sensorのattestation predicate: https://cicd-sensor.github.io/user-guide/attestation-predicate.html- HTTPリクエスト監視機能の設計: https://github.com/cicd-sensor/cicd-sensor/issues/136- GitHub Actions: https://github.com/features/actions- GitLab CI/CD: https://docs.gitlab.com/ci/- eBPF: https://ebpf.io/- CEL (Common Expression Language): https://cel.dev/- Open Policy Agent (Rego): https://www.openpolicyagent.org/- Expr: https://github.com/expr-lang/expr- Falco: https://falco.org/- Tetragon: https://tetragon.io/- cilium/ebpf: https://github.com/cilium/ebpf- cgroups: https://man7.org/linux/man-pages/man7/cgroups.7.html- Renovate: https://docs.renovatebot.com/- GMO Flatt Security: https://flatt.tech/─────────────YouTube: https://youtu.be/DK1-qUmI_pAWeb: https://yaoyorozu-oss.henteko07.com/X: https://x.com/yaoyorozu_oss
#15 103 Early Hints、返すだけでは速くならない
103 Early Hintsは、最終的なHTMLが完成する前に、必要になりそうなCSSやJavaScriptを`Link`ヘッダーでブラウザへ知らせる仕組みです。ただし、103を返すだけでページが速くなるわけではありません。今回catatsuyが紹介するEarly Hintsについて、初めて聞くhentekoが仕組みから実運用の注意点まで質問しながら掘り下げます。前半では、現在は主要ブラウザから削除されたHTTP/2 Server Pushから振り返ります。サーバーにはブラウザのキャッシュ状態が分からず、不要なリソースまで送ってしまう問題がありました。H2Oはこの問題に対して、ブラウザが持っていると推測されるリソースを`h2o_casper` Cookieで管理するCASPerを実装しました。さらに、その発想をHTTP/2へ一般化するCache Digestsも提案されましたが、標準化には至りませんでした。Early HintsではリソースそのものをPushせず、取得するかどうかをブラウザに委ねることで、この役割分担を変えています。後半では、SSRでHTMLを生成している間にCSSやJavaScriptの取得を進める仕組み、CDN Edgeから早く返す利点、fingerprint付きassetとデプロイ世代の同期問題を取り上げます。nginx 1.29.0の`early_hints`ディレクティブはupstreamから届いた103を転送する機能であり、nginx自身が103を生成するものではありません。また、HTTP/2・HTTP/3かつ`Sec-Fetch-Mode: navigate`に対象を絞る理由や、nginx 1.29.7以降ではproxy先のデフォルトがHTTP/1.1に変わったことも紹介します。Early Hintsで重要なのは、確実に使う少数のリソースだけをHintし、端末別に計測することです。Shopifyの観測データの事例も参照しながら、preloadするリソースを増やしすぎると逆効果になり得ることや、実際にLCPが改善したかを確認する必要性まで考えます。- Early Hintsの解説（Chrome for Developers）: https://developer.chrome.com/docs/web-platform/early-hints- Remove HTTP/2 Server Push from Chrome（Chrome for Developers）: https://developer.chrome.com/blog/removing-push- H2O HTTP/2 Directives — http2-casper: https://h2o.examp1e.net/configure/http2_directives.html- Cache Digests for HTTP/2（IETF Datatracker）: https://datatracker.ietf.org/doc/draft-ietf-httpbis-cache-digest/- RFC 8297: An HTTP Status Code for Indicating Hints: https://datatracker.ietf.org/doc/html/rfc8297- NGINX Introduces Support for 103 Early Hints: https://blog.nginx.org/blog/nginx-introduces-support-103-early-hints- nginx Issue #779 — Enable Early Hints 103 without upstream support: https://github.com/nginx/nginx/issues/779- Keep-alive to upstreams is now default in NGINX 1.29.7: https://blog.nginx.org/blog/keep-alive-to-upstreams-is-now-default-in-nginx-1-29-7- Fastly Early Hints documentation: https://www.fastly.com/documentation/reference/http/early-hints/- Fastly VCL `early_hints()`: https://www.fastly.com/documentation/reference/vcl/functions/tls-and-http/early-hints/- FastlyとYottaaのEarly Hints導入事例: https://www.fastly.com/jp/blog/how-fastly-and-yottaa-transform-site-performance-with-early-hints- Early Hints at Shopify（Performance @ Shopify）: https://performance.shopify.com/blogs/blog/early-hints-at-shopify関連リンク:- 103 Early Hints（MDN）: https://developer.mozilla.org/ja/docs/Web/HTTP/Reference/Status/103- Sec-Fetch-Mode（MDN）: https://developer.mozilla.org/ja/docs/Web/HTTP/Reference/Headers/Sec-Fetch-Mode- Next.js: https://nextjs.org/- Go `net/http`: https://pkg.go.dev/net/http- Lighthouse（Chrome for Developers）: https://developer.chrome.com/docs/lighthouse/overview- CrUX（Chrome UX Report）: https://developer.chrome.com/docs/crux- New Relic: https://newrelic.com/─────────────YouTube: https://youtu.be/jFyg4t3hK80Web: https://yaoyorozu-oss.henteko07.com/X: https://x.com/yaoyorozu_oss
#14 画像変換を支えるOSSと実運用
Webサービスで画像をきれいに、軽く配るには何から考えればよいのでしょうか。今回は、可逆圧縮で透過も扱えるPNGと、非可逆圧縮で写真に向くJPEGの違いを出発点に、画像フォーマットの選び方と、それを実際のサービスで運用するための設計を整理します。現代のスマートフォンはカメラの性能が高く、Webサービスでそのまま扱うには大きすぎる画像がアップロードされることがあります。Canvas APIを使えば、ブラウザ上で画像を変換できます。ただし、必要な画質や保存したい元画像、通信量、変換を行う場所はサービスによって異なります。画像を一律に小さくすればよいのではなく、そのサービスに合った扱いを決める必要があります。配信する画像では、細かなquality設定より先に十分な画像サイズを確保します。高密度ディスプレイではCSS上の表示幅より大きな画像が必要ですが、全員に最大サイズを送ると転送量が増えます。そこで、固定サイズのサムネイルを事前生成する構成から、必要な派生画像を動的に生成してCDNへキャッシュする構成へ。`Accept`ヘッダーによるフォーマットの出し分けと、`picture`・`srcset`で複数サイズからブラウザに選ばせる方法を紹介します。WebPは写真に有効な一方、テキスト画像やドット絵まで機械的にWebPへ変換するのは現実的ではありません。WebPの実装が実質的にlibwebp一つに限られていることや、画像の種類に応じたpresetの扱いも取り上げます。現在ではAVIFも有力な選択肢で、JPEGをフォールバックにしてAVIFを追加する構成も考えられますが、AVIFはエンコード負荷が高い点に注意が必要です。どの形式でも同じqualityの値が同じ見た目を意味するわけではないため、実際の画像と容量を見ながら調整します。ImageMagickやcwebpを使えば、サーバー側でも画像を変換できます。ただし、変換処理が一度成功することと、ユーザーがアップロードする多様な画像を継続して処理できることは別です。極端な縦横比や想定外の画像が来たときの処理負荷、変換後のファイルサイズなど、実サービスで確認すべき点にも踏み込みます。画像URLをフロントエンドで自由に組み立てず、バックエンドが許可済みの候補URLを返す理由も、後方互換性とCDNキャッシュ効率の両面から考えます。派生画像をCDNへキャッシュし、実際に配信されたオブジェクトサイズを監視する。必要に応じて画像変換SaaSへ任せる。WebPを選べば終わりではなく、入力、変換、URL、キャッシュ、監視をどのようにつなげるかまで、実際の運用を想像しながら考える回です。- catatsuy「CDNを活用した画像配信の設計と最適化」: https://zenn.dev/catatsuy/articles/43b5cf583fac76- catatsuy「サムネイル画像URLはバックエンドで生成すべき」: https://zenn.dev/catatsuy/articles/4070de849114e0- catatsuy「CDNを活用して高速なWebサービスを提供する」: https://zenn.dev/catatsuy/articles/ea86bdba548ab9- catatsuy「Webサービス上の画像変換とWebPの利用について」: https://engineering.mercari.com/blog/entry/20201211-image-optim-webp/- ImageMagick: https://imagemagick.org/- WebP: https://developers.google.com/speed/webp- libwebp: https://chromium.googlesource.com/webm/libwebp- libavif: https://github.com/AOMediaCodec/libavif- Squoosh: https://squoosh.app/- Fastly Image Optimizer: https://www.fastly.com/products/image-optimizer- picture要素（MDN）: https://developer.mozilla.org/ja/docs/Web/HTML/Reference/Elements/picture- レスポンシブ画像（MDN）: https://developer.mozilla.org/ja/docs/Web/HTML/Guides/Responsive_images- Acceptヘッダー（MDN）: https://developer.mozilla.org/ja/docs/Web/HTTP/Reference/Headers/Accept- Canvas API（MDN）: https://developer.mozilla.org/ja/docs/Web/API/Canvas_API─────────────YouTube: https://youtu.be/7Qlmj-X1yhUWeb: https://yaoyorozu-oss.henteko07.com/X: https://x.com/yaoyorozu_oss
#13 memcachedはシンプルなまま —— Netflix EVCacheの「賢いクライアント」設計
memcachedはシンプルで高速です。一方で、複数の場所にデータを複製したり、障害が起きたときの読み書きを切り替えたりするところまでは面倒を見ません。では、大規模なサービスでは、たくさんのmemcached serverをどう扱えばよいのでしょうか。今回はNetflixが公開しているOSS「EVCache」を読みながら考えます。EVCacheはmemcached serverそのものを複雑にするのではなく、アプリケーション側のsmart clientが状況を判断します。writeは複数のAvailability ZoneにあるServerGroupへ送り、readは近くのServerGroupを優先。近くのcacheに問題があれば、別のzoneへ切り替えます。すべてのwriteが終わるまで必ず待つのではなく、一部の失敗や古い値を許容するのも、消えても作り直せるcacheならではの割り切りです。serverを増減したとき、保存先の変化をどう小さくするのか。アクセスが一つのkeyに集中したらどうするのか。空のcache clusterをいきなりread対象にすると何が起きるのか。こうしたcacheの一般的な問題から出発し、consistent hashing、client-side in-memory cache、先にwriteだけを流して温めるwrite-only ServerGroupといったEVCacheの実装につなげていきます。EVCacheのコードを手がかりに、Netflixが大規模なcacheをどう支えているのかを読み解きます。cacheをserverだけでなく、client、deploy、障害時の切り替え、監視まで含めて考える視点を学ぶ回です。- Netflix EVCache: https://github.com/Netflix/EVCache- memcached: https://memcached.org/- pecl memcached: https://pecl.php.net/package/memcached- 達人が教えるWebパフォーマンスチューニング（ISUCON本）: https://gihyo.jp/book/2022/978-4-297-12846-3─────────────YouTube: https://youtu.be/8_zwaJgqN5YWeb: https://yaoyorozu-oss.henteko07.com/X: https://x.com/yaoyorozu_oss
#12 全部やらないデプロイツール — ecspresso/lambrollが引いた"分界点" | fujiwara
「デプロイって、実はAPIを3回くらい叩けばできるんですよ」——ECS用デプロイツール「ecspresso」とLambda用の「lambroll」を作ったfujiwaraさんをゲストに迎え、自作デプロイツール10年の進化を深掘りするゲスト回です。SAMやServerless Frameworkを選ばずCloudFormationを経由しない道を選んだ理由から始まり、最初は300行だったツールが1万行に育つまでに足されてきた機能の話が続きます。デプロイ前にイメージやサブネットの存在を検証するverify、マネコンでの手動変更による先祖返りを防ぐdiff、プルリクから生まれたrun task対応、Terraformのtfstateを名前解決に使うtfstate-lookup。Jsonnetとテンプレート記法が衝突した「食い合わせ問題」や、ECS側にネイティブロールバックが入って追従に苦労した話など、APIを直接叩くツールならではの苦労も赤裸々です。終盤はREADMEを丸ごとバイナリに埋め込むAI対応と、ecspressoインスパイアなツールが独立に複数生まれている最近の面白い現象へ。デプロイツールを自作したい人、OSSのメンテナンスのリアルを知りたい人におすすめの回です。- ecspresso: https://github.com/kayac/ecspresso- lambroll: https://github.com/fujiwara/lambroll- tfstate-lookup: https://github.com/fujiwara/tfstate-lookup- Amazon ECS: https://aws.amazon.com/ecs/- AWS Lambda: https://aws.amazon.com/lambda/- Terraform: https://www.terraform.io/- AWS CDK: https://aws.amazon.com/cdk/- AWS SAM: https://aws.amazon.com/serverless/sam/- Serverless Framework: https://www.serverless.com/- apex: https://github.com/apex/apex- Jsonnet: https://jsonnet.org/- go-jsonnet: https://github.com/google/go-jsonnet- skillsmith: https://github.com/Songmu/skillsmith─────────────YouTube: https://youtu.be/P2gl8GSH-EcWeb: https://yaoyorozu-oss.henteko07.com/X: https://x.com/yaoyorozu_oss
#11 Let’s Encryptは無料より自動化がすごい！証明書運用の知られざる世界
無料でTLS証明書を発行できるLet's Encrypt。でも本当に画期的だったのは「無料」ではなく、ACMEプロトコルによる自動更新だった——そんな話から始まる今回は、証明書運用の知られざる世界をcatatsuyがたっぷり語ります。前半は、ドメインの所有をどう証明するかという「ACMEチャレンジ」の話。定番のHTTP-01、catatsuyが愛用するDNS-01、TLS終端リバースプロキシや大規模ホスティング事業者向けのTLS-ALPN-01という3方式の使い分けから、Certbot・dehydrated・legoといったクライアントの乗り換え遍歴、Route 53と組み合わせたDNS-01運用のノウハウまでを深掘りします。中盤では、Cloudflare DNSがダッシュボードに表示されないCAAレコードを自動追加していたという話と、そこから始めたCTログ監視の話も飛び出します。後半は、証明書の有効期限が45日に短縮される規定路線を見据えた「プロファイル」の解説から、有効期限わずか6日のshortlived証明書を自宅サーバーで実運用してみた体験談へ。レートリミットとの戦い、ARIによる更新タイミングの調整とレート制限回避、常にクリティカルになってしま監視アラート、通知があふれて機能しなくなるCTログ監視……最先端を走ると何が起きるのか、実際に運用したからこそ見えた学びが満載です。証明書を「ポチポチ手作業」で更新している人、これから自動化を考えるインフラエンジニアにこそ聞いてほしい回です。- Let's Encrypt: https://letsencrypt.org/- ACMEプロトコル (RFC 8555): https://datatracker.ietf.org/doc/html/rfc8555- Let's Encrypt 証明書プロファイル: https://letsencrypt.org/docs/profiles/- ARI — ACME Renewal Information (RFC 9773): https://datatracker.ietf.org/doc/html/rfc9773- CAAレコード (RFC 8659): https://datatracker.ietf.org/doc/html/rfc8659- Certbot: https://certbot.eff.org/- dehydrated: https://github.com/dehydrated-io/dehydrated- lego: https://go-acme.github.io/lego/- Certificate Transparency: https://certificate.transparency.dev/- Amazon Route 53: https://aws.amazon.com/route53/- Cloudflare: https://www.cloudflare.com/- nginx: https://nginx.org/- New Relic: https://newrelic.com/─────────────YouTube: https://youtu.be/7FQ_5ukYkqwWeb: https://yaoyorozu-oss.henteko07.com/X: https://x.com/yaoyorozu_oss
#10 なぜMeetやZoomで録らないのか —— ポッドキャスト収録の技術
Meetの録画じゃダメなの？——ダメなんです。音質の劣化、そして何より話者ごとにトラックを分離できないから。今回はhentekoが「八百万のOSS」を支える自作ツール群を解説します。ブラウザだけで収録できる「Maycast Room」、非破壊編集にこだわったmacOSアプリ「Maycast Studio」、Apple公式SpeechAnalyzerとDeepgramの使い分け、50分の音源が10秒で文字起こしされる衝撃、Remotion製の予告編動画の作り方。失敗して捨てたハイライト抽出ツールが予告編のアイデアに繋がった話も必聴です。自分でもポッドキャストをやってみたい人への実践的なヒントが詰まった回です。- MayCast Studio (henteko): https://github.com/henteko/maycast-studio- deepgram-cli (henteko): https://github.com/henteko/deepgram-cli- Cloudflare: https://www.cloudflare.com/- Cloudflare R2: https://developers.cloudflare.com/r2/- Mediabunny: https://mediabunny.dev/- Auphonic: https://auphonic.com/- Deepgram: https://deepgram.com/- Remotion: https://www.remotion.dev/- FFmpeg: https://ffmpeg.org/- Apple SpeechAnalyzer: https://developer.apple.com/documentation/speech/speechanalyzer- Google Gemini API: https://ai.google.dev/- Claude Code: https://claude.com/claude-code- Logic Pro: https://www.apple.com/logic-pro/- VLC media player: https://www.videolan.org/vlc/- Pocket Casts: https://pocketcasts.com/─────────────YouTube: https://youtu.be/7WsDmAzB-r4Web: https://yaoyorozu-oss.henteko07.com/X: https://x.com/yaoyorozu_oss
#9 HTTP/2で速くなった、はずだった —— HTTP/3との違いとCDN利用の現実
HTTP/2とHTTP/3は、Webを速く、安定して使うために出てきたプロトコルです。ただし「HTTP/3はHTTP/2より常に速い」という単純な話ではありません。今回は、HTTP/1.1で同じホストに複数TCP接続を張っていた時代から、SPDYを経てHTTP/2が生まれ、HTTP/3では何が変わったのかまでを整理します。HTTP/2は、1本のTCP接続で複数のリクエスト・レスポンスをストリームとして多重化し、HTTP/1.1にあったHTTPレイヤーのHead-of-Line Blockingを改善しました。HPACKによるヘッダー圧縮、ALPNによる`h2`と`http/1.1`の切り替え、仕様上は平文の`h2c`もあるがブラウザ向けWebでは実質HTTPS前提になっていること、nginxでは現在`http2 on;`で有効化することも扱います。一方でHTTP/2はTCPの上で動くため、TCP由来のHead-of-Line Blockingは残ります。パケットロスが起きると、1本のTCP接続に多重化された複数ストリームがまとめて影響を受けることがあります。HTTP/3はUDPを使うことで、このTCP由来の問題を避けやすくしようとしたプロトコルです。ただしHTTP/3は完全上位互換ではありません。安定した低遅延・低ロス環境ではHTTP/2と大差ないこともあり、データセンター間通信のような安定したネットワークでは通常HTTP/3は使いません。効きやすいのは、モバイル回線、海外通信、高RTT、パケットロスのあるような不安定なエンドユーザー回線です。導入面では、HTTP/3はHTTP/2のように同じTCP接続上で自然に切り替わるわけではなく、`Alt-Svc: h3=":443"`やHTTPS RRで「このオリジンはHTTP/3も使える」と知らせます。失敗すればHTTP/2やHTTP/1.1にフォールバックするため、実運用では共存が前提です。nginxでのHTTP/2はかなり実用上枯れてきており、ブラウザ向けHTTPSでは有効化しやすい選択肢です。一方でHTTP/3はアプリケーション側で実装・制御する範囲が大きく、自前で扱うのは大変です。現実的にはCDN側でHTTP/3を有効化し、CDN-Origin間やデータセンター間通信はHTTP/1.1やHTTP/2のままにする構成が普通です。OSS、ブラウザ、サーバー、CDN、標準化が絡み合ってHTTPが進化してきた話として、HTTP/2とHTTP/3の違いを見ていきます。- HTTP/2 (RFC 9113): https://www.rfc-editor.org/rfc/rfc9113- HTTP/3 (RFC 9114): https://www.rfc-editor.org/rfc/rfc9114- HPACK / HTTP/2ヘッダー圧縮 (RFC 7541): https://www.rfc-editor.org/rfc/rfc7541- TLS 1.3 (RFC 8446): https://www.rfc-editor.org/rfc/rfc8446- ALPN (RFC 7301): https://www.rfc-editor.org/rfc/rfc7301- Alt-Svc ヘッダー (RFC 7838): https://www.rfc-editor.org/rfc/rfc7838- SVCB / HTTPSリソースレコード (RFC 9460): https://www.rfc-editor.org/rfc/rfc9460- SPDY (Chromium): https://www.chromium.org/spdy/- nginx: https://nginx.org/- nginx HTTP/2 module: https://nginx.org/en/docs/http/ngx_http_v2_module.html- curl: https://curl.se/- nghttp2: https://nghttp2.org/- OpenSSL: https://www.openssl.org/- Next.js: https://nextjs.org/- webpack: https://webpack.js.org/- jQuery: https://jquery.com/- Cloudflare: https://www.cloudflare.com/- さくらのVPS: https://vps.sakura.ad.jp/- AWS: https://aws.amazon.com/─────────────YouTube: https://youtu.be/pOth4rhg3M8Web: https://yaoyorozu-oss.henteko07.com/X: https://x.com/yaoyorozu_oss
#8 GETするだけなのに書き込みが走る？memcachedのLRUとCPUの話
キャッシュサーバmemcachedをGoで再実装したcatatsuy。「マップに入れて返すだけでしょ」と思いきや、メモリを使い切る前にデータを捨てるeviction、最近使われていないデータを管理するLRU、そして素直なLRU実装では「GETがhitしてもリスト更新が走る」という落とし穴がありました。read-heavyなキャッシュなのに、GETが書き込みに近い処理になる。この自作版ではLRUがボトルネックになり、コード上は1コアしか使わない実装になっていました。自作してみると、mapで返すだけでは終わらない、LRUとロックの難しさが見えてきます。本家memcachedはHOT / WARM / COLD / TEMPのような世代分けを持ち、GETのたびに毎回LRU順位を真面目に更新するのではなく、active bit、async bump、LRU maintainerなどでリスト更新を分散・近似しています。LRUを真面目にやりすぎるとロックが増えるから、あえて真面目にやらない。その工夫があるからこそ、本家memcachedは複数CPUのある環境でもスケールしやすい。hentekoと一緒に、プロトコルの単純さと内部実装の難しさのギャップを覗いていきます。- utsuro: https://github.com/catatsuy/utsuro- memcached: https://github.com/memcached/memcached- memcached - a distributed memory object caching system https://memcached.org/blog/modern-lru/- Redis: https://redis.io/- OpenAI Codex: https://github.com/openai/codex- Go: https://go.dev/─────────────YouTube: https://youtu.be/KzZSzbZF5ikWeb: https://yaoyorozu-oss.henteko07.com/X: https://x.com/yaoyorozu_oss
#7 nginxを使わない理由がない？Webアプリを楽にするリバースプロキシの基本
nginxは「速いWebサーバー」というより、Webアプリケーションの前段でクライアントとの通信を受け持つ定番OSSです。遅いクライアント、大量接続、静的ファイル配信、gzip圧縮、バッファリング、キャッシュをnginxに任せることで、アプリケーションサーバーは本来の処理に集中できます。今回は、C10K問題、イベント駆動、ノンブロッキングI/Oといったnginxの基本的な考え方から、静的ファイル配信、gzip、upstream keepalive、古いコピペ設定が変わりつつある話までを取り上げました。「とりあえずnginxを置く」と言われがちな理由を、設定例の暗記ではなく、Webアプリケーションを楽にするための役割分担として整理していきます。EnvoyやPingoraとの違い、Cloudflareで使われてきた実績、そして「全部入り」はUnix哲学に反するのか、という話も取り上げています。nginxをなんとなく使っている人にも、設定の意味を改めて整理したい人にも楽しめる回です。- nginx: https://nginx.org/- freenginx: https://freenginx.org/- NGINX Plus（エンタープライズ版）: https://www.f5.com/products/nginx/nginx-plus- Envoy: https://www.envoyproxy.io/- Pingora（Cloudflareのプロキシ実装）: https://github.com/cloudflare/pingora- H2O（Fastlyで使われるHTTPサーバー）: https://github.com/h2o/h2o- PHP: https://www.php.net/- Node.js: https://nodejs.org/- AWS ALB（Application Load Balancer）: https://aws.amazon.com/elasticloadbalancing/application-load-balancer/- Cloudflare: https://www.cloudflare.com/- Fastly: https://www.fastly.com/- Mercurial: https://www.mercurial-scm.org/- OpenSSL: https://www.openssl.org/- Redis: https://redis.io/- Go: https://go.dev/- epoll（Linux man page）: https://man7.org/linux/man-pages/man7/epoll.7.html─────────────YouTube: https://youtu.be/e8lkL79n9KUWeb: https://yaoyorozu-oss.henteko07.com/X: https://x.com/yaoyorozu_oss
#6 ブラウザに巨大JSONが眠ってる？巨大データで見るブラウザの裏側
毎日使っているのに、ブラウザが中で何をしているか実はよく知らない——そんな話から始まる今回。catatsuyが取り上げるのは、ChromiumやFirefoxが裏側で扱っている「巨大なデータ」です。ブラウザはHTMLを描画するだけでなく、HTTPSへ強制するドメイン一覧、危険URLのリスト、証明書の失効情報、よく使われるリソースURLパターンなど、さまざまな補助データを持っています。しかし、それらを単純な巨大リストとしてそのまま持つのは難しく、毎回サーバーへ問い合わせるのもレイテンシやプライバシーの問題があります。今回はHSTS Preload、Google Safe Browsing、CRLite、Pervasive resource URL patternsなどを題材に、巨大なデータをブラウザがどう持ち、どう配り、どう高速に判定しているのかを話しました。HSTS Preloadのドメイン一覧とsuffix判定、Safe Browsingのhash prefix、CRLiteのBloom Filter cascade、そしてURL patternによるリソースURLの扱いなど、暗号やTLSだけではない、ブラウザを支えるデータ構造と配布設計を覗いていきます。trie treeやBloom Filterといったデータ構造の話も出てきますが、完全な仕様解説ではなく、ブラウザの裏側にある設計の面白さを見ていく回です。ブラウザの中身に興味が湧いてくる、盛りだくさんなお話です。* Chromium: https://www.chromium.org/* Firefox: https://www.mozilla.org/firefox/* HSTS Preload: https://hstspreload.org/* Google Safe Browsing: https://safebrowsing.google.com/* CRLite（Firefox）: https://github.com/mozilla/crlite* Certificate Transparency: https://certificate.transparency.dev/* Trie: https://en.wikipedia.org/wiki/Trie* Bloom Filter: https://en.wikipedia.org/wiki/Bloom_filter* Pervasive resource URL patterns: https://chromium.googlesource.com/chromium/src/+/HEAD/services/network/pervasive_resources* Brotli: https://github.com/google/brotli* Zstandard (zstd): https://github.com/facebook/zstd* Hono: https://hono.dev/* jQuery: https://jquery.com/* Rust: https://www.rust-lang.org/─────────────YouTube: https://youtu.be/NH1yseBycOwWeb: https://yaoyorozu-oss.henteko07.com/X: https://x.com/yaoyorozu_oss
#5 systemdは「プロセス起動係」じゃない？何でもできる正体に迫る
Linuxを触っていれば必ずお世話になっているのに、意外と中身を知らないsystemd。henteko の「OS起動時にプロセスを立ち上げる便利ツールでしょ?」という理解から話はスタートしますが、catatsuy が解き明かすその正体は想像のはるか上。依存関係の管理、死活監視、リソース制御、ソケットアクティベーション、cronより柔軟なタイマーまで——「何ができないのか」を探すレベルです。Linuxサーバーを運用する人なら絶対に聞いてほしい一本です。https://github.com/systemd/systemd
#4 AIが攻撃してくる時代、OSSの信頼はどう守る？
「ソースを公開する方がリスクが高い」——そんな時代が本当に来てしまったのかもしれません。攻撃者がAIでOSSをスキャンして自動で弱点を突いてくる今、守る我々もAIで立ち向かうしかない。xz事件からHonoのAI Slop問題、TanStackのサプライチェーン攻撃、Takumi Guardのような新しい防御サービスまで、catatsuy が実体験を交えて語ります。なぜ今、狙われているのが「開発者本人」なのか。OSSに関わるすべてのエンジニアに聞いてほしい一本です。## xz* Everything I Know About the XZ Backdoor - https://boehs.org/node/everything-i-know-about-the-xz-backdoor* CVE-2024-3094 / Ubuntu security page - https://ubuntu.com/security/CVE-2024-3094## Hono - OSSにおけるAI Slop問題の何が問題なのか？* https://zenn.dev/yusukebe/articles/3fd5bc6ea341c9## TanStackのnpmサプライチェーン攻撃とGitHub Actionsの危険な権限設計* TanStack npm supply-chain compromise - https://tanstack.com/blog/npm-supply-chain-compromise-postmortem* npm staged publishing - https://docs.npmjs.com/staged-publishing/* pull_request_target の背景・リスクに関するGitHub Community discussion - https://github.com/orgs/community/discussions/179107## axios ソフトウェアサプライチェーン攻撃の概要と対応指針* https://blog.flatt.tech/entry/axios_compromise## tj-actions/changed-files CVE-2025-30066* https://www.cisa.gov/news-events/alerts/2025/03/18/supply-chain-compromise-third-party-tj-actionschanged-files-cve-2025-30066-and-reviewdogaction## Takumi Guard* https://flatt.tech/takumi/features/guard
#3 ファイル改ざんに張る「kekkai」
EC2にPHPやRailsをポンと置いて運用している現場、ファイルがこっそり書き換えられたらどうやって気付きますか？ OSS「kekkai」は、ファイルごとのハッシュ値で改ざんを検知するシンプルなCLIツール。なぜエージェント型ではなくCLIなのか、S3とIAMでハッシュをどう守るのか、.gitignoreを敢えて共有しない設計思想までを丁寧に解説します。Docker時代に忘れられがちな「ファイル配置型」サーバーのセキュリティが気になる人にぜひ。https://github.com/catatsuy/kekkai
#2 なぜ自分で nginx をビルドするのか？ — nginx-build の世界
apt で入る nginx で大抵は事足りる。でも「この機能を使いたい」「最新の OpenSSL じゃないと動かない」となった瞬間、自分でコンパイルする世界が待っています。今回は catatsuy がメンテナンスする nginx-build を題材に、henteko が「そもそも、なんでビルドが必要なの？」と素朴に切り込みます。スタティックモジュールの話から、catatsuy が個人 VPS で ECH を動かすために加えた機能まで、nginx のディープな運用に興味がある人にぜひ。https://github.com/cubicdaiya/nginx-build
#1 GitHubで200スター集めた「Purl」の作り方
OSSを作って公開しても、誰にも届かずに埋もれていく──そんな経験はありませんか。今回はcatatsuyが作ったGo製CLIツール「Purl」がGitHubで200超のスターを集めた裏側を聞きました。READMEに動画を貼った理由、英語圏に向けて発信する意味、そして「自分が一番のユーザーであること」が改善の芯を食う、というドッグフーディングの話まで。ツールを作って広めたい人、自作OSSを育てている人にぜひ聞いてほしい回です。https://github.com/catatsuy/purl
こちらもおすすめ
で、売上になるんですか？～ポッドキャストとマーケの話～ #うりなる
マーケティングって売上に本当になっているの？ポッドキャストって売上につながるの？本来は売上・利益になる全ての活動が「マーケティング」ですが、なかなか判断が難しいところ。。この番組は株式会社オトバンクでポッドキャスト制作・音声コンテンツ制作の事業を手掛ける２人が、ポッドキャスト・音声を中心に、マーケティング活動と売上のことや、コンテンツづくり、ネットビジネスのトレンドやニュースなどを取り上げながら話していく番組です。▼ホスト富山真明（株式会社オトバンク、ポッドキャスト事業PitPa責任者）山田大介（株式会社オトバンク、スタジオオトバンク）▼SNSハッシュタグ#うりなる▼メッセージフォーム番組への感想や質問、リクエストの他、ポッドキャストに関するご相談は下記フォームよりお問い合わせください。https://bit.ly/3BNM3Rp▼制作PitPa（株式会社オトバンク）https://pitpa.jp/
BIBLIO JAM
BIBLIO JAMは新刊ノンフィクションを紹介するPodcast番組です。ノンフィクション好きのメンバーが選び抜いた一冊を、会話形式でお届けします。本が会話を生み出し、会話がさらに本を面白くする。本と人が織りなす、筋書きのない会話エンターテインメント。それがBIBLIO JAMです。毎週金曜朝に更新予定 ・BIBLIO JAM https://note.com/bibliojam/m/m4e5e7a1dfe0e ・SNS https://x.com/biblio_jam https://www.instagram.com/biblio_jam ・ご感想は https://forms.gle/CbdxwMHwytnJUgws7 または X（@biblio_jam）へのメンション #bibliojam まで
休憩
休憩中
キョースケのひとりごと
はじめまして，キョースケです！ 大学生の日常や出来事，おもしろかったこと そして大好きな読書の記録など，気ままに声にします！
OSSのレキシラジオ
エンジニアであるへんてこが毎週1つのOSSプロジェクトを取り上げてそのプロジェクトの歴史を紹介する番組です
カメラのこと、じぶんのこと、
40歳。これまでの人生を振り返ると、いつもそこにはカメラがあって。 これからもきっとずっと一緒に居ることになるから、一度ちゃんと真剣に向き合ってみようと。 カメラのこと、写真のこと、映像のことを主な題材にしながら「じぶんのコト」も織り交ぜながら話せればと。