Alibaba ECSとAmazon EC2を並べて機能性を比較してみる

#導入
Alibaba Cloudを利用するにあたり、導入時の比較対象となりうるパブリッククラウドとしてAmazon社提供のAmazon Web Service（通称AWS）、Microsoft社提供のMicrosoft Azure（通称Azure）、Google社提供のGoogle Cloud Platform（通称GCP）など、各社色々なサービスが提供されています。
今回、この記事でパブリッククラウドではシェアNo.1のAmazon Web ServiceとAlibaba Cloudの各コンポーネントの比較などを行いたいと思います。

比較対象として、まずは仮想サーバのコンピューティングサービスであるAmazon Elastic Compute Cloud（Amazon EC2）と、Alibaba社のElastic Compute Service（ECS）を比較してみます。

##性能諸元
それぞれのコンピューティングサービスの性能諸元は以下のページに記載があります。
各プランに関する記述は、以下から抜粋、引用させていただきました。
AWS：https://aws.amazon.com/jp/ec2/instance-types/
Alibaba Cloud：https://jp.alibabacloud.com/product/ecs#pricing

では、それぞれ概要を確認してみましょう。

##Amazon Elastic Compute Cloudのプラン
AWSのEC2はそれぞれ特徴ごとに以下のカテゴリに分けられているようです。

カテゴリ：汎用
プラン名：T2,M5,M4
T2のユースケース：Web サイトや Web アプリケーション、開発環境、ビルドサーバー、コードリポジトリ、マイクロサービス、テストやステージング環境、基幹業務アプリケーション。

個人利用としてはこのT2プランが拡張性高く安いため多く使われている印象を受けます。

カテゴリ：コンピューティング最適化
プラン名：C5,C4
C5のユースケース：ハイパフォーマンスのウェブサーバー、科学的モデリング、バッチ処理、分散分析、高性能コンピューティング (HPC)、機械学習/深層学習推論、広告サービス、拡張性の高いマルチプレイヤー、動画エンコーディング。

カテゴリ：メモリ最適化
プラン名：x1e,x1,R4
X1eのユースケース：ハイパフォーマンスデータベース、インメモリデータベース (SAP HANA など)、メモリ負荷の高いアプリケーション。x1e.32xlarge インスタンスは、AWS クラウドで、次世代ビジネススイート S/4HANA、Business Suite on HANA (SoH)、Business Warehouse on HANA (BW)、および Data Mart Solutions on HANA の実行を SAP によって認定されています。

カテゴリ：高速コンピューティング
プラン名：P3,P2,G3,F1
P3のユースケース：機械学習/深層学習関連のハイパフォーマンスコンピューティング、数値流体力学、金融工学、耐震解析、音声認識、自動運転車、創薬

これは最近流行っているGPUを用いたプランですね。クラウド技術の進歩に伴いグラフィックボードを手掛けているNVIDIAの時価総額が急上昇した要因でもあります。高度な３次元解析などではこのプランが有用そうです。

カテゴリ：ストレージ最適化
プラン名：H1,I3,D2
H1のユースケース：MapReduce ベースのワークロード、HDFS や MapR-FS などの分散型ファイルシステム、ネットワークファイルシステム、Apache Kafka などのログまたはデータ処理アプリケーション、ビッグデータワークロードクラスター。

##Alibaba Cloud Elastic Compute Serviceのプラン
同様に、AlibabaのECSはそれぞれ特徴ごとに以下のカテゴリに分けられているようです。

カテゴリ：一般目的
プラン名：コミュニケーションタイプ sn2、sn2ne
ユースケース：中規模および大規模のWebサーバー（高い並行性）に適しています。 MMO（Massively Multiplayer Online）ゲームのフロントエンド、データ解析、コンピューティングCPUが提供する高精度のエンコード/デコード、レンダリング、遺伝子計算、その他の固定性能コンピューティングのシナリオを提供しています。

カテゴリ：コンピューティング最適化
プラン名：コミュニケーションタイプ sn1、sn1ne
ユースケース：上記と同等

カテゴリ：メモリ最適化
プラン名：コミュニケーションタイプ se1、se1ne
ユースケース：Cache / Redis、検索、インメモリデータベースを持つアプリケーションなど、多数のメモリ操作、クエリ、およびコンピューティングが必要なアプリケーションに適しています。

