1. システムとオフィスの融合|株式会社QES
  2. media
  3. AWS マイクロサービス Azure Docker Googleソリューション
  4. 3大クラウドサービス(Azure/AWS/GCP)のコンテナサービスをさわって比較してみた

QESブログ

3大クラウドサービス(Azure/AWS/GCP)のコンテナサービスをさわって比較してみた

GCP
  • LINEで送る
  • このエントリーをはてなブックマークに追加
3大クラウドサービス(Azure/AWS/GCP)のコンテナサービスをさわって比較してみた


はじめまして!システムソリューション営業本部の川原広之と申します。
春風の心地よい季節になりましたが、皆さま、いかがお過ごしでしょうか。

4月から新生活の方が多いと思いますが、私も今年の1月から新たなスタートいうことで
QESに中途入社し、新しい技術に触れながら楽しく仕事をさせていただいております。
「新しい技術」という抽象的な言葉で皆さんはどのような技術を思い浮かべられたでしょうか。

様々な技術が候補に挙がると思いますが、今回はその中でも業界で話題の(個人の主観です!) 「マイクロサービス」アーキテクチャで必ずと言っていいほど選択肢に上がってくる「コンテナ」サービスを、Azure/AWS/GCPの3大クラウドサービスそれぞれで実際に使ってみて、いくつかの観点で比較を行ってみたいと思います。 

マイクロサービスについては弊社HPの中でも紹介しておりますので、是非ご覧ください!

1. コンテナとは

コンテナは、互いに影響されない隔離された実行環境を提供する技術です。
ホストOSのリソースを論理的に分離し、複数のコンテナで共有して使うことができます。
ホストOSの上で別のゲストOSを動かすサーバ仮想化技術に比べてオーバーヘッドが少ないため、軽量で高速に動作します。

container_vm.png

アプリケーションの実行に必要なモジュールをコンテナとしてまとめられるため、複数のコンテナを組み合わせて1つのアプリケーションを構成するマイクロサービス型のアプリケーションと親和性が高いのが特徴です。
また、コンテナ型の仮想化技術によって、1台のコンピューター上で複数のサーバーを動かすためのソフトウェアの「Docker」もコンテナと同じく良く聞くワードかと思います。

弊社ではDockerに関連した技術ブログも複数掲載しておりますので、あわせてご確認いただければと思います。

本ブログではブラウザにメッセージ(例:It works!)を表示するだけのWebアプリケーション実行環境を搭載したコンテナを対象として、3大クラウドそれぞれでコンテナを実行しての使用感や費用感を比較してみたいと思います。

2. Azureでコンテナを作成、実行してみる

Azureでは、Azure Container Instancesサービスを利用します。
それでは、今回は以下の公式クイックスタートを参考に、Azure Container Instances を利用したいと思います!
クイック スタート:Azure portal を使用してコンテナー インスタンスを Azure 内にデプロイする

クイックスタートに沿って進めていきますが、AWSやGCPでも出来るだけ同じコンテナ構成で比較したいと思いますので、「クイックスタートイメージ」ではなく、Docker Hubからhttpdのコンテナイメージを取得するように設定します。
(Docker Hubはざっくりの説明ですと、「コンテナイメージの共有場所」です。詳細については公式ドキュメントをご参照ください。)

mcs_a132_01.png

DNS名ラベルはクイックスタートで記載されている名前をリージョン内で一意となるように変更して、作成を行います。

作成後、DNS名でブラウザからアクセスすると、コンテナ内のWebサーバが起動していて、初期作成されているhtmlで定義されているメッセージ「it works!」が表示されることを確認できます。


mcs_a132_02.png

Azureでは管理ポータルからコンテナインスタンスに接続できるので、試しにIt worksの文字列をプログラムのことはじめでお馴染みのHello Worldに変更してみます。
接続は「コンテナーの設定」の[コンテナー]を選択して表示される画面下部の「接続」タブを選択します。
シェルの選択を求められますが、初期値の/bin/bashのままconnectボタンを押下します。
接続が成功すると、CUIをポータル上で操作することができます。

mcs_a132_03.png

Docker Hubのhttpdコンテナイメージには、Linuxでファイル編集に使うコマンドViがインストールされていなかった為、今回はsedコマンドでファイル内の文字列を置換で変更してみます。

