スケーリングに耐え、データセンター間ですべてを同期する方法

そうでない場合は、彼はAmazonにトラフィックを誘導し、そこで$ 26のボトル入り飲料水を販売します。SaaSコンストラクターのサイトについて説明します



たとえば、1年間、中断のない動作を保証できるサイトはありません。これは、いくつかの理由で与えられています。 そのため、データセンターレベルでフォールトトレランスを確保し、トラフィックを少し拾うバックアップサイトを作成するには、「プランB」が必要です。 すべてがサーバーを同期します。Yandex、Google、およびカットされたヒーロー。



新しいサイトビルダーを作成し始めたとき、チームには10人しかいませんでしたが、そのようなオフィスの代わりに、職場はアパートでした（長くはありませんが、覚えておくべきことがあります）。 これにより、サーバーの同期を1年以上試すことができました。同時に、他のプロジェクトの同僚に、どのように、どのように機能するかを尋ねました。



n回目の実験とn回目の秘密のイベントに参加した後、プログラマのマキシムが来て言った： 「私たちはそんなに夢中ではないようです。 」 つまり、独自の同期システムを完全に作成しました。 そして今、その理由を説明します。

プロローグ：システム管理者の目を通してuKit

私たちのシステムの主要なエンティティの1つは「サイト」です。これは、ユーザーが何らかの方法で配置して記入する構成要素「ウィジェット」へのリンクを含むデータベース内のドキュメントです。 ウィジェットを好みに合わせて配置し、入力した後、ユーザーは「公開」ボタンをクリックする時間であると判断し、いわば彼のサイトが実稼働に入るはずです。





プロジェクトのメインデータベースとしてMongoDBを選択したため、フォールトトレランスについて特に心配する必要はありませんでした。すぐに使用できる非同期レプリケーションがあり、これはすべて良好です。



また、2つのデータセンター間をすばやく切り替えることができる必要がありました（そして、突然met石がそれらの1つに落ちます）。つまり、すべてのサイトが両方のサーバーで常に最新である必要があります。 Mongoのようにシンプルにしたかった。 しかし、単純さには複雑さが伴い、逆もまた同様です。 特に反対！



これが私たちが探し求めた道です：

私たちは「ハイロイド」を発明します

裸のrsync'omで発生する可能性のある問題

非同期を追加しますか？ ああ、追加しません

岐路に立って：アマゾンとあなた自身のルナパーク？

ターニングポイント：または上級の仲間が行う方法

「Vershansky comb」：非同期性のある並列性の問題を解決する方法

ナノ秒を考えないでください：レコーダーシステムをテストするときに考慮すべきこと

ハッピーエンド：メンバーサーバーのヒロイックレスキュー

私たちは「ハイロイド」を発明します

最初のアイデアは、サイトの現在の状態を別のコレクションにコピーすることでした。 この形式では、タスクはプログラマに与えられました。しかし、いじくり回して、彼はすべてをファイルに取り込んでダンプし、ディスクに置くことを提案しました。 マキシムは通常、システムリソースを処理する傾向があります。



熟考すると、私たちは徐々にこのアイデアに触発され始めました：「高負荷」の観点から、より優れた、より信頼性の高いものを考え出すことはおそらく不可能です。 ベースは、どれほど良いものであっても、遅かれ早かれ、シャーディング、新しいインデックスの構築、その他の定期的なメンテナンスを要求し始めます。 そして、私たちは非常に負荷の高いサービスを行っています。私たちはそのようなことを考える義務があります。 結局、さらに簡単です。

裸のrsync'omで発生する可能性のある問題

したがって、静的ファイル、主に異なる形式のHTMLおよび画像があります。 2つのサーバー間でそれほど多くないファイルを同期する方法は？ Rsync



私たちは十分に小さい間、cronを切って、ディレクトリ全体をサイトと毎分同期しました（ロックファイルを使用）。 スクリプトはすぐに機能し、サーバー間で数回切り替えましたが、悲しみは知りませんでした。





マーケティング担当者のタスクは、システム内のサイトを大きくすることです。 そして私は言わなければならない、彼らは仕事に対処する。



