こんにちは、同僚！
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」は自動的に接続し、アプリケーションサーバーとして使用できます。
信頼性
プロジェクトマシンのバックアップは、
S3の
EBSディスクのスナップショットで作成され
ます 。 航空機または弾道ミサイルがデータセンター（アベイラビリティゾーン）に当たった場合、ディスクを備えたマシンを数分で別のデータセンター（アベイラビリティゾーン）で拾うことができます。 スナップショットは、自動統合により増分として保存されるため、少なくとも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システムは、負荷の高いリソースのクライアントの設定に応じて、自動および手動の両方でさまざまな方法で簡単にスケーリングできます。
ストリーム内の次のエントリを読むには
、会社
プロフィールの [いいね]をクリックし
て 、
フィード設定を確認してください。