sed -i -e 's/It works/Hello World/g' htdocs/index.html

mcs_a132_04.png

(CUIの改行がされていないところはいけてないですね)

変更後に再度アクセスしてみると、It works!からHello World!に変わったことが確認できます。クイックスタート開始から10分もたたない内にコンテナを利用してWebアプリケーションを起動、文字列の変更まで確認することができました。簡単ですね!!

mcs_a132_05.png

コンテナを実行するまでの設定が少なく、コンテナに接続できるところまで管理ポータルでの操作だけで完結できる点から、とにかくまずはコンテナに触れてみたい方には、お勧めしたい選択肢だと思いました。

検証が終わったら、「コンテナーインスタンス」を削除して費用が発生しないようにしておきます。

3. AWSでコンテナを作成、実行してみる

AWSでは、AWS Fargateサービスを利用します。
それでは、今回は以下の公式チュートリアルを参考に、AWS Fargate を利用したいと思います!
(※チュートリアル閲覧にはAWSアカウントが必要です。)
Fargate を使用して Amazon Elastic Container Service (Amazon ECS) の使用を開始

他のクラウドサービスと構成を合わせる為、今回はコンテナの定義はcustomを選択します。

mcs_a132_06.png

イメージはAzureの検証時と同様にDoker Hubのhttpdイメージを設定します。
メモリもAzureの検証時とあわせて1.5Gibに設定します。
CPUもAzureの検証時とあわせて1vCPUに設定します。

設定後、customの表記が設定したコンテナ名に変わっていることが確認できます。

mcs_a132_07.png

コンテナ定義時にポートマッピングは空欄で設定した為、ロードバランサーの設定は無効になっています。今回はロードバランサー無しで作成します。セキュリティグループは自動で作成してくれます。

mcs_a132_08.png

クラスターの設定ではクラスター名の指定だけです。VPCやサブネットも自動で作成してくれます。

mcs_a132_09.png

設定が完了したら、後はリソースが作成されるのを待ちます。自動で作成してもらうリソースの名前は後々自分が作成したものと分かるように控えておくと良いと思います。

mcs_a132_10.png

全てのリソース作成完了後、作成されたクラスターから、タスク>ネットワーク>パブリックIPとたどって表示されているIPアドレスでブラウザからアクセスすると、コンテナ内のWebサーバが起動していて、初期作成されているhtmlで定義されているメッセージ「it works!」が表示されることを確認できます。

mcs_a132_11.png

AWSでは管理ポータルからコンテナインスタンスへの接続はできないようです。(※1)

※1:本ブログ執筆時(3/上旬)はECS/Fargate上のコンテナインスタンスに接続する公式の手順は無かったのですが、AWS CLI経由で接続できる機能「ECS Exec」がリリースされたようです。
Amazon ECS で、Amazon EC2 または AWS Fargate で実行されているコンテナでのコマンドの実行が可能に
今後、管理ポータルからも接続できるようになっていくようです。

AWSは設定項目が多く、自動で作成できるとはいえ、VPCやサブネット、セキュリティグループ等、コンテナ以外で事前に理解しておいた方が良い知識もあり、Azureほど手順が簡単とは感じませんでしたが、逆に初期設定時に細かく設定を制御できることが特徴とも思いました。

最後に、今回の手順で複数のサービス(VPC、サブネット、セキュリティグループなど)が自動で作成されているので、検証が終わったらクラスターの削除から、全て削除しておきます。

4. GCPでコンテナを作成、実行してみる

GCPでは、Cloud Runサービスを利用します。
それでは、今回は以下の公式クイックスタートを参考に、Cloud Run を利用したいと思います!
クイックスタート: 事前にビルドされたサンプル コンテナをデプロイする

まずは、クイックスタートに沿って、プロジェクトを新規作成して、今回の検証で使用するサービスを管理します。作成したプロジェクト内でCloud Runサービスを作成します。

次はコンテナイメージの設定なのですが、ここまできて気づきました。Docker Hubから直接コンテナイメージを取得することはできないようです。エラーメッセージにありますように、URLがgcr.ioまたはpkg.devで始めるものでないと駄目なようです。ローカルでビルドしたコンテナイメージをGCP内のContainer Registryサービス(or Artifact Registryサービス)にアップ(push)して使うことを前提としているのかと思います。

mcs_a132_12.png