カテゴリ：ビッグデータ
プラン名：コミュニケーションタイプ d1
ユースケース：対応するエフェメラルディスクストレージタイプ：SATA HDDリソース。膨大なストレージリソース、Hadoop、並列データ処理、その他のビジネスシナリオに適しています。 

カテゴリ：ローカルSSD
プラン名：SSDタイプ i1
ユースケース：対応するエフェメラルディスクストレージタイプ：NVMe SSDリソース。高いランダムIOPS、高いシーケンシャル読み取り/書き込みスループット、および低レイテンシ
OLTP、NoSQLデータベース、Hadoop、その他のアプリケーションのシナリオに適しています。

カテゴリ：高いクロック速度
プラン名：CPUタイプ cm4、コミュニケーションタイプ ce4
ユースケース：MMO（Massively Multiplayer Online）ゲームのフロントエンド、データ解析、コンピューティングに適しています。 CPUが提供する高精度のエンコード/デコード、レンダリング、遺伝子計算、その他の固定性能コンピューティングのシナリオを提供しています。

##スペック比較してみての感想
それぞれ、カテゴリ分けもコンピューティング最適化、メモリ最適化、など似た形となっていることがわかりました。その他の項目も表現は違えどかなり似通っているように見えます。
また、これらのプランごとに、vCPU、メモリの違い（1vCPU、2GB　、　2vCPU、4GBなど）で金額が異なってきます。
個人的に気になったのはAWS側ではGPUによる高処理能力を前面に押し出したプランがあることです。今後、高度な画像処理などのサービスを見据えてのラインナップなのか、他のプランと横並びで「GPU」という言葉が用いられていました。

##実際にデプロイしてみた
では、次は実際にそれぞれのインスタンスをデプロイし、UI/UX部分を比較してみたいと思います。
多少、主観が入るかもしれませんが、みなさまがデプロイするにあたって画面遷移など参考になれば幸いです。また、ネットワークに多少依存するところもありますが、デプロイ速度などもざっくり評価してみます。

##Amazon EC2のデプロイ
まずは以下のURLから自分の持っているアカウントでサインインし、トップページにアクセスします。
https://console.aws.amazon.com/ec2
右上に自分の登録しているアカウント名が出ますので、本記事では隠させていただいています。
トップページにアクセス後画面上部の「サービス」にカーソルを合わせてクリックすると、AWS上で利用できるサービス群が表示されますので、「EC2」をクリックします。するとEC2専用のコンソール画面に遷移します。

<img width="940" alt="00_トップ.jpg" src="https://qiita-image-store.s3.amazonaws.com/0/255826/5f2d9921-df61-5d11-23bc-743b284e0eaa.jpeg">

画面の構成としては左側タブに各コンポーネントの選択があり、真ん中～右に自分の所持しているリソースが表示されます。クラウド基盤のOSSの主流であるOpenstackや、Microsoft社のAzureなども同じ画面構成ですね。では早速インスタンスの作成をしてみましょう。画面中央の「インスタンスの作成」ボタンをクリックします。

<img width="957" alt="01_EC2トップ.jpg" src="https://qiita-image-store.s3.amazonaws.com/0/255826/b2490e76-185c-a2c1-b748-2b5db11e28fd.jpeg">

すると、ステップ１としてAmazonマシンイメージ（AMI）というページに遷移します。作成するインスタンスのOSを選択する画面になりますので、利用したいOSを選択します。この画面ではUNIXベースのOSが表示されていますが、画面をスクロールするとwindowsなどのOSも選択可能です。ここでは一番上の「Amazon Linux AMI」を選択します。

<img width="957" alt="02_マシンイメージ.png" src="https://qiita-image-store.s3.amazonaws.com/0/255826/3b4ad5c6-0946-0e29-ebbc-bac08ff8d98a.png">

するとステップ２としてインスタンスタイプの選択という画面に遷移します。vCPU、メモリなどのインスタンスのスペックを指定します。ファミリーとして、上記で記述した「コンピューティング最適化」などのカテゴリごとに一覧化されており、基本的には下にスクロールするほどスペックが上がるようになっています。ここではファミリー：汎用のタイプ：t2.microを選択して、次の手順：インスタンスの詳細の設定をクリックします。

