Bitrix24アーキテクチャ-内面図

4月12日に、新しい新しいプロジェクト-Bitrix24を開始しました。これは、従来のチームワークツール（カレンダー、タスク、CRM、ドキュメントの操作）とソーシャルコミュニケーション（いいね、ソーシャル検索、インスタントメッセージ）を組み合わせたソーシャルイントラネット、SaaSサービスですその他）。



このサービスの最初のプロトタイプは、昨年2月に発売されました。 1つのサーバーで、スケーリングのための特別な機能はなく、データセンターレベルでのバックアップはありません... :)概念のみ。



この出版物を使用して、一連の投稿を開きます。この投稿では、開発の年に何が行われたか、プロジェクトの最終的なアーキテクチャがどうなったかをお伝えします。 プロジェクトの実際の「24」時間を1日あたりに確保するために行うこと。 1C-Bitrix開発プラットフォームでどのような変更を加える必要があったか。 Amazonクラウド機能など。



私たちは、大規模なWebプロジェクトやサービスを立ち上げようと計画している、またはすでに運用およびサポートしているすべての開発者にとって、この経験が役立つことを本当に望んでいます。



* * *



そのため、最初の投稿はプロジェクト全体のアーキテクチャについてです。 行こう！



Bitrix24のアイデア自体を開発する過程で、私たち自身のためにいくつかのビジネスタスクを策定しました。

• 最初から、最初のBitrix24関税は無料であると想定していました。
• これは、このような無料アカウントのコストが非常に低いことを意味します。
• 私たちのプロジェクトはビジネスアプリケーションであるため、その負荷は非常に不均一になります。日中はより多く、夜はより少ないです。 理想的には、（両方向に）スケーリングし、いつでも必要なだけ正確にリソースを使用できると便利です。
• 同時に、信頼性はあらゆるビジネスアプリケーションにとって非常に重要です。データの継続的な可用性とその安全性です。
• 私たちは、ロシア、アメリカ、ドイツのいくつかの市場ですぐに始めました。

これらのビジネス要件は、最終的に、スケーラブルなフォールトトレラントな（少し先の「クラウド」に見える）開発プラットフォームの形成とプロジェクトインフラストラクチャの技術プラットフォームの選択という2つの大きな「フロント」を形成しました。



1C-Bitrix開発プラットフォーム



従来のWebアプリケーションデバイスは、スケーラビリティと冗長性が非常に不十分です。 最良の場合、アプリケーション、キャッシュ、データベースを異なるサーバーに分散できます。 何らかの方法でWebをスケーリングできます（ただし、同時にWebサーバー上のデータ同期の問題を解決する必要があります）。 キャッシュとベーススケールはすでに悪化しています。 また、分散ジオクラスター（データセンターのレベルでのバックアップ用）についても話していません。



1C-Bitrixプラットフォームの開発における大きなステップは、昨年春のバージョン10.0でのWebクラスターモジュールの出現でした 。



Habréで彼について詳しく書いた。 主な機能を簡単に繰り返します。

• 垂直シャーディング（個別のモジュールを個別のMySQLサーバーに転送）
• プラットフォームコアレベルでのサーバー間のMySQLレプリケーションと負荷分散
• 分散データキャッシュ（memcached）
• Webサーバー間のセッション継続性（データベースへのセッションの保存）
• Webサーバークラスタリング

その結果、交換可能なサーバーのWebクラスターとしてプロジェクトを紹介する機会を得ました。 すべてが非常によく見えました。トラフィックが増加すると、クラスターに新しいサーバーをすばやく追加できました。 1つまたは複数のクラスターサーバーに障害が発生した場合、すべてが残りのサーバーで機能し続け、システムは引き続きクライアントにサービスを提供し続けました。







しかし、理想はまだ遠く、「ボトルネック」がありました。

• 異なるWebサーバー上のファイルを同期する問題は完全には解決されていません。 自社サイトではcsync2を使用しましたが 、非常にうまく機能しました。 ただし、大量のデータの場合、すべてのサーバー間で変更を転送する時間がありません。
• MySQLレプリケーションでのマスターサーバーの障害は、スレーブの1つをマスターモードにするための何らかの手動または半自動操作を意味していました。 これには時間がかかりました。つまり、サービスの円滑な運用を保証できませんでした。
• スレーブを使用すると、読み込みのためにベースに負荷を分散できますが、マスターはそのまま残ります。 これは、レコードがデータベースのボトルネックのままであることを意味します。
• 私たち自身の悲しい経験が示すように、 落雷はデータセンターを襲い 、それらを完全に無効にすることができます。 つまり、個々のサーバーだけでなく、データセンター全体も予約する必要があります。

