[Google Cloud Platform] GKE と ECS を色んな角度から比較してみた |

Blog

2016.11.21

[Google Cloud Platform] GKE と ECS を色んな角度から比較してみた

こんにちは。アドテクスタジオでネットワークエンジニアをしている山本孔明です。

コンテナ流行ってますね。そんなコンテナを使いたいとなった時にクラウドで利用することを考える方も多いと思います。今日は、AWS と GCP の2つのパブリッククラウドサービスで提供されているコンテナのマネージドサービスである「Amazon EC2 Container Service (ECS)」と「Google Container Engine (GKE)」の比較をしてみました。

はじめに Google Trend の結果を見てみます。ECS で検索すると他のワードが入ってきたりとノイズもありますので、それぞれ正式名称で比較しています。

やはりどちらもコンテナのマネージドサービスとして同程度の関心をもたれていることがわかります。

1. サービス概要について

簡単に両者のサービスを説明します。

1-1. GKE

Google が開発した Kubernetes を用いたマネージドサービス
gcloud / docker コマンド / kubectl で操作することが可能
GCE のインスタンスを用いて、クラスタを構築
Docker コンテナフォーマットをサポート

1-2. ECS

Amazon が構築した独自クラウドのマネージドサービス
AWS CLI /docker コマンドを用いて操作することが可能
EC2 のインスタンスを用いて、クラスタを構築
Docker コンテナフォーマットをサポート

2. 制約について

スケールの部分について記載します。最新の情報はドキュメントを確認してください。

2-1. GKE

Maximum of 50 clusters per region.
Maximum of 2000 nodes per cluster.

https://cloud.google.com/container-engine/pricing

2-2. ECS

Maximum of 1000 clusters per region, account
Maximum of 1000 nodes per cluster

http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/service_limits.html

3. 使い方

ここでは比較をするための大まかな手順のみ記載します。詳細な操作方法については最新のマニュアルを参照するようにしてください。

また、コンテナイメージはあらかじめ用意されているものとします。 kubectl に慣れている人には GKE はとても理解しやすいものとなると思います。

3-1. GKE

手順

gcloud でコンテナがデプロイされるクラスタを作成する
kubectl で Repliation Controllerを起動する
kubectl で service を起動する

説明

kubenetes を理解する上で、まず Pod の説明をします。Pod は複数のコンテナの集合体です。Pod 単位で Start / Stop の操作をしたり、同一ホストにデプロイされネットワークを共有したりします。

一方で、Replication Controller は Pod の状態を監視し適切な状態を維持するようになります。Pod を作成するだけでは、何らかの障害などで Pod が Stop した際はそのままの状態となります。

Replication Controller を利用することで Pod は設定ファイル内の replicas の値を維持します。

以下に Pod の設定ファイル例を記載します。

apiVersion: v1
kind: Pod
metadata:
 name: ""
 labels:
 name: ""
 namespace: ""
 annotations: []
 generateName: ""
spec:
 containers:
 - name: nginx
 image: nginx
 ports:
 - containerPort: 8001
 resources:
 cpu: ""
 memory: ""

apiVersion: v1

kind: Pod

metadata:

labels:

namespace: ""

annotations: []

generateName: ""

spec:

containers:

- name: nginx

image: nginx

ports:

- containerPort: 8001

resources:

cpu: ""

memory: ""

http://kubernetes.io/docs/user-guide/pods/multi-container/

以下は ReplicationController の設定ファイル例です。Pod と同様の containers という記載と特徴的なのは replicas という記載が確認できるかと思います。

apiVersion: v1
kind: ReplicationController
metadata:
  name: nginx
spec:
  replicas: 3
  selector:
    app: nginx
  template:
    metadata:
      name: nginx
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 8001

apiVersion: v1

kind: ReplicationController

metadata:

spec:

replicas: 3

selector:

app: nginx

template:

metadata:

labels:

app: nginx

spec:

containers:

- name: nginx

image: nginx

ports:

- containerPort: 8001

http://kubernetes.io/docs/user-guide/replication-controller/

次に Service の定義です。Service は外部に公開するためのパラメータを定義します。

kind: Service
apiVersion: v1
metadata: 
 name: nginx
