JAWS-UGコンテナ支部 #3に参加してきた #jawsug #jawsug_ct

はじめに

今日はJAWS-UGコンテナ支部 #3に参加してきました！

場所はDeNAさんのセミナールーム。いつ来ても立派なお部屋です。

レポート

Amazon EC2 Container Service by AWSJ 岩永亮介さん (@riywo)

Amazon ECSデモ

　node.jsで書かれたGeneratorがダミーのアクセスログを作成、Kinesisに投入
　Pythonで書かれたConsumerがKinesisからログを取得、AWS IoTにMQTTでPublish
　node.jsで書いたダッシュボードでログを表示

DevOpsのライフサイクル

　開発、ビルド、テスト、プロダクション環境へのリリース。
　裏でもう1つやらなくてはいけないことがある。サーバの構築。環境ごとの設定。
　　アプリケーションとは別にメンテし続けなくてはいけないのが結構辛い。
　Dockerになると？アプリケーション、サーバ、環境設定が一まとめになっている。
　　Dockerの中のプロビジョニングはShellでもいい。ほとんど一回しか流さない。
　　一回プロビジョニングしたらあとはテスト環境にもプロダクション環境に巻くだけ。
　DevOpsの流れが変わる可能性があるのがDocker。

Amazon ECS

　Containerをただ起動するだけなら超簡単。管理する必要が無い。
　ECSを使えば？
　　ホストとなるEC2の利用を効率的に行える。
　　ホストEC2のインスタンスタイプを分散(EC2 Spot Fleet)
　　Cluster管理、リソースの状況を監視し、適切に配置

Amazon ECS Update

　Amazon EC2 Container Registory
　　もうちょっとでリリースされる、ご期待ください。
　AZを意識したスケジューリング
　　フェールセーフな作りができる
　ECS CLI
　　Docker Composeと連携、yamlで制御
　Docker Containerの設定オプションを改善
　CloudWatchメトリクスの追加

まとめ

　DevOpsの改善が一番大きなメリット
　クラスタ管理をECSにぶん投げると、Dockerのコンテナ管理が非常に簡単
　ECRがリリースされるとレジストリ管理を考えなくて良くなる 　

Next FRESH! Applications with Amazon ECS by 株式会社サイバーエージェント @stormcat24さん

AmebaFRESH!

　生放送動画配信プラットフォーム
　12月に一般公開予定、現在クローズド公開中
　スマホナイズドされたUI、オシャレなニコ生を目指している
　Amazon ECSで全て稼働している
　4月からプロジェクト開始、メンバー約30名
　配信はRTMP Publishing、視聴側はHLS
　サーバサイドは全てAWS。Go1.5 + Docker 1.9.0。
　マイクロサービスアプローチを取っている。APIはRESTful(goji)

アーキテクチャー

　目指していること
　　極力メンテを入れず運用していくことを目標
　　　24時間何かしら配信があるような状況に持っていきたい。
　　　ゼロダウンタイムのためのBlue-Green Devployment。
　　　インフラは更新せず入れ替える。
　　素早く頻繁にどんどんリリースしていきたい
　　　システムは疎結合、マイクロサービス。
　　　何が使いやすいか？出した答えがコンテナ。
　マイクロサービス
　　特定の開発言語に依存しない。使い続けると飽きる。
　　　来年Elixirとかやるかもしれないし、Javaに戻るかもしれないし...
　　　エンジニアのモチベーションを維持する一つの方法がマイクロサービス化かなと思っている。
　　通信プロトコル
　　　RESTFul API。HTTP。
　　　ELBがHTTPSをサポートしていないのでgRPCはまだ対応していない
　　マイクロサービスの粒度
　　　タイムラインとか、システム的なドメインで切っている。
　　　あとから切り直すのも全然ありかなと思っている。
　インフラはECS
　　ちょうど検証中に東京リージョンに来た。
　　コンテナ構成管理とスケジュールがあれば運用できると判断。
　　他にもAWSで使いたいサービスがあった。LambdaとかAuroraとか。
　実際どうやって作っているか。基本方針
　　マイクロサービスごとにTask Definition
　　1ECS Cluseterに1Service
　　1Clusterには1つのAutoScaling Groupが紐付いている
　　　動画配信サーバは特殊なので例外
　Taskの構成方針
　　Dockerを使う上で一番気をつけなきゃいけないのはログ。消失しないように。
　　　td-agentでログを転送。各コンテナのログは、コンテナが所属するホストに吐く。
　　　td-agentがホストのログディレクトリをマウントして、他の場所に転送
　　　Docker 1.8からサポートされたlogging driverを使えばtd-agentがいらなくなる
　　　　が、まだ導入していない
　　Internal Serviceであってもログを出すのが楽なので必ずNginxを通している
　1Cluster=1Serviceのデメリット
　　リソース効率的にはいまいち。1クラスターに複数のサービスを任せるのがベスト
　　リソース効率が悪いので、インスタンス数は増える傾向にある。
　　開発環境ではt2.microのような小さいインスタンスを有効活用。
　　　nanoインスタンスが出てくると有効活用できそう。
　1Cluster=1Serviceにしている理由
　　Dockerビギナーにとって視覚的に分かりやすい
　　サービス単位にIAM Roleで制御したいが、IAM RoleはEC2にしか割り当てられない
　　サービス単位でのSecurity Group→ELBを活用すればクリアできる。

