コンデナストトラベラーマルチメディアプロジェクトのウェブサイトとモバイルアプリケーションがAmazon 1C-Bitrixウェブクラスターで公開

こんにちは、同僚!



CondéNast Digital Russiaは、旅行者向けのCondéNast Travelerマルチメディアプロジェクトを開始しました。これは、 印刷版デジタル版ウェブサイトモバイルアプリケーションを組み合わせたものです 。 プロジェクトは2011年9月21日に開始されました。 Webベースとして、1C-Bitrix製品は、推奨されるAmazonクラウドに基づいて、ホスティングプラットフォームとしてWebクラスタープラットフォームに選ばれました。



ウェブサイトwww.cntraveller.ruには旅行に関する記事が含まれており、最も重要なことは、ホテル、レストラン、世界のさまざまな国のエンターテイメントの場所に関する情報をすばやく見つけ、サイトに独自のオブジェクト、写真、レビューを追加し、将来の旅行のガイドを作成できるようにすることです。 オブジェクトに関するすべてのデータは、 コンデナストトラベラー-My Addresses iPhoneアプリケーションでも使用されます。このアプリケーションを使用すると、旅行ルートを作成できるだけでなく、地図上の場所を特定し、雑誌の編集スタッフとWebサイト訪問者が推奨する最寄りの住所を確認できます。



一般的に、このプロジェクトはユニークで大規模で興味深いものです-1つの段落では説明しませんが、興味がある場合は自分で確認してください。 そして、私たちの目標は、プロジェクトの「内部」を見ることです。

そのため、ソリューションのアーキテクチャと信頼性を批判的に評価します。 使用されているクラウドホスティングとBitrix クラスタリングテクノロジーの長所と短所を比較検討します











高負荷のボックスごとのアーキテクチャ





統計はクラウドに取り出され、Cloud Storageモジュールの機能使用してCDN(CloudFront)から配信されます 。 もちろん、たとえばs3fsなどのFUSEモジュールを使用してファイルの作業を整理できますが、プラットフォームの組み込みツールを使用してクラウド内部「情報ツリー」を配置する方が簡単です。



通常のMySQLマスタースレーブレプリケーションが使用されますが、負荷分散はBitrixプラットフォームのコアによって実行されるため、気にしない既存のアプリケーションに変更を加える必要はありません(1つのデータベースまたはマスター+ 20スレーブ)。



memcachedクラスター化キャッシュがBitrixクラスタープラットフォームに組み込まれているのがわかります。これは、ノードのいずれかで障害が発生したときに機能し、「古い」データを自動的に押し出します。 これは特に、大量のキャッシュファイルが作成される(エラーが原因で発生する)大規模で負荷の大きいプロジェクトに当てはまります。このようなキャッシュをファイルシステムに格納する場合、そのサイズを常に監視し、古いデータを定期的に消去する必要があります。



「垂直分割」方式を使用してWebサービスを使用してシステムにアクセスする訪問者およびプロジェクトの外部アプリケーションによって集中的に使用される検索インデックスは、管理パネルのウィザードを介して別のサーバーに転送されます。 検索サービスの使用の強度が増すと、数分以内に( Amazon APIを介して )より「強力な」ハードウェアでマシンを再起動することができます。



負荷が増加すると、「サーバー2」は自動的に接続し、アプリケーションサーバーとして使用できます。



信頼性





プロジェクトマシンのバックアップは、 S3EBSディスクのスナップショットで作成されます 。 航空機または弾道ミサイルがデータセンター(アベイラビリティゾーン)に当たった場合、ディスクを備えたマシンを数分で別のデータセンター(アベイラビリティゾーン)で拾うことができます。 スナップショットは、自動統合により増分として保存されるため、少なくとも10分ごとに実行できます。 EBSディスクのスナップショットを作成してデータベースをバックアップするには、短時間ロックし(「 読み取りロック付きフラッシュテーブル 」)、ファイルシステムを短時間フリーズします( fsfreeze )。



データベース内の最も関連性の高いデータへのアクセスをすばやく復元するため(たとえば、データベースウィザードのファイルシステムが壊れた場合)-データベーススレーブは簡単にウィザードモードに切り替わり、プロジェクトで使用されます。 必要に応じて、このプロセスを自動化できます。 別のAmazonデータセンター(アベイラビリティーゾーン)に複製してから、現在のデータセンターで「落雷」を起こせば、数分で次のことができます。a)別のデータセンターのスナップショットからマシンを持ち上げる、b)スレーブデータベースのハードウェア構成を変更する(APIを使用) c)DNSを切り替えて別のバランサーを使用するか、Amazonに組み込まれたバランサーを使用する場合、トラフィックは自動的に別のデータセンターにリダイレクトされるか、最小限のELB構成が必要です(完全自動化の場合は、構成する必要があります) オートスケールのグループAWS自動スケーリング )。



どこで育つ





データベースの読み取り量が増加すると、プロジェクトの作業を中断することなくデータベースサーバーサーバーを追加できます。 ウィザードで増加したレコードの量を処理するには、サーバー1のハードウェアのパワーを(Amazon API呼び出しを介して)増やすか、マスターデータベースを別のサーバーに転送します。



PHPアプリケーションサーバー(「サーバー1」)の負荷が増加した場合、 csync2 (Amazonは組織の複数のサーバーに1つのEBSディスクをマウントできません)を使用してファイルを同期することにより、1つ以上のアプリケーションサーバーを追加できます(プロジェクトコードを書き換えずに)クラスターFSタイプocfs2 )。 もちろん、アプリケーションサーバーはロードバランサーの背後に「隠れ」ている必要があります。 この場合、組み込みのフォールトトレラントでスケーラブルなバランサーAmazon ELBまたはnginxを備えた低電力マシンが理想的です。 SSLのテストをバランサーにかけるのは理にかなっています(Amazonはこれを行う方法を知っています)-アプリケーションサーバーに証明書を塗りつけないようにします。



PS





クラウドホスティングサービスの機能を知り、効果的に活用し、このWebプロジェクトのテクノロジーを書き換えずにクラスタリングサポートするプラットフォームを使用すると、実質的に「破壊不可能な」Webシステムを迅速かつ自信を持ってデプロイできます。 必要に応じて、このWebシステムは、負荷の高いリソースのクライアントの設定に応じて、自動および手動の両方でさまざまな方法で簡単にスケーリングできます。



ストリーム内の次のエントリを読むには会社プロフィールの [いいね]をクリックしフィード設定を確認してください。



All Articles