クラウドサービス メリット・デメリット

前へ << クラウドサービスとは何か AWS・Azure・GCP クラウド比較 >> 次へ

クラウドサービスのメリット・デメリットを解説します。 特にオンプレミスと比較することで、クラウドサービスの利点・欠点や、得意分野・不得意分野を浮き彫りにします。


目次

クラウドサービスのメリット・デメリット一覧表

開発
導入スピード ◎ (これがクラウドサービスの最大のメリット)
検証容易性 ○ (すぐに試せる)
PaaS 利用による開発ボリューム削減
料金・コスト
価格 場合による
価格透明性 △ (料金は記載されているが、最終的な金額は読みづらい)
初期費用 ○ (不要)
最低利用期間 ○ (最低利用期間なし)
経費計上
性能
マシン性能 △ (ハイエンドではオンプレミスが若干優勢)
ストレージ性能 △ (例えば IOPS で比べるとオンプレミスの圧勝)
ネットワーク性能 △ (InfiniBand などで、オンプレミス有利)
運用
インフラ障害対応 ◎ (クラウドベンダにおまかせ)
開発者の手離れのよさ ×
サポート
ハードウェア EOL/EOSL ○ (オンプレミスでありがちなハードウェアの EOL 対応は不要)
セキュリティ
インフラセキュリティ・脆弱性対応 ○ (PaaS ならば全部おまかせ)
WAF・アンチウィルスソフト
うっかりミスによる被害 × (クラウドならではの事故は起こりうる)
厳格なアクセス制限 × (専用線を引いて、ガラス張り・入室制限した運用ルームからのみ操作可能、といったことはやりづらい)
権限管理
法規
管轄裁判所
日本国内制限
信頼性
故障 × (故障前提)
拡張性
スケールアップ
スケールアウト
大規模データ
大量アクセス
超大規模データ (コスト面) × (一定規模を超えると、クラウドは割高)
安定性
価格安定性 △ (突然の値上げはありうる)
不意のシステムトラブル × (PaaS では起こりがち)
突然のスローダウン × (PaaS では起こりがち)
狭い範囲での可用性 × (共用環境のため一時的な失敗は多い。リトライ必須)
リソース制限の拡大 × (起こりがち)
SDK バージョンアップ・仕様変更 × (仕様はよく変わります)
その他
ライセンス管理 ○ (ライセンス込みなので管理が楽)
ライセンスコスト △ (CPU コア数課金などは高額になりがち)
災害対策
謝罪・損害賠償 × (謝罪はあまりしない、損害賠償はほぼ無理)
責任転嫁 ○ (クラウドベンダのせいにできます)
透明性 × (すべては雲の向こう側)
連番生成・一度だけ × (どこか一箇所に集中する形は苦手)
名前の重複可能性 × (なくはない)

開発

導入スピードについて

導入のスピードが早い。これはクラウドサービスの一番のメリットと言っていいでしょう。 ブラウザで管理画面にアクセスし、ぽちぽちと操作すれば基本的なインフラは準備ができます。

一方、オンプレミスのシステム導入において、特にハードウェアの導入は以下のような感じです。 提案依頼書を書いて、ハードベンダにばらまき、提案を受け、比較検討し、さらに詳細条件を詰め、 見積提示してもらい、契約締結して、搬入を待ち、ラックにマウントし、ネットワーク結線し、 試験し、なんて感じです。そして「海外からの出荷なので 1ヶ月待ちです」なんて言われたり、 初期不良で返品となり代替品の到着を待つのに数週間も必要だったり。

検証容易性について

上記の導入スピードとも関係しますが、画面操作だけで設定が可能なんで、 「まずは試してみよう」ができてしまいます。 オンプレミスのシステムからクラウドへの移行について、比較検討から始めるのもいいのですが、 ちょっと優秀な技術者に 10日くらい与えてみると、「それなりに動くようになりました」となることも多いでしょう。 特に自社サービスであれば、検討・計画をすっとばして、まずは試してみるというのは十分ありえる選択肢です。

PaaS 利用による開発ボリューム削減

