$30 off During Our Annual Pro Sale. View Details »

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

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

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

FUJIWARA Shunichiro

August 08, 2023
Tweet

More Decks by FUJIWARA Shunichiro

Other Decks in Technology

Transcript

  1. 隙間家具職人が考えること
    2023.08.08 ecspresso MeetUp
    @fujiwara 藤原俊一郎

    View Slide

  2. @fujiwara (Twitter, GitHub, Bluesky)
    面白法人カヤック SREチーム
    ISUCON 優勝4回
    ISUCON 運営(出題)4回
    代表作 github.com/kayac/ecspresso
    Amazon ECS デプロイツール

    View Slide

  3. 謝辞
    ecspressoをはじめ拙作のOSSをご利用の皆様
    ecspresso handbookをご購入の皆様
    GitHub Sponsorsの皆様
    meetupを企画、運営してくださったJAWS-UGコンテナ支部の皆様
    いつも本当にありがとうございます!

    View Slide

  4. 今日の話
    ecspressoの話は(あまり)しません
    つ AWS Dev Day 2023 Tokyoの発表
    ("ecspresso 5年"で検索)
    隙間家具OSSについて
    名前について
    設定について
    作って使ってメンテする

    View Slide

  5. 隙間家具OSS

    View Slide

  6. 隙間家具OSS
    初出 吉祥寺.pm 16 (2018.11)
    AWS Dev Day 2019でも発表
    ("隙間家具 speakerdeck"で検索)

    View Slide

  7. 隙間家具OSSとは
    マネージドサービス、コンポーネントの隙間を埋めて便利にするもの
    マネージドサービスが時間とともに成長して不要になったら取り外す(ことも念頭に)

    View Slide

  8. 隙間家具とGlue
    Glue = 糊 複数のコンポーネントの間をつなぐもの
    隙間家具 = 隙間に入れて便利になるもの
    似ているけどちょっと違う?
    Glue = 形がない、柔軟、オーダーメイド、個別に書くコード
    隙間家具 = 形がある、そこまで柔軟ではない、レディメイド、単体ソフトウェア

    View Slide

  9. クラウドのサービスと単体ソフトウェア(ミドルウェア)の進化
    クラウドのマネージドサービスはより周辺と繋がる方向に進化しがち

    View Slide

  10. 【例】 MySQLとAmazon RDS for MySQL
    たとえばログの取り扱い
    MySQLのログ = ファイル(またはテーブル)に書き出す
    RDSのログ = (最初期) MySQLのログファイルを取り出すAPI
    → (今) CloudWatch Logsに送れる
    MySQL = RDBMSそのものの進化
    機能が増える、SQLで使える構文が増える、パフォーマンスが上がる
    RDS = 運用を簡単にする、関連コンポーネントの連携を含めて進化
    フェイルオーバー、バックアップ/リストア、ログ

    View Slide

  11. クラウドのコンポーネントの進化
    需要があるものは実装される(ないものはされないけど…)
    進化する → 隙間が減る
    隙間を密に繋いでしまうと取り外しに難儀する
    取り外しできるパーツを入れておいて、必要なくなったら取り外す

    View Slide

  12. Glueではなく隙間家具(単体のソフトウェア)にする理由
    Glueなコードはプロジェクト固有の事情に密結合しがち
    あるプロジェクトのリポジトリの中に置かれる
    コードの責任分界点が曖昧
    他のプロジェクトにコピペ(fork)されがち
    → 固有の事情(コピペ先の事情)によって改変されてだんだん別物に
    あるプロジェクトで行われたバグ修正が行き渡らない

    View Slide

  13. 【例】 APNs Push通知送信サーバー
    カヤックでの昔話
    APNs(Apple Push Notification Service)への送信は独自TCPプロトコル
    (いまはHTTP/2)、都度接続ではなく接続永続化が必要
    削除されたデバイストークンに送るとエラーになって切断される
    送信中の別通知が巻き添えを食ったりする。リトライが必要
    Perl/PHPなどのPreforkなWebアプリケーションから直接送信するのが難しかった
    → PerlのAnyEvent::APNSで実装された独自サーバーから送信していた

    View Slide

  14. 【例】 APNs Push通知送信サーバー
    カヤックでの昔話
    PerlのAnyEvent::APNSで実装された独自サーバーを
    単体のソフトウェアにせず、社内の各プロジェクトにコピペして使っていた
    各プロジェクトに依存するコードが埋め込まれて微妙に別物に
    デバイストークンの消し込みをDBに直接アクセスするとか
    → あるプロジェクトで直したbug fixがそのまま適用できない
    運用がつらい

    View Slide

  15. APNsのHTTP/2化を契機に単体OSSを作成
    kayac/Gunfish
    APNs/FCMにpush通知を送るサーバー
    Go製 OSS
    独立したアプリケーションとして実装
    プロジェクト個別カスタマイズはしない(できない)
    エラーになったデバイストークンの消し込みは外部コマンドを起動
    コマンドの標準入力にJSONを流し込むインタフェース

    View Slide

  16. 単体ソフトウェア/ライブラリとしてOSSにする
    各プロジェクトに依存するコードは入らない(入れられない)
    一般的なユースケースに対応できるようにインタフェースが整理される
    プロジェクト固有の事情と一般的な事情を分離して設計と実装をするようになる
    bugfixはバージョンアップで適用できる
    ノウハウも統一できる
    複数プロジェクトの運用が楽になる

    View Slide

  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
    完全に当初の想定外、だけど隙間家具としてはありかなあ…

    View Slide

  18. 名前のはなし

    View Slide

  19. 作る前に名前を考える
    最初に名前を考える
    ないと書き始められない (package名とかになるので)
    よい名前を付けるのは難しい、けど大事
    よいソフトウェアの名前の条件
    名が体を表している
    (隙間家具の場合) 関連するコンポーネントが連想しやすい
    覚えやすい、typeしやすい、短い
    既存のソフトウェアと被らない

    View Slide

  20. 名前の考えかた
    だいたい連想ゲーム
    ソフトウェアの責務から考えたり
    deployツール → deployの関連語
    英語の場合シソーラスを使うと便利
    thesaurus.com

    View Slide

  21. 命名の具体例(1) stretcher
    デプロイツール fujiwara/stretcher
    Pull型deploy(S3からtar.gzを取得して展開、みたいなの)を実現するもの
    stretch → 引っ張る、伸ばす(tar.gzを展開するから)
    stretcher → 担架(で運ぶ)
    担架 → tar.gzを運んでくるという意味でもありでは?
    覚えやすい、呼びやすい、タイプしやすい、短い

    View Slide

  22. 命名の具体例(2) lambroll
    Lambdaデプロイツール
    fujiwara/lambroll
    Lambdaを入れたら分かりやすい?
    Lamb(子羊)に何かくっつける?
    deploy → roll out
    lamb+roll → lambroll
    "lamb roll"で画像検索してみたら…
    (美味しそう)

    View Slide

  23. 命名で気を付けること
    名前かぶり
    GitHubで検索してみる
    完全に被らないのはまず無理だけど有名な(スターが多い)やつと被ってないか
    文化圏が遠そう、あんまり著名じゃなさそうならある程度被るのは許容する
    変な意味がないか(特に外国語で)
    Googleで(画像)検索してみる
    画像のほうがぱっと見で変なものが出ないか分かりやすい

    View Slide

  24. そのまんまの名前を付けることも
    kinesis-tailf
    Kinesis Data Streamsを tail -f
    のように追尾して表示するもの
    tfstate-lookup
    Terraform tfstateの要素を参照するCLI/ライブラリ
    これはこれで分かりやすいのでよい
    ライブラリはこのほうが他の人に探されやすいかも?

    View Slide

  25. ちなみに ecspresso は
    ECSをもじった名前
    espressoはいっぱいある
    ecspresso はなかった
    連想しやすい、覚えやすい
    呼びやすい、タイプしやすい
    短い、被るものがない

    View Slide

  26. 設定について

    View Slide

  27. 設定項目、設定ファイル
    理想 = ゼロコンフィグ
    なにもしないで思った通りに動いてほしい(無理)
    なんらかの値を渡す必要はある

    View Slide

  28. 設定ファイル vs Flag vs Env
    コマンドライン引数だけで済むのか、設定ファイルがいるのか
    設定項目が単純、少数ならflagかenvでよい
    設定項目が多数、複雑、階層が必要ならファイルでないと厳しい
    ある値を設定したい場合
    設定ファイルの値
    CLI flagの値
    環境変数の値
    どれをどう受け入れてどういう順序に優先するか
    場当たり的に実装するとぐちゃぐちゃになりがち

    View Slide

  29. 設定の指針
    設定ファイル: 実行時に(ほぼ)変更したくならない値
    Flag, Env: 実行時に環境によって決まる可能性が高い値や上書きする値
    ごく小規模なうちは問題になりくい
    規模/ユースケースが増えると混乱しがち
    将来「この設定ファイルの値を上書きするflagを1個足してほしい」
    という一見シンプルなissueで苦しむことになる……(かもしれない)

    View Slide

  30. 設定ファイルのフォーマット
    JSON, YAML, TOML, HCL, DSL, 独自記法……いろいろある
    作者の好みでもいいけど "PlainなJSON" も扱えるとよいのでは
    各種CLIやプログラミング言語からの生成、加工( jq
    でも)に一番便利なのがJSON
    (ただし人間が書くには辛い)
    YAML, Jsonnet, CUE langなどで管理 → JSONに変換して使う
    この経路があると周辺で工夫しやすい、活用範囲が広くなる
    設定ファイルも外界とのインターフェースの一部

    View Slide

  31. 設定ファイルは必要悪
    なにも書かないでいい感じに動いてほしい(理想)
    → デフォルトがいい感じ、変えたいところだけ変えればいい(落とし所)
    0からファイルを書くのは(作者でも)面倒
    設定させる項目が多すぎるとつらい
    面倒なツールは使い始める気が起きない
    自動生成を検討する
    特に隙間家具の場合、なんらかの関連コンポーネントが既にある
    そこを参照していいかんじの設定ファイルを自動生成できると
    使い始めるハードルがものすごく下がる

    View Slide

  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月以前)に使ってくれていた人はすごい、感謝

    View Slide

  33. 作って使ってメンテしていくこと

    View Slide

  34. 作って使ってメンテしていくこと
    「コードはできるだけ書かない方がよい」
    それはそう。書いたものは資産にも負債にもなる
    「できるだけ既存のツールの組み合わせでなんとかしたい」
    それでよい運用ができるならもちろんOK
    「このツールだけで全部完結させたい」
    (趣味なら好きにすればいいけど仕事では)ひとつのツールに拘りすぎないほうがよい
    適切な道具を適切に使う、必要なら道具も自分で作るのがプロフェッショナル

    View Slide

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

    View Slide

  36. 自分で設計したシステムをメンテする経験
    システムをシンプルに作ってシンプルに保つ力は経験で得るしかない
    大きなシステム、ビジネスのメインプロジェクトで経験を積むのは難しい
    隙間家具なら…
    小さいのでいくつも作れる (練習になる)
    なくても何とかなるけどあると便利 (失敗したら使わなければよい)
    成功してもいつか取り外すことも念頭に作る (そのための設計を考える)
    使い始めたらメンテはしていく (要望の取捨選択も含めて)
    コードはできれば書かない方がいい
    でも、鍛えておかないといざという時にうまく書けない

    View Slide

  37. Any Questions?
    今日の話について、ecspresso自体の話、なんでもどうぞ!

    View Slide