*

2016年 GCE vs AWS:何故Amazonを絶対使ってはイケナイのか!

公開日: : 投稿者: GCE

2016年 GCE vs AWS:何故Amazonを絶対使ってはイケナイのか!
本文章は以下の記事の超訳(著者の許可を得て)に一部私のコメントを付加したものになります。
GCE vs AWS in 2016: Why you should NEVER use Amazon!
https://thehftguy.wordpress.com/2016/06/15/gce-vs-aws-in-2016-why-you-should-never-use-amazon/

###以下超訳になります

はじめに

この文章は典型的なWebスタートアップにおける私の経験によるものです。我々はAWS上で100以上のインスタンスを起動させ、一定のペースで成長してきた中である程度の期間そうやってきました。

我々の全てのオペレーションはクラウド上で行われています。Webサーバ、データベース、マイクロサービス、git、wiki、BIツール、監視、、、これらは全て典型的なテクノロジー会社では必要となるオペレーションです。

後はオフィスにはインターネットアクセスのために少しのスイッチと一つのルータがあるだけで、以上です。オンサイトにはサーバは1台もありません。

以下のAWS上で日々遭遇するたくさんの問題についてハイライトしてますが、皆さんにはAWSを選択したことによる同じ過ちを犯さないよう願っています。

クラウドは何を提供するものか?

世の中にはたくさんのクラウドがあります:GCP、AWS、Azure、Digital Ocean、RackSpace、SoftLayer、OVH、GoDaddy、、、などなどこちらの記事もチェックしてください。
Choosing the right cloud provider: Amazon AWS vs Google Compute Engine vs Microsoft Azure vs IBM SoftLayer vs Linode vs DigitalOcean vs OVH vs Hetzner
ここではGCEとAWSにのみフォーカスします。両者は完全な機能を備え、それぞれ共有のインフラでIaaSとして提供されているメジャーなサービスです。

どちらも典型的なデータセンタとして必要な全てを提供しています。

インフラストラクチャーとハードウェア

  • 様々なスペックのサーバを立ち上げる
  • 地球上の複数のデータセンタで
  • リモートやローカルのストレージ
  • ネットワーク(VPC、サブネット、ファイヤウォール)
  • 起動、停止、削除等全てを数クリックで
  • 使った分だけ課金

追加のマネージドサービス(オプション)

  • SQL データベース(RDS,Cloud SQL)
  • NoSQL データベース(DynamoDB, Big Table)
  • CDN(CloudFront, Google CDN)
  • Load balancer(ELB, Google Load Balancer)
  • 長期ストレージ(S3, Google Cloud Storage)

Amazonについて知っておくべきこと

GCE vs AWSの価格について: Good vs Evil

AWS側の実際のコスト:

  • ベースのインスタンスとストレージのコスト
  • データベースでは追加のIOPSを購入(ノーマルのEBSではIOが十分では無い)
  • ローカルSSDを追加 (675$ per 800 GB + 4 CPU + 30 GB. ALWAYS ALL together)
  • 全体コストに対する+10%のプレミアムサポートへの加入が必須
  • 専用のインスタンスや専用ホスト向けには追加で10% (もし必要ならば)

GCE側の実際のコスト:

  • ベースのインスタンスとストレージのコスト
  • GoogleのリモートSSDボリュームにより信頼出来る外部のIOを楽しむ
  • 最終的にはローカルSSDを追加(82$ per 375 GBで既存のどのインスタンスにも追加可能)
  • 継続利用割引により自動的に割引される(24時間利用の場合最大30%割引)

AWSのIOは安定しておらず高価

EBSのSSDボリューム:IOPSとプロビジョンド IOPS

我々は信頼性を必要とする場合は常にプロビジョンドIOPSのために追加で支払いをする必要がありました。
プロビジョンドIOPSは特段速くは無い。若干、速いけどでも最も大事なのはばらつきが少ないことです(例えば 90%-99.9%のレイテンシ)。これは幾つかのワークロード(データベースとか)では通常のIOPSでは非常に安定しないので致命的です。

結局、プロビジョンドIOPSは非常に高額であり、一般的な今日のどんなハードディスクよりも残念なものです。(720ドル/月額で10k IOPSで更に追加0.14ドル/GB)

ローカルSSDストレージ

