Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
隙間家具職人が考えること/ecspresso meetup
Search
FUJIWARA Shunichiro
August 08, 2023
Technology
5
4.8k
隙間家具職人が考えること/ecspresso meetup
JAWS-UG コンテナ支部 #24 ecspresso MeetUp
https://jawsug-container.connpass.com/event/285124/
FUJIWARA Shunichiro
August 08, 2023
Tweet
Share
More Decks by FUJIWARA Shunichiro
See All by FUJIWARA Shunichiro
CEL(Common Expression Language)で書いた条件にマッチしたIAM Policyを見つける / iam-policy-finder
fujiwara3
0
710
awslim - Goで実装された高速なAWS CLIの代替品を作った/layerx.go#1
fujiwara3
4
560
AWS CLIの起動が重くてつらいので aws-sdk-client-go を書いた / kamakura.go#6
fujiwara3
7
9.1k
コードを書く隙間を見つけて生きていく技術/Findy 思考の現在地
fujiwara3
29
6.7k
fujiwara-ware OSSをひたすら紹介する/ya8-2024
fujiwara3
7
600
Amazon ECSで好きなだけ検証環境を起動できるOSSの設計・実装・運用 / YAPC::Hiroshima 2024
fujiwara3
22
7.7k
リアル事例から読み解くWebパフォーマンスチューニングの勘所/Offers web performance tuning
fujiwara3
4
1.6k
隙間家具OSS開発で『自分の庭』をつくる / kayac-andpad-event
fujiwara3
0
800
ISUCON作問入門/ ISUCON Summer Fes 2023
fujiwara3
2
1.7k
Other Decks in Technology
See All in Technology
エンジニアの生存戦略 〜クラウド潮流の経験から紐解く技術トレンドのメカニズムと乗りこなし方〜
shimy
9
1.9k
可視化プラットフォームGrafanaの基本と活用方法の全て
hamadakoji
0
230
Scaling Technical Excellence at 104: Evolution in AWS and Developer Empowerment
scotthsieh825
1
150
データ分析を支える技術 生成AI再入門
ishikawa_satoru
0
380
データベース研修 DB基礎【MIXI 24新卒技術研修】
mixi_engineers
PRO
0
210
地理情報とAPIのトレンド
nagix
0
160
AWSで”最小権限の原則”を実現するための考え方 /20240722-ssmjp-aws-least-privilege
opelab
10
4.3k
公共領域から学ぶ クラウド移行についてエンジニアが意識していること
kawakawa2222
0
140
ゆめみのアクセシビリティの現在地と今後
ryokatsuse
3
290
Git 研修 Basic【MIXI 24新卒技術研修】
mixi_engineers
PRO
0
310
楽しくGoを学び合う、LayerXの勉強会文化 / LayerX's study culture of having fun and learning Go together
ar_tama
2
350
クラウド利用者の「責任」をどう果たす?AWSセキュリティ対策のススメ #AWSSummit
hiashisan
0
270
Featured
See All Featured
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
36
9.1k
Statistics for Hackers
jakevdp
792
220k
The MySQL Ecosystem @ GitHub 2015
samlambert
248
12k
The Pragmatic Product Professional
lauravandoore
29
6.1k
Designing for humans not robots
tammielis
247
25k
Happy Clients
brianwarren
94
6.5k
Agile that works and the tools we love
rasmusluckow
325
20k
The Language of Interfaces
destraynor
151
23k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
13
430
Six Lessons from altMBA
skipperchong
24
3.2k
The Brand Is Dead. Long Live the Brand.
mthomps
52
36k
Design by the Numbers
sachag
277
18k
Transcript
隙間家具職人が考えること 2023.08.08 ecspresso MeetUp @fujiwara 藤原俊一郎
@fujiwara (Twitter, GitHub, Bluesky) 面白法人カヤック SREチーム ISUCON 優勝4回 ISUCON 運営(出題)4回
代表作 github.com/kayac/ecspresso Amazon 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とは マネージドサービス、コンポーネントの隙間を埋めて便利にするもの マネージドサービスが時間とともに成長して不要になったら取り外す(ことも念頭に)
隙間家具とGlue Glue = 糊 複数のコンポーネントの間をつなぐもの 隙間家具 = 隙間に入れて便利になるもの 似ているけどちょっと違う? 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/Gunfish APNs/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/stretcher Pull型deploy(S3からtar.gzを取得して展開、みたいなの)を実現するもの stretch → 引っ張る、伸ばす(tar.gzを展開するから) stretcher →
担架(で運ぶ) 担架 → tar.gzを運んでくるという意味でもありでは? 覚えやすい、呼びやすい、タイプしやすい、短い
命名の具体例(2) lambroll Lambdaデプロイツール fujiwara/lambroll Lambdaを入れたら分かりやすい? Lamb(子羊)に何かくっつける? deploy → roll out
lamb+roll → lambroll "lamb roll"で画像検索してみたら… (美味しそう)
命名で気を付けること 名前かぶり GitHubで検索してみる 完全に被らないのはまず無理だけど有名な(スターが多い)やつと被ってないか 文化圏が遠そう、あんまり著名じゃなさそうならある程度被るのは許容する 変な意味がないか(特に外国語で) Googleで(画像)検索してみる 画像のほうがぱっと見で変なものが出ないか分かりやすい
そのまんまの名前を付けることも kinesis-tailf Kinesis Data Streamsを tail -f のように追尾して表示するもの tfstate-lookup Terraform
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 init ecspresso init --cluster ESC クラスタ名 --service ECS サービス名
指定したクラスタのサービスを参照して設定ファイルを自動生成する ecspresso.yml ecs-service-def.json ecs-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自体の話、なんでもどうぞ!