「隙間家具OSS」に至る道 Fujiwara Tech Conference 2025 藤原俊一郎 @fujiwara 

自己紹介 @fujiwara (X, GitHub, Bluesky) @sfujiwara (hatena, mixi2) 面白法人カヤック 〜2025-01(退職) ISUCON 優勝4回 / 運営(出題)4回 github.com/kayac/ecspresso github.com/fujiwara/lambroll 

No content

好きなもの 収まりがよくて 手触りがよくて 高性能 フラッグシップにはあまり興味がない 

https://sfujiwara.hatenablog.com/entry/wdpress108 

OSSとの出会い 2000年12月 Linux Conference 2000 Fall & Perl/Ruby Conference WEB+DB PRESS 創刊号 

2006年 Plagger Plugin 関連の記事をブログ(はてなダイアリー)に書いていた このころ年間50記事とか https://sfujiwara.hatenablog.com/entry/20060529/1148879110 

2007年 IRC / CodeRepos での交流 CPAN authorになる WebService::FC2::SpamAPI Catalyst::Plugin::ClamAV blogをCatalystで実装していた https://gigazine.net/news/20060629_passnavi/ 

2009年 YAPC::Asia 2009 でLTに誘ってもらった (初めてのリアル登壇) 

Sub::Pipe print "" | html; # <a> こういう関数( html )を実装できるモジュール 本質部分は2行しかない use overload '|' => sub { $_[0]->( $_[1] ) }; sub joint(&) { bless $_[0], __PACKAGE__ }; danさんに添削してもらった https://dankogai.livedoor.blog/archives/5121567 8.html 

2011年 カヤックに転職, ISUCON優勝 https://isucon.net/archives/30155061.html 

2011/10 YAPC::Asia 2011 ベストスピーカー https://sfujiwara.hatenablog.com/entry/20111014/1318576104 

2012年 Fluentd との出会い fluent-plugin-zabbix fluent-plugin-suppress fluent-plugin-imkayac fluent-plugin-cloudwatch (メンテナ引継ぎ) Fluent::Logger(perl) https://github.com/fluent/fluent-logger-perl 

OSS活動 初期の振り返り だいたい何かの Plugin 的なものを書いている 実は自前WebフレームワークとかORMも書いたことはある pluggable な OSS 開発のいいところ 大きなフレームワークから明示的なインターフェースで委譲された 「隙間」を埋める小さなパーツ 取りかかるハードルが低い(技術的にも心理的にも) すぐに成果が出る 

2014年〜 Go をメインに https://www.kayac.com/news/2014/08/golang 作問した ISUCON3(2013) で Go初期実装提供開始 

2014-12 Stretcher Pull型デプロイツール 使っていた Archer (perl + ssh + rsync) が辛くなってきたため AWS CodeDeploy や sorah/mamiya を 参考にして設計 pull型 (tarをS3から取ってくる) tar, rsyncをコマンド呼び出し コマンド実行(アプリ再起動) Go でシングルバイナリ 

2015年ごろ ほぼ全てのワークロードがAWSになる(というか移行した) 最初はIaaS的に使っていたが、だんだんクラウドネイティブな使い方に マネージドサービスの活用 データストア、メッセージング(queue)などをマネージドサービスに コンピューティングとストレージの分離 オートスケール 

クラウド以前のシステム = サーバーの中で動く 1台のサーバーの中のアプリケーションで ストレージ(ファイル) メッセージング(ただの関数呼び出しだったりするけど) コンピュート(計算処理) 大きなアプリケーションの中で小さい隙間を埋めたい → プラグイン、Glueコード 

クラウド前提のシステム = 複数のサービスにまたがってシステムを構築する クラウドの中で ストレージ(オブジェクトストレージ) メッセージング(message queue) コンピュート(FaaSも含む) サーバー上の1プロセス → クラウド上の1コンテナ(Function) スケーラビリティを獲得するために進化した結果 大きなクラウドの中で小さい隙間を埋めたい → 入出力がAPIになったアプリケーションやFaaSのコード 