spec: 
 ports: 
 - protocol: TCP
 port: 80
 targetPort: 8001

kind: Service

apiVersion: v1

metadata:

spec:

ports:

- protocol: TCP

port: 80

targetPort: 8001

http://kubernetes.io/docs/user-guide/services/

また、SSL の終端など GLB が必要な場合は以下の type について一読しておくと良いかと思います。

http://kubernetes.io/docs/user-guide/services/#type-nodeport

http://kubernetes.io/docs/user-guide/services/#type-loadbalancer

3-2. ECS

ECS は GKEのように独自実装ではありませんが、概念としては GKE と似ていますので先ほどの説明をベースに説明します。
まずは手順概要です。

手順

ECSクラスタ用の IAM ロールを準備する
ECSクラスタを作成する
ECS用の AMI からインスタンスを起動する。この際に起動スクリプトにクラスタ情報を格納するファイルを作成するようにする
タスク定義を作成する
サービスを作成する

説明

ECSのタスク定義とは、GKE でいう Pod の概念にあたる部分です。

コンテナ上で実行するDockerイメージの定義
予約するメモリやCPU数などのリソースの定義

基本的には Pod を作成するように上記などの必須項目を設定していきます。GUI ないしは Json 形式のファイルを用いて AWS CLI から設定します。
一つ気をつけることとしては、 ECS には logConfiguration という概念があります。こちらは 6章にて後述します。

http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/create-task-definition.html

http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/task_definition_parameters.html

ECS のサービスですが、本質的には GKE と同様の概念ですが、若干違う点がありますので説明します。GKE と同様、クラスタに上記のタスクを単体で起動することも可能ですが、その維持という目的でサービスを作ります。以下が設定のサンプルですが、desiredCount という部分がタスクの数です。

GKE と若干違うと記載しました、ECS ではサービスの設定内にタスクに相当する設定を直接記載するのではなくタスク定義をリンクさせます。そのため、タスク定義自体は必要です。この概念を忘れると、あれ？サービスってなんだっけ？タスクってなんだっけ？と GUI で画面を右往左往することとなります・・・。概念理解していないと ECS の GUI はかなり混乱します。もう 1 点、Elastic Load Balancing との紐付けはここで実施します。GKE と違い Type の概念がなくタスクに portmapping を設定していれば、クラスタインスタンスの IPアドレスにマッピングされアクセスが可能です。さらに ELB をサービスに設定すれば ELB 経由でのアクセスが可能（要事前作成）です。つまり、GKE でいうType LoadBalancer に相当する部分がありません。

{
    "cluster": "",
    "serviceName": "",
    "taskDefinition": "",
    "loadBalancers": [
        {
            "targetGroupArn": "",
            "loadBalancerName": "",
            "containerName": "",
            "containerPort": 0
        }
    ],
    "desiredCount": 0,
    "clientToken": "",
    "role": "",
    "deploymentConfiguration": {
        "maximumPercent": 0,
        "minimumHealthyPercent": 0
    }
}

