コンテナで目指す育てやすいサービス開発

Amazon Container Service 事例祭り （2017 年 10 月 30 日開催）
https://pages.awscloud.com/ECSSeminar20171030.html

Transcript

1. コンテナで目指す育てやすいサービス開発 株式会社フォアキャスト・コミュニケーションズ @ Amazon Container Service 事例祭り 2017/10/30
2. フォアキャスト・コミュニケーションズ？ テレビ・メディア関係の事業を技術で支える会社 サイト配信 • 日本テレビ (https://www.ntv.co.jp/) • 読売巨人軍 (http://www.giants.jp/) ニュース配信 • 日テレNews24 (http://www.news24.jp/) 動画配信 • Hulu Japan (https://www.happyon.jp/) • 日テレオンデマンド (https://vod.ntv.co.jp/)
3. 自己紹介 Name： - 佐藤 司(@tsukapah) - (株)フォアキャスト・コミュニケーションズ システムサービスディビジョン Works： - 日本テレビ THE MUSIC DAY(番組連動ビンゴ企画等) - 某局年末歌番組投票企画(投票API) - etc AWS re:Invent 2017参加予定
4. • 弊社の業務の一つのWebコンテンツ運用向けツールとして、2017年4月からCMS の自社開発に着手、7月から社内でテストを兼ねての実運用を始めている。 • このCMSのプラットフォームにAWSおよびECSを活用しているのでご紹介。
5. アジェンダ • ECS採用経緯 • CMSの構成要素 • ECSのなにがいいか • ECSを採用するにあたって気をつけていること • 今抱えてる課題
6. ECS採用経緯 • 社内ツールを育てていく計画のため、マイクロサービスな実装にしたかった • 設計段階で開発言語を決めきれなかった • 一部のメンバーが個人的にDockerの検証を進めていた • 以上の点からDockerを採用してみることにした • 元々AWSの利用実績が多く、チーム内は満場一致でAWSを採用することになった • KubernetesやSwarmも検討したが、オーケストレーションツール自体の保守を避 けたかったのでECSを採用することにした
7. • Web UI • Web API • デーモン型のワーカーアプリケーション • 時限式(日次、毎時、等)のバッチアプリケーション • データストア(オブジェクトストア、RDBMS、ドキュメント指向DB) • ログ基盤 • システム監視 CMSの構成要素
8. こんな構成 ECS ECS ECS ECS
9. あらためてCMSの構成要素 • Web UI ◦ ALB+ECS+S3 • Web API ◦ ALB+ECS+各種データストア • デーモン型のワーカーアプリケーション ◦ ECS+各種データストア • 時限式(日次、毎時、等)のバッチアプリケーション ◦ CloudWatch Events+ECS+各種データストア • データストア(オブジェクトストア、RDBMS、ドキュメント指向DB) ◦ S3+RDS+Elasticsearch on ECS • ログ基盤 ◦ CloudWatch Logs+S3+Elasticsearch on ECS • システム監視 ◦ CloudWatch+Mackerel
10. ECSのなにがいいか • 実行環境が統一できる ◦ Dockerさえ動けばローカルPCでも環境の再現が可能。 • EC2インスタンスのリソースを有効活用できる ◦ 複数アプリケーションをモジュール等の依存関係を無視して一つのインスタンスで稼働させることができる。 • デプロイ方法が統一できる ◦ すべてのアプリケーションのデプロイ方法がコンテナイメージ(ECS Task)のデプロイに統一できる。 • ALBとの組み合わせがサイコー！！！ ◦ サービスディスカバリ(コンテナ稼働インスタンス、動的ポート等)を人間が意識する必要がない。必要なキャパシティの 分だけサービスをスケールすればOK。 • Logging DriverとしてCloudWatch Logsが使える ◦ Syslogサーバやfluentdサーバの保守から解放される。 • IAM Roles for Tasksで必要最低限のアクセス管理ができる！！！ ◦ 2016年7月まではインスタンスに紐付けられたIAM Roleをコンテナが利用する形だったので、すべてのコンテナの最 大公約数的なポリシーを設定する必要があったが、コンテナごとにポリシーが設定できるようになったのでコンテナに 必要最低限のアクセス許可をすることができる。 ※古いSDKを使ってるとAWSから認証情報が取得できないのでバージョンには要注意！
11. ECSを採用するにあたって気をつけていること • ECSだけではダメ、Dockerだけでもダメ ◦ 当たり前だが、両方のドキュメントを読むこと。特に、コンテナインスタンスに最新のDocker Engineを利用する場合、 ECSのドキュメントよりもDockerのドキュメントが優先されると思って良い。 ※開発初期、動的ポートマッピングについての ECSのドキュメントが最新の Dockerに追いついておらず、 セキュリティグループの設定により ALBとコンテナが通信できなくてコンテナが殺され続けるという悲劇に … • アプリケーションエンジニアにもコンテナを理解してもらう ◦ 当チームでは開発指針としてThe Twelve-factor Appを採用し、実装上困ったら参考にするようにしている。 ◦ Dockerfileは原則アプリケーションエンジニアに書いてもらい、インフラエンジニアはプラットフォームに集中する。 • 他の実装方法もあることを理解する ◦ ECSに限ったことではないが、同じことを実現するために、いろいろな選択肢がある。なぜこの実装方法を選択したの か、を理解し説明できるようにしておくと後で迷いが少なくなるし、方針を変える時にも有効。
12. いま抱えてる課題 • CI/CDのPipelineに悩んでいる ◦ 特にアプリケーションのビルドはどのタイミングですればいいのか悩んでる。コンテナ外でアプリの ビルドが通ったからといってコンテナで動くとは限らない。かと言ってコンテナビルド時にアプリケー ションビルドをするとコンテナイメージが大きくなる。 • デプロイに時間がかかる ◦ アプリケーションのビルドに加えコンテナのビルドに時間がかかるためデプロイが完了するまでに時 間がかかる。ビルド環境を見直せば改善できそうな気はしてる。 • 学習コストが高い ◦ コンテナ自体がまだまだ学習コストが高く、その敷居を跨いでもらうのに苦労する。 • ECSクラスタ自体の保守が面倒 ◦ ECSクラスタに参加するEC2(AMI)の保守がなくなるわけではない。 KubernetesやSwarmでも同じ ことが言えるが、インスタンスを意識しないで良いコンテナサービスを AWSに期待！
13. Let’s container Life！
14. 絶賛採用中!! http://www.4cast.co.jp/recruit/requirements/carrier.html