Campus.ruソーシャルネットワークのシステムアーキテクチャの概要

Creative Media LLCが開発したソーシャルネットワークwww.campus.ruの高レベルシステムアーキテクチャの概要を紹介します。 私の意見では、この資料は、インターネットリソースの開発における考慮されたアプローチと技術​​の適用性を評価できるという点で興味深いものです。 少なくとも当社がキャンパスプロジェクトを開始したとき、私はそのような情報が本当に不足していました。



Campus.ruソーシャルネットワークは、大企業の特別コンテストを開催したり、インターンシップやトレーニングセミナーを開催したり、コミュニケーション、情報交換、その他の教育ニーズに必要な機能を通じて、学童や学生が将来のキャリアを築くのを支援します。カリキュラムを作成します。 Campus.ruの機能は、おなじみのソーシャルネットワークの機能と主に交差しています。登録ユーザーは、チャットしたり、コミュニティで集まったり、ブログに書いたり、写真を投稿したりできます。 ただし、このソーシャルネットワークはもともと学童と学生を対象としていたため、たとえば、「トレーニングポートフォリオ」-材料を保存するためのフォルダー、または「グライダー」-カリキュラムを作成するためのサービスなど、いくつかのことは特に生徒のニーズを考慮して実装されました。



Campus.ruがJavaプラットフォームに実装されているという情報から、システムアーキテクチャのレビューを開始します。 一般的な統計から判断すると、Webメディアリソースを実装するためのツールとしてのJavaプラットフォームの選択は、かなり非標準的なソリューションですが、次の考慮事項に基づいてこのプラットフォームを選択しました。



•負荷が大きく、耐障害性があり、水平方向にスケーラブルなJavaアプリケーションの開発におけるこれまでの経験は成功しています。

•Javaコミュニティは、ほとんどすべての場合に、高品質のオープンソースライブラリとフレームワークの膨大なコードベースを蓄積しています。

•プロジェクトチームを「ゼロから」構築する場合、たとえば、以下の作業を行うよりも、労働市場でのソフトウェアアーキテクチャ（デザインパターン）を理解する分野で必要な資格、チームワークの経験、知識を持つ適切なJava開発者を見つけるのが簡単ですRuby（同僚の経験によると、この言語はまだ広く普及していないため）、またはPHPを使用しているため（私自身の経験からすると、スキルを失った人が多すぎます。



Javaアプリケーションのパフォーマンスに関する皮肉なコメントを想定すると、Javaを優先することを決定したときに、JVMが最速で最も経済的なインタープリターではないことが明確にわかりました。 ただし、第1に、JVM 6.0はWebアプリケーションのニーズに対して十分に生産的であり、第2に、プログラマの作業は鉄のコストよりも高くなっているため、長い間、生産性の5％-10％を獲得できる高価な「バイク」を発明しました不合理です。 私は「10％の鉄を節約してデバッグで行き詰まるよりも、最小限のコードと美しいアーキテクチャですばやく作業する方が良い」という原則を固守しています。



プロジェクトのメインフレームワークはTapestry 5です。 Tapestry 5を選択した理由はいくつかありますが、その主な理由は次のとおりです。

•タペストリーを使用すると、レイアウトとプレゼンテーションのロジックを完全に分離できます。 JSPのように、ブラウザで解釈されない特別なタグをHTMLに追加する必要はありません。 これは特に重要です ほとんどの場合、Webプロジェクトには複雑なレイアウトが含まれます。これは原則として、別の専門家によって実行および保守されます。 ところで、レイアウトの最適化の観点から、 ベストプラクティスに従うようにしました 。

•ページプールなど、高パフォーマンスの作業を目的とした多数のアーキテクチャソリューションが含まれています。

•適切なバランスのとれたフレームワークアーキテクチャにより、アノテーションと命名規則、および組み込みのIoCが広く使用されているため、コンポーネントの構成と相互の統合ではなく、アプリケーションのビジネスロジックに集中できます。

Tapestry 5の経験がなかったため、最初にアプリケーションのテストプロトタイプを作成し、 JMeterユーティリティを使用して負荷テストを実行しました。 テストにより、応答時間の短縮、ハードウェアプラットフォームの安定した使用、ロックの欠如が示され、その後Tapestry 5を使用する決定が最終的に承認されました。



上記に基づいて、Campus.ru Webアプリケーションの内部アーキテクチャは、Tapestry 5フレームワーク用のアプリケーションを開発するためのルールによって決定されます。

Tapestryに加えて、Webアプリケーションは次のライブラリを使用します。

• DOJO 1.0 -AJAXを使用したJavaScriptフレームワーク

