この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
現在開催中のre:Invent 2017にてCON410のセッション「Designing Control Planes for Microservice Deployments and Job Orchestration」に参加してきました。そのセッションレポートを書きます。
以下がセッションの概要です。Event pageから引用します。
Every engineering team has their own peculiarities and requirements, and the tools a team uses should fit their needs, without requiring them to build infrastructure from the ground up. This session focusses on how to design and build Control Planes on top of AWS services to reflect your engineering culture. We will explore how Clever builds control planes to manage deployments on Amazon ECS via CLIs and Slack and for orchestrating complex workflows via Step Functions.
1時間のセッションのうち40分以上が参加者とのdiscussionとして充てられ、活発な質疑応答があり非常に内容の濃いセッションとなりました。
About Clever Inc.
Cleverは2012年に設立されたeducation platform service providerで、授業アプリや教育機関向けのサービスを展開しています。
全部で数十のアプリケーションが存在しています。そのほとんどをAmazon ECS上でDocker Containerとして動かしており、アプリケーションのデプロイにはCloudFormationを用いています。非同期で複雑なジョブの実行にはAWS Step Functionsを利用しています。
Cleverのプラットフォームには複雑かつ大量のアプリケーションをデプロイする必要がありますが、環境構築・日々のデプロイ・アプリケーション監視などをシンプルに行うための「Control Planes（制御システム）」が必要だという考えで、Cleverではいくつかのシステムを内製しています。
Control planesを作る上で、「複雑な部分はAWSのサービスを使ってアウトソースし、自分たちの問題を解決することにフォーカスする」と語っていたのが印象的でした。
実際に、以下のような仕組みを作り上げているそうです（全ては取り上げられないので一部）。
- ECS + CloudFormationを使った、アプリケーションデプロイを自動化するCLIツール
- AWS Step Functionsを使ったジョブ実行のための管理GUIツール
- Event Routingのためのミドルウェア
- 複数のGitリポジトリにライブラリのアップデートなどを横展開するためのツール
画面では実際に実行される時のスクリーンショットも紹介されていました。印象に残ったのが
- ステップ実行になっているようなタスクの場合、どのタスクが完了しているかのprogressが可視化されていること
- エラーになった場合はエラーの詳細を確認できるURLが提示されていること
- 非同期で実行されるようなジョブの場合は、Slackを利用してジョブの結果が通知されること
という点でした。実際に利用するアプリケーション開発者やインフラエンジニアがツールを使うのが嫌にならないように、非常に気を遣われていると感じました。
その後の質疑応答ではインフラの具体的な構成、ツールの話から文化の醸成に関する話まで多岐にわたるディスカッションが行われました。私の印象に残ったところをいくつか書き残しておきます。
ECSのデプロイにCloudFormationを使うのか？
Clever社では現状、ECSのデプロイのためにCloudFormationを使っているという説明がありました。質疑応答では「CloudFormationを使うのと、直接ECSのAPIを叩いてデプロイするのではどちらが好ましいのか？」という主旨の質問がありました。その質問に対して「ECSを使い始める時、まだECSの仕組みに慣れていないのでCloudFormationを利用した。概ね満足しているが、ECSの知識も溜まってきたのと、より細かなデプロイの制御を行うために直接APIを叩いて実行する形式にこれから移行していくプランもある」という回答がありました。
私も今関わっているプロダクトでECSを利用しています。導入時、そのデプロイにCloudFormationを使うのか別のプロダクトを使うのかで悩みました。結局、細かな制御ができないことを懸念してCloudFormationの採用をせず、独自に開発したCLIツールで行うことにしました。しかし、初期の頃はECSの知識に書けていたためなかなかコンセプト実装が固まらずに苦労していました。知識を貯めるまでは、自動デプロイを達成するという目的を最優先してCloudFormationを使っておけばよかったかもしれないな、とセッションを聞きながら反省していました。
アプリケーションの定義ファイルについて
「アプリケーションのデプロイ定義ファイル（どの環境変数を設定して、どのPortを開いて...などが記載されたファイル）は、誰がメンテナンスするのか？」という質問からまた熱いディスカッションが始まりました。
Clever社のプロダクトでは、各Githubリポジトリにアプリケーションの動作定義yamlが配置されていると話がありました。そのため、この設定に責任をもつのはインフラ担当者だけではなく、各アプリケーションの開発者だという話がありました。
もともと、デプロイのためのツールを作っている時にYAMLの形式を一から作っていった際、「このファイルには、このアプリケーションが動作するために必要な情報が全て記載されているようにしよう」という意識でつくっていたそうです。環境変数やポートはもちろん、このプロダクトが依存している別のプロダクトに対する依存が記載されているなど、アプリケーションが動作するための前提条件が設定ファイルを見るだけでわかるようになっているとのことです。
デプロイツールの設定ファイルを書く時、そのアプリケーションがデプロイされる時の設定を羅列するだけのものを作っていたので、この考え方は個人的に衝撃的でした。と同時に、アプリケーションの定義ファイルとは、本来こうあるべきなのか、と新しい考え方に気づくことができました。
Circular dependency is evil.
アプリケーションはそれぞれ別のコンポーネントに依存しているが、循環参照(Circular dependency)は必ず作らないようにしていると言っていました。これは当然 & その通りなのですが、ディスカッション中に言い切られたので思わず笑ってしまいました。
=====
この後も、re:Inventのレポートをお届けしていきます。re:Inventの情報は、このページでまとめて確認できますのでご覧ください！
5