<img width="958" alt="03_インスタンスタイプ.jpg" src="https://qiita-image-store.s3.amazonaws.com/0/255826/226f6b20-da02-67a7-f8af-c524fd5fe3a2.jpeg">

するとステップ３としてインスタンスの詳細の設定に遷移します。一つ一つの項目についての説明は省略します。例えば「ネットワーク」ではすでに作成しているネットワークに本インスタンスを所属させたい場合は、ここで選択を行います。ここでは何も変更せずに次の手順：ストレージの追加をクリックします。

<img width="958" alt="04_インスタンスタイプ詳細.jpg" src="https://qiita-image-store.s3.amazonaws.com/0/255826/a812e611-8dea-36c7-b0dc-5d66f064ef0c.jpeg">

次にステップ４としてストレージの追加に遷移します。サイズ（GB）ですが、選択したプランではデフォルトでは8GBとなっているようです。
何も変更せずに、次の手順：タグの追加をクリックします。

<img width="957" alt="05_ストレージ.jpg" src="https://qiita-image-store.s3.amazonaws.com/0/255826/362fc2ca-8fa0-c94d-18d3-d6bcb3e540f7.jpeg">

ステップ5としてタグの追加に遷移します。特に今回設定することはないので次の手順：セキュリティグループの設定をクリックします。

<img width="957" alt="07_タグ.jpg" src="https://qiita-image-store.s3.amazonaws.com/0/255826/d5e42b7b-211b-d08c-8f0a-3d4d4773fc08.jpeg">

ステップ６としてセキュリティグループの設定に遷移します。ここでは作成したインスタンスのACL的な設定が実行できます。デフォルトではすべてのソースIPからのSSH接続を許可する設定が入っています。
今回は試験的にインスタンスを作成するため特に詳細な設定はしませんが、本来であれば自分のアクセス元となるIPのみSSH接続を許可するなどの設定が必要になると思います。
ここでは何も実施せずに確認と作成ボタンをクリックします。

<img width="948" alt="08_セキュリティグループ.jpg" src="https://qiita-image-store.s3.amazonaws.com/0/255826/decf1b7b-ff51-abc7-174e-912664df6e54.jpeg">

ステップ７：インスタンス作成の確認画面として、これまで入力してきた設定内容の最終確認の画面が表示されます。問題がなければ作成をクリックします。

<img width="955" alt="09_インスタンス作成の確認.jpg" src="https://qiita-image-store.s3.amazonaws.com/0/255826/afcbb238-3213-7d42-254e-181844086199.jpeg">

するとポップアップが表示され、サーバにセキュアにアクセスするためのキーペアについての作成画面が表示されます。この認証キーを使ってサーバのアクセスできるようです。ここでは新しいキーペアの作成を選択、キーペア名に「test」と入力してキーペアをダウンロードしておきました。下に.pemファイルがダウンロードされていることがわかると思います。
ダウンロードを完了した上で、インスタンスの作成をクリックします。

<img width="950" alt="10_キーペア作成画面.jpg" src="https://qiita-image-store.s3.amazonaws.com/0/255826/216f8eb6-93da-3776-5304-6073a0c57b82.jpeg">

ローディング画面を少し挟んだのち、インスタンス作成中の画面が出ます。
その後ホーム画面に戻ると、すでにインスタンスは作成され、runningの状態でリストに存在していました。作成したインスタンスのスペックが低いとはいえ、非常に速いです。約１分ほどといったところでしょうか。

<img width="955" alt="11.インスタンス作成中.jpg" src="https://qiita-image-store.s3.amazonaws.com/0/255826/7107b368-8bb7-418e-4dd4-80ee591c102d.jpeg">

<img width="957" alt="12.home.jpg" src="https://qiita-image-store.s3.amazonaws.com/0/255826/3fcf4b5c-b7ca-71f1-5e12-e6f5dda2bef9.jpeg">

これにてインスタンスの作成が完了となります。

