PipeCDプラグインへの期待 / Anticipating PipeCD Plugins

Transcript

1. PipeCDプラグインへの期待
2. Koji AGAWA @atty303 ソフトウェアエンジニア AI事業本部 協業リテールメディアDiv. ミライネージカンパニー Scala/Rustが好き #times_atty303 1/9
3. 今日のLT PipeCDにプラグインが導入されるということで、自分のプロダクトでの利用状況とPipeCDに 期待することを話します。 2/9
4. 現在の利用状況 LambdaApp の CUSTOM_SYNC ステージのみ使っている 2年近くリファクタリングしていないので SCRIPT_RUN ステージもまだ使っていない PipeCDらしい機能を使えていない Analysis, Canary, Rollback, ... 3/9
5. デプロイ頻度はこんな感じ 4/9
6. CUSTOM_SYNCの内訳 ECSサービスのデプロイ ecspressoを利用 デプロイしたイメージに対してECRのタグ付け Lambdaのデプロイ AWS SAMを利用 数が多いので複数のLambdaを単一Appで扱う SPAのデプロイ aws s3 syncを利用 5/9
7. なぜ組み込みECSではないのか？ PipeCDの前は aws/amazon-ecs-cli を利用してGitHub Actionsでデプロイしていた PipeCDに移行し、ecspressoを利用するように変更 なにか致命的な理由があったと思うが忘れた とりあえずecs-cliは使いにくかった ecs-cli/ecspressoで管理しているサービスをPipeCD管理にそのまま移行できるか不 明だった デプロイしているイメージにECRタグを付けたいのでカスタムステップを実行したいが当時 のECS Kindでは不可能だった 6/9
8. なぜ組み込みLambdaではないのか？ PipeCDの前からAWS SAM＋GitHub Actionsでデプロイしていてそのまま移行でき た インフラは基本Terraformで管理しているが、Lambdaローカルリソース（IAMや CloudWatchなど）はSAMのCloudFormation機能で管理 SAMはデプロイで関数だけでなくプロビジョニングも出来るのが良い 41個のLambda × 3環境 = 123 App の料金（社内マネージドサービス）がちょっと重 い 7/9
9. プラグイン導入により コアチームが関与することなくデプロイ戦術をカスタマイズできる SCRIPT_RUN より柔軟にコアと連携できることを期待 デプロイ戦略はコアチームが提供する GitOpsに特化 デプロイメントの状態管理（ステートフル） コアとプラグインのI/Fの拡張性が大事かも 基本なんでもできてしまうので、PipeCDでやる意味が必要 8/9
10. PipeCDに期待すること コア機能とプラグインに委任する機能の明確化 コアドメインが提供する価値に集中 PipeCDを選ぶ理由となるもの 個人的にPipeCDに求めるもの 特定の技術（K8s、ECS…）に依存しない中立なコアドメイン 宣言的なデプロイメントの状態管理とその状態への遷移定義 Script Run相当のメタプラグインは欲しい 9/9
11. ありがとうございました