ecspressoの設計思想に至る道 設計ナイト2025 2025-07-25 @fujiwara 

自己紹介 @fujiwara (X, GitHub, Bluesky) @sfujiwara (hatena, mixi2) 2011〜2024 面白法人カヤック 2025-02〜 さくらインターネット ISUCON 優勝4回 / 運営(出題)4回 

ecspresso Amazon ECS デプロイツール(OSS) github.com/kayac/ecspresso 940 2017-12〜 現在 v2.6.0 主に国内企業で広く利用されている (ニンテンドーアカウントでも！) 「エスプレッソ」と読みます 

ecspressoの設計思想 ecspressoは、ツールが操作する 範囲を意図的にECSのみに限定 するように設計されています。 必要な関連リソースについては 利用者が他の手段で管理するこ とを前提としています。 (ecspresso handbookより引用) ECSはbuilding blockの一つ 他のコンポーネントとの関わり (VPC, LB)が多いが管理を分けた いことが多い ライフサイクル(変更頻度)が違う 

この設計思想はどこから? ecspresso 最初のリリース 2017-12 この時点では特になかった ecspresso handbook 2020-12 執筆時に初めて言語化 作ってから3年経って初めて意識した (言語化した)いわば後付け 

思想が生まれるには理由というか経緯がある 今日はそこに至る流れの話をします 

2014年10月 カヤックが運営していた Lobi (スマホゲームユーザー向けSNS) Rec SDK(プレイ動画共有)を モンスターストライクに導入 大量の動画がアップロードされて 変換処理を行うシステム ElasticTranscoderでは破産する EC2 spotでオートスケールしたい (EC2は全部で100台規模に) 

2014〜2015年 Hashicorp Consul + fujiwara/stretcher オートスケールするにはデプロイをpull型にする必要があるので作ったシステム 　 

Consul + Stretcher このデプロイシステムはともても良かった(自画自賛) オートスケールするEC2 spot インスタンスは使い捨て可能 Consul クラスタに参加したサーバーをヘルスチェックして管理 DNSによるサービスディスカバリー KVSによるデプロイ関連情報などの保存、参照 Stretcher Consulのイベントで全台にデプロイ通知 オートスケール対応、高速デプロイ・ロールバック デプロイもロールバックも1分で 

2015年 とあるソーシャルゲームを開発、運用開始 発注元(プラットホーム) ゲーム開発と運営(カヤック) AWSインフラ管理(MSP) の座組でやることに 発注元の意向でAWSやEC2上のOS、ミドルウェア管理はMSP ここに Consul+Stretcher を入れた (成功体験ゆえに) 

責任範囲 システム構成 アプリケーション Consul,nginx,Fluentd... EC2 OS IAM, VPC, LB, RDS... 👥 カヤック 👥 MSP 運用が意外と大変に… Consul = アプリケーションとの接点が多い ミドルウェア 当時一般的ではない(2014〜)ので MSPさんに知見はない サーバーはRaftクラスタなので 「異常があったら再起動」は MSPさんは快く運用を引き受けてく れたが、お互い苦労が多かった (他にnginx, Fluentdなども責任が曖昧) 

責任範囲 システム構成 ECS App,nginx,Fluentd... IAM, VPC, LB, RDS... 👥 カヤック 👥 MSP 2017年 同じ座組で新タイトル そろそろコンテナでいけそうな時代? (2015 - Amazon ECS/Kubernetes v1.0) 前回で懲りたので 責任分界点を事前に切った 「ECS上は全部好きにしたい」 「それ以外の管理はお任せします」 (IAM的にいうと ecs:* をください) アプリと密接なミドルウェアはECS →管理責任が明確 

ecspresso の設計思想は前提条件が由来 ツールが操作する範囲を意図的にECSのみに限定するように設計されています これは後付け 最初から確固たる思想があって設計されたわけではない 「ECS上は好きにできる環境」を前提に作られたのが ecspresso ただし、結果的にはとても良かった 

2020年 ecspresso リリースから3年後 社内外にユーザーが増えて質問が多くなってきた OSS = 社外の利用は自己責任(as is)だが社内ではそうもいかない マニュアルを充実させないといけないがOSSなので英語で書くのも大変 …アドベントカレンダーで24本記事を書いたら充実するのでは? → 一人で10万字書き切って、Zenn の本としてまとめたのが ecspresso handbook 初日の記事で「開発思想」として述べている https://zenn.dev/fujiwara/articles/4847fb822f2820 

ecspresso の設計思想(再掲) ecspressoは、ツールが操作する範囲を意図的にECSのみに限定するように設計さ れています。必要な関連リソースについては利用者が他の手段で管理することを 前提としています。 この思想は ecspresso が生まれた環境由来 つまり、これがマッチする組織(体制)とそうでないところがあるはず 

ecspresso が向く組織、向かない組織 向かない: 小数名で全部やる、上から下まで一つのツールでやれる 向いている: 一つのチームで面倒を見るがある程度複雑なシステム アプリのデプロイとインフラの変更は分離して扱いたい 向いている: アプリケーションの開発運用(デプロイ)をやるチームと、 それ以外をやるチームが分かれている 向かない(かも): アプリケーションの開発者は開発しかしない 本番へのデプロイや設定(secretsや環境変数を含む)は全て運用チームの責務 ツールの責任範囲と、使う組織の責任範囲が揃っているところに向いている 

設計 = 世界をどこで切り分けるか コードの中でも外(システム全体)でも 設計とはほぼ 「どこで切るか」 を決めることではないか? 切る箇所が適切 = 堅牢、問題の切り分けや変更が容易、開発も運用もしやすい 切る箇所が不適切 = その逆 

適切な境界線は未来永劫同じわけではない サービス、システムや組織が成長拡大すると 適切な境界もそれに応じて移動することがある 例: 1人で全部面倒を見ていたサービスが成長 → 10人の開発者、2人のSREを含む30人のチームになった 一つの変更で全てを管理するツールを使うことは適切でなくなる(場合がある) その時々に応じて、適切な境界の見極めをしていくことが大事 

設計思想に至る道 みんな最初から適切な設計手法や思想があったわけではない(と思う) 書籍などからのインプット+成功や失敗の経験を踏まえて導き出されたもの https://speakerdeck.com/twada/quality-and-speed-aws-dev-day-2023-tokyo-edition?