Webクラスター-現実世界の経験

こんにちは、共犯者の皆さん！



この記事では、ニュースポータルにWebクラスタを実装する方法について説明します（1日あたりの訪問者のピークは130,000人-これは3日間で7 TBのトラフィックです-選挙とそれに続く2回のトラフィックです。月）、プログラマとジャーナリストが同じタスクを異なる方法で理解する方法、異なる方法で同じ目標を達成する方法について。



天文学的な量を機器に投資することなく、簡単にスケーラブルな地理的に分散したWebクラスターを構築したい人にとって興味深いものになります（テレビの標準では、一般的にばかげた量になります）。



「スケーラブルWebクラスター」または「水平無限スケーラブルWebクラスター」という言葉を使ってリリースされたばかりの製品のユーバーソリューションを推進しているマーケティング担当者は、私を嫌うでしょう。



お客様の競合他社が、使用したソリューションのシンプルさに驚くことは間違いありません。







PHP、Nginx、Firebirdのセットアップチュートリアルで見つかる一般的な構成は提供しません（後者は厳密には構成するものがありません。すべてが「すぐに使える」ハーフキックで機能します）、一般的に本質について説明しますPHPのどのバージョンが優れているかではなく、決定です。



経験豊かなデザイナーは興味を持ちそうにありません-彼らはすでにすべてを知っていますが、システム設計の困難な分野で旅を始めたばかりの人にとっては、「Hello、World！」よりも難しいでしょう。おそらく構成する何かがあるでしょう-ソリューションはすぐに戦闘モードになりますアーキテクチャ上の問題はありませんでした（ただし、3つのノードのうち2つで同時に障害が発生したハードドライブが2つありましたが、誰も気づきませんでした。サイトは通常よりも少し遅くなりました）。



それで、いくつかの言葉、それがどのように始まったか。 昔々、本物のテレビになることを夢見ていた独立したジャーナリストのグループのウェブサイトがありました（先を見て、彼らは成功したと言います-彼らは「ブラックジャックと性交...」で独自の、非常に成功したテレビを作成しました-以下）。 私たちの国は小さいので、悪いことは何も起こりません（そしてこれに満足しています）が、伝統的に議会選挙を4年ごとに開催しています。 すでに伝統的に大統領を選出していません。 （恐れることはありません。ここには政治はありません。これは現時点の一般的な理解のためだけです）。



もちろん、選挙前の期間と、やがてインターネットメディアは非常にソーセージになります。 一部のサイトはうそをついているだけでなく、うろうろしており、定期的に少なくとも1行のテキストを提供しようとしていますが、問題は普遍的で有名です-サイトは訪問者の流入に対処できません。 私は通常のテキストサイトについて話している。 また、お客様には珍しいサイトがありました。 実際には、彼らはビデオも持っていた-ニュース記事、月に10ギガバイトを生産した-その当時、今では1日あたり非常に多くのビデオを作成している。 他のすべてのことに加えて（これは正直なところ政治の最後の言及です）、これらのジャーナリストは当局に特に忠実ではありませんでした。 彼らは話し、彼らが望むものを書きました。 まったく無頓着ですよね？ 私たちは常にmerc兵としての地位を確立しています-クライアントがタスクを提供し、ソリューションを提供します。 他のすべては私たちの興味を引くものではなく、私たちは中立です。



タスクは私たちのために設定されました-5万から1万人の訪問者を生き延びるだけでなく、世界中に地理的に散らばり、 宇宙のどこかのモバイルバンカーから制御されるニュースサイトのソリューションを提案します 。 もちろん、クラスターノードの地理的な広がりはそのまま残りました。 その結果、次のスキームを提案しました（私のアーティストはいません、すみません）：







（これは11月の簡略化されたスキームで、その後Netdirektには一定のソーセージチャネルがあったため、ほとんどすべてのサーバーがHetznerに転送されました。現在では、ネットワークの状況が改善されています）。

