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