オンプレミスでは自前で構築・開発しなければならないところを、 クラウドサービスの PaaS を利用することで、構築・開発を省略することができます。 結果的に開発スピード向上につながるでしょう。

以下は、当ページ管理人が考える、クラウドサービスの PaaS を使った方が楽で早いと思われる箇所です。

  • RDBMS 構築 (冗長化・バックアップ含む) → Amazon RDS などを利用
  • DNS サーバ構築 → Route 53 などを利用
  • データウェアハウス構築 → Amazon Redshift などを利用
  • ストレージの構築 (冗長化・バックアップ含む) → Amazon S3 などを利用
  • キャッシュサーバの構築 (Memcached・Redis など) → ElastiCache などを利用
  • ロードバランサ構築 → ELB を利用
  • バックアップサーバ構築 → Amazon RDSS3 等の標準バックアップを利用
  • 監視・モニタリングサーバ構築 → CloudWatch などを利用
  • CI/CD サーバ構築 → AWS CodeBuild などを利用
  • Web サーバ構築 → PaaS を利用

料金・コスト

価格について

価格については「場合による」です。 単にサーバ費用だけみると、クラウドの方が高額になることも多々あります。 ただしインフラ構築ベンダが不要なので、その分が浮く。 さらにオンプレミスのような数年おきの EOL/EOSL 対応が不要なので、結果的にクラウドの方が安くなるというパターンは何度か見ました。

当ページ管理人の私見としては、オンプレミスより安くなるということはあまり期待せず、 似たような金額で開発期間の短縮・スモールスタートによるリスク軽減・スケールアップでの柔軟性・災害対策の容易性といった点を重視した方がよいのではと思います。

価格透明性について

クラウドサービスの Web ページにおいて料金はしっかりと記載されていますが、最終的な金額は読みづらいものです。 AWS移行で予算超過のリスク判明、ダイソーの回避策 では、AWS Lambda・DynamoDB などを組み合わせたシステムを設計・開発したものの、 いざ作ってみると年間数千万円のコスト超過が発生するという事例が紹介されています。

内部的な PaaS サービスの処理性能・リクエスト数・データ量などは大変読みづらいものですので、 あまりに理想的な見積もりを出すのは気をつけた方がよいのでしょう。 また、予測しづらいというリスクをあらかじめ経営層に伝え、最終試算や設計見直しフェーズを設けておくなど、 マネジメント面でも対策をとっておいた方がよいと思います。

また、クラウド破産 もご一読ください。

初期費用 について

ほとんどのクラウドサービスでは、初期費用は不要です。

「ほとんど」というのを詳しく説明すると、当ページ管理人が把握している限りでは、 初期費用が必要だったのは以前の AWS CloudHSM のv$5,000 のみで、 2018年現在では初期費用は不要となっています。よって、AWS・Azure・GCP においては、 初期費用のあるサービスは存在しないという認識です。

最低利用期間 について

一般的な最低利用期間はありませんが、 AWS のリザーブドインスタントなど前払い系であれば、リザーブドインスタンスを契約した期間中は請求が継続されます。

経費計上

オンプレミスで自社で購入する場合、サーバ機材などは資産化して 6年間減価償却をしていく必要があります。 また、最初に大きなお金が出ていくのでキャッシュフローに影響を与えます。

一方、クラウドサービスの場合 (ホスティングも同様ですが)、経費で落とせますので、 利益が出ているならば利益圧縮 (≒ 法人税節税) が可能です。 毎月使った分だけ支払いなので、キャッシュフローも安定します。

ただこの点は、「赤字なので利益圧縮できない」とか「BS をよく見せるためにあえて資産化したい」という状況であれば、 デメリットになりますね。

性能

マシン性能

CPU・メモリなどのマシン性能は、ハイエンドであれば、オンプレミスが優勢です。 2018/7 現在、AWS EC2 のベアメタルサーバ i3.metal の E5-2686 v4 2.30GHz 36コア (72論理コア) が 最速ではなかろうかと思うのですが、 オンプレミスであればマルチソケットでより多くのコア数に対応可能です (と思うけど、ハードウェアに詳しくないので自信を持って言い切れない)。

