隙間家具職人が考えること/ecspresso meetup

JAWS-UG コンテナ支部 #24 ecspresso MeetUp
https://jawsug-container.connpass.com/event/285124/

Transcript

1. 隙間家具職人が考えること 2023.08.08 ecspresso MeetUp @fujiwara 藤原俊一郎
2. @fujiwara (Twitter, GitHub, Bluesky) 面白法人カヤック SREチーム ISUCON 優勝4回 ISUCON 運営(出題)4回 代表作 github.com/kayac/ecspresso Amazon ECS デプロイツール
3. 謝辞 ecspressoをはじめ拙作のOSSをご利用の皆様 ecspresso handbookをご購入の皆様 GitHub Sponsorsの皆様 meetupを企画、運営してくださったJAWS-UGコンテナ支部の皆様 いつも本当にありがとうございます！
4. 今日の話 ecspressoの話は(あまり)しません つ AWS Dev Day 2023 Tokyoの発表 ("ecspresso 5年"で検索) 隙間家具OSSについて 名前について 設定について 作って使ってメンテする
5. 隙間家具OSS
6. 隙間家具OSS 初出 吉祥寺.pm 16 (2018.11) AWS Dev Day 2019でも発表 ("隙間家具 speakerdeck"で検索)
7. 隙間家具OSSとは マネージドサービス、コンポーネントの隙間を埋めて便利にするもの マネージドサービスが時間とともに成長して不要になったら取り外す(ことも念頭に)
8. 隙間家具とGlue Glue = 糊 複数のコンポーネントの間をつなぐもの 隙間家具 = 隙間に入れて便利になるもの 似ているけどちょっと違う? Glue = 形がない、柔軟、オーダーメイド、個別に書くコード 隙間家具 = 形がある、そこまで柔軟ではない、レディメイド、単体ソフトウェア
9. クラウドのサービスと単体ソフトウェア(ミドルウェア)の進化 クラウドのマネージドサービスはより周辺と繋がる方向に進化しがち
10. 【例】 MySQLとAmazon RDS for MySQL たとえばログの取り扱い MySQLのログ = ファイル(またはテーブル)に書き出す RDSのログ = (最初期) MySQLのログファイルを取り出すAPI → (今) CloudWatch Logsに送れる MySQL = RDBMSそのものの進化 機能が増える、SQLで使える構文が増える、パフォーマンスが上がる RDS = 運用を簡単にする、関連コンポーネントの連携を含めて進化 フェイルオーバー、バックアップ/リストア、ログ
11. クラウドのコンポーネントの進化 需要があるものは実装される(ないものはされないけど…) 進化する → 隙間が減る 隙間を密に繋いでしまうと取り外しに難儀する 取り外しできるパーツを入れておいて、必要なくなったら取り外す
12. Glueではなく隙間家具(単体のソフトウェア)にする理由 Glueなコードはプロジェクト固有の事情に密結合しがち あるプロジェクトのリポジトリの中に置かれる コードの責任分界点が曖昧 他のプロジェクトにコピペ(fork)されがち → 固有の事情(コピペ先の事情)によって改変されてだんだん別物に あるプロジェクトで行われたバグ修正が行き渡らない
13. 【例】 APNs Push通知送信サーバー カヤックでの昔話 APNs(Apple Push Notification Service)への送信は独自TCPプロトコル (いまはHTTP/2)、都度接続ではなく接続永続化が必要 削除されたデバイストークンに送るとエラーになって切断される 送信中の別通知が巻き添えを食ったりする。リトライが必要 Perl/PHPなどのPreforkなWebアプリケーションから直接送信するのが難しかった → PerlのAnyEvent::APNSで実装された独自サーバーから送信していた
14. 【例】 APNs Push通知送信サーバー カヤックでの昔話 PerlのAnyEvent::APNSで実装された独自サーバーを 単体のソフトウェアにせず、社内の各プロジェクトにコピペして使っていた 各プロジェクトに依存するコードが埋め込まれて微妙に別物に デバイストークンの消し込みをDBに直接アクセスするとか → あるプロジェクトで直したbug fixがそのまま適用できない 運用がつらい
15. APNsのHTTP/2化を契機に単体OSSを作成 kayac/Gunfish APNs/FCMにpush通知を送るサーバー Go製 OSS 独立したアプリケーションとして実装 プロジェクト個別カスタマイズはしない(できない) エラーになったデバイストークンの消し込みは外部コマンドを起動 コマンドの標準入力にJSONを流し込むインタフェース
16. 単体ソフトウェア/ライブラリとしてOSSにする 各プロジェクトに依存するコードは入らない(入れられない) 一般的なユースケースに対応できるようにインタフェースが整理される プロジェクト固有の事情と一般的な事情を分離して設計と実装をするようになる bugfixはバージョンアップで適用できる ノウハウも統一できる 複数プロジェクトの運用が楽になる
17. ところで ecspresso は【隙間家具】なのか ecspresso = Amazon ECSデプロイツール 最初は ecspresso → ECS という一方的な関係 Terraform tfstate、CloudFormation Output、SSM Parameter参照が追加された現在は… [(大きい)IaCツール] ⇔ ecspresso ⇔ [Amazon ECS] Terraform, CFn, CDKで小回りがきかない部分(＝ECSへのデプロイ)を埋めるツールに? 【最近観測した例】 CDKでタスク定義を管理 CI/CDで ecspresso init → jq で生成ファイルの image だけ書き換え → ecspresso deploy 完全に当初の想定外、だけど隙間家具としてはありかなあ…
18. 名前のはなし
19. 作る前に名前を考える 最初に名前を考える ないと書き始められない (package名とかになるので) よい名前を付けるのは難しい、けど大事 よいソフトウェアの名前の条件 名が体を表している (隙間家具の場合) 関連するコンポーネントが連想しやすい 覚えやすい、typeしやすい、短い 既存のソフトウェアと被らない
20. 名前の考えかた だいたい連想ゲーム ソフトウェアの責務から考えたり deployツール → deployの関連語 英語の場合シソーラスを使うと便利 thesaurus.com
21. 命名の具体例(1) stretcher デプロイツール fujiwara/stretcher Pull型deploy(S3からtar.gzを取得して展開、みたいなの)を実現するもの stretch → 引っ張る、伸ばす(tar.gzを展開するから) stretcher → 担架(で運ぶ) 担架 → tar.gzを運んでくるという意味でもありでは? 覚えやすい、呼びやすい、タイプしやすい、短い
22. 命名の具体例(2) lambroll Lambdaデプロイツール fujiwara/lambroll Lambdaを入れたら分かりやすい? Lamb(子羊)に何かくっつける? deploy → roll out lamb+roll → lambroll "lamb roll"で画像検索してみたら… (美味しそう)
23. 命名で気を付けること 名前かぶり GitHubで検索してみる 完全に被らないのはまず無理だけど有名な(スターが多い)やつと被ってないか 文化圏が遠そう、あんまり著名じゃなさそうならある程度被るのは許容する 変な意味がないか(特に外国語で) Googleで(画像)検索してみる 画像のほうがぱっと見で変なものが出ないか分かりやすい
24. そのまんまの名前を付けることも kinesis-tailf Kinesis Data Streamsを tail -f のように追尾して表示するもの tfstate-lookup Terraform tfstateの要素を参照するCLI/ライブラリ これはこれで分かりやすいのでよい ライブラリはこのほうが他の人に探されやすいかも?
25. ちなみに ecspresso は ECSをもじった名前 espressoはいっぱいある ecspresso はなかった 連想しやすい、覚えやすい 呼びやすい、タイプしやすい 短い、被るものがない
26. 設定について
27. 設定項目、設定ファイル 理想 = ゼロコンフィグ なにもしないで思った通りに動いてほしい(無理) なんらかの値を渡す必要はある
28. 設定ファイル vs Flag vs Env コマンドライン引数だけで済むのか、設定ファイルがいるのか 設定項目が単純、少数ならflagかenvでよい 設定項目が多数、複雑、階層が必要ならファイルでないと厳しい ある値を設定したい場合 設定ファイルの値 CLI flagの値 環境変数の値 どれをどう受け入れてどういう順序に優先するか 場当たり的に実装するとぐちゃぐちゃになりがち
29. 設定の指針 設定ファイル: 実行時に(ほぼ)変更したくならない値 Flag, Env: 実行時に環境によって決まる可能性が高い値や上書きする値 ごく小規模なうちは問題になりくい 規模/ユースケースが増えると混乱しがち 将来「この設定ファイルの値を上書きするflagを1個足してほしい」 という一見シンプルなissueで苦しむことになる……(かもしれない)
30. 設定ファイルのフォーマット JSON, YAML, TOML, HCL, DSL, 独自記法……いろいろある 作者の好みでもいいけど "PlainなJSON" も扱えるとよいのでは 各種CLIやプログラミング言語からの生成、加工( jq でも)に一番便利なのがJSON (ただし人間が書くには辛い) YAML, Jsonnet, CUE langなどで管理 → JSONに変換して使う この経路があると周辺で工夫しやすい、活用範囲が広くなる 設定ファイルも外界とのインターフェースの一部
31. 設定ファイルは必要悪 なにも書かないでいい感じに動いてほしい(理想) → デフォルトがいい感じ、変えたいところだけ変えればいい(落とし所) 0からファイルを書くのは(作者でも)面倒 設定させる項目が多すぎるとつらい 面倒なツールは使い始める気が起きない 自動生成を検討する 特に隙間家具の場合、なんらかの関連コンポーネントが既にある そこを参照していいかんじの設定ファイルを自動生成できると 使い始めるハードルがものすごく下がる
32. ecspresso init ecspresso init --cluster ESC クラスタ名 --service ECS サービス名 指定したクラスタのサービスを参照して設定ファイルを自動生成する ecspresso.yml ecs-service-def.json ecs-task-def.json 生成しただけの状態で ecspresso deploy は完全に動作する (何も挙動は変わらないでデプロイされる) 変えたいところだけ変えてみる、テンプレート化してみる → ecspresso deploy で変更が反映される これがなかったころ(2019年11月以前)に使ってくれていた人はすごい、感謝
33. 作って使ってメンテしていくこと
34. 作って使ってメンテしていくこと 「コードはできるだけ書かない方がよい」 それはそう。書いたものは資産にも負債にもなる 「できるだけ既存のツールの組み合わせでなんとかしたい」 それでよい運用ができるならもちろんOK 「このツールだけで全部完結させたい」 (趣味なら好きにすればいいけど仕事では)ひとつのツールに拘りすぎないほうがよい 適切な道具を適切に使う、必要なら道具も自分で作るのがプロフェッショナル
35. https://speakerdeck.com/twada/quality-and-speed-aws-dev-day-2023-tokyo-edition
36. 自分で設計したシステムをメンテする経験 システムをシンプルに作ってシンプルに保つ力は経験で得るしかない 大きなシステム、ビジネスのメインプロジェクトで経験を積むのは難しい 隙間家具なら… 小さいのでいくつも作れる (練習になる) なくても何とかなるけどあると便利 (失敗したら使わなければよい) 成功してもいつか取り外すことも念頭に作る (そのための設計を考える) 使い始めたらメンテはしていく (要望の取捨選択も含めて) コードはできれば書かない方がいい でも、鍛えておかないといざという時にうまく書けない
37. Any Questions? 今日の話について、ecspresso自体の話、なんでもどうぞ！