{

"cluster": "",

"serviceName": "",

"taskDefinition": "",

"loadBalancers": [

{

"targetGroupArn": "",

"loadBalancerName": "",

"containerName": "",

"containerPort": 0

}

"desiredCount": 0,

"clientToken": "",

"role": "",

"deploymentConfiguration": {

"maximumPercent": 0,

"minimumHealthyPercent": 0

}

http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/service_definition_paramters.html

大まかに説明しましたが、どちらも概念は似ています。個々で少しつづ違う部分を理解しておけば良いと思います。

4. コスト

コストに関しては、CPUやネットワークパフォーマンス、ディスクの性能差であったり割引に関する条件の違いもありますので、一概に性能を揃えることができないため、あくまでも指標ですが、条件をつけて比較してみました。合わせて注意点ですが、価格は今後の価格改定や条件により異なりますので、必ずご自身で調査するようお願い致します。

	インタンス料金（per hour）	Container Engine料金（per hour）
GKE	$0.077 (n1-standard-2 )	$0.15 (6台目以降)
ECS	$0.174 (m4.large)	不要

※ GKE 、ECS 共に追加の SSD はなしとしています。

※ GKE 側は稼働時間による割引が適用されています。

※ GKE の Container Engine 料金は6台から上限の2000台まで同一の金額です。

冒頭にも記載しましたが、このデータはリザーブドインスタンスなどコストを下げる施策はお互いにあります。こちらは1時間あたりのコストで比較したものです。

5. レジストリ

両者ともにプライベートのレジストリサービスを用意しています。この点で大きな差はないと思います。

	利用料金 (per GB per Month)	速度測定（128MBのimage）
GKE（Google Container Registry）	$0.026	31.248s
ECS（Amazon EC2 Container Registry）	$0.10	23.585s

※ GKE ECSともに、データ転送に関わる費用が別途発生します。

※ GCP に関しては、asia-east1-a を使用しております。AWS は ap-northeast-1 を利用しています。

6. その他

6-1. ロギング

ロギングの仕方は fluentd を利用するなど何パターンかありますが、ここでは各クラウド上のサービスでできることに着目し比較します。

6-1-1. GKE

・標準で Stackdriver logging に出力されます。

個人的には Stackdriver logging の advanced logs filter がかなり使いやすいロギングの観点では Stackdriver logging を利用できるのは大きなメリットであると感じています。

6-1-2. ECS

・Cloud watch logs

・Fluentd

などが利用可能です。これは Task に設定が必要で、Cloud watch logs にロググループをあらかじめ作成しておきそこに投げることが可能です。

グループの配下にタスク名で <Task definition name>/<Task ID> 配下に格納されます。

ECS から fluentd を使用して GCP 側へ飛ばすことも可能ですが、組み込みが必要ないという点では GKE は使い勝手が良いと思います。

6-2. アクセス制御とクレデンシャル

6-2-1. GKE

GKE ではアクセス制御としてインタンスに設定された Cloud API アクセス範囲により制御が行われます。
BigQuery や Cloud SQL などリソース単位で読み取り/書き込みなどの制御が可能です。

GKE では、Pod の設定内で env パラメータを用いて環境変数を設定することが可能です。ID やパスワード情報はこちらに記載することとなるかと思います。

http://kubernetes.io/docs/user-guide/configuring-containers/#environment-variables-and-variable-expansion

6-2-2. ECS

ECS ではタスクに IAM のロールを設定することが可能です。そのため、コンテナ単位で細かい制御が可能です。

タスクには environment という項目があり、任意の name に対する value を記載することができますので、ID やパスワード情報はこちらに記載することとなるかと思います。Task 定義ではクレデンシャル系の情報は見せないようにしつつ、アクセスを制限した S3 や何らか別の場所から持ってくるなども検討の余地があるかと思います。

ECS では IAMロールをコンテナに付与して細かいリソース制御が可能な点が大きく、S3 へのbacket 単位での制御など利用者が考える細かな制御ができるのが大きなメリットです。

あか・

クレデンシャル

ロギングき

6-3. Auto Scale

ここでは二つの観点で比較をします。クラスタインスタンス自体のスケールとコンテナのスケールです。

6-3-1. GKE

クラスタインスタンスの Auto Scale は非常に簡単に実現可能です。インスタンスグループで自動スケーリングを有効にして各種設定をするだけなので割と簡単に実現可能です。

Pod の Auto Scale は Horizontal pod autoscaling という概念がありますので Pod の replica を動的に設定することが可能です。

http://kubernetes.io/docs/user-guide/horizontal-pod-autoscaling/

6-3-2. ECS

こちらもクラスタインスタンス、タスクの両方で Auto Scale が可能です。

いずれも、Cloud Watch のメトリックと連動してスケールさせることが可能です。

まとめ

環境・条件に寄るため一概には言えないのですが、コスト面やロギングで「GKE」アクセス制御で「ECS」に魅力を感じる結果となりました。

扱いたいデータが S3 に格納されている、kubernetes に慣れているなど、様々な状況下での判断となりますが、参考にして頂ければと思います。

ECS + Fluentd + Stackdriver など組み合わせでカバーできるところもあります。特に運用面においてこれから知見が溜まってくると思いますので、

また GKE、ECS、特にコンテナの運用まわりについて書く機会を設けたいと思います。

Author

komei