ストレージ性能

クラウドサービス当初は HDD しかなかったストレージですが、 2018/7 現在、AWS・Azure・GCP とも、ほぼ SSD が選択可能となっており、ストレージ速度は以前と比べると上がったと考えます。それでも例えば、Amazon EC2 から利用可能なストレージ Amazon EBS では、 予約可能な IOPS は最大 32,000 どまりです。 RAID0 化でさらに IOPS を上げることはできますが、それでもインスタンスあたりの上限は 80,000 IOPS だそうです。

一方、オンプレミスには NVMe 接続というマザーボード直刺し形態のフラッシュメモリがありますが、 2018/7 現在、SanDisk 社の NVMe SSD (は、ランダム Read で 250,000 IOPS、ランダム Write で 83,000 IOPS です。 (2010年頃、Fusion-IO 社の io-dirve が爆速だというブログ記事が流行りましたが、それを買収したのが SanDisk です)。これは複数枚接続が可能ですので、さらに IOPS アップも可能でしょう。

さらに、フラッシュメモリを山ほど積んだフラッシュストレージというものがあります。 各社のオールフラッシュ (All Flash) ストレージのIOPSまとめ にあるように、数十万〜数百万 IOPS のものまであります (測定方法が Read のみとか、Read/Write 混合とかあるので、単純比較はできません)。

よって、IOPS ではオンプレミスの圧勝と言えますが、これはある意味仕方がないことで、 EBS はネットワーク経由で HDD や SSD に読み書きしているので、ハードウェア直結のものより遅いのは当然です。 遅い代わりに、冗長性と可用性 (インスタンスが落ちても、他インスタンスから EBS を読み書きできる) が確保されています。なお、NVMe 接続フラッシュメモリで 100万円以上、フラッシュストレージは数百万〜数千万円しますので、価格も全然違います。

なお、AWS・Azure・GCP とも、NVMe 接続のフラッシュメモリはあるにはあるのですが、 インスタンスの停止で内容が消えてしまうとか、立ち上げた後は停止ができないなどの制限があり、 クラウドならではのデータ可搬性は実現できていません。

ネットワーク性能について

おそらくですが、クラウドサービスのデータセンタ内の接続は 10Gbps だろうと思います。 これは一般的なデータセンタでも同じでしょうから、ここには差がありません。

しかしオンプレミスの場合、Oracle RAC やフラッシュストレージ間のインターコネクトなど、 より高速な通信が必要な場合は Infiniband を使ってさらに高速化するという選択肢がありますが、 クラウドサービスでは 2018/7 現在利用はできませんので、オンプレミスの方が有利です (ただし Azure では GPU 間を Infiniband でつないでいるそうです)。

また、オンプレミスからクラウドに移行するにあたり、 Web サーバ・AP サーバなどはクラウドに移行するが、 個人情報を含む DB などをどうしてもオンプレミスに残しておきたい場合があります。 AP サーバ・オンプレミス間は通常はインターネットを経由するため、それなりの遅延は発生します。 遅延を小さくするために AWS Direct Connect などで専用線接続をすることは可能ですが、 その分費用はかさみます。

運用

インフラ障害対応 について

インフラ障害は、すべてクラウドサービス側で対応してくれます。 個々のマシンの CPU・メモリ・電源・HDD・SSD・ネットワークカード・スイッチ・ルータすべて面倒を見てくれます。 ただし「このインスタンスで HDD がクラッシュしたため交換しました」のような細かな障害情報は提供されません。 我々が知ることができるのは、「この時間にインスタンス再起動が起こったようだ」程度です。

ハードウェア EOL/EOSL にあわせた開発

EOL (End Of Life)・EOSL (End Of Service Life) は、製品のサポート終了を意味する用語です。 オンプレミス、特にハウジングなどでハードウェアを購入する場合最大の問題点は、 すべてのハードウェアに 5〜6年程度の EOL/EOSL が設定されていることだと当ページ管理人は考えます。 ベンダによっては 8年や 10年に延長可能な場合がありますが、保守料金がアップしたりします。 仮に 6年だと仮定すると、中規模〜大規模システムでは

  • 2年前から検討開始
  • 1年半前に発注
  • 1年3ヶ月前に納品
  • 1年前に設置・ネットワーク設定完了
  • 1年前〜3ヶ月前で試験実施

といったスケジュールになると、1年3ヶ月前に納品し、そこから保守期間がスタートしているわけですから、 実質的な残りサポート期間は 4年9ヶ月です。

世の中のシステムは、このタイミングにあわせてシステム更改を計画・実施する必要があります。

一方、クラウドサービスにおいては、このようなハードウェアに関する EOL/EOSL はありません。 よって、利用者はハードウェアの EOL/EOSL を意識する必要もありません。 これは大きなメリットです。

Amazon・マイクソフト・Google などの大規模クラウドサービスはそもそも自作ハードウェアを 使っているため外部ハードウェアベンダ起因の保守期限といったものはありませんし、 おそらくはパーツごとに寿命管理をして交換時期を計画しているでしょうし、 交換パーツも山のように準備しているはずです。 また、古い世代のサーバ、新しい世代のサーバは存在しますが、 仮に古い世代のサーバを削減したい場合は、新しいサーバに振り直せばよいだけですので、 古いハードウェアを維持管理する必然性もないのです。

セキュリティ

インフラセキュリティ・脆弱性対応

インフラに関するセキュリティ・脆弱性対応は、クラウドベンダに任せるのが一番よいと考えます。 例えば 2017年末〜2018年の Spectre (スペクター) ・Meltdown (メルトダウン) 対応において、 Google・AWS・マイクロソフトより早く対応できたベンダはあったかと言うと、ほぼなかったのではないかと思います。

また、Web サーバなどの脆弱性についても、Azure App ServiceGAE などの PaaS サービスを使う分には、 クラウドベンダにおまかせできますのですごく楽です (IaaS を立てて Apache や IIS を使っている場合は自前で対応する必要があります)。

WAF・アンチウィルスソフト について

これまでオンプレミスで様々なアンチウィルスソフトを使っていた場合、 それがクラウド上でそのまま実現できるかという点では、「難しい」と考えます。

また、WAF にういても、クラウドサービス各社が AWS WAFCloud Armor などの WAF 機能をリリースしてきていますが、まだ機能不足という状況と思います。

うっかりミスによる被害

うっかりミスによる被害としてありがちなのは、Amazon S3 などオブジェクトストレージにおいて、 公開状態にしてしまうことでしょう。 相次ぐAmazon S3の設定ミスによる情報漏えい事故 より引用すると、

  • 米Verizon、1400万人の顧客情報が誰でもアクセス出来る状態で公開
  • ダウジョーンズ、400万人の個人情報がアクセス可能な状態で公開
  • WWE、300万件の個人情報がアクセス可能な状態で公開

といった事故が S3 の公開設定ミスで発生しています。

オンプレミスでこのようなことが絶対に起きないとは言いませんが、 管理画面操作で簡単に操作できてしまうクラウドサービスでは事故が起きやすいと考えます。

拡張性

スケールアップ

スケールアップは、CPU を高速化したり、メモリを増やしたりして処理能力を増強することを指します。 クラウドサービスの得意なところで、管理画面からの操作で簡単にスケールアップができます。 ただし 2018/07 現在、CPU のコア数増加 (128 程度)、メモリ 2〜3TB 程度が上限で、 それ以上が必要な場合はオンプレミスのハイエンドマシンに軍配が上がります。

スケールアウト

スケールアウトは、サーバ台数を増やすことで処理能力を増強することを指します。 こちらもクラウドサービスが得意とする領域で、数百〜数千台程度であればさくっとインスタンス作成ができます。

ただし ELB では暖気運転が必要などという話もありますので、 テレビ番組での紹介による急激なアクセス増などは注意が必要です。

安定性

コスト安定性

クラウドサービスは、価格安定性はありません。 数は多くはないですが、当ページ管理人が把握している値上げは下記です。

  • AWS・Azure: Oracle が、承認済クラウド環境 (AWS・Azure) のコア係数 ×0.5 を撤廃し、 Oracle の必要ライセンス数が 2倍、コストも 2倍に。
  • Azure: 2015頃(?)、為替レート差異解消のため 日本で 10% 程度値上げ
  • Azure: 2018/1、為替レート差異解消のため 日本で 10% 値上げ
  • GCP: 2011年、Google AppEngine のコストを CPU 使用時間からインスタンス時間に変更し、サービスによって数倍〜10倍の実質値上げに

とはいえ各社ともクラウドシェアを必死に争っている状況ですので、値下げがトレンドです。 値上げはごくまれなケースと言ってよいでしょう。

当ページ管理人の予言ですが、将来的に 1社が独占した、あるいは数社にて寡占状態となりシェアの大きな変動はなさそう、 となった段階で、大幅値上げがあったり、無料期間の撤廃があると考えます。 クラウドサービスではありませが、Amazon プライム米国価格は当初 79ドルでしたが、今は 119ドル。33% 値上げされています。 クラウドサービスも間違いなくそうなるでしょう。

不意のシステムトラブル

オンプレミスと比較すると、クラウドでは、不意のシステムトラブルは起こりがちであると当ページ管理人は考えます。 理由は下記。

  • リリースしてから、それほど時間が経過していない
  • クラウド内部がどんどん更新されている
  • クラウド内部構成が複雑化している
  • 共用環境であるため、システムリソース逼迫による問題が起こりがち

DevOps が進み、テスト自動化と頻繁なデプロイが普通になりつつある現在であっても、 先人たちの「必要がなければ変えるな!」というのは、安定性最優先という観点では正しいと思います。 しかしながらクラウドサービスは、より便利に、より早く、より使いやすくするために、日々機能が追加されていますが、 内部のリファクタリングも日々行われています。その結果、 昨日動いていたものが今日は動かない (エラーになる、遅い) ということが、結構頻繁にあります。

ちなみに当ページ管理人が体験した実例としては、

uri = new URI("http://example.com/foo?a=b");
req = new HttpRequest(uri);
res = req.getResponse();
といったコードがあったのですが (あくまで例です)、ある日突然エラーが発生。理由はこのコードが不適切で、本当は
uri = new URI("http://example.com/foo");
req = new HttpRequest(uri);
req.setRequestParameter("a", "b");
res = req.getResponse();

と書くべきであった。これまではたまたま動いていたものが、 クラウドサービスの内部実装が変更になったため、ある日突然エラーとなった、 というものでした。 このようなケースは、オンプレミスでは起こりえないものです。

狭い範囲での可用性

クラウドサービス、特に PaaS においては、狭い範囲での可用性は低くなると当ページ管理人は考えます。 具体的には、API を叩いたり、サービスに接続シたりする場合、エラー発生率がオンプレミスと比較すると異常に高いと感じます。 推測ですが、PaaS は共用環境であるため、他ユーザからアクセスが殺到している場合、 一時的な利用制限がかかっていたり、ハードウェア故障が発生して別マシンに自動移行中、といったことに遭遇しやすいのではないかと考えます。

例えば Azure の SQL Server の PaaS サービスである SQL Database を利用する際、下記のように実装するよう推奨されています。

[SQL Database] アプリケーション作成における推奨事項について (Microsoft Azure SQL Database) より:

  • リトライ ロジックを実装し、接続切断や接続タイムアウトなどを検知時にリトライ処理を実施する
  • 接続タイムアウト値 (既定 15秒) を 30秒以上に設定する
  • リトライ処理の間隔は、10秒以上 (最低 5 秒以上) に設定する

また、1分間にN回以内といったレート制限が設けられてその制限に引っかかることもよくあります。 PaaS の場合、エラーは起こり得ると考え、メッセージング/キュー などを用いて再実行可能なように設計することをおすすめします。

前へ << クラウドサービスとは何か AWS・Azure・GCP クラウド比較 >> 次へ

ご意見・ご指摘は Twitter: @68user までお願いします。