隙間家具OSSの個人的エポックメイキング Rin - Redshift data Importer by SQS messaging. https://github.com/fujiwara/Rin 2015年に開発 Redshift へのデータ取り込み概念図 COPY クエリを誰か(利用者)が実行する必要がある 

最初は fluent-plugin-redshift を使っていたが… 手軽で便利なんだけど、運用していると辛くなってきた 1, 2 が同期的・不可分なplugin処理で実装されているため… 2で失敗するとリトライして1からやり直し → S3にごみが残る Redshiftのダウンタイム中にリトライが頻発する 

Rin の設計方針 S3 へのアップロードは他に任せる (fluentd) S3, SQS の可用性は大変高い ⇔ Redshift のダウンタイムは比較的大きい ミスマッチ部分を一度に処理しないことでリトライを容易に Redshift への COPY 発行に特化するツール 

誰もが困る隙間は埋まる(ことが多い) Rin 開発2ヶ月後 Firehose がリリース。マネージドな取り込みができるようになった が、東京リージョンで使えるようになったのは2年後 Rinのメリットもあった 設定が柔軟にできる S3に置かれるログなら何でも取り込める(ALB, CloudFront, 他何でも) Firehose はリトライが2時間まで、Redshift の長時間停止が難しい 結局 2015〜2024 まで10年使い続けた (2025/01上旬に引退) 2024-10-30 「Amazon Redshift の自動コピーの一般提供のお知らせ」 https://aws.amazon.com/jp/about-aws/whats-new/2024/10/general-availability-auto-copy-amazon-redshift/ 

2018年「隙間家具OSS」の言語化 https://speakerdeck.com/fujiwara3/xi-jian-jia-ju-ossfalsesusume https://speakerdeck.com/fujiwara3/aws-devday-tokyo-2019 

その後の隙間家具OSS ecspresso Amazon ECS デプロイツール (2017/12) mirage-ecs ECS で好きなだけ環境構築 (2019/06) lambroll AWS Lambda デプロイツール (2019/11) tracer ECS タスクのログ(など)を見やすく表示 (2021/11) ecrm Amazon ECR を安全に掃除 (2022/08) cfft CloudFront Functions デプロイツール (2024/01) lamux AWS Lambda multiplexer (2024/10) 「fujiwara-ware紹介 Advent Calendar 2024」 https://adventar.org/calendars/10954 

2018年以降 IaaS をほぼ使わなくなった クラウドサービスを直接扱うものや、開発環境をいい感じにするものが増えている デプロイツール(公式のがあんまり…) ecspresso, lambroll, cfft... マネージドサービスの機能が物足りないのを補完 ecrm, tracer... 開発環境構築を容易にする mirage-ecs, lamux... 

隙間家具OSSとして大事なこと 必要な機能だけ作る、手を広げすぎない、やりすぎない 公式/自前がどこまでやるか(やるべきか)を考えてインターフェースを設計する 公式で十分な物がでたら捨てる/代替することを常に考えておく 「隙間」を見極めて 適切なインターフェースをもった 過不足がない 外しやすい ソフトウェアを書く → 設計力が必要 

個人の作品としてのOSS 「隙間家具OSS」は大人数で作るようなものではない 数百行ぐらいのコードを書き捨てて済ませる「隙間」を あえて適切な汎用性を持ったプロダクトとして抽出する → 1人でできる仕事 「早く行きたければ一人で行け、遠くへ行きたければみんなで行け」 「隙間」はみんなで埋めるほど大きくない。1人でさっさと埋めればよい でもよくある「隙間」なら、そこを埋めるパーツを使い回せるといいよね 

https://speakerdeck.com/twada/quality-and-speed-aws-dev-day-2023-tokyo-edition 

個人の力で打開する局面はある 現代の IT エンジニアリングはチーム戦、だけど チームでやる大きな仕事 = 個々の小さい局面の組み合わせ 個々の局面は個人の力で打開するしかない そのための力(設計力・実装力・運用力)は常に鍛えておきたいですね 

結局、好きなものを作っている 収まりがよくて = 隙間によくフィットして 手触りがよくて = 使いやすくて 高性能 = いい感じに動く