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