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

  • このエントリーをはてなブックマークに追加

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

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

クラウドサービスのメリット・デメリットを一覧にまとめました。

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

開発

導入スピードについて

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

一方、オンプレミスのシステム導入において、特にハードウェアの導入は以下のような感じです。

  • 提案依頼書 (RFP) を書く
  • 提案依頼書をハードベンダにばらまく
  • 説明会を実施する
  • ハードベンダからの提案書を受けとる
  • 提案書を比較検討し、さらに詳細条件を確認する
  • 最終的な見積提示をしてもらう
  • 契約を締結する
  • ハードウェア搬入を行う
  • ラックにマウントし、ネットワークを結線する
  • 試験を行う

そして「海外からの出荷なので 1ヶ月待ちです」なんて言われたり、初期不良で返品となり代替品の到着を待つのに数週間も必要だったり。

大規模システムでは、クラウドサービス化により数ヶ月や1年間の期間短縮が可能です。これは全く大げさな話ではありません。事実です。

検証容易性について

上記の導入スピードとも関係しますが、画面操作だけで設定が可能なので、「まずは試してみよう」ができてしまいます。

オンプレミスのシステムからクラウドへの移行の際、固い組織だと「まずはクラウドサービスの選定プロセス検討から始めないと!」となったりします。そういうやり方も否定はしませんが、ちょっと優秀な技術者に 10日くらい与えてみると、「それなりに動くようになりました」となることも多いでしょう。

特に自社サービスであれば、検討・計画をすっとばして、まずは試してみるというのは十分ありえる選択肢です。

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

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

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

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

料金・コスト

価格について

価格については「場合による」です。オンプレミスから EC2 などの仮想マシンへの単純な移行であれば、クラウドの方が高額になることも多々あります。ただしインフラ構築ベンダの作業量が減る、あるいはアプリ開発ベンダがインフラ構築も担当できることもあるので、その分は浮きます。さらにオンプレミスのような数年おきの EOL/EOSL 対応が不要なので、結果的にクラウドの方が安くなるというパターンは何度か見ました。

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

価格透明性について

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

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

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

初期費用 について

ほとんどのクラウドサービスでは、初期費用は不要です。「ほとんど」というのは、初期費用が必要なクラウドサービスも存在していたからです。

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

最低利用期間 について

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

経費計上

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

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

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

性能

マシン性能

CPU・メモリなどのマシン性能は、ハイエンドであれば、オンプレミスが優勢です。2019/3 現在、AWS EC2 のベアメタルサーバ m5.metal などの Xeon Platinum 8175 の 48コア (96論理コア) が 最速ではなかろうかと思うのですが、オンプレミスであればマルチソケットでより多くのコア数に対応可能です。

ストレージ性能

クラウドサービス当初は HDD しかなかったストレージですが、2018/7 現在、AWS・Azure・GCP とも、ほぼ SSD が選択可能となっており、ストレージ速度は以前と比べると上がったと考えます。それでも例えば、Amazon EC2 から利用可能なストレージ Amazon EBS では、予約可能な IOPS は最大 64,000 どまりです (2018年11月、最大IOPSが 32,000から64,000に引き上げられました)。

