AWSとAzure、性能と運用機能を比較する：PHP開発で使える2大クラウドを徹底検証（3）（3/3 ページ）
運用評価
■監視項目とアラート
インスタンスの監視項目としては、AWS、Azureともに、CPU使用率、ネットワークI/O、ディスクI/Oなど、基本的なものはどちらも同様に取得できます。
AWSでは、Amazon Management Consoleの各項目や、CloudWatchから、リソースの利用状況をグラフで見ることができます。
また、AWSでは、アラートを作成することで、特定のサーバのメトリクスが特定の値になったときに下記の処理を行うことができます。
- ユーザーにメールで通知
- Amazon SNSを利用して他のプログラムに通知して自動処理を実行
- Auto Scalingを利用してスケールアウト処理を実行
アラートに利用するメトリクスは、基本的に1サーバ、1項目ずつ設定する
必要があり、若干手間が掛かります。AWS SDKを利用すれば、プログラムからアラートを登録することもできるので、多数のサーバを管理する場合は、管理プログラムで自動化すると良いでしょう。第2回で紹介しましたが、Elastic Beanstalkを利用すれば、ロードバランサのスループットを監視して、スケールアウト処理を行うこともできます。
なお、Elastic Beanstalkは、以前はJavaにしか対応しておらず、PHPを動作させるためには、JavaによるPHP実装であるQuercusが必要でした。しかし、3月20日より正式にPHPに対応しました(【AWS発表】 AWS Elastic BeanstalkにてPHPのサポート開始、Gitを用いたデプロイも可能に:)。これで不安なく、PHPをElastic Beanstalkで利用きるようになります。
Azureでもリソース監視を行うことは可能ですが、メール通知やプログラムに通知しての自動処理を実行する機能は、PowerShellのスクリプトを自分で記述する必要があります。ログ情報はAzureのストレージサービスに格納されるため、Visual Studioやサードパーティ製のツール（Red Gate社の Azure Diagnostics Manager等が有名）を利用して、インスタンスを監視します。
オートスケーリング処理については、Windows Azure Autoscaling Application Block（WASABi）を利用することで対応が可能であり、他のログ等を監視した運用の自動化は、PowerShellを記述してスクリプトを自作することで対応が可能です。
AzureのWebロールでは、CPU使用率、ネットワークI/O、ディスクI/Oなどの他に、IISやVisual Studioでプロファイリングを行うためのログなど、AWSに比べ、PaaS寄りのログが取得できるようになっています。AWSがクラウドリソースとしての監視項目を主体として用意しているのに対して、AzureはWindows Serverの延長としての監視項目を提供していると言えるでしょう。また、AWSがCloudWatchで統一的なインターフェイスを提供しているのに対して、Azureは従来の資産であるVisual StudioやAzure Cmdlet（PowerShel のライブラリ）等を使い分けて運用監視を行う点も異なります。
監視項目については、AzureがWebサーバの情報を取得できるなど若干有利です。AWSの場合、Webサーバのログについてはユーザーが自前で収集する必要があります。ただし、オートスケーリングについては、AWSではAuto ScalingやElastic Load Balancingなどで条件を指定すれば、監視に基づき自動的にインスタンスを増減させることができるので、AWSの方が有利と言えるでしょう。
■ 課金状況の確認
AWSでは、課金状況を各サービス毎に確認することができます。また、インスタンスやストレージ毎のより細かなレポートも見ることができます。
Azureも、課金情報を確認することが可能です。契約したサブスクリプション毎に、AWSと同様に、利用したサービスごとにレポートを確認することが可能です。
課金情報の確認については、AWSとAzureのどちらもポータルサイトを用意しており、サービス単位で細かな課金情報を確認することが可能です。
障害への対応と可用性
■ データのバックアップ
AWSは、EBSでブートした仮想マシンイメージであれば、スナップショット機能を利用して簡単にバックアップを取ることができます。ただし、世代管理はしてくれないので、複数世代のバックアップを取る場合は、スナップショットを自分で管理する必要があります。 Amazon RDSであれば、指定した時間に定期的にバックアップを取ることができます。バックアップ期間は最大8日間保存可能で、バックアップ期間が来るまで各バックアップの世代管理は自動的で行われます。
Windows Azureでは、ストレージサービスとSQL Azureでバックアップの手法が異なります。Windows AzureストレージサービスのBLOBにはスナップショット機能が存在するため、世代管理されたバックアップが可能です。一方で、テーブルのバックアップを取得する場合はWindows Azure Cmdlets等を利用して別領域に保管する必要があります。SQL Azureのバックアップは、標準で提供されているインポート／エクスポートを利用する方法のほか、SQL Azure Data Syncを利用して異なるデータセンタにデータをバックアップする方法が考えられます。これらは全て手動で行う必要があるため、バックアップを自動化するにはPowerShellのスクリプトを記述する必要があります。
■ 障害時の対応
AWSは、Amazon RDSを利用すれば、データベースに障害が発生した場合でもフェーズオーバできます。RDSによるデータベースのインスタンスは異なるデータセンターにデプロイされるため、災害発生時の対策も万全で、大地震によりデータセンター全体が停止した場合でも別のデータセンターでフェールオーバすることができます。 ただし、EC2インスタンス上でMySQLを動かす場合は、クラウドユーザーが自分でフェールオーバの仕組みを構築する必要があります。
Windows Azureコンピュートサービスは、自動でフェールオーバを行い、Windows Azure Traffic Managerを利用することで、データセンタをまたいだ障害時の負荷分散も可能です。Windows Azureのストレージサービスに保存されたデータは、特に設定をしなくとも異なるデータセンタ間で冗長化され、データが保存されます。 また、AWSと同様の考慮点として、コンピュートサービス上のみでMySQL等のRDBを動かす場合は、クラウドユーザーが自分でフェールオーバの仕組みを構築する必要があります（今回の条件下では、MySQLのデータはドライブに保存されていますが、コンピュートサービスのみを利用してMySQLを動作させる場合、データの永続化に注意が必要です）。
■ SLA
バックアップやフェールオーバでサービスの障害を回避できても、そもそも、クラウド自体の稼働率が低いと意味がありません。ここで、各クラウドがどの程度のSLAを保証しているのかが気になってきますが、AWSとAzureのSLAは次のように定義されています。
| 対象 | SLA（％） | |
|---|---|---|
| AWS | EC2 | 99.95（*1） |
| S3 | 99.9（*2） | |
| RDS | - | |
| Azure | ネットワーク | 99.95（*3） |
| インスタンス | 99.95（*3） | |
| ストレージ | 99.9（*3） | |
| SQL Azure | 99.9（*3） | |
| 表3 AWSとAzure、主要サービスのSLA（稼働率） *1: http://aws.amazon.com/jp/ec2-sla/ *2: http://aws.amazon.com/jp/s3-sla/ *3: http://www.microsoft.com/japan/windowsazure/sla/ | ||
なお、サービスの稼働率が上記のSLA以下の場合でも、サービス障害による損害を補償してもらえるわけではありません。サービスに障害が発生した場合、SLA以下の稼働率となった分の支払いを割り引くスタイルとなっているので、注意してください。
さて、AWSとAzureを比較していくと、インスタンスについては、両者とも99.95％になっています。ただし、Windows AzureでインスタンスのSLAを99.95％にするためには、1つのサービスに対して、仮想マシンを2個以上にする必要があります。このため、インスタンスのSLAについてはAWSの方が有利になります。ただし、Azureのネットワークについては99.95％と、AWSと同等のSLAを出してきています。 ストレージサービスは、Amazon S3とSQL Azureで同じSLAですが、Amazon RDSについては、まだパブリックベータのためかSLAは定められていません。SimpleDBとDynamoDBも同様です。
インスタンスについては、2台以上のインスタンスを利用する場合は互角、データベースについてはAzureの勝利と、Azureの方が有利そうです。データベースについては、AWSはベータサービスが多いのが痛いところです。
■ セキュリティ標準の認定状況
クラウド上には、多数の企業、ユーザーのデータが混在しています。ひょっとしたら、他人にクラウド上のデータを覗き見されるかもしれません。また、システム的なセキュリティはきちんと実装されていても、運用上の脆弱性をついてデータが漏えいする可能性もあります。セキュリティの担保を保証する目安として、セキュリティ標準の認定や法規制などへの対応状況が参考になります。
AWSとAzureのセキュリティ標準・法規制への対応状況は、次のとおりです。
| 認証 | AWS | Azure | 概要 |
|---|---|---|---|
| SOC | SOC1 | - | 企業の財務諸表に影響する情報が委託会社にないこと、財務諸表を監査する監査人によって検証している。 |
| FISMA | ○ | - | 米国の連邦情報セキュリティマネジメント法：the Federal Information Security Management Act）への準拠。各連邦政府機関とその外部委託先に対して義務付けている。 |
| PCI DSS | レベル1 | - | JCB、アメリカンエキスプレス、Discover、マスターカード、VISAの国際ペイメントブランド5社が共同で策定した、クレジット業界におけるグローバルなセキュリティ基準。 |
| ISO 27001 | ○ | ○ | 組織内の機密情報を漏洩させないことを目的とした社内体制を整備するための国際規格。 |
| HIPAA | ○ | - | 米国連邦政府による医療保険の相互運用性と説明責任に関する法律への準拠。 |
| FIPS 140-2 | ○* | - | 暗号モジュールに関するセキュリティ要件の仕様を規定する米国連邦標準規格。 |
| 武器規制国際交渉規則へのコンプライアンス | ○* | - | 米国国際武器取引規則法による武器の輸出規制へのコンプライアンス。 |
| 表4 AWSとAzureのセキュリティ関連標準・法規制への対応状況 *: FIPS 140-2と武器規制は、AWS米国リージョンのGovCloudのみ利用可能 | |||
歴史が長いせいか、AWSの方が多くの標準や規制に対応しています。Azureが現在対応しているのはISO 27001のみですが、他の標準についても対応の予定とされています。セキュリティ標準認定の状況については、AWSの圧勝といえそうです。
さて、3回にわたってAWSとAzureについて徹底比較してきましたが、いかがだったでしょうか？ クラウドの機能・価格は日進月歩なので、読者が本稿を読んでいるタイミングによっては、情報が時代遅れになっているかもしれません。また、クラウド上で構築するアプリケーションやシステムによっては、評価結果は異なると思います。
AWSとAzure比較の連載なので、最後に比較の結論を出したいところですが、本連載を初回から改めて眺めてみると、ある側面では一方が優れており、別の側面では他方が優れているという感じです。敢えてここでは結論は出さずに、読者の判断に委ねたいと思います。 どちらのクラウドを利用するか、それを決めるのは、あなたです。
補足：AWS、Azureインスタンス料金表
| 40%インスタンス | 料金（ドル） |
|---|---|
| t1.micro | 0.020 |
| m1.small | 0.080 |
| m1.medium | 0.160 |
| m1.large | 0.320 |
| m1.xlarge | 0.640 |
| m2.xlarge | 0.450 |
| m2.2xlarge | 0.900 |
| m2.4xlarge | 10800 |
| c1.xlarge | 0.660 |
| Amazon EC2インスタンス料金表 http://aws.amazon.com/jp/ec2/pricing/ | |
| 40%インスタンス | 料金（円） |
|---|---|
| Extra Small | 1.75 |
| Small | 10.49 |
| Medium | 20.98 |
| Large | 41.96 |
| Extra Large | 83.92 |
| Azureインスタンス料金表（3月上旬に価格変更） https://www.windowsazure.com/ja-jp/pricing/details/ | |
Copyright © ITmedia, Inc. All Rights Reserved.
注目のテーマ
ITmediaはアイティメディア株式会社の登録商標です。