ローカルSSDのストレージはAWSの中でも(全てのクラウドの中でも).最も高額なインスタンスグループであるi2インスタンスファミリーを利用する必要があります。
いい感じの粒度のものは無く、CPU、メモリ、SSDストレージ量はi2xxxという形で2倍毎のタイプしかありません。4CPU+30GBメモリ+800GB SSD で $765/monthの倍数しか無いのです。
この制限はローカルSSDストレージを非常に高価なものにし、利用するのは特殊なケースになります。

AWSのプレミアムサポートは必須

プレミアムサポートはAWS費用の全ての更に10%追加になります。(例えば EC2インスタンス+EBS Volume + S3 storage + トラフィック費用 + 全て)

トラフィックのスパイクに対する対応

ELBやS3は突然のトラフィックスパイクには対応出来ません。これらはサポートに事前にお願いして手動でスケールさせておく必要があります。
計画外のイベントは5分間503としてサイト到達不能になります。

制限の取り扱い

すべてのリソースは、デフォルトではハードコードされた非常に低いクォータによって制限されています。この制限はサポートにチケットを送り、1つずつ手動でのみ増加させることが可能です。

2つのc4.largeのインスタンスを起動しようとする(既に15を起動した状態で)と、”limit exhaustion: 15 c4.large in eu-central region”と表示され失敗した時のフラストレーションを完全に表現することは難しいでしょう。サポートに連絡し、4通のメールと1日以上待たされ、そうして再度挑戦した時に “limit exhaustion: 5TB of EBS GP2 in eu-central region”と出てまた失敗するのです。

このような曲芸が2~3週間おきに発生し、時には1件で3つの制限にぶちあたったりもします。全てのリソースにリージョン毎、アベイラビリティゾーン、リソースタイプ毎、リソース種別毎に制限があります。

特定のチケットに24時間以内での応答を保証するためにはサポート料を支払う必要があります。無料のサポートでは動作しない状態でも1週間(かそれ以上)待つかも知れません。これは不合理ですが、プレミアムサポートが必要な本当の理由です。

AWS側で起こった障害に対応する

インフラの中で何が起こっているかのログや指標は一切ありません。何かおかしなことが起こったらサポートが必須になります。

例えば、ELBが不規則にリクエストを取りこぼし始めたとしましょう。サポートにコンタクトした後、彼らは何が起こっているか分からないと認め、「リクエストをありがとう。ELBの1台がおかしい状態でしたのでそれを停止し新しいものと差し替えました」と返ってきます。
問題は修復されました。残念なことに、何の気付きも意味のある情報も提供されません。これは将来の障害に対して計画したり修復したりするには大変手痛い点です。

メモ: 我々の仕組みに紹介されたさらなるマネージドサービスについて質問を浴びせたところ、最初こそ非常にセットアップが容易だったのでトライしましたが、 (注: 人的時間不足や興味のためです)。 それらはすぐに定期的に問題を起こし、デバッグもトラブルシュートも出来ないということがわかりました。

ELBはいろんなワークロードで役に立たない

ELBはホスト名でしかアクセス出来ません。割り当てられたIPはTTLが60秒で、毎分でも変わる可能性があります。

これは、固定IPが必要な全てのサービスや起動時に一度だけしかIPの名前解決しないサービスには適用不可能です。

ELBは落ちた時(実際、落ちる)にデバッグ出来ない、突然のスパイクにも対応出来ません。CloudWatchのグラフはとても残念です。 (ホントに、 Datadog に18ドル/月/ノード払ってCloudWatchを離れてしまいました)

ロードバランスは高可用性とスケーラブルな設計のキモです。冗長化されたロードバランスはその次です。ELBはそこまで行ってません。

ELBの代替案としてHAProxyを自前でペアで立て、VRRP/Keepalivedを利用する方法がある。でもそれを本番にきちんとした形でデプロイするには数週間かかります。

対して、Googleのロードバランサーは1,2時間で同じことが出来ます。Googleのロードバランサーは1つの固定IPを持てます。そのIPは1k/sから10k/sのリクエストを即座にもれなく処理可能で、動きます。

メモ: 今日、あるサービスを本稼働されたとき、500/sから15000/sまで3秒で対応出来たのを目の当たりにしました。賭けても良いけどELBではその半分も出来ないでしょう。

専用インスタンス

”専用インスタンスは仮想プライベートクラウド(VPC)内の特定の1顧客向け専用のハードウェア上で動作するAmazon EC2のインスタンスです。他のAWSアカウントに紐づくインスタンスや他の専用インスタンスでは無いインスタンスとはハードウェアホストレベルで物理的に孤立したインスタンスになります。”