通常の訪問者は3つのサーバーの1つを見ると同時に、モルドバからのすべての訪問者が3つのうちの1つからプルした「ライト」コンテンツとテキストの形の「重い」コンテンツ（ビデオ）-ローカルプロバイダーにあるサーバー。 外部の訪問者はモルダビアの鏡を見ずに、ドイツのサーバーの1つからすべてのコンテンツを引き出しました。



結果として訪問者に得られたものは次のとおりです（ポータルの各部分には独自のカウンターがあります）。







このスキームにより、管理サーバーをいつでも変更でき、クラスターノードの可用性を確認し、簡単にスケーリングできます-Amazon ECはバックアップとしても考慮されました-さらに、Amazon ECはビデオストリーミング（約4か月）にも使用されましたトラフィックのコストが高いにもかかわらず、ストリーミングノードをドイツのヘッツナーに転送することが決定されました。

「X」の2週間前に、バックアップサーバーを用意して準備しました（ただし、サーバーをアクティブにしておくほうが戦闘モードで使用するよりトラフィックが少ないため、ユーザーには見えませんでした）。



どのように機能しますか？ 非常にシンプル-静かに、24時間体制で;）。



管理サーバー（既に述べたように、ポータルには2つの大きな「セクション」があります。写真付きのテキスト形式のニュースと、テキストダイジェストとビデオ形式のニュースです。事実上、2台のサーバーが使用されます。一般にコンテンツ管理システムと呼ばれます。



このサーバーの主な目的は、ジャーナリストがニュースを追加できるようにすることです。 特定の時間（3〜5分）に1回、スクリプトが開始され、サイトのオフラインコピーが作成されます。 もちろん、変更されたページ、またはクロスリンクと依存関係のために再構築する必要があるページのみが生成されます。



これは、Firebirdのシーケンサーとカスケードトリガーを使用して非常に簡単に実装できます。手順はサイトのメインページでのみ変更する必要があり、カスケードトリガーは更新が必要な各ページをマークすることですべての依存関係を更新します。 マークは、1/0フラグの形式ではなく、ジェネレーターに基づいて取得された一意の番号の形式で設定されます。 起動時にオフラインバージョンを作成するスクリプトは、ジェネレーターの新しい値を認識し、以前の起動からこのジェネレーターの値を読み取り、結果の範囲内のすべてのページを再作成します。 同時に、Firebirdトランザクションメカニズムを使用しているため、スクリプトは実行中にどのような変更が発生するかについて気にしません。 私たちは常に記者がそれをしないように、サイトの不可欠で一貫したバージョンを作成します。



そのため、ポータルのマスターコピーを作成します（必要に応じて、テキストとビデオの2つのポータル）。 スクリプト（および管理パネル自体）はPHPで記述されており、ADODBを使用してFirebirdを操作します。したがって、顧客の要求に応じて非常に簡単に再構築できます*。



（*ただし、今後のすべてのプロジェクトでADODBをすぐに削除する予定です-データベースを操作するための通常のメカニズム（Firebird SQLサーバーのすべての機能を使用できるようにする（ただし、他のものと同様）が実装されていないため、その汎用性は害を及ぼすだけです） 、選択的な手順から選択するときに例外をキャッチすることは不可能であり、柔軟なトランザクション管理はありません。一般に、これらのクラスにはAIが多すぎます-トランザクションをロールバックするタイミングと確認するタイミングを自分で決定することを好みます）



Firebirdの設定で変更する必要があるのは、データベースページキャッシュのサイズだけでした-データベースへの接続数が非常に少ないため（50-60を超える同時接続はほとんどありません）、ページ数は実験的に2048に増加しました（クラシックオプションを使用します）スーパーアーキテクチャの場合、共通のページキャッシュがあるため、この値は簡単に10倍に増やすことができます。Firebird3.0の今後のバージョンでは、開発者は共通のキャッシュを持つSMPフレンドリーアーキテクチャを約束します。 astroekページキャッシュ）。