ロックファイルがラッシュアワーで10分以上ハングし始めることに気づき始めました-ディレクトリの階層が成長し、Rsyncはすぐにそれを回避する時間がありませんでした。 Rsyncは最初にソース上のすべてのディレクトリを巡回し、ツリーを構築し、受信機から同様のツリーを取得し、比較します...そしてその後、何かを送信し始めます-これも時間がかかります。 その結果、2番目のサーバーの統計は遅れをとっており、特定の時点からの不一致は発生しないため、問題が増大します。

非同期を追加しますか？ ああ、追加しません

そこで、私たちは「分散ファイルシステム」というアイデアを思いつきました-世界にはたくさんあります：LeoFS、LustreFS、GlusterFS、XtreemFS、WhateverFS。 しかし、その時点で（おそらく変更されています）、すべてが同期であったか、非同期モードが実際に機能しませんでした。 またはあまりにもひどく働きました。



Habréに夢中になって、私たちはLsyncdプロジェクトを発見しました-各ディレクトリでハングするInotifyウォッチャーと、ファイルの作成/変更/削除のイベントによってトリガーされる同じRsyncを介して動作します。 私たちは試してみることにしました：約1時間、100万個のディレクトリでハングしましたが、最終的には動作し、何かを同期し始めました。 しかし、Lsyncdには再試行と変更の長いリストの記憶に問題があることが判明しました。







はい、Lsyncdはサーバー間の通信で長い中断を経験しています。

岐路に立って：アマゾンとあなた自身のルナパーク？

「聖杯」を探した結果、次の2つのオプションの奇妙な岐路にたどり着きました。



S3-Likeストレージを使用します -たとえば、Amazon S3または多くのアナログの1つ。 オプションとして、自分にデプロイします。 そのようなアプローチは、一方で、ファイルがどこにどのように保存されているかを考えるのをやめ、生活を始めることができます。一方で、多くの新しい問題を約束します。



まず、ファイルを操作するためにコード全体を書き直さなければなりません。さらに、ファイルがほぼ瞬時に即座にディスクに書き込まれるという事実に依存する場所をリファクタリングする必要があります。 第二に、デバッグ中に必要になることがあるMidnight Commanderファイルをウォークスルーする機能が失われます。



第三に、このスキームのファイルが他の人の叔父のものである場合、それらはどんな汚いトリックでも私たちに合うことができます-例えば、突然価格を2倍にするか、あなたのサービスを落として、ウィンドウでミスをします はい、ファイルはSwift / Elliptics / Riakにある可能性があります-しかし、たとえばYandexの場合、データが私たちのものよりも10倍多い場合は合理的です。 すぐに5台のサーバーに配置されます。3台はデータがあり、2台はマネージャーです。これは最小限です。



一般的に、タスクに必要以上に難しい。



独自の高度に専門化されたソリューションを開発します。 だから、あなたのルナパーク-まあ、またはあなたが好きな自転車。 はい、とにかくコードを書き換えることができます：しかし、そのほとんどが通過する場所を見つけることができます。 そして、この場合のファイルは、サーバー上の通常のファイルの形式です。



唯一の欠点があります-これは自分で行わなければならず、場所がなくなる前に間に合うようにする必要があります。 Xは2017年の新年の前夜でした。

ターニングポイント：または上級の仲間が行う方法

自作ソリューションを支持する選択には時間がかかりました。 同時に、ホテル経営者や非女性だけでなく、ワークショップでの同僚の経験にも導かれました。イベントで彼らを捕まえて、慎重に尋問しました。





親愛なる同志、私たちの考えが理解できませんでした。



おそらくターニングポイントは、おそらくVKのメンバーとの会議でした。会議の傍らで、彼らがファイルを同期する方法を尋ねました。 彼らはまた、自分が同期できると言いました。





後で、Badooで写真が同様の方法で同期されることがわかりました。



一般に、マキシムはシステムを書くために座って、その間、LVM zashniksからディスクスペースを取り出し、重いログをクリーンアップしました。

「Vershansky comb」：非同期性のある並列性の問題を解決する方法