2011年秋にリリースされた「1C-Bitrix」プラットフォームバージョン11.0では、これらの問題も解決しました。 クラウドファイルストレージのサポートは 、静的コンテンツの同期の問題を解決し、MySQLのマスターマスタレプリケーションのサポートの実装により、地理的に分散したWebクラスタを構築することが可能になりました。



そして、2番目の大きなタスクに近づきました...



インフラストラクチャ展開プラットフォーム



正直に言うと、選択はそれほど難しくありませんでした。 :)



「クラウド」または「クラウド」ではない-そのような質問は立っていませんでした。 :)



所有またはリースされた機器は、プロジェクトの開始時にインフラストラクチャにかなり深刻な投資を必要とします。 物理ハードウェアのスケーリングは困難です（長くて高価です）。 管理（特に異なるDCでの）は不便です。



したがって-「クラウド」！



どっち？ Amazon AWSを選択しました。



当社のすべてのサイトは、かなり長い間Amazonで機能しています。 S3クラウドストレージ、 Elastic Load Balancing 、 CloudWatch 、 AutoScalingなど、独自のバイクを発明するのではなく、プロジェクトで簡単に利用できる既製のサービスが多数あるという事実が気に入っています。



非常に単純化された形式では、Bitrix24のアーキテクチャ全体は次のようになります。







Web-自動スケール



アプリケーション（Web）は、垂直（サーバー容量の増加）ではなく、水平（新しいマシンの追加）に合わせてスケーリングされます。



これを行うには、一連のElastic Load Balancing + CloudWatch + Auto Scalingを使用します。 すべてのクライアントリクエスト（HTTPおよびHTTPS）は、1つ以上のAmazon Balancer（ELB）に送信されます。 CloudWatchを使用して、負荷の増加と減少を監視します。 2つの興味深い指標があります-EC2ノードの状態（％CPU Utilization）とバランサー（レイテンシー時間-秒）。



遅延は実際の負荷だけでなく、ネットワーク遅延、アプリケーションエラーなどのその他の理由によっても変化する可能性があるため、マシンの負荷データを主な特性として使用します。 この場合、誤報が発生する可能性があるため、新しいマシンを非常に非効率的に追加します。



これで、最終的には、平均CPU使用率（Amazonの用語で）が60％を超えると新しい車が自動的に起動し、平均負荷が30％を下回ると自動的に停止して廃棄されます。



私たちは長い間これらのしきい値を実験してきましたが、今ではそれらを最適と考えています。 上限しきい値をさらに設定すると（たとえば、70〜80％）、システムの一般的な低下が始まります-ユーザーは作業に不便です（長時間ページを読み込む）。 下限しきい値はより低くなります-バランスシステムはあまり効果的ではなくなり、車は長時間アイドル状態になります。







サービスユーザーの静的コンテンツ



上記のスキームでは、Webノードは基本的に「消耗品」になります。 それらはいつでも、いつでも消火することができます。 これは、ユーザーコンテンツが存在しないことを意味します。



そのため、Bitrix24で各新しいポータルを作成するときに、S3にデータを保存するためにAmazonで個人用アカウントが作成されます。 したがって、各ポータルのデータは互いに完全に分離されています。



同時に、S3ストレージ自体は非常に信頼性があります。 Amazon自身がデバイスを詳細に説明しています（そして、原則として、それらを信じない理由はありません）。



S3のデータは複数のポイントに複製されます。 同時に-地理的に分散したポイント（異なるデータセンター）へ。



各ストレージデバイスは監視され、何らかの障害が発生した場合に迅速に交換されます。



リポジトリに新しいファイルをアップロードすると、ファイルがいくつかの異なるポイントで完全に保存された場合にのみ、アップロードが成功したという応答を受け取ります。



通常、データは3つ以上のデバイスに複製されます。2つのデバイスに障害が発生した場合でもフォールトトレランスを確保するためです。



言い換えれば、信頼性-すべてが順調です。 たとえば、同じAmazonは、S3アーキテクチャは、小数点以下2ナインのレベルでアクセシビリティを提供できるように設計されていると述べています。 また、データ損失の確率は10億分の1パーセントです。



2つのデータセンターとマスターマスタレプリケーション



現在、プロジェクト全体が2つのデータセンターに配置されています。 2つの問題を一度に解決します。まず、負荷を分散し（現在はロシアのユーザーが1つのDCで作業し、アメリカとヨーロッパのユーザーが別のDCで作業しています）、次に、すべてのサービスを予約します-DCの1つが故障した場合トラフィックを別のトラフィックに切り替えるだけです。



もう少し詳細-それがすべてどのように機能するか。



各DCのベースは、2番目のDCのスレーブに相対的なマスターであり、同時にスレーブはマスターに相対的です。



このメカニズムを実装するためのMySQLの重要な設定はauto_increment_incrementと

auto_increment_offset 。 レコードの重複を避けるために、フィールドauto_incrementのオフセット値を設定します。 大まかに言って、あるマスターでは-偶数のIDのみ、別のマスターでは-奇数のIDのみです。



Bitrix24で確立された各ポータル（その中に登録されているすべての従業員）は、いつでも1つのDCと1つのベースでのみ動作します。 別のDCへの切り替えは、障害が発生した場合にのみ実行されます。



異なるデータセンターのデータベースは同期していますが、互いに独立しています。データセンター間の接続が失われるのは数時間に及ぶ可能性があり、データは復旧後に同期されます。



信頼性、信頼性、信頼性



Bitrix24で最も重要な優先事項の1つは、サービスの継続的な可用性とフォールトトレランスです。



シンプルなサービススキームを覚えていますか？ その結果（とにかく簡略化されていますが、それでも:)）、次のようになります。







1つ以上のWebノードで事故が発生した場合、ロードバランシングは障害が発生したマシンを特定し、バランシンググループの指定されたパラメーター（実行中のマシンの最小必要数）に基づいて、必要なインスタンス数を自動的に復元します。



データセンター間の接続が失われた場合、各データセンターは引き続き顧客セグメントにサービスを提供します。 再接続後、データベース内のデータは自動的に同期されます。



データセンターに完全に障害が発生した場合、またはたとえばベースで障害が発生した場合、すべてのトラフィックは自動的に稼働中のデータセンターに切り替わります。



これによりマシンの負荷が増加した場合、CloudWatchはCPU使用率の増加を判断し、AutoScalingのルールに従って1つのデータセンターに必要な数のマシンを追加します。



同時に、マスターレプリケーションは中断されます。 必要な作業を実行した後（復旧-事故が発生した場合、または計画した場合-たとえば、ある時点でまったく同じ方法で、標準のMySQLからPercona Serverに移行しました-サービスのユーザーのダウンタイムなし） 、データベースをオンにしてレプリケーションを復元します。



すべてが順調に進んだ場合、トラフィックは再び両方のデータセンターに分散されます。 平均負荷がしきい値を下回った場合、増加した負荷を処理するために発生させた余分なマシンは自動的に消滅します。



* * *



この最初の投稿を「簡単に」パノラマにしようとしました。 :)共有したいものをすべて1つのテキストに入れて、一度にすべての経験について話したとしたら、あまりにも多くの手紙を受け取っていたでしょう。 :)



一連のテーマ別の投稿をする方が論理的に思えます。 準備中のトピック：

• Amazonのニュアンス：明白ではない制限、さまざまなバランサーのモード、AMIイメージの操作
• Webノード固有：ソフトウェア更新メカニズム、Apache /非Apache、セキュリティおよびユーザー分離
• MySQL：なぜPercona、マスターマスターの機能、大量のデータの複製、クエリキャッシュのニュアンス、シャーディング
• データのバックアップと最も重要なこと-それらの回復
• 何千ものオブジェクトの監視、アラートで自分をスパムにしない方法、通知への反応を自動化

あなたにとって最も興味深いのは何ですか？ 自発的に投票し、コメントに直接マークすることができます。 :)



そしてもちろん-自分でBitrix24を試してみてください！ 最初の関税は無料です。 その制限または機能が十分でない場合-より高い関税に切り替えることが可能になります。 :)



つながる-喜んで仕事しましょう！