次に、通常のrsyncを使用して、変更の違いがミラー全体に分散されます。ミラーは、Nginxに基づいて静的を配布するための通常のノードです。 静的データのみを配信する場合、12ギガバイトのRAMを搭載した4コアサーバーが何を処理できるかを伝える必要はないと思いますか？ ;-)



同時に、各ノードのチャネルの10％（特定の接続に応じて10メガビットまたは100メガビット）が同期用に予約されます。 同期は2段階で行われます-最初に、「重い」コンテンツが同期されます-写真とビデオ、次に-テキスト（html / xml / js）。



時々（チャンネルがコントロールサーバーからミラーにロードされるとき）、訪問者はロードされていない画像やビデオの形で小さな不一致を見ることがあります-ラウンドロビンDNSが使用されるため、ユーザーはページのテキストを別のミラーから、ビデオへのリンクを取得できます。 これはポータルの機能を妨げません-常にテキストがあり、写真またはビデオは遅かれ早かれ発表されます。



サイトには動的なフォーム（ニュースレターの購読など）があるため、これらのフォームは別のサーバーで処理されます（図には示されていませんが、本質は変わりません）。 ニュースを購読するためにすべての訪問者が一度に故障し、このサーバーが「レイダウン」すると仮定しても-悪いことは何も起こりません-フォームはiframeにロードされ、これらのフォームの欠如はニュースの可用性に影響しません。



新しいノードの追加は簡単です-最初に新しいミラーがメインコピーと同期され（これはシンクロナイザーの通常の動作モードと並行して行われます）、その後、レコードがDNSに追加され、誰も気づきません。



ノードの削除は簡単です-DNSからレコードを削除するだけです。 追加と削除は自動化に非常に適しています（これは、Amazom ECで約1000メガビットストリームのWebストリーミングを担当した部分で行ったこととまったく同じです）が、突然これを繰り返すことに決めた場合は、最初にプライマリデータの同期にかかる量を計算することをお勧めします（これがあります） 「ポータルのライトバージョン」用に2ギガバイト、ビデオ用に約1テラバイト。過去数か月間のみ保存されます。



そのため、しばらくしてスペアプールからノードの動的な追加/削除を削除しました。プロジェクトはコンテンツを大量に消費し、スクリプトは妄想的すぎます。ノードとの通信の問題ごとにノードを削除しました。



それとは別に、ニュースの表示の計算について言及する価値があります。 ジャーナリストのお気に入りの娯楽（レポートの作成/撮影に加えて）は、特定のニュース項目への訪問者の数の尺度であるという印象を受けました。 ジャーナリスティックな友愛関係に、カウンターの変化をリアルタイムで表示する必要がないことを納得させるために、約1リットルの血液と1キロの神経を費やさなければなりませんでした。



プログラマは、現在記事を読んでいる人の数を知ることは単に不可能であることをよく知っています。サーバーからの記事リクエストの数を計算することはできます。ジャーナリストにとっては同じ概念です。 :)



ビューをカウントするために、 Kilil Korinsky （ catapとも呼ばれます ）に連絡しました。彼はNginxブランチにURLビューをカウントする機能を追加することに親切に同意しました。 それでは、すべてが簡単です。すべてのノードが定期的にポーリングされ、ページカウンターがページ自体のプロパティで考慮されます。 カウンタ（値自体）は個別のファイルに保存されるため（現在はニュース用の1つのファイルです。まもなくファイルの数を減らすために1つのファイルにカウンタのグループを作成する予定です）-サイトページは同期中に転送されません全体としては、ファイルカウンターのみ。 多数のファイルがある場合、これによりディスクサブシステムに追加の負荷が発生します。したがって、同じアプローチを使用する場合、カウンターをグループに分割する方法をすぐに考えてください。ニュースと日付の種類ごとにカウンターを分類するのを止めました-ファイルは比較的小さく、時間の経過とともに停止、古いニュースは誰にとってもほとんど興味がないので。



