同セッションでは、さくらインターネット株式会社のfujiwara（@fujiwara）さんが登壇。Amazon ECSのデプロイツールecspressoの8年間にわたる開発を題材に、技術選定における設計判断の積み重ねと失敗からの改善プロセスについてお話しいただきました。ぜひ本編のアーカイブ動画とあわせてご覧ください。
fujiwara：これからお話しする「ecspresso」は、Amazon ECSのデプロイツールです。2017年11月に開発を始めてから、8年間ずっとメンテナンスを続けています。
今回のタイトルは「作るべきものと向き合う」ですが、このトークには前編にあたるものが2つあります。1つは昨年の設計ナイトで発表した「設計思想に至る道」、もう1つはYAPC::Fukuokaで発表した「正しい抽象の探求」です。
今回はこの2つの続編、そして完結編として技術選定についてお話しします。
ecspressoの特徴と設計思想
ecspressoの特徴は、ECSのサービスとタスク定義のみを管理する点にあります。
ECSのサービスが動くためには、ネットワークのVPCやロードバランサー、データストアも必要になりますが、それらはあえて管理しません。ECSのサービスとタスク定義だけに集中して操作できるようにしています。
この設計思想の背景には、以前のEC2環境での課題がありました。アプリケーション開発とインフラ管理が分かれている環境では、1つのEC2上で動作しているNginxやFluentdのようなミドルウェアをどちらが管理するかが難しく、作業が衝突することがあったのです。これを避けるため、ECSを導入した際に責任分界点を明確に分けました。ECSの上はすべてアプリケーションのデプロイ担当者が行うようにし、この時につくられたのがecspressoです。
ツールが責任を分担し、「ここはやらない」と決まっている方が、変更頻度の高いアプリケーションをデプロイする際に都合が良いと感じています。インフラを誤って変更する事故を防げるためです。
正しい抽象化の探求
次に、「正しい抽象化の探求」というテーマについてお話しします。IaCツールとしてどのような抽象化レベルを選択するかという話です。
対比として挙げたいのが、AWS公式のECSデプロイツールである「AWS Copilot CLI」です。AWS Copilot CLIは独自の概念でECSや周辺リソースを一括で作成してくれるツールですが、5年間運用された後、2025年2月にメンテナンスが終了しました。
AWS Copilot CLIの抽象化がもたらした制約
AWS Copilot CLIは1つのYAMLファイルを書くだけでデプロイできるオピニオネイテッドな設計で、裏側でCloudFormationが自動生成されます。しかし、抽象化されているがゆえの制約がありました。
たとえば、ECSは1つのサービスに内部用と外部用の複数のロードバランサーを付けられます。しかしAWS Copilot CLIのDSL構造は、1アプリケーションにつき1ロードバランサーと強く結びついていたため、最後まで複数ロードバランサーをサポートできませんでした。また、対応していないリソースを使いたい場合はCloudFormationのテンプレートを自分で書く必要があり、複雑なことをやろうとすると制約が大きくなってしまいます。
世の中のあらゆるアプリケーションパターンを1つのYAMLファイルで網羅することは非常に難しいです。結果的にAWS Copilot CLIはメンテナンスが止まってしまいました。AWSが発表したサポート終了の記事でも、独自構文による学習コスト、可視性や拡張性の制約、トラブルシューティングの難しさについて触れられています。