Rabbitmq（プロジェクトで既に使用されていました）とfpm npmモジュールをシステムの基盤として使用しました-ほとんどのファイル操作はそれを通過しました。 アイデアはこれでした-fsモジュールを再定義し、キューで実行されるすべてのアクションを強制的に書き込み、完了したと見なします（プルコールバック）。 キューの隣にデーモンが起動され、キューからジョブを取得し、http経由で受信サーバーで実行される別のデーモンに送信します。 これがファイルを作成している場合、削除する場合は削除コマンドなどを送信するためにファイルを送信します。



ただし、 Node.jsがデフォルトで行うように、すべてのタスクを連続して実行し、非同期で作業する場合、アクションが順不同になる可能性があります。 たとえば、まだ存在しないフォルダーなどにファイルを書き込もうとします。 また、タスクを順番に完了すると、時間がかかります。



キッチンでこのジレンマについて話し合ったとき、ビティヤは偶然であることが判明しました。 VityaはCRUDの動作を象徴する垂直線を描き始めました。線は互いに平行に走り、a、b、c、dと呼ばれていました。





ギターで-これはVityaです。 会社でこのような興味深いことに取り組んでいるパシャも、「くし」のアイデアを完成させるのを助けました。



ビンゴ！ ファイルは古き良きa / b / cスキームに従って保存されます。つまり、サイトvasya.ruはパス/v/a/s/vasya.ruに沿って配置されます。 私たちは、受信側が1つの「上位」レター内で順番にタスクを実行することを決定しましたが、それは非同期です。 それは迅速かつ確実に起こりました。 また、ボード上のVitiの図は櫛に似ているため、この原則は、たまたま適切な場所に適切なタイミングでいたプログラマーにちなんで命名されました。

ナノ秒を考えないでください：レコーダーシステムをテストする際に考慮すべきこと

テストするものがすでにある場合、古代の場合と同じ方法で2つの場所でディレクトリの同期を確認することにしました。つまり、Rsync自体がドライランモードです。



このオプションでは実際には何も起こりませんが、発生するアクションは表示されます。コピーする必要があるすべてのファイルがそれぞれ表示されます。これが「非同期」のポイントです。







別の問題が待っていました -Node.jsはctimeファイルを最も近いミリ秒に設定し（その後さらにゼロにします）、Rsyncは同じもののファイルを比較するときにナノ秒も考慮します！ そして、実際には同じファイルであっても、ファイルが異なると考えます。



ファイルのmd5ハッシュを計算して比較できますが、これは非常に遅いです。 UltraHDモードで作成時間ファイルを変更できる既製のモジュールを検索しても何も起こらず、これらの目的のためにCでモジュールを作成する必要がありました。 これが、同期の起源に戻ると、プログラミングの起源に戻った理由です。

ハッピーエンド：2つのメンバーサーバーのヒロイックレスキュー

すべてが順調に進み、2番目のサーバーのディスクをより大きなサーバーに交換する準備を始めました。



移行の準備として、彼らは、愛情を込めてcoolSyncと呼ばれる「コールド同期」スクリプトを作成しました。長い間ディスク上にあり、何のアクションも行わないファイルをダウンロードします（ただし、どのファイルかはわかりません）。 通常の再帰的Rsyncを使用したバリアントは、ここには適合しませんでした。 この再帰は永遠に続き、結果として生じるファイルのリストは、完了しなければ関連しなくなります。 スクリプトはa / b / cパス自体を生成し、それらに沿って歩いて、「詳細な」フォルダのみをバイパスし、各反復で個別のフォルダごとにRsyncを実行しました。 わずか1週間で、ほぼすべてのファイルをダウンロードすることができました。









ほんの数週間で、「ほぼ」の理由を決定しました。 2台のサーバー間の個々の「文字」の同期を確認し始めたとき、失われたファイルが発見されました。たとえば、ファイルが作成直後に別のディレクトリに移動され、送信デーモンが適切な場所でそれを見つけられなかったことが判明しました。



その結果、これらの問題を克服することができました-新しい2017年はすでに鼻にかかっていましたが、ハリウッドの大ヒット作品のように、X時間で管理しました。システムは次のように機能します：

エピローグの代わりに

残念ながら、そのようなプロジェクトのための既製のソリューションもありませんでした。 したがって-Lunaparksを構築してください！ そして、あなたの経験を共有してください。