一方、オンプレミスには 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 を使ってさらに高速化するという選択肢があります。一方 AWS・Azure・GCP いずれも 2019/3 現在Infiniband の利用はできませんので、オンプレミスの方が有利です (ただし Azure では GPU 間を Infiniband でつないでいるそうです。ちなみに IBM Cloud では 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 Service や GAE などの PaaS サービスを使う分には、クラウドベンダにおまかせできますのですごく楽です (IaaS を立てて Apache や IIS を使っている場合は自前で対応する必要があります)。

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

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

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

なお、AWS・Azure・GCP いずれも、Marketplace から WAF やアンチウィルス等のソリューションを起動することができますが、これを使う場合接続先が EC2 や Azure Virtual Machine・GCE などの IaaS ソリューション限定になりがちであるという欠点があります。

うっかりミスによる被害

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

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

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

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

拡張性

スケールアップ

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

スケールアウト

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

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

安定性

料金・コスト安定性

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

  • AWS・Azure: 2017年、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 サービスで起こりがちなのですが、これまでは 0.1 秒で処理できていたものが、いきなり数倍の時間がかかって遅くなることがあります。原因としては、クラウド事業者側でのバージョンアップによるエンバグ、クラウド事業者側でのリソース制限の追加、などが上げられます。

しばらくしたら直ることもありますし (クラウド事業者側で気づいたか、他の利用者からサポートへのクレームがあったものと推測されます)、サポートへ連絡すると「バグであることが判明したのでただいまからロールバック (切り戻し) を行います」ということもあります。

「 クラウド事業者側でのバージョンアップによるエンバグ 」の実例は、BigQuery でスローダウンしたことがあります。ロールバック完了まで 2~3日かかりました。

「 クラウド事業者側でのリソース制限の追加」の実例としては、Azure Table Storage で「あるアクセス方法を1分あたりN回行うと、ペナルティとして一定期間スローダウンする」というのがありました。なお、ドキュメントには「このようなアクセス方法は推奨されません」とありましたので確かによくないアクセス方法ではあるのですが、ペナルティがあるとは一言も書いてありませんでした。現時点でもその記載はないように見えますが、そのペナルティが継続しているのかは不明です。

狭い範囲での可用性

クラウドサービス、特に PaaS においては、狭い範囲での可用性は低くなると当ページ管理人は考えます。具体的には、API を叩いたり、サービスに接続したりする場合、エラー発生率がオンプレミスと比較すると明確に高いと感じます。

推測ですが、PaaS は共用環境であるため、他ユーザからアクセスが殺到している場合、一時的な利用制限がかかっていたり、ハードウェア故障が発生して別マシンに自動移行中、といったことに遭遇しやすいのではないかと考えます。

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

SQL Database の接続に関する問題と一時的なエラーに対応する より:

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

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

SDK バージョンアップ・仕様変更

クラウドサービスの各機能は、おおむね API が用意されています。例えば Amazon S3 には S3 を操作するための API があります (API ドキュメントは こちら)。このような API は http や https 経由でアクセスすることが多いのですが、普通は開発効率アップのために SDK (開発キット) が用意されています。

このような SDK には残念ながらサポート期限または使用期限があり、未来永劫使えるものではありません。SDK の期限は下記のように公開されています。

  • Azure SDK の場合:Support and Retirement Information for the Azure SDK for .NET and APIs
    • 例えば 2016/03/30 にリリースされた Azure SDK 2.9 は、2019/07/01 にてサポート期限切れとなることがわかります。なお、この例ではサポート期限切れになるだけで、即使えなくなるわけではありませんが、期限切れになるといつエラーになってもおかしくない状況になります。
  • GCP の Dataflow の場合:SDKバージョンのサポート状況
    • 例えば 2018/01/30 リリースの SDK 2.3.0 は、2019/01/30 に非推奨 (=サポート期限切れ) となり、2019/03/25 に動かなくなることがわかります (と言っても、書き方がわかりづらいのでぱっと見ではわからないと思います)。

なお、期限切れとなる場合、エンジニアが泣きながら SDK バージョンアップ作業を行うのですが,その作業がどれくらい大変かはその時の状況次第です。「バージョン表記だけ変えればするっと動く」ケースもありますし、「大改修でテストもほぼやり直し」ということもあります。また、「バージョンアップするとビルドが通らず数千行エラーになったけれど修正パターンは数パターンしかなく、地道になおしていけば1日作業」ということもあります。

オンプレミスの場合、サポート期限切れというのはあり得る話ですが、ある日をもって動かなくなるということは起こりえませんので、これはクラウドサービスの PaaS 系のデメリットと言えるでしょう。ただし、「サポート範囲を狭くすることでテスト範囲を限定して開発スピードを上げる」ことが目的でしょうから、一概にクラウドがダメとは言いません。


  • このエントリーをはてなブックマークに追加

SNSでもご購読できます。

Leave a Reply

*

CAPTCHA