Blue Green Deployment

　2AutoScalingパターン
　　Blue、GreeのClusterを作成。
　　それぞれがAutoScaling Groupに所属。
　　AutoScaling Group単位でELBの切り替えを行う。
　　特徴。とても安全にデプロイできる。ロールバックも楽。
　　　ただしデプロイ前にStandbyのウォームアップが必要。
　　2系統あるのでコストが嵩む。不要になったGroupは落とすなどで対処。

Diet Docker Image

　イメージは小さいほど良い。Build時間もCI時間も下がる。
　Registoryからのダウンロード時間も短くなる。
　AutoScalingで立ち上がるサービスの起動も早くなる。
　dokcer hub
　　たくさん公式イメージがあるが、大きいものがたくさんある。
　　Dockerを運用する上ではボトルネックになりがち。1GB超えるとデブ。
　不要なものは削除
　　対処の積み重ね。不要なファイルの削除、ビルドで生じたゴミを消す。
　　Data Volumeを使ってホストのファイルシステムを利用→ポータビリティが落ちる
　RUNの回数を減らす
　　Dockerは差分ビルドなので、RUNの分だけイメージのレイヤーが増える。
　　なるべく&&でチェインして、RUNの回数を減らすのが良い。
　　長いdocker buildで途中でこけるとRUNの頭から始まる→辛い。
　　RUNを1回でやるのがスタンダードなのかな、と思う。
　軽量イメージを使う
　　オフィシャルでもslimイメージが用意され始めている
　　busybox、とても軽い
　　　ポータビリティは高い
　　　アプリケーションが求める環境を構築する難易度が高くなる
　減量による弊害
　　x509問題、軽量化し過ぎて発生
　　　コンテナからHTTPS通信ができなくなる
　　外部ツールに依存しすぎていると辛い
　ベースイメージの作成
　　aptなどパッケージアップデートは時間がかかる
　　　たまにaptが調子悪くてbuildが失敗したりする
　　アップデート済みのイメージを作成しておく

ローカル開発はどうやっているか

　docker-machineとVirtualBox
　docker-compose
　docker-machine
　　バックエンドにDockerホストを構築する
　　あたかもローカルにDocker環境があるかのように操作ができる
　　Vagrantは捨てた。Dockerに比べると起動も遅い、プロビジョニングも辛い。使い捨てコストが高い。
　　アプリケーション、ミドルウェアを全部ローカルで確認できる
　　nginxへの通信などはVirtualBoxのポートフォワードを使う。
　ローカルをフルでDockerにするとマシンリソースが必要。
　　ローカルPCをメモリ16GBに変更。コンテナをいっぱい立ち上げると辛い。
　　コンテナを立ち上げてもTwitterができるように。
　docker-compose
　　Docker Toolboxの一部。元々figと言われていた。
　　DockerコンテナをYAMLで管理。
　　ローカルのデータストアもDockerでやっている。
　　　MySQLやRedisなどをdocker-composeで立ち上げ。一瞬で手に入る。
　DBのマイグレーション。
　　環境があってもデータ不備があると意味が無い。
　　FRESH!ではgoのgooseを使っている。SQLを時系列で並べて適用。
　　　SQLじゃなくてGoでも書ける。
　ecs-formation
　　docker-composeのように、YAMLでコンテナを管理。
　　当時はecs-cliが無かったので自作。aws-sdk-goを利用。
　　主な機能。Task Definitionsの更新、クラスタに配置するサービスの更新。Blue-Green Deploymentの実現。 　　

その他のツール

　AMI
　　EC2-Otimized AMI。Docker + ECS Agent。便利だけど社内で面倒見切れなかった。
　　自前のUbuntuイメージを作成。
　Private Registory
　CircleCI
　　1リポジトリに1Dockerfile。
　　インフラ系ミドルウェアは別のリポジトリに。
　Terraform
　　インフラ構築のためのオーケストレーションツール
　　AWSでのインフラ構築で利用
　　EC2、SG、Route53(Internal)、ECS Cluster、AutoScaling Groupの起動構成
　　癖のあるツールなので、ELBなど運用によって状態が変わるものには無いていない
　　ビルドに時間がかかるRDSやElastiCacheにも向いてい無い
　　クリティカルなものは避けている(Route53、IAM)
　　tfstateはS3上に保持
　　全てを1つのtfstateで管理しない。環境によって分ける。
　Mackerel
　　監視は基本的にMackerel。綺麗で見やすい、お気に入り。
　　最近Dockerのメトリクスが取れるようになった。

所感

　ECSの進化が早く、ついていくのは大変だが、周辺ツールが充実してきた
　全然運用できるな、という感想
　やりたいと思う人はぜひやってみてほしい

最後に

サイバーエージェントさんの事例は非常に興味深かったです。Imageのダイエット方法など、とても参考になりました。

さて、これからLTタイムですが、僕はビールを飲みながらピザを食べるので特にメモは取りません！楽しみます！