今回はDocker Hubのhttpdコンテナイメージを使う事をあきらめて、用意されているデモコンテナを利用することにします。

mcs_a132_13.png mcs_a132_14.png

詳細設定でコンテナポートやCPU、メモリの値を設定することができます。
ブラウザからアクセスできるように、「未承認の呼び出しを許可」も選択しておきます。
設定が完了しましたら、イメージがCloud Runにデプロイされて管理画面が表示できます。

mcs_a132_15.png

管理画面右上に表示されているURLでブラウザからアクセスすると、コンテナ内のWebサーバが起動していて、初期作成されているhtmlで定義されているメッセージ「It's running!」が表示されることを確認できます。

mcs_a132_16.png

Docker Hubに接続できないことにより、私にとって想定外の手順となりましたが、それ以外はCPUやメモリ等コンテナのスペック変更ぐらいでAzureの検証時に近い、実行できるまでの設定の簡単さを感じました。
管理画面右上の「継続的デプロイの設定」を選択することで、Cloud Buildによる継続的デプロイの設定を表示させることもできて、次の展開へスムーズに移行できる操作性の良さも感じました。

Cloud RunもAWS同様に管理ポータルからコンテナインスタンスに接続はできないようです。ただ、ローカルで作成したコンテナイメージをGCPのコンテナレジストリにアップして、Cloud Runへのデプロイの運用となる想定の為、その点は問題ないかと思いました。

検証が終わったら、プロジェクトを削除して費用が発生しないようにしておきます。

5. 比較

それでは、コンテナサービスをベースに3大クラウドを比較してみます。

CPU、メモリ別の料金、割り当てられる値の最小値・最大値を比較

2021年3月時点での公式サイト掲載の情報をもとに比較しています。
対象リージョンは東京リージョン、料金は米国ドル($)で合わせています。

   Azure   AWS   GCP 
 サービス名   Azure Container Instances   AWS Fargate   Cloud Run 
 CPU料金(vCPU/h)   $0.05060   $0.05056   $0.08640 ※2 
 メモリ料金(GB/h)   $0.00553   $0.00553   $0.00900 ※2 
 最低CPU   1vCPU   0.25vCPU   1vCPU 
 最低メモリ   1GB   0.5GB   128MB 
 最大CPU   2vCPU(Linuxコンテナ) 
 4vCPU(Windows Server 2016)※1  
 4vCPU   4vCPU 
 最大メモリ   8GB(Linuxコンテナ) 
 16GB(Windows Server 2016)※1  
 30GB   8GB 

※1:リージョンによって最大値が異なるので、詳細は以下の公式ドキュメントを参照ください。
Azure リージョンの Azure Container Instances のリソースの可用性
全リージョンの中で最大はLinux,Windowsコンテナ共に、CPU:4vCPU、メモリ:16GBとなっています。

※2:Always Free 枠として、CPU料金は、180,000 vCPU 秒(1か月あたり)、メモリ料金は、360,000 GiB 秒(1か月あたり)が割り当てられており、1か月30日フル稼働として無料枠を考慮した場合、CPU料金は、$0.08040/h、メモリ料金は、$0.00775/h程度までは下がる見込みです。

2CPU、1GBメモリで1日フル稼働させた場合の費用面でみると、Azure、AWSは同等、GCPは少し高め(約1.7倍)のようです。
(無料枠やリクエスト数は対象外で算出)

Azure:CPU料金($0.05060×24×2) + メモリ料金($0.00553×24) = $2.56152
AWS :CPU料金($0.05056×24×2) + メモリ料金($0.00553×24) = $2.55960
GCP  :CPU料金($0.08640×24×2) + メモリ料金($0.00900×24) = $4.36320

CPU、メモリの設定できる値枠でみると、AWSの最大メモリが30GBと他のクラウドサービスに比べて大きい値であることが分かります。負荷の高い処理を行う場合には魅力的な違いかと思います。また最小値からみてもAWSは0.5vCPU、0.5GBから始められるため、費用を抑えての検証時でもメリットがあると思います。

AzureはLinux OS以外にもWindows OSを選択できる点が特徴です。

GCPはメモリの最小値が128MBと他のクラウドサービスに比べて非常に小さい値を選択できますが、費用面でもCPU料金の割合の方がメモリ料金に比べて1桁大きいことより、費用面の貢献にはならずに、さほどメリットにはならないと思いました。