##EC2をデプロイしてみての感想
特にUIベースで操作に迷うことはなく、淡々と作成できました。欲を言えば、おそらくチュートリアル等には書いてあるのだと思うのですが、キーペアでの鍵認証でないbasic認証（ID/PWを用いた認証）でのSSHログインをするときに、どうしたらよいのか流れの中ではわかりませんでした。まあ鍵認証のほうがセキュアなので意図的にそうしているのかもしれませんが・・・個人的には少し気になるポイントでした。



##Alibaba Cloud ECSのデプロイ
AWSの時と同様にコンソール画面にログインします。個人情報も同様にホワイトアウトしています。
「プロダクトとサービス」の中にある「Elastic Conpute Service(ECS)」をクリックすると、ECS専用のコンソール画面に遷移します。

<img width="955" alt="00_トップ.jpg" src="https://qiita-image-store.s3.amazonaws.com/0/255826/18d1eb6e-4a4d-b58d-f1bb-866307f71c24.jpeg">

AmazonのAWSと比較を念頭に置いて画面を見ていきますが、まず、トップページでは各リージョン（インスタンスを置いている地域）ごとのインスタンスの状態がグラフィカルに見えているので、非常にわかりやすい印象を受けました。
ここでは、試しに「US West1(Silicon Valley)」にインスタンス作成しようと思います。「インスタンス 0」をクリックします。

<img width="957" alt="01_トップECS.jpg" src="https://qiita-image-store.s3.amazonaws.com/0/255826/aec64ca8-e14d-308e-b9df-e7e122a08e3f.jpeg">

すると次にインスタンスリストに「US West 1」が選択された状態で次の画面に遷移します。
現在は何もインスタンスを作成していないので、「条件を満たすレコードが見つかりません。」と表示されています。おそらくインスタンス作成後はここに作成したインスタンスの情報が表示されそうです。
右側の青いボタン「インスタンスを作成」をクリックします。

<img width="960" alt="02_トップECS.jpg" src="https://qiita-image-store.s3.amazonaws.com/0/255826/1a2073b9-d21d-e835-ab29-b69da8c8462f.jpeg">

次にインスタンスの作成をする上でのパラメータを入力する画面に遷移します。
一目見て気づくのが、画面下の帯に「パッケージコスト」として現在の設定での課金金額が動的に表示されます。これはインスタンスを作成するうえでコストが一目でわかるので、金額を見ながらパラメータの選択を行うことができ、非常に便利だなと思いました。
「価格モデル」はAmazonとの比較のために「従量課金」を選択しました。「サブスクリプション」を選択すると一か月、一年単位の金額に下のパッケージコストが切り替わります。
「リージョン」は先ほど選んだ「US West 1」が「米国西部1」に和訳されて表示されています。
デフォルトで「ランダム」が選択されていましたが、ゾーンの任意選択も可能でした。ここでは「米国西部１ゾーンA」を選択しています。
画面をスクロールすると「インスタンスタイプ」を選択できます。

<img width="958" alt="03-1_インスタンス作成.jpg" src="https://qiita-image-store.s3.amazonaws.com/0/255826/9922c4bd-75f0-4dfa-4296-b5ebfc06130e.jpeg">

インスタンスタイプでは、上部「Alibaba Cloud Elastic Compute Serviceのプラン」段落で記載したプランの選択を行います。ここでは「一般目的」の「コミュニケーションタイプsn2」の「ecs.sn2.medium」を選択します。
画面をスクロールします。

<img width="960" alt="03-2_インスタンス作成.jpg" src="https://qiita-image-store.s3.amazonaws.com/0/255826/ca4c9fb8-eaa0-8fee-dbdc-f8553d1e0822.jpeg">

イメージを選択します。プルダウンをクリックすると、パブリックイメージとして標準的なOSを利用できます。カスタムイメージは持ち込みOSなどをアップロードして利用できるようです。ここでは個人的に使いやすい「CentOS」の「6.9.64bit」を選択しました。
ストレージを選択します。容量はデフォルトで40GBとなっており、任意に変更可能でした。ここではデフォルトのままとします。
完了後、次のステップ：ネットワークをクリックします。

<img width="959" alt="03-3_インスタンス作成.jpg" src="https://qiita-image-store.s3.amazonaws.com/0/255826/7bd282ee-5d91-2ea4-a2e9-17bbfb4adb2e.jpeg">