メインのJavaScriptフレームワークとしてのDOJOの選択は、ウィジェットを含む多数の既製のコントロールの存在と、DOJOによってクライアント側でコンポーネントのすべてのスタイル変換を実行できるという事実によって決定されました。 同時に、リソースに最初にアクセスすると、必要なすべてのCSSおよびJavaスクリプトがダウンロードされてブラウザーにキャッシュされ、最小のボリュームマークアップを持つHTMLページのみがサーバーからロードされます。 これにより、トラフィックとサーバーの負荷が大幅に削減されます。

さらに、重要なことに、チームはすでにDOJOの経験があり、困難な点として、DOJO-Tapestryの統合部分を独自に開発する必要がありました。 将来的には、オープンソースプロジェクトの形式で整理し、オープンアクセスにする予定です。

• SwfUpload 2-ファイルをサーバーにアップロードするためのJavaScriptコンポーネント。

• Hibernate 3 -ORMフレームワーク。 Tapestry 5は、Hibernateと透過的に統合されます。 エンティティのマッピングには注釈を使用します。

• Hibernate Search 3 -Luceneベースの全文検索エンジン。 Hibernateエンティティのコンテンツのインデックス作成を許可し、エンティティの注釈を便利に構成します。 クラスタ内で機能します。

• Spring Security 2.0-注釈付きで構成されたTapestry 5と透過的に統合される認証および承認システム。 十分な機会がありますが、ドメインオブジェクトに個人ユーザーのアクセス権を課すのに適したACLメカニズムがなかったため、自分で考えなければなりませんでした。 将来的にはオープンソースプロジェクトとして提供する予定です。

• Quartz 1.6-バックグラウンドおよび非同期操作を実行するためのスケジューラ。 郵送、サーバー上のファイルの処理などの長期的な操作は、ユーザーインターフェイスを長時間ブロックしないように、非同期に実行されるアクションとして実装しようとします。

状況の組み合わせがうまくいくと、ソーシャルネットワークのユーザー数（つまり、リクエスト数）とユーザーに関連付けられたデータ量が雪崩のように増えます。 この点で、システムの水平スケーリングと十分なレベルのフォールトトレランスを確保することが非常に重要でした。 これらの目標は、重要なシステムノードに冗長ハードウェアサーバーを使用できることと、OSレベルで特別なソフトウェア（haproxy、hartbeatなど）を使用することによって達成されました。したがって、成長事故や病気を恐れることはほとんどありません。



ソフトウェアといえば。 インフラストラクチャで、キャンパスは以下を使用します。

• Nginx 0.6-静的コンテンツ（JavaScript、CSS、アイコンなど）を配信するためのロードバランサー（HTTPリクエスト）およびHTTPサーバー。 TomcatアプリケーションサーバーへのHTTP要求のバランスは、1つのセッション中に1人のユーザーからのすべての要求がTomcatサーバーの1つのインスタンスに分類されるように構成されます。 この負荷分散設定は、スティッキーセッションと呼ばれます。 これは、Tomcatサーバー間でユーザーセッションを複製しないようにするためです。 さらに、リソースと線形水平スケーリングを節約します。 マイナス-サーバーに障害が発生した場合、ユーザーはリソースにログインする必要があります。

• JDK 6-開発ツールのセットと仮想Javaマシン（JVM）。これに基づいてJ2EEアプリケーションサーバーが実行されます。

• Tomcat 6 -J2EEアプリケーションサーバー（Webアプリケーション用のJ2EEコンテナー）。 Campus.ruアプリケーションは彼の制御下で実行されます。 このレベルで線形水平スケーリング機能を維持するため、Tomcatサーバーをクラスター化しませんでした。

• PostgreSQL 8.3-バージョン管理されたDBMS。 MySQLとPostgreSQLを選択します。 Postgresに立ち寄り、さまざまなレビュー、専門家のブログ、DBMSのクラスタリング用ユーティリティの可用性を分析しました。

• PgPool-II 3.4-クラスター内の2つのPostgreSQLサーバーをクラスター化するために使用されるロードバランサーとデータレプリケーター。 データ変更要求は両方のデータベースサーバーに同時に送信され、読み取り要求はいずれかのサーバーに順番に送信されます。 したがって、負荷は2台のマシンに分散されます。

