主要クラウド事業者を比較する――AWS、Azure、Google Cloudなど
AWS、Azure、Google Cloud、Alibaba Cloud、Tencent Cloudを、動かしたいシステム、費用の総額、運用の手間、移行のしやすさから比較するための考え方を紹介します。

まず、どのような処理を動かす必要があるかを考えましょう。運用の手間、費用、別の事業者へ移る手段を比べてから、どこで動かすかを選びます。
ある小規模な企業が、商品の写真と顧客の注文一覧を扱うウェブサイトをつくりたいとします。必要なのは、アプリケーションを動かす場所、画像ファイルを保存する場所、注文を検索・更新できるデータベースです。まずは、この三つの仕事から考えましょう。市場シェアの一覧を見るよりも、クラウド事業者をずっと比較しやすくなります。
名前は違っても、役割は理解できる
仮想マシンは、遠隔から設定し、動かすコンピューターです。オブジェクトストレージは、画像などのファイルを保存します。マネージド型リレーショナルデータベースは、構造化されたレコードを保存し、運用作業の一部を事業者が担います。以下は各事業者の製品一覧から挙げた例であり、同一の製品でも、順位付けでもありません。
|
事業者 |
仮想マシン |
オブジェクトストレージ |
マネージド型リレーショナルデータベース |
|---|---|---|---|
|
AWS |
Amazon EC2 |
Amazon S3 |
Amazon RDS |
|
Microsoft Azure |
Azure Virtual Machines |
Azure Blob Storage |
Azure Database for PostgreSQL |
|
Google Cloud |
Compute Engine |
Cloud Storage |
Cloud SQL |
|
Alibaba Cloud |
Elastic Compute Service (ECS) |
Object Storage Service (OSS) |
ApsaraDB RDS |
|
Tencent Cloud |
Cloud Virtual Machine (CVM) |
Cloud Object Storage (COS) |
TencentDB for MySQL |
製品名と分類は、Googleによるクラウド事業者間のサービス比較、AlibabaのRDS概要、Tencentの製品一覧に基づいています。データベースエンジン、選べる構成、対応機能はそれぞれ異なります。PostgreSQLを使うアプリケーションを、MySQLのサービスにそのまま置き換えることはできません。
チームが実際に担う作業を比較する
先ほどのウェブサイトなら、仮想マシンを借りて、アプリケーションとデータベースを自分たちでインストールする方法があります。別の方法は、マネージド型データベースとアプリケーションのホスティングサービスを使うことです。後者なら運用作業を減らせますが、それでも設定、アクセス、復旧、そしてアプリケーションが依存する機能について理解しておく必要があります。
まず、今あるシステムから確認しましょう。どのデータベースエンジンを使っているでしょうか。どのようにデプロイしているでしょうか。チームが保守できるツールは何でしょうか。使い慣れた構成なら作業を減らせます。一方、慣れていないサービスでも、具体的な問題を解決できるなら使う価値があります。その利点を明確にしましょう。
次に、アプリケーションを利用できる必要がある地域を選びます。ユーザーが実際に接続する場所から応答時間を測り、必要なサービスと機能を、選んだリージョンでまとめて利用できるか確認しましょう。事業者が世界中に持つリージョンの数だけでは、このどちらも分かりません。
一か月に必要な費用をすべて見積もる
各候補を同じ前提で比べます。想定するアクセス数、計算資源の稼働時間、保存するファイル、データベースの容量、バックアップ、ユーザーへ送信するデータ量を揃えましょう。チームにサポートが必要なら、その費用も含めます。安価な仮想マシンは、見積もりの一項目にすぎません。
たとえば、AWS Pricing Calculatorのガイドでは、リージョン、サービス、利用量の想定から見積もりを作成し、サポートも追加できます。見積もりは、そうした入力条件に基づくものであり、請求額を保証するものではありません。同じ条件で比較できるよう、金額と一緒に前提条件も残しておきましょう。
写真が多いサイトでは、小規模な社内フォームの場合よりも、閲覧者への画像送信が費用を大きく左右することがあります。迅速な復旧が必要なシステムでは、追加のデータベース処理能力や復旧体制も重要です。どんな場合でも最安になる事業者を探すのではなく、自分たちの利用の仕方で試しましょう。
採用を決める前に、移り直す手順も試す
候補を絞ったら、それぞれで同じアプリケーションの小規模版を動かします。サンプルの写真をアップロードし、テスト用の注文を作成し、レコードをエクスポートして、別のテスト環境に復元します。事業者固有のサービスをどう置き換えるかも確認しましょう。ファイルのコピーは、アプリケーションの移行に必要な作業の一部にすぎません。
記録するのは三つです。動かせるようになるまでにどれだけの作業が必要だったか。同じ利用量の想定で、いくらかかるか。移行や復旧には何が必要か。試行がうまくいけば、小さなチームにとって、ブランドのランキング順位よりも確かな選択の根拠になります。
目的に沿って選ぶ
独立性を示すためだけに、複数のクラウドにまたがる構成をつくる必要はありません。十分に理解した一つのサービスから始めるのが、最も現実的な場合もあります。大切なのは、どの責任を外部に委ねたのか、別の構成へ移ることが今後も実行可能なのかを把握しておくことです。
クラウドのサービスモデルでは、この役割分担を説明しています。続くエッジコンピューティングとクラウドコンピューティングでは、それぞれの処理をどこで行うべきかを考えます。マシンを複数の場所に分散することと、意思決定の権限を分散することは、別の問題です。適切なインフラの選択は、その両方を見えやすくします。