ネットワーク部分に関しては、VPCなどは作成していないのでデフォルトのまま次に進みます。
パブリックIPの割り当てはデフォルトのままチェックありとしておきます。
前のステップ：基本構成に隠れてしまっていますが、トラフィック毎にかかる料金も表示されるようになりました。

<img width="959" alt="04-1_ネットワーク.jpg" src="https://qiita-image-store.s3.amazonaws.com/0/255826/a924735e-827e-21b5-ac02-2a947763105a.jpeg">

同じくこちらもデフォルトのまま次のステップ：システム構成をクリックします。

<img width="956" alt="04-2_ネットワーク.jpg" src="https://qiita-image-store.s3.amazonaws.com/0/255826/40c3f8db-06ba-a581-107b-ae9b4742bc46.jpeg">

次にログオン資格の選択画面に遷移します。デフォルトではAmazonと同じようにキーペア式が選択されていました。ここでは手軽にログイン確認するために、AmazonのEC２とは変えてパスワード方式を選択してみます。パスワードの入力を求められるので、任意のものを入力します。
インスタンス名などは、複数のインスタンスを作成するときは間違いないように任意の名称を付けるべきですが、ここではデフォルト値のまま次のステップ：グループ化をクリックします。

<img width="958" alt="05-1_システム構成.jpg" src="https://qiita-image-store.s3.amazonaws.com/0/255826/56bb8ed5-bffb-cd9c-6869-2bc449d4c155.jpeg">

ここでは特にタグ付けはせず次のステップ：プレビューをクリックします。

<img width="957" alt="06_グループ化.jpg" src="https://qiita-image-store.s3.amazonaws.com/0/255826/deed1a7b-29da-0455-4809-8255c1cd3479.jpeg">

今まで入力してきた内容が表示されるので、確認後利用規約のチェックボックスをクリックします。
ここで今まで隠れていたパブリックトラフィック料金が見えました。このケースでは8.36円/GBでかかるようです。パッケージコストとの合算がこのインスタンスにかかる合計金額になります。やはりわかりやすいですね。
その後、インスタンスの作成をクリックします。

<img width="959" alt="07_プレビュー.jpg" src="https://qiita-image-store.s3.amazonaws.com/0/255826/3c9b0671-2b3c-5928-8262-c9e64818de35.jpeg">

作成の画面遷移します。

<img width="957" alt="08_作成中.jpg" src="https://qiita-image-store.s3.amazonaws.com/0/255826/0cd80bee-e02c-709e-4e80-7f278ae3ea06.jpeg">

<img width="959" alt="09_コンソール.jpg" src="https://qiita-image-store.s3.amazonaws.com/0/255826/e11f554e-8803-e319-9e9e-c0f816611184.jpeg">

有効化のポップアップが出た後、一分後くらいに「コンソール」をクリックすると、ECSの管理コンソールに遷移し、すでに作成したインスタンスのステータスが「実行中」になっていました。
せっかくなので、表示されていたインターネットアドレスにSSHログインをしてみました。

<img width="494" alt="10_ログイン.jpg" src="https://qiita-image-store.s3.amazonaws.com/0/255826/8e61e8fd-3e08-3981-ad88-f233c874cab5.jpeg">

作成したインスタンスID名のバーチャルマシンに無事アクセスできていることが確認できると思います。
Root権限でのアクセスということでもちろん危険なので、PermitRootLoginをOffにしていただくことをお勧めします。

##ECSをデプロイしてみての感想
AmazonEC2と同じく、特にUIベースで操作に迷うことはなく、淡々と作成できましたが、個人的にはECSのほうが以下の点がわかりやすかったです。
　・パッケージコストとトラフィック量の総和が動的に表示されて一目で課金額がわかる
　・認証方式を簡単にパスワード方式に変更できる。
デプロイスピードも１分ほどと、申し分ないと思います。

#まとめ
AmazonEC2とAlibaba Cloud ECSを比較してみました。どちらにも一長一短、UIも微妙に違いますが、基本的な機能で大きな差はないように見えます。作成できるインスタンススペックもそこまでの差はありませんでしたので、お気に召すほうをお使いいただくとよいのではないかと思います。