専用インスタンス/ホストはもしかしたら幾つかのサービスでは法令順守や規制を遵守しない隣人のために必要になるかもしれません。

我々は幾つかの規則に準拠するために、そこここで幾つかの専用オプションを持っています。それはインスタンス価格の上位10%の価格です(さらに固定で月額1500ドルがリージョン毎にかかります)

メモ: Amazonは何が専用についてて、何をコミットしないのか詳細には説明してくれません。おかしなことに規制当局の誰もそこにツッコミを入れないのです。

頂いたコメントへの回答: Googleは”GCEのの専用インスタンス”を提供していません。それは必要無いからです。トリックなのは、規制当局やエンジニアが存在しないものを持ってないことには誰も文句がないということです。

リザーブドインスタンスはクソ

予約は特定のリージョン・アベイラビリティゾーン・インスタンスタイプ・場所・その他に紐付けられます。セオリーでは、予約は何が変更出来るかを学習することで変更は可能です。幾つかのパラメータの組み合わせは変更可能だけど他はダメです。慎重に計画して、最初のトライからより良い結果を持てるようにしましょう。

1年間にわたり全ての時間を予約して支払う必要があります、動いてようが動いてなかろうが。

ディスカウント幅はとっても小さいです。たくさんの予約の中でたった一つ誤った予約をすると節約した全てが水泡に帰すことになります。事前に全てのインフラを何日も掛けてレビューを行い、ミスを割けるためにサービスの移行にはもっと日にちを掛けて行うべきです。

リザーブドインスタンスは6~12ヶ月毎に発生する価格低減からすると全然利益にならないことを覚えておくとよいでしょう。

それに比べてGCEは、本当に素晴らしい自動月額割引です!インスタンス利用時間は毎月計算され自動的に割引が適用されます。(例:24時間稼働させっぱなしの場合30%オフになる)アルゴリズムはまたインスタンスを起動・停止・変更したような場合にも複数のインスタンスを組み合わせてくれます。

AWSのネットワークはサブパー

ネットワークのバンド幅の余裕はインスタンスサイズと相関しています。
1~2コアのインスタンスは100-200Mbpsでピークを打ちます。これは今のよりもっとたくさんのものが接続されネットワークに依存している世界においては非常に小さいものです。

ネットワークの制限により速度低下を経験する典型的なものとしては:

  • インスタンスプロビジニング、OSインストールやアップグレード
  • Docker/Vagrantのイメージのデプロイ
  • sync/sftp/ftpによるファイルコピー
  • バックアップやスナップショット取得
  • ロードバランサーやゲートウェイ
  • 通常のディスク読み書き(EBSはネットワークストレージ)

我々の最も大事なバックアップは本番のホストから他のロケーションにコピーするのに97秒かかります。半分の時間はネットワーク帯域が飽和していて(130Mbpsのキャップがかかっている)、半分の時間はEBSボリュームをホストで受け取るところで飽和しています。(ファイルは最初の転送時にメモリ上にバッファリングされてその後100%iowaitになりますが、EBSの帯域幅のキャップのためです)

同じバックアップ処理はGCEの同等ハードではたったの10秒~20秒くらいしかかかりません。

コスト比較

この記事はインスタンス同士のコスト比較をしないと完成じゃ無いですよね。:GCEとAWSの典型的なコスト比較

いろんな箇所の隠れた費用 + 信頼出来ない機能 = 回避策のための無駄な工数

キャパシティプランニングと日々のオペレーション

スケールしないリソース、信頼出来ないパフォーマンス能力、不十分な粒度、隠れた制約がいたるところにある状況では、キャパシティプランニングは無益な程困難を極めます。コスト計画はまさに悪夢です。

ことあるごとに我々はインスタンスを追加します。インスタンスページ、価格のページ、EBSのページをまた読む必要があります。そこには選択肢は多すぎるし、その幾つかは後では変更が難しいものもあります。印刷すると4×7フィートのテーブルを覆い尽くすでしょう。対して、Googleでは適切なインスタンスを選ぶのに両名1枚程度で済みます。

利用の最適化は失敗する運命にあります

リザーブドインスタンスを最適化するためにかかる時間はそれにより得られるコスト削減と同一に近いものになるでしょう。

