クラウドの進化:ソーシャルメディアサービスエクスペリエンス

この記事についてCTO NovaPress Publisherに感謝します。 ロシアのスタートアップスタートアップコンペティションの優勝プロジェクト





みなさんこんにちは! 今日は、NovaPress Publisherサービスのアーキテクチャと、それをMicrosoft Azureクラウドに移行した経験についてお話します。



NovaPress Publisherは、企業がソーシャルネットワークで作業しやすくするWebサービスです。 これにより、数日または数か月前からソーシャルネットワーク上のコンテンツを計画できます。 また、会社のWebサイトに表示されるコンテンツを自動的に取得し、すべてのソーシャルネットワークに投稿します。



現在、このサービスは、雑誌、新聞、テレビチャンネル、商業および政府機関などの有名ブランドを含む9500社以上の企業で既に使用されています。











それがすべて始まった方法



私たちのサービスは2010年に登場しましたが、すぐにAzureと連携することはできませんでした。 サービスの最初の数年間は、さまざまなホスティングサービスが動作するように仮想マシンを使用しました。



私たちの仕事は、ソーシャルネットワーク上で1分間に数千のレコードを処理し、 遅滞なく投稿することでした



そして実際の問題は、仮想マシンの動作の定期的な中断でした。 それらは、キューが膨大な数の未公開のレコードを蓄積したか、ユーザーが作成したコンテンツが一時的に利用できなくなったという事実につながりました。



さらに、ピーク時にサービスの負荷が大きすぎたため、レコードの送信が遅れました。



当時、このサービスはソーシャルネットワークに毎分最大6000エントリを送信し、毎分最大1500のRSSフィードを同期することになっていた。 現在、これらの値は大幅に大きくなっています。



負荷は、特に00分と30分(たとえば、17:00、17:30、18:00など)の午前と夜間に最も高くなりました。











当時の決定は次のとおりです。







スケジュールされたタスク(ソーシャルネットワークでのコンテンツの公開)を実行するロボットは、ユーザーが生成したコンテンツと同様に、複数のサーバーで複製されます。 ユーザー数の増加に伴い、追加のサーバーを接続しました。



しかし、時間が経つにつれてスケーリングはより難しくなり、新しいボトルネックが開かれました。 さらに、ホスティングプロバイダーの定期的な混乱により、当社にとって重大な問題が発生しました。 また、サービスに新機能を導入する代わりに、増加した負荷に対処し、すべてにもかかわらず、サービスの高可用性とレコードの公開を遅延なく確保するために多くの時間を費やしました。



したがって、障害から保護し、負荷に応じて柔軟にスケーリングできる新しいソリューションを探し始めました。



最後に、2013年にAzureクラウドを選択しました。Azureクラウドでは、スケーリング、レプリケーション、負荷分散のオプションがすぐに利用でき、すぐに使用できました。



Azureへの移行



これは、Azureクラウドに切り替えた後のサービスのスキームでした。







ユーザーはWebサイト(Azure Webサイト、ASP.NET MVC)を介してサービスを操作し、データはAzure SQLデータベースとAzure Storageに保存されます。 データにすばやくアクセスするために、クラウド内のRedisキャッシュが使用されます。



すべての自動化(ソーシャルネットワークへの投稿、サイトまたは他のソーシャルネットワークからの投稿のコピー)は、多数のAzure VM仮想マシンでホストされるWindowsサービスによって実行されます。 これらのサービスは複数のスレッドで動作し、ServiceBusキューに到着するとタスクを実行します。 より多くのタスクがあり、負荷が増加する場合、仮想マシンの数を増やします。



さらに、ピーク時(18:00、18:30など)にサービスが再構成され(二次タスクを実行するロボットの数が自動的に削減され、ソーシャルネットワークに公開するロボットの数が増加します)、可能な限り迅速かつ遅延なくコンテンツをソーシャルネットワークに公開します。



移行プロセス



最も重要なものから始めて、いくつかの段階でAzureに移行しました。

  1. データベースの移行。 クラウドに移行する前に、SQL Serverデータベースを使用しました。 SQL ServerデータベースをAzureクラウドベースのSQLに移行するのは、専用のアプリケーションを使用すれば非常に簡単でした。 移行後、障害のない安定したデータベース操作が得られました。 (可用性レベル99.99%)。

  2. カスタムコンテンツを転送します。 クラウドに移行する前に、障害発生時の可用性を確保するために、複数のサーバーでユーザーコンテンツ(写真、テキスト)を複製しました。 ただし、多くのリソースとディスク容量が必要でした。 クラウドに移行する際、すべてのコンテンツを自動ジオレプリケーションでAzure Storageに転送しました(すべてのコンテンツは3つのAzureデータセンターで自動的に複製されます)。 可用性レベル:99.99%

  3. タスクキューをServiceBusに移動します。 以前は、タスクキュー(たとえば、公開する必要のあるレコード)はデータベースに関連付けられていました。 Azureへの移行後、サービスは完了する必要のあるすべてのタスクをServiceBusキューに送信します。 これにより、データベースから負荷の一部が取り除かれ、サービスのさらなるスケーリングの可能性が大幅に増加しました。

  4. Webサイトをクラウドに転送します。 サイトはAzure Webサイトに移動され、自動スケーリングがオンになったため、サイトは常に利用可能で、負荷をより適切に保持できます。

  5. クラウド内のRedisキャッシュ。 Redisを使用して、ソーシャルネットワーク上で可能な限り迅速に投稿が投稿されるようにします。 公開用に準備されたコンテンツとその公開設定はキャッシュに保存されるため、適切なタイミングで、できるだけ早くソーシャルネットワークにアクセスできます。 クラウド内のRedisは、すぐに使用可能な自動レプリケーションをすでに備えており、少なくとも99.99%の可用性を保証します。



さらなるステップ



2015年12月、 新しいベータ版をリリースし、サービスの内容を改善しました。



将来の計画では、次の改善が行われています。



得られた結果



Azureへの移行の結果、次のようになりました。








著者について



Artem Zhukovets-NovaPress Publisherのテクニカルディレクター



All Articles