使用したソリューションの利点は次のとおりです。

1. 静的サイトをWebクラスターノードとして使用すると、クラスター全体の管理を、ノードのオペレーティングシステムの更新とトラフィックの支払いといったいくつかの日常的なタスクに減らすことができます。 同じアイテムを使用すると、クラスターノードを地理的に分散させることができます。これは、GEO-DNSとともに、一般的にコンテンツ配信ネットワーク（CDN）の類似物と見なすことができます。
2. データベースのトランザクションメカニズムを使用し、ロジックをデータベース自体に転送することで、サイトの統合された論理的に一貫したバージョンを常に保持できます。ただし、サーバーからのデータの「スライス」が論理的に一貫していない場合は非常に驚かされます。
3. 訪問者の流入が予想される場合、クラスタノードを増やすだけで簡単に対処できます。 私たちの場合、新しいサイトの完全な試運転には、ポータルのテキスト部分に1時間以上かかり、ビデオには約1日かかります（歓迎できません）。 サイトの部分的な同期に同意し、残りをバックグラウンドに「追加」すると、ビデオ用の新しいサイトへの入力も1時間に短縮できます。
4. 管理サーバーは、任意のノードから作成できます（必要な場合）-データベースのバックアップを展開するだけです（約100メガバイトの圧縮形式で）。 他のすべてのコンテンツはすでにそこにあります。

さて、いくつかのマイナス点があるので、すべてがそれほど雲一つないように見えるわけではありません：

1. このソリューションは、サイトの一部にさまざまなユーザーが別々に表示する必要がある場合、つまり タスクの条件により、ページがユーザーごとに個別に生成される場合。 私たちの場合、これは不要であることが判明しました。
2. 訪問カウンターは約30分遅れて更新されます。 寛容ですが、長い間クライアントを納得させる必要があります。
3. ほとんどの問題は、ローカルミラーとの同期が原因です。当社のプロバイダーは、テラバイトあたり7ユーロの価格でトラフィックを販売しておらず、100メガビットを世界に提供する場合、非常に不適切な価格でトラフィックを販売します。
4. クラスターノードの偏執性の少ない追跡システムを設計します。感度が高すぎることがわかったため、ノードの追加と削除を手動モードに切り替える必要がありました。

そして、文字通り、ひとつまみの経験で、日常生活の新鮮なおを多様化します。



サイトのオフラインコピーを保存するには、JFSファイルシステムを使用します。 彼女は、多くの小さなファイルを扱うときと大きなファイルを扱うときの両方で非常によく証明しました（私の経験では、XFSだけがサイズが200〜300 GBのファイルをほぼ瞬時に削除できます）。



だから-デフォルトでは、ファイルシステムはデフォルト設定でマウントされました。 しかし、時間がたつにつれて多くのファイルがあったため、ディスク操作が少し遅くなり始めました。 ファイルに最後にアクセスした時刻は必要ないため、FSマウントオプションに「noatime」オプションを追加しました。 ここに何が起こった-追加する瞬間、私はあなたが自分で決定すると思います：







簡単に繰り返す-通常モードでの安定した動作のために使用されます：

• コンテンツ配信用の3台のサーバー
• 「管理パネル」用の2台のサーバー
• DNS用の2台のサーバーと他のサーバー用の追跡システム。

クラスタノードは地理的に分散しており、異なるプロバイダーに配置されています。

予想されるイベントが多数の訪問者を引き付ける場合、追加のサーバーが接続されてコンテンツを配信します。



1か月あたり約40TBのトラフィックが消費され、コンテンツの合計量は1テラバイトをわずかに超え、ビデオコンテンツは約3か月間保存されます。



私はhabrasocietyからの質問に喜んでお答えします。