使用感

今回、実際に簡単なコンテナを作成、実行してみての使用感で比較してみます。 完全な個人的所感です!
(◎:とても良い、〇:良い、△:少しもの足りない)

   Azure   AWS   GCP   概要 
 容易性   ◎   △   〇   コンテナ作成/実行に至るまでの手順の簡単さ、事前知識必要数の観点 
 操作性   〇   〇   ◎   管理ポータルの操作しやすさ、次のアクションに移りやすいか、ログや設定を迷わずに閲覧できるか等の観点 
 拡張性   △   ◎   〇   コンテナ作成時に設定変更できる設定数の観点
 

Azureは、「とにかく簡単」の印象です!作成時に設定できる項目が少ない分、迷う時間も少なく、さくさく作成して実行まで確認できました。現時点で唯一コンテナに管理ポータルから接続できるのも魅力的だと感じました。

AWSは、「初級者には少し壁が高く、ある程度AWSの知識がある中級者以上向け」の印象です!その代わりにコンテナ作成時に設定変更できる項目が多く、知識がある人にとっては仕様にあわせて作成時にカスタマイズし易く、一番使いやすいと感じる可能性もあると思いました。

GCPは、「バランスが良い」の印象です!コンテナ作成時に変更できる設定も多いですが、操作性が良く、あまり迷わずにさくさく作成、実行できた印象です。作成後の管理画面も画面移動することなく、ログや設定を確認できて、次のアクション(例:継続的デプロイ)への誘導もされており、使いやすいと思いました。

6. まとめ

3大クラウドサービスそれぞれのコンテナサービスを比較してみましたが、どれが一番ということはなく、使う人が自分にとって、そしてお客様にとって選びやすい特徴をそれぞれが持っていると感じました。
マイクロサービスもコンテナだけで完結することはなく、それぞれのクラウドサービスがもつ独自のサービスと連携して使うことになると思います。

例えば、ユーザー管理、認証はAzure AD、コンテナ/コンテナオーケストレーションはAWS ECS、そこからMicrosoft 365やGoogleのGoogle MapやGoogle 翻訳、Google Driveにつなげたり等、それぞれの良さ、特徴を活かしたマルチクラウド構成も考えられますね。

今後はコンテナ以外のサービスでも実際に各クラウドサービスでさわってみて、それぞれの特徴を理解し、お客様にとってより良い選択肢をご提供できるようにしていければと思います。

さいごに

本ブログでは、コンテナサービスをベースとして、3大クラウドサービス(Azure/AWS/GCP)の公式ドキュメントの事実に基づく比較と実際に使ってみた私個人の所感に基づく使用感の2つの比較を行いました。今回はコンテナを作成して実行しただけの比較でしたが、それでも各クラウドサービスの違い、特徴を垣間見ることができました。簡単なところからはじめて、理解が徐々に深まっていく感じ、楽しいですね。

今後はコンテナで作成した複数のAPIを CI/CDで改善していくような仕組みや、BFF(Backends For Frontends)について考慮し、最終的にマイクロサービス的な構成のシステムに発展させることを検討しています。

QESでは様々なアプリケーションの開発・導入を行っております。 私共が提供するサービス・ソリューションにつきましては下記の弊社強みのページに掲載しております。

また、現在Power Platform に力を入れて取り組んでいます。Power Apps等のPower Platformについては、下記の弊社支援サービスページをご覧ください。

システム開発・構築でお困りの問題や弊社が提供するサービス・ソリューションにご興味を抱かれましたら、是非一度、下記の弊社お問い合わせページからお問い合わせください。

・このブログで参照されている、Windows Azure、その他のマイクロソフト製品およびサービスは、米国およびその他の国におけるマイクロソフトの商標または登録商標です。
・このブログで参照されている、Amazon Web Services、およびブログで使用されるその他のAWS商標は、米国その他の諸国における、Amazon.com, Inc.またはその関連会社の商標です。
・このブログで参照されている、GCP、その他のGoogle製品およびサービスは、Google LLCの商標です。
・このブログで参照されている、DockerおよびDocker Hubは、米国およびその他の国における Docker Inc. の商標または登録商標です。
  • LINEで送る
  • このエントリーをはてなブックマークに追加

お気軽にお問い合わせください。

ページのトップへ