この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
みなさんコンテナを使うことの意味を自信もって答えられるでしょうか？
ここ1年ほどコンテナ関連の仕事をメインでやっているハマコーですが、いろんなお客様からこういったお声をいただくことが多くありました。
- 「それはコンテナ化する意味があるの？」
- 「こんなコンテナ運用は危ない？」
- 「ECSの設定とか実際めんどい。docker runじゃだめ？」
- 「EKSって使えんの？」
そういう声を聴く中で、自分なりの答えを模索していたわけですが、岡山での弊社イベントAWS最新技術の祭典Developers.IO 2019 at 岡山城へ登壇するにあたり、そのあたりのもやもやを自分なりに昇華したのが、本日の内容です。
- 「このアプリをコンテナ化する意味があるのか、わからない」
- 「コンテナ化することで余計めんどくさくなった」
- 「AWSのコンテナサービスの何を使ったら良いのかわからない」
という悩みを抱えている方には、是非一度こちらの内容を見て、ヒントを掴んでいただければと想います。
（祭） ∧ ∧ Y ( ﾟДﾟ) Φ[_ｿ__ｙ_l〉 ｺﾝﾃﾅ ﾀﾉｼｸ ﾔﾘﾏｯｼｮｲ |_|＿| し'´Ｊ
発表資料
こちらから参照できます。
迷える子羊に捧げるコンテナ環境徹底比較 〜ECS、Fargate、EKSは何が得意で不得意か〜 - Speaker Deck
導入「迷いないコンテナ運用を目指して」
みなさん、コンテナ使っていますか？本日お話することは、一言、こちら。
45分という短い時間なので、コンテナやAWS関連サービスの細かい技術要素の話はしません。どちらかというと、これからコンテナを導入してみようという人であったり、コンテナの運用に苦労している方に向けたセッションとなります。
それでは、「迷いないコンテナ運用を目指して」をテーマに始めていきます。
本日の話の流れは以下の通りです。
「コンテナとは何かを理解する」
最初に、コンテナそのものについて振り返りましょう。コンテナ型仮想化技術を図示したものがこちら。
一般的には仮想化ソフトウェアを使わずにOSのリソースを隔離するので、起動のオーバーヘッドが少ないのが従来の仮想化技術との差別化要素です。
Dockerを使うには、何がなくともDockerのインストールが必要です。こちら（Docker Desktop for Mac and Windows | Docker）からインストールしてみましょう。
一番最初に試してみて頂きたいのがこちら。Pandocというプロダクトを使ってmarkdownファイルをWord（docx）に変換します。1行です。Dockerインストールするだけでこれが動きます。
sample.mdからsample.docxを作るコマンドがこちら。
$docker run -v `pwd`:/source jagregory/pandoc -f markdown -t docx sample.md -o sample.docxPandocのインストールも何もしていないのに、いきなり文書変換できる理由がこちら。
ここで、Dockerの使い方として覚えていただきたいことは、DockerはCLIっぽく使えるということです。なので、従来の仮想化技術とは利用用途がかなりことなります。
自分好みのイメージを作るには、Dockerfileを作る必要があります。
Dockerfileの凄いところは「インフラのプロビジョニングからアプリケーションのインストールまで、一つのテキストファイルで記述できる」点です。
従来のEC2インスタンスをたてて、動かした場合との比較した表がこちら。
インフラをコードで管理するのが最近のトレンドですが、コンテナの場合は、全てDockerfileで完結します。
Dockerfileを書いたり、container buildを極めたい方は、ぜひこちらの資料を御覧ください。
- Best practices for writing Dockerfiles | Docker Documentation
- 【docker buildのマニアックすぎる狂宴】Container Build Meetup #1に参加してきた #container_build ｜ DevelopersIO
「コンテナを使う意味を考える」
そこにアプリケーションがあり、コンテナ化を迷った時の判断基準として必ず抑えておくべきなのは以下の3つです。
私の個人的な感触ですが、このうち2つ以上YESなら、コンテナ化を検討してみましょう。
対して、コンテナ運用するには非常に微妙な例として、GitLabについて紹介します。
GitLab CE、インストール方法は複数あるんですが、長きに渡って運用する場合、やらないほうが良いインストール方法があります。それがこちら。
Docker Imageを利用したインストールって確かに簡単なんですね。ただ、それをきちんと長きに渡って運用していくとき、常にコンテナの中に状態をもつアプリケーションの運用は、はっきり言ってDockerには向いていません。普通にEC2で運用したほうが、絶対安定します。
先程の判断基準は、具体的なユースケースに基づいています。これらが必要な場合は、コンテナ化することのメリットは非常に大きくなります。
- 複数の環境でつかうか？
- 開発〜検証〜本番で同じイメージを使う
- 頻繁に変更するか？
- どんどん機能追加をしていきたい
- 増えたり減ったりするか？
- 負荷に応じて弾力的に数を変えたい
アプリケーションをコンテナ化するときの指針はあります。まずは一番定番で王道なのがこちら。
もうすこし、Docker向けに焦点を絞っているのがこちら。
これらの情報は是非一通り目を通しておいてほしいのですが、重要なポイントを抜粋するとこうなります。もし、アプリケーションがこれを満たしていないのであれば、Dockerfileを作り始める前にこの対応をしましょう。
「AWSにおけるコンテナについて理解する」
AWSにおけるコンテナサービスを区別すると、まずはこうなります。
ECR（Amazon Elastic Container Registry）とは
その他のサービスについて説明していきますが、まず最初にお知らせしておきたいのはこちら。
ので、AWSのコンテナサービス郡を最初に理解するためには、コントロールプレーンとデータプレーンについて理解する必要があります。
コントロールプレーンとデータプレーン
コントロールプレーンとは、コンテナの管理をする場所
- 動く場所の管理
- VPC、Subnet、Load Balancer、Security Group
- コンテナ生死の管理
- 監視設定、自動復旧
- コンテナ数の管理
- 負荷に応じたコンテナ数のオートスケール
データプレーンとは、実際にコンテナが稼働する場所
- コントロールプレーンからの指示にしたがって起動
- コンピューティングリソースを消費（従量課金対象）
- 状態をコントロールプレーンに通知
これらの関係性を図示するとこうなります。
今のサービス名とラベリングするとしたらこうなりますね。今回のセッションでも、この前提でお話していきます。
ECS（Amazon Elastic Container Service）とは
AWS完全マネージドのコンテナオーケストレーションツールです。
- 簡単なオートスケール設定
- ロードバランサー統合
- コンテナのIAM権限管理
- コンテナのセキュリティグループ管理
- CloudWatch メトリクス統合
- CloudWatch Logs統合
- スケジュール実行機能
最大の特徴は、元がAWSフルマネージドなサービスのため、他のAWSサービスとの連携が簡単という点です。
ただ、ECSの内部構造は決して簡単ではないです。ので、ここでは図示して一つずつ説明していきます。
まず、タスク定義とコンテナ定義の構造がこちら。
コンテナ定義には、各コンテナ単位での設定情報（ほぼ、Docker run時に設定できる内容）が含まれており、それらを統合してタスクとしてハードウェアリソースを割り当てます。
1タスクに複数コンテナを割り当てる代表的な例をあげます。
さらに、クラスターとサービスの関係性がこちら。クラスターが全体的なサービスを論理的に統合し、サービスには、タスク定義から具体的にサービス提供するためのインフラ周辺の情報を登録することになります。
実際にこれを、先程のタスク定義例で動かしたときの動作イメージがこちら。
EKS（Amazon Elastic Container Service for Kubernetes）とは
AWSマネージドなKubernetesサービス
- 正式名称はAmazon Elastic Container Service for Kubernetes
- Kubernetes正式準拠
- Kubernetesコミュニティが作成した既存のプラグインやツールを利用できる
最大の特徴は、元がオープンソースプロダクトなため、Kubernetes用に開発されたツールを 広く使うことができるという点です。
具体的には、Kubernetesのコントロールプレーン、ここをマネージドとして提供しているのがEKSです。
こちらのデータプレーンは、EC2で提供され、実際の構築はCloudFormationなどを利用することになります。
ここで、EKSの各特徴をECSに比べた観点で並べてみた表がこちら。
| ECS | EKS | |
|---|---|---|
| コンテナのIAM制御 | タスクへのIAMロール付与 | 公式未提供（OSSのkube2iam, kiam） |
| スケジュール実行 | スケジュールタスク | なし（Scheduler） |
| セキュリティグループ | サービスへの付与 | EC2で自前管理 |
| 監視 | CloudWatch統合 | なし（Datadog、Prometheus） |
| ログ | CloudWatch Logs統合 | Fluentd |
| デプロイ | CodePipeline統合 | 自前構築（helm, kustomize, spinnaker） |
コンテナのコントロールプレーンとしては、ECSよりもKubernetesのほうがはるかに自由度が高く高性能といえますが、マネージド未提供なものが多いです。
EKSを採用するときは、この点を真っ先に知っておく必要があります。
Fargateとは
サーバーやクラスターを一切管理することなくコンテナを実行できます。
- 仮想マシンのクラスターのプロビジョニングが不要
- ECSおよびEKSに対応したコンピューティングエンジン
- コンピューティングリソースに対しての料金としてはEC2より割高（1割〜2割）
EC2オンデマンドに比べて、ランニング費用は割高ですが、以下のメリットを享受できます。
- ホストインスタンスの管理が省けること
- EC2の余剰リソースが不要
- セキュリティはAWS側で常にカバー
- オートスケールの設定も不要
この概念を、ごっつわかりやすい図で表したのがこちら。
（引用元：https://www.slideshare.net/AmazonWebServices/operational-excellence-with-containerized-workloads-using-aws-fargate-con320r1-aws-reinvent-2018/40）
管理コストを氷山で表しています。水面から出ていて目に見える部分のコスト（ランニング費用）は、Fargateのほうが大きいですが、目に見えない運用上のコスト（スケーリング設定、セキュリティ管理、インスタンス管理）は、EC2のほうが圧倒的にでかい、ということです。
また、気になるランニング費用も先日のアップデートで、大幅に下がりました。是非利用を検討してみてください。
後悔しない選択をする
最後、これらのAWSサービスから最適なコンテナサービスを選択する方法をお伝えします。
単純です。まずは、これを使ってください。
Fargateは、EC2を隠蔽することでコンテナの管理〜運用に特化することができる素晴らしいサービスです。最初に検討すべきなのは、Fargateであると断言します。
ただ、ECS on EC2と比べてFargateではできないこともあるので、注意が必要です。
- ホストインスタンスにSSHログインできない
- ホストインスタンスにSSHログインしてコンテナの状況を確認するコマンドが利用できない（docker ps、docker images、docker logs、docker execなど）
- ログドライバがawslogsのみ
- 標準ではCloudWatch Logsのみに出力される
- （Fluentdは将来対応予定）
- EFSが利用できない
- 複数タスクで同一のローカルリソースを共有することが現状無理
- S3などを利用できないか検討する
- スポットインスタンスが使えない
- EC2でオートスケール部分をスポットインスタンスを使うことでコスト削減するなどの方法が使えない
- ホストインスタンスに導入する前提のセキュリティソフトが利用できない
- コンテナ単体でセキュリティをチェックする仕組みが必要
- GPUインスタンスなど、リソース最適化されたEC2インスタンスが利用できない
- Windowsコンテナが利用できない
では、EKSを使うパターンとしては何があるでしょう？
代表的なパターンとしては、もともとk8sを自前（オンプレ、EC2）で運用していた場合。この場合は、もともとあるk8sのノウハウを活かしながら、コントロールプレーンの管理をマネージドに任せることでTCOを削減できます。
もうひとつ、EKSの導入に重要なポイントは？
これ、案外真面目に言ってます。
Kubernetesを学ぶということは、モダンな分散アプリケーションのプラットフォームを管理する方法を学ぶということです。
本来的にはアプリケーションの特性に応じて最適なプラットフォームを選択するのが筋ですが、オープンなプラットフォームであり、関連するサードパーティーやOSSが非常に充実して、今一番勢いがあるのは間違いなくKubernetesです。
そういった技術にど真ん中から飛び込みながら、貪欲に新しいものにチャレンジしていく組織であれば、EKSも非常に良い選択肢となりうるでしょう。
迷いないコンテナ運用を目指して
迷いないコンテナ運用を目指してということで、45分お話させていただきました。
- そもそも検討しているアプリケーションがコンテナに向いているかきちんと検討する
- そのアプリケーションのワークロードに当てはまるAWSのコンテナサービスを選定する
- 途中で状況が変わったら躊躇なく再検討しよう
様々な場面で運用しているアプリケーションをコンテナ化したほうが良いかどうか、AWSで何を使うか、検討はされると思いますが、今日の話が皆様のよりよいコンテナ運用の一助となれば、これほど嬉しいことはありません。
それでは、今日はこのへんで。濱田（@hamako9999）でした。
発表スライドはこちら。
夜の岡山城…
岡山ええところでした… また来ますー。
3