CPUの数、メモリサイズ、EBSのボリュームサイズ、IOPS、プロビジョンドIOPSの全てはAWS上で余分にプロビジョンします。一部は人間には理解して最適化するには困難な情報量であったり、また機能に矛盾があった際の回避策が必要だったり、また本稼働しているインスタンスに対して後から修正するのは難しかったりするからです。

これらの全ての問題は直接的にAWSのプラットフォーム自体に起因します。
HWのオプション面もHWの能力面でもお金の面でも、すっきりしてないし水平に綺麗に拡張出来ません。いつも我々がコストを減らすために何かを変えようと考えると、だいたいは何もしない方が安価に済みます。(エンジニアリングの時間を考えると)

結論

AWSにはいたるところに隠れたコストや制限があります。システムの機能性は満足では無く持続的なスケールは出来ません。AWSを選んだのは間違いでした。GCEが常に良い選択です。

GCEは価格体系として何も考えなくても同等のインフラと比較して20%~50%安いです。最後になりますがそしてより早く、より信頼でき、より簡単に日々利用出来ます。

我々の会社の将来

不幸なことに我々のインフラはAWSで動いており、移行は深刻な作業になります。
最近我々の会社は思った以上に収益性の高い会社であったということを学びました。従業員一人あたりの収入トップ10企業を見ると我々はトップ10以内にいるみたいです。近い将来AWSではスタックし、たくさんの費用をかけて問題に対して回避策をうつのでしょう。会社としてはその費用を吸収可能だし、いまのところコスト最適化は再優先事項ではありません。
諺に「問題を解決するのに金を投げ捨てる」というのがありますが、我々はさしずめ、「問題解決にいえを投げ捨てる」というのがより現状を表すでしょう。

仮に我々が現状のペースで成長を続けると、垂直的にスケールする必要が出てくると思うけど、その時は”Amazonでビルを放り投げる”ということになるでしょう。

####訳はここまで

以上、収益ベスト10って相当デカくて聞いたことある会社しかありませんでしたが、どこの企業なのか気になりますねぇ。
Amazonで苦労されている方のお話でした。皆さんは是非はじめからGCP(GCE)を利用して、苦労知らず、金を投げ捨てる事のないようにしてください。

GCPの利用に関するご相談はクラウドエースまで!

この記事を書いた人

ayatoshi
ayatoshi
徳島県出身、吉積情報株式会社最高技術責任者
愛光高校、東京大学卒業後、アクセンチュアにて5年間システム開発を経験。
CP300のアジア初取得者。
Google基盤上でのシステム開発の普及を目標として日々活動中。

関連記事

東京リージョン内でのGAE・GCS・GCE間の通信はこのくらいだった

11月8日に Google Cloud Platform にて待ちに待った日本リージョンがリ

記事を読む

2015/10/16 GCE vs AWS ベンチマーク

2015/10/16 GCE vs AWS ベンチマーク 本シリーズでは定期的に

記事を読む

2016/08/12 GCE vs AWS vs Azure ベンチマーク

2016/08/12 GCE vs EC2 vs Azureベンチマーク 本シリー

記事を読む

2015/07/10 GCE vs AWS ベンチマーク

2015/07/10 GCE vs AWS ベンチマーク 本シリーズでは定期的にGCEとEC2のベ

記事を読む

手軽にオンプレからGCEに移行できる、VM-Migration Serviceの解説と検証!(1/3)

~まずはとりあえずやってみよう~ みなさん、こんにちは。@prsdnt_hanage と申

記事を読む

2015/02/25 GCE vs AWS ベンチマーク

2015/02/25 GCE vs AWS ベンチマーク 本シリーズでは定期的にGCEと

記事を読む

Google Cloud SQL APIのサンプルプログラムを動かしてみた

今回は、去年の6月にリリースされたGoogle Cloud SQL APIについてご紹介します。

記事を読む

手軽にオンプレからGCEに移行できる、VM-Migration Serviceの解説と検証!(2/3)

~詳しい移行設計ポイントと手順~ みなさん、こんにちは。@prsdnt_hanage です。

記事を読む

GCEディスクのオンライン拡張を試してみた

GCEではなんと、ディスクを割り当てしたまま拡張することが可能です。 通常良くあるクラウド等では一

記事を読む

[GoogleAPI千本ノック] Google Compute Engine API を試してみた

こんにちは。GoogleのAPIを隔週で片っ端から紹介する、GoogleAPI千本ノック 第二回目

記事を読む

PAGE TOP ↑