• PgBouncer 1.3 -PostgreSQL用の軽量の接続プール管理システム。 多数のアプリケーションサーバーによるユーザーリクエストの同時処理には、多数のデータベース接続のサポートが必要です。 PgBouncerは各接続の維持に約2 KBのメモリを消費し、PostgreSQL DBMSから負荷を大幅に取り除きます。 したがって、Tomcatサーバー上のJDBCプールは、PgPoolではなくPgBouncerに接続するように構成されます。 さらに、データベースに短時間アクセスできない場合（クイックリスタート時など）、PgBouncerはデータベースへの接続を試行し続け、これが設定されたタイムアウトの前に発生した場合、アプリケーションサーバーはデータベースが一時的に利用できません。

• ActiveMQ 5.2 -JMSサーバー。 JMS Master / Slave設定モードで設定されたHibernate Search全文検索システムの非同期JMSメッセージングに使用されます（ 詳細はこちら ）。 また、Quartzフレームワークに基づいて非同期タスク実行サブシステムと情報を交換するためにも使用されます。

•Sendmail-有名なメールサーバー。 ニュースレターに使用します。

• Zabbix 1.6-システムインフラストラクチャ監視システム。 MBeansインターフェースを介してJMXプロトコルを介して、JVM、Tomcatの状態を監視します。 最大30台のホストを無料で監視します。

• Smssend -SMSを送信できるFreeBSDのパッケージ。 リソースの問題についてシステム管理者にSMSメッセージを送信するために使用します。

• チャンドラーサーバー -オープンソースWebアプリケーション。これは、オープンCalDavプロトコルを介して外部と通信するカレンダーサーバーです。 車輪を再発明しないために、Gliderサービスでこのサーバーを使用して、ユーザーとコミュニティの時刻表を保存します。

• Amazone S3-ユーザーファイルの信頼できるストレージに使用されます。 さらに、このサービスを使用すると、アプリケーションサーバーからの負荷を軽減できます。 ファイルは、ユーザーがAmazonサーバーから直接ダウンロードします。 ファイルのメタデータはCampusデータベースに保存されます。

Amazonと連携するために、 クライアントJava APIがあります 。 サービスは有料ですが、組織にとっては高価ではありません。 このようなものを自分で整理することに決めた場合は、Java APIも備えたMogileFSをお勧めします。

•Fotki.com-パートナーの写真ホスティング。ユーザーがアップロードした写真を保存し、写真アルバムに変換します。 ブラウザーへの写真のアップロードは、写真ホスティングサーバーから直接行われるため、Campus.ruアプリケーションサーバーの負荷が軽減されます。 自分で写真を変換する必要がある場合は、おそらくImageMagickに注目します。JavaAPIも含まれています。



ともに、次のように機能します。

1）ユーザーリクエストはロードバランサーサーバーに送られます。 Nginxは、Tomcatサーバーの1つへのユーザーのバインディングに関する情報を含むヘッダーがリクエストに含まれているかどうかを確認します。 そうでない場合、そのようなヘッダーが追加され、要求は適切なTomcatサーバーにリダイレクトされます。 最初に、サーバーはラウンドロビン方式で選択されます。 このメカニズムは、スティッキーセッションを提供します。

2）Tomcatサーバーでは、実際にはHTMLページ用の動的コンテンツが生成されます-スタイルが最小限のデータのみです。 ページの生成にデータベースのデータが必要な場合、Campus.ruアプリケーションはこのサーバーのJDBCプールから接続を取得します。 JDBCプール内の接続はPgBouncerで行われ、PgBouncerはPgPoolとの接続を確立し、PgPoolはPostgreSQLとの接続を確立します。 JDBCプールで接続を確立するプロセスは、Tomcatサーバーの開始時にすぐに発生するため、プールからの接続の取得は、アプリケーション操作中に非常に高速です。

3）ユーザーのリクエストがフルテキスト検索に関連する情報を変更すると、アプリケーションはマスターノード検索サーバーにJMSメッセージを送信します。マスターサーバー検索サーバーは、各クラスターノードのフルテキストインデックスを同期します。

4）HTMLページのコンテンツがユーザーのブラウザーに返されます。 その後、ユーザーのブラウザーは、Nginxサーバーから静的コンテンツ（JavaScript、CSS、画像）のダウンロードを開始します（このコンテンツがブラウザーによってまだキャッシュされていない場合）。また、外部写真ホスティングサーバーからの写真とアバターもダウンロードします。

5）ユーザーのブラウザーは、ロードされたDOMツリーにCSSおよびJavaScript変換を適用し、その結果、完成したページをユーザーにレンダリングします。



