今日、Microsoft Azureを使用してCloudStats.meサーバーとサイト監視システムのスケーラビリティと復元力を確保した経験を共有したいと考えています。
アクセラレータIIDFの6番目のセットで作業を開始し、Microsoft Azureリソースの使用許可を受け取る前に、ほとんどのプラットフォームは、 SolusVMパネルを使用してOpenVZ仮想マシンに分割された通常の専用サーバーで動作しました。
最初に、2つのIntel Xeon E5 2620v3、128 GB RAM、2つの500 GB SSD、H / W RAID1の構成でいくつかのOnline.net、Redstation、およびOVHサーバーを使用しました。これらのディスクシステムは、テストによると最大15,000 IOPSを提供します。 統計収集プラットフォームでは、大量の着信データを処理し、データベースに操作を書き込む必要があるため、ディスクシステムのパフォーマンスは特に重要です。
前に書いたように、無料のHaProxyロードバランサーとApache TomcatおよびMySQL MariaDB MySQLクラスターを使用して、サーバーに負荷を分散しました。 一方では、専用サーバーが必要なパフォーマンスを提供しましたが、他方では、リソースの個別の監視が必要であり、データセンター側に別のバランサーがないためにフォールトトレランスを許可しませんでした。これにより、ロードバランサーが落ちたときにシステムがクラッシュする可能性がありました。
アクセラレータとBizSparkプログラムのフレームワーク内でマイクロソフトの専門家と協力して、Azureの機能をテストし、データウェアハウスを2つのタイプ-SQL（MariaDB Cluster）とNoSQL（DocumentDB）に分割しました。
それで、何が行われましたか？
まず、Azureで仮想マシンのディスクシステムをテストしました。 仕様によると、標準のA0〜A7仮想マシンは、VMあたり約500 IOPSというかなり低いIOPSを持っています。 これは、専用サーバーにある通常のVPSとは異なり、仮想マシンがリモートネットワークストレージを使用するためです。
ただし、仮想マシンのIOPSの数を増やすためのいくつかのオプションがあり、RAIDおよびここにある追加の設定を使用します 。 RAID0を使用すると、IOPSの数が実際に増加することに注意してください。RAID0で4つのディスクを組み合わせることで、約2000〜3000 IOPSを達成できました。
これで十分でない場合は、ローカルSSDストレージを備えた「DS」などの仮想マシンを使用できます。また、より多くのリソースを提供するプレミアムドライブ（SSD）を接続できます（ リンク ）。
可用性セット/自動スケーリング/負荷分散
ディスクシステムの機能にもかかわらず、Azureは非常に柔軟な構成オプションを提供して、アプリケーションの復元力（可用性セット）とスケーラビリティ（自動スケーリング）を保証します。
頻繁に発生する技術的な作業やMicrosoft Azureシステムの更新中にサービス拒否を回避するために、すべてのシステムコンポーネントを複製して可用性セットに追加する必要があると警告されました。 技術的な作業により、特定の期間中に仮想マシンが誤って再起動され、アクセスできなくなる可能性があります。
仮想マシンのコピーを作成して可用性セットと自動スケーリングに追加する場合、それらをオフにして保存できることに注意してください。 Stopped（Deallocated）ステータスのマシンは支払いできません（ストレージを除く）。
さらに、Azureには、たとえばNginx / Apacheに負荷を分散するために、フロントエンド仮想マシンで簡単に使用できるロードバランサーがあります。 ただし、データベース（MariaDBなど）の負荷を分散するには、このバランサーは適切ではありません。 MySQLクラスターでは、データベースを使用してサーバーのステータスを監視する必要がありますが、Azureロードバランサーではまだ実行できません。 MySQLの場合、 HaProxyまたはMaxScaleの方が優れています （MariaDBは提供されていますが、ステータスを追跡するためのグラフィカルインターフェイスはありません）。
DocumentDBとMongoDB
Microsoftのストレステストラボでの作業の一環として、アプリケーションデータベースの円滑な運用を確保することが課題となりました。 当時は、MySQL MariadbクラスターとHaProxyロードバランサーのみを使用していましたが、これにより、クラスターが非同期になり、クラスターに新しいサーバーを手動で追加する必要があるため、必要な耐障害性を提供できませんでした。
なぜなら 使用されたスキームが最適ではなかったため、データウェアハウスをSQL（MariaDB）とNoSQLの2つのタイプに分けることにしました。 ユーザーアカウント、支払いデータなどのユーザーデータに引き続きMySQLを使用し、NoSQLストレージの監視サーバーに統計データと履歴データを割り当てて、メインデータベースをアンロードすることにしました。
NoDocumentストレージのバリアントとしてAzure DocumentDBとMongoDBをテストしました。 現時点では、DocumentDBにはRubyアプリケーションのサポートが組み込まれていないため、基本的なodmラッパーでJavaライブラリを使用しました（オンデマンドで使用できます）。 なぜなら DocumentDBはDBaaSソリューションです。その利点は、仮想マシン自体で手動で構成する必要があるMongoDBとは異なり、サーバーサポートに時間と労力を費やす必要がないことです。 一方、データセンターを変更する必要がある場合、MongoDBを使用すると、サービスインフラストラクチャを簡単に移行できます。
現時点では、DocumentDBに決定しましたが、CouchDB（便利なコントロールパネルがあります）とMongoDBのソリューションを引き続きテストしています。
Microsoft Azureプラットフォームを使用する際の注意事項：
- Azure仮想マシンには非常に厳しいIOPS制限がありますが、それでもRAID0と追加のシステムチューニングで増やすことができます
- 仮想マシンを可用性セットに追加して、Microsoftデータセンターでの技術作業中のダウンタイムや偶発的な再起動を回避する必要があります。
- Auto-Scalingを使用すると、必要な場合にのみ仮想マシンを実行してお金を節約できます
- 仮想マシンの起動には最大数分かかります。これは、Auto-Scalingパラメーターを構成する際に考慮する必要があります。
- 各Azureサブスクリプションは、5つの予約済みパブリックIPアドレスのみにアクセスできます
- アプリケーションコードを最適化してクラウドコストを削減することをお勧めします
- Azureロードバランサーは、フロントエンドのNginx / Apache仮想マシンに簡単に使用できますが、データベースの負荷分散には適していません
- Azureを使用する場合、デフォルトでは利用できないテクニカルサポートパッケージを個別に購入することをお勧めします
- ICMP（ping）はAzureでブロックされ、仮想マシンにpingすることはできません。 telnetまたはpspingを使用して、ポートが開いているか閉じているかを判断します。
その結果、何が得られましたか？
Azureに組み込まれたロードバランサーであるNginx / Tomcat、および可用性セットと自動スケーリングを備えたフロントエンドの仮想マシンを使用して、アプリケーションのフォールトトレランスを確保することができました。 データウェアハウスをSQLとNoSQLに分割して、データベースの負荷を分散しました。 MongoDBの場合のように、DocumentDBを長期的に使用すると、サーバーの構成、監視、および保守のコストが削減されることを願っています。
また、Azureリソースのおかげで、無料アカウントの制限を軽減し、100台のサーバー、100個のWebサイト、100個のIPアドレスを完全に無料で監視できるようになりました。 ここで試してみることができます 。
近い将来、CloudStatsプラットフォームを更新し、New Relicモデルを使用してアプリケーション監視を追加しますが、これについては次の記事で詳しく説明します。
2015年7月のCloudStats.meサービスアーキテクチャ 