八百万のOSS

ミソラボ

毎回1つまたは複数のOSSを取り上げて、それについてエンジニアであるcatatsuyとへんてこで技術的なところも深掘りながら話をしていく番組です。 https://yaoyorozu-oss.henteko07.com/

  1. 6h ago

    #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-X1yhU Web: https://yaoyorozu-oss.henteko07.com/ X: https://x.com/yaoyorozu_oss

  2. Jul 28

    #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_zwaJgqN5Y Web: https://yaoyorozu-oss.henteko07.com/ X: https://x.com/yaoyorozu_oss

  3. Jul 21

    #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-Ec Web: https://yaoyorozu-oss.henteko07.com/ X: https://x.com/yaoyorozu_oss

  4. Jul 14

    #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_5ukYkqw Web: https://yaoyorozu-oss.henteko07.com/ X: https://x.com/yaoyorozu_oss

  5. Jul 7

    #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-r4 Web: https://yaoyorozu-oss.henteko07.com/ X: https://x.com/yaoyorozu_oss

  6. Jun 30

    #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/pOth4rhg3M8 Web: https://yaoyorozu-oss.henteko07.com/ X: https://x.com/yaoyorozu_oss

  7. Jun 23

    #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/KzZSzbZF5ik Web: https://yaoyorozu-oss.henteko07.com/ X: https://x.com/yaoyorozu_oss

  8. Jun 16

    #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/e8lkL79n9KU Web: https://yaoyorozu-oss.henteko07.com/ X: https://x.com/yaoyorozu_oss

See All (14)

About

毎回1つまたは複数のOSSを取り上げて、それについてエンジニアであるcatatsuyとへんてこで技術的なところも深掘りながら話をしていく番組です。 https://yaoyorozu-oss.henteko07.com/

Information

  • Creator
    ミソラボ
  • Years Active
    2026
  • Episodes
    14
  • Rating
    Clean
  • Copyright
    © ミソラボ
  • Show Website
    八百万のOSS

You Might Also Like