AWSとAzure、性能と運用機能を比較する：PHP開発で使える2大クラウドを徹底検証（3）（3/3 ページ）

運用評価

■監視項目とアラート

　 インスタンスの監視項目としては、AWS、Azureともに、CPU使用率、ネットワークI/O、ディスクI/Oなど、基本的なものはどちらも同様に取得できます。

　AWSでは、Amazon Management Consoleの各項目や、CloudWatchから、リソースの利用状況をグラフで見ることができます。

図4　AWSのリソース監視(EC2インスタンスの場合)（クリックで拡大）

　また、AWSでは、アラートを作成することで、特定のサーバのメトリクスが特定の値になったときに下記の処理を行うことができます。

　アラートに利用するメトリクスは、基本的に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等が有名）を利用して、インスタンスを監視します。

図5　Visual Studioを利用したAzureのリソース監視（クリックで拡大）

　オートスケーリング処理については、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では、課金状況を各サービス毎に確認することができます。また、インスタンスやストレージ毎のより細かなレポートも見ることができます。

図6　AWSでの課金状況の確認（クリックで拡大）

　Azureも、課金情報を確認することが可能です。契約したサブスクリプション毎に、AWSと同様に、利用したサービスごとにレポートを確認することが可能です。

図7　Azureの課金状況の確認（クリックで拡大）

　課金情報の確認については、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以下の場合でも、サービス障害による損害を補償してもらえるわけではありません。サービスに障害が発生した場合、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が現在対応しているのはISO 27001のみですが、他の標準についても対応の予定とされています。セキュリティ標準認定の状況については、AWSの圧勝といえそうです。

　さて、3回にわたってAWSとAzureについて徹底比較してきましたが、いかがだったでしょうか？ クラウドの機能・価格は日進月歩なので、読者が本稿を読んでいるタイミングによっては、情報が時代遅れになっているかもしれません。また、クラウド上で構築するアプリケーションやシステムによっては、評価結果は異なると思います。

　AWSとAzure比較の連載なので、最後に比較の結論を出したいところですが、本連載を初回から改めて眺めてみると、ある側面では一方が優れており、別の側面では他方が優れているという感じです。敢えてここでは結論は出さずに、読者の判断に委ねたいと思います。 どちらのクラウドを利用するか、それを決めるのは、あなたです。

補足：AWS、Azureインスタンス料金表