(レポート) DVO308: 本稼働環境のDockerおよびECS:インフラストラクチャをHerokuからAWSに移行した方法 #reinvent

(レポート) DVO308: 本稼働環境のDockerおよびECS:インフラストラクチャをHerokuからAWSに移行した方法 #reinvent

Clock Icon2015.10.10

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

丹内です。掲題のセッションをレポートします。

スピーカー

背景

教師向けメッセージングプラットフォームRemindのシステムは、初期はモノリシックな(Railsを使っていることと絡めて、モノレールと表現していました)状態からスタートしたそうです。この時はHerokuで動いていました。
そして、ビジネスの拡大に伴い問題が出て、マイクロサービスへの移行を決意したそうです。
マイクロサービスに期待するのもは、開発を早く行うことができる、ということだったそうです。

Building an Empire

アプリケーションをマイクロサービスに書きなおした後はデプロイとなるのですが、その際には12Factorを意識したとのことでした。 そして、それをサポートするためにEmpireというデプロイツールを作成したそうです。
デプロイの単位として1アプリを内蔵したコンテナが考えられ、それが多数存在し、デプロイが管理されることになります。

ECS

デプロイ先にはAmazonECS(EC2 Container Service)を採用しました。 これにより、インフラ管理やコンテナのマネージのために書くソースコードがほぼ無くなったそうです。

スライドの28ページから、12Factorの実現方法の詳細になります。

LogをKinesisにながしたりするところは、昨今のKinesisの進化の恩恵を受けれそうで、非常に良いと思います。

最後に書いてますが、ECSホストの待ち時間が現在のところ課題になっているそうです。
同じく時間がかかると思われるDockerイメージのビルドですが、こちらは独自にconveyorというツールを作り、解決しています。

感想

マイクロサービスの運用について、実践してみないとわからない問題や解決にむけた取り組みを知ることができました。
特に、12Factorの実現方法が書いてあるのは良かったです。

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.