このスキームにより、第1に、アプリケーションサーバーの負荷を減らし、トラフィックを最小限に抑えることができ、第2に、ブラウザーの制限を克服してページの全体的な読み込みを加速し、1つのリソースから同時に4つのストリームのみでデータをダウンロードできます。 コインの裏返しは、IE 6などの古いブラウザーで観察される副作用です。IE6では、表示されるまでページにすべての動的スタイル変換を適用する時間がありません。そのため、ユーザーは目の中の湾曲したページがどのように美しいページに変わるかを観察できます。 また、すべてのCSSおよびJavaスクリプトを低速チャンネルで最初にロードするのには時間がかかる場合があります。

ところで、ユーザーのブラウザーでキャッシュされた静的コンテンツ（CSS、JS）を更新する際の問題を思い出しました。 それを解決するために、静的リソースのURLにバージョン番号を追加します。 スクリプトが変更されると、URLのバージョン番号が変更され、ブラウザーはサーバーから更新されたファイルをダウンロードします。



上記を頭に収めやすくするために、図はCampus.ru Webアプリケーションの高レベルの展開図を示しています。 図を複雑にしないために、コンポーネント間のいくつかの接続は示されていません。





図1. Campus.ruの展開図



JVMは、各サーバーJVMインスタンスに少なくとも2つのプロセッサコアを搭載するという推奨事項を考慮して、最大2 GBのメモリサイズで効率的に動作することが示されています。 これらの理由により、Tomcatアプリケーションサーバーの4つのインスタンスが各ハードウェアサーバーに展開されました。 キャンパスおよびチャンドラーのWebアプリケーションは、各Tomcatコンテナーにデプロイされています。 厳しいテストの結果、GCによって行われた設定により、この構成により、負荷が増加してもハードウェアリソースをほぼ直線的に利用でき、同時に応答時間に許容できる結果が得られることがわかりました。



すべてのハードウェアサーバーで、アプリケーションはFreeBSD 7.1で実行されます。 ceteris paribus、すべてのLinuxには独自の特性があり、システム管理者がお互いに知識を伝達することはより困難であるため、LinuxではなくFreeBSDを選択しました。 当社では、すべてのプロジェクトがまだFreeBSDで作業しているため、企業標準のようなものになりました。 JavaプロジェクトにおけるFreeBSDの欠点のうち、SunはFreeBSD用のJDKをリリースしていません。また、FreeBSDのポートはSunのアップデートに比べて遅れています。 また、すべてのデバッグユーティリティがJDKポートで使用できるわけではありません。



負荷分散サーバーのフォールトトレランスは、 HAProxyユーティリティを使用して実装されます。



キャンパスハードウェアサーバーの構成は次のとおりです。

1）負荷を分散し、静的コンテンツを返すサーバー：

CPU Intel Xeon Dual Core 2.67GHz \ RAM DDR 2 8Gb \ HDD 4xSAS 73gb 15000 rpm

2）Webアプリケーションをデプロイするためのサーバー：

CPU 2xIntel Xeon Quad Core 2.66GHz \ RAM DDR 2 16Gb \ HDD 4xSATA 300gb 15000 rpm

Webアプリケーション用のサーバーを選択する際の主な原則-より多くのコア/プロセッサとRAM-より良い。

3）データベースのサーバー：

CPU 2xIntel Xeon Quad Core 2.66 GHz \ RAM DDR 2 16Gb \ HDD 8xSAS 147gb 15000 rpm

大量のデータを処理することを期待してデータベース用のサーバーを選択する際の主な原則は、ディスクが多ければ多いほど高速であるということです。 ハードウェアRAIDが必要です。 次に、RAMが優先され、次にプロセッサが続きます。



サーバーは、シスコのハードウェアファイアウォールの背後にある大規模なモスクワのインターネットサービスプロバイダーのデータセンターでホストされています。



結論として、私は、膨大な量の作業が行われたにもかかわらず、まだ改善すべきことがあると言いたいと思います。 たとえば、IE 8のリリースに関連して、DOJO 1.3への痛みを伴う移行の概要を説明しました。 また、地域の学生は実際に学校/大学で128Kbit / sとIE 6チャンネルを持っているため、サイトのレイアウトを簡単にする（影、半透明性、余分な丸みを削除する）予定です。実績のある分散Memcachedキャッシュのベース。 また、今日、データ量が突然危険になり始めた場合、シャーディングデータの問題は解決していません。 したがって、将来的には、Hibernate Shards、PL \ Proxy、その他の手段を検討する予定です。 誰かが実際の経験とそれを共有したいという願望を持っているなら、私はとても幸せです。



次の記事では、あなたが私をサポートするなら、私はキャンパスプロジェクトの管理と私たちのチームについて話すつもりです



ご清聴ありがとうございました！

Creative Media LLCのテクニカルディレクター

セルゲイ・セドフ

Creative Media LLCのジェネラルディレクターIvan Sokolovの許可を得て公開