プロジェクトの生涯から1年

この記事では、プロジェクトAnswersに関連するタスクの実装で遭遇したすべての困難と落とし穴を思い出して説明し、プロジェクトのアーキテクチャについても説明します。



それはすべて、私の契約が終了したという事実から始まりました（Mail.ruメールの作業に参加した年の間に）。 「冒険は再び私を待っています」、「新しい国、新しい仕事」と私の考えをフラッシュしました。 私は上司のもとに行きましたが、それでも議論の過程で、面白いプロジェクトの形で冒険の一部を受け取りました-応答プロジェクトを取り上げます。



2012年10月15日の時点で、プロジェクトには1日あたり平均350万人のユニークビジターが訪れました。

カウントは、各訪問者に発行される一意の「Cookie」（Cookie）によって実行されました。 訪問者のブラウザでCookieの受信が無効になっている場合、訪問者はカウントされません。

プロジェクトの名刺はスクリーンと呼ばれることもあります。スクリーンは誰もが知っていると思います。







使用されたテクノロジーのセットは次のとおりです。

• CentOS 5 i386
• Apacheでのmod_perl
• Nginx
• SQLデータベース
• rsyncを使用した戦闘中のコードのレイアウト

アーキテクチャ：

名	行き先	CPU	ラム、GB	hdd	メモ
プリムス	正面	2xE5504	8	2 x sata	エントリーポイント、バランサー
アルファ	ベック	2xXeon古い	2	2 x scsi	その上で、すべてのクラウンスクリプトを起動します
アルゴン	ベック	2xE5504	8	2 x sata
ブタン	ベック	2x E5506	4	2 x sata
ルナ	ベック	2xE5405	8	2 x sata	ここでwapとmバージョン
オクタン	ベック	2xE5405	8	2 x sata
メタン	ベック	2xE5506	4	2 x sata
プロパン	ベック	2xE5405	4	2 x sata
ラドン	ベック	2xE5504	8	2 x sata
ネオン	ベック	2xE5-2620	16	2 x sata	新しい
窒素	ベック	2xE5-2620	16	2 x sata	新しい
プラズマ	ベック	2xE5-2620	16	2 x sata	新しい
タイタン	拠点	2 x E5620	96	4sata + 20sas	マスター
ブラン	拠点	2 x E5620	64	2 sata + 4 ssd	一次レプリカ
極大	拠点	2 x 5110	32	2 sata + 4 scsi	管理パネルのレプリカ
ミニマス	拠点	2 x 5110	16	2 sata + 4 scsi	管理パネルのレプリカ
巨人	拠点	2 x 5130	8	6 scsi	コメントベース

問題は次のとおりです。

• プロジェクトの不安定性
• このSQLデータベースの運用部門にはスペシャリストがほとんどいません。データベースが落ちたときに、何が何でなぜ理解できない唯一のスペシャリストが常に利用できるわけではありません。
• レプリカの遅れの永遠の問題、それを解決する人はいない
• データベース内のロジックの90％が新しい機能の開発が難しい

リーダーシップからの挑戦

サービスの安定した運用とそのさらなる開発の可能性、特にモバイル版の起動を確認してください。

Mysqlに移行してプロセスロジックをグローブに入れると、ほとんどの問題が解決します。



最初のステップは監視でした。 私は彼について記事に書きました（ところで、

AnyEventで書き直したところ、生産性は毎秒50から24万行に増加しました）。



彼は次のことに目を開けました。

1. 私たちは毎日落ちます！
2. エラー504の膨大な背景、1日約5万。

504の理由は何ですか？

• 遅いHTMLパーサーで、質問ページを表示するとき、つまりオンザフライでその仕事をします。
• コンテンツをダウンロードするボット。
• YandexとGoogleのインデックス。

Yandexからの手紙：

otvet.mail.ruについては、負荷を増やし始めましたが、1分あたり200を超えるリクエストを行うことはしませんでした

時刻に関係なくHTTP 503を受信し始めると判明します。 可能ですか

あなたの側でそれを排除しますか？

別の問題が表面化しました。バランサーでは、1つのIPから1秒あたり1つのリクエストの制限があり、それを増やすと負荷に対処できなくなります。



検索トラフィックはResponsesプロジェクトにとって最も重要なことなので、迅速に行動する必要があります。 誰もが緊張していて、状況は過熱しています=）。



最も単純で、最も簡単で、安価なものから、ネオン、プラズマ、窒素の3つのバックエンドを購入しました。 プリムスバランサーにRAMを追加しました）、許可されていないすべてのユーザー向けにnginxに約40％のhtmlキャッシュを追加しました。 バランサーの制限は、1秒あたり15リクエストに増加しました。



彼らは毎日落下を止め、Yandexはもはや私たちについて不平を言いませんでした。 重大な問題が解決されたので、タスクについて考えることができます。



今後は、新しいAPIで、遅いHTMLの問題が解決されたと言います。 独自の解析済み（Perl XS）パーサーを適用し、データベースに保存するときにのみ解析しました。 誰かがXSSを見つけると、すべての文字を解析するのに多くの時間（5ペタバイトのデータ）がかかるため、そのようなソリューションはメールには適していません。そのため、保護を追加し、その場で解析するのがより簡単で迅速です。



移行とモバイル版



移行は、データの整合性の維持とプロジェクトの24時間365日のパフォーマンスという2つの条件を満たす必要があります。 したがって、プロジェクトをオフにしてデータを転送すると失敗します。



APIを作成します。これに基づいて、モバイルバージョンと将来の「ビッグ」バージョンの両方で、すべてが機能します。 APIはマッスルからのみ読み取り、古いデータベースと新しいデータベースの両方に書き込みます。



MySQLが古いデータベースから変更を取得するために、同期する必要があるエンティティを書き込むキューを開始しましょう（古いエンティティから取得して、新しいエンティティで追加または置換します）。



これを行うには、ベース全体をエンティティに分割する必要があります。 たとえば、回答、質問、ユーザー、すべてのユーザーの回答などを再同期するタスク。



また、同期のためのタスクのストリームが膨大であるため、このキューのハンドラーが並行して動作することを考慮する必要があります。 最終的に12個のフォークを処理できました。



これはすべて必要なため、いつでもキューにタスクを追加して、必要なエンティティを完全に再同期できます。



それで、それは始まりました。 1月10日、 アレックスQ大麦がリリースされました。 ラインは筋肉に実装されました。 マッスル用に2つのサーバー（「バーチ」と「パイン」と呼ばれる）と2つのフロント（「バロン」と「バーボン」）を購入しました。 マッスルマスターとレプリカ。 彼らは古いバージョンに、再同期のためにキューにタスクを書くことを教えました。 それは非常に日常的で、痛みを伴う長いプロセスでした。 古いグローブに書き込む小さなグローブのすべての場所を見つけて、対応する再同期タスクでバックアップする必要がありました。

現時点では、主なことは次のことを忘れないことです。

• データベース内のcronジョブ。 その後、データベース内のパッケージコードに干渉したくないため、新しいバージョンにアナログを実装する必要がありました。
• 通常の王冠スクリプト。 彼らのために、我々は新しいバージョンで同様のものを書きました。
• まあ、最も陰湿な、これらはトリガーです。 私たちの場合、ベースの戦闘バージョンは開発バージョンとは異なることが判明しました。 したがって、これを注意深く徹底的に確認してください。

上記のエラーはそれぞれ14日間かかります。 なぜそんなに多いのですか？ これについては後で詳しく説明します。



そのため、古いバージョンはキューに書き込み、負荷を確認できます。 古いバージョンを最初に2つのベックで展開し、次に4つのベックで展開し、筋肉を確認します。すべて問題ありません。すべての分岐で展開し、負荷を維持します。 次のステップに進みます。



彼らは、子を分岐して追跡する方法を知っているキューハンドラを作成しました。子が落ちたら、新しい子を生成します。 彼はタスクの一部を取り、それらを再同期し、それらを必要な構造に変えます。 将来的には、2つの戦略のうち、それぞれがあらゆる種類のタスクをレイクする12のフォークの起動が、タスクAを実行する4つのフォーク、タスクBを完了する4つのフォークの起動よりも遅いことに気付きました。



これは、キュープロセッサが現在のパスで再同期したエンティティを記憶し、再度一致する場合はそれらをスキップするという事実によって説明されます。また、エンティティの種類を制限すると、既に処理されたタスクに入る確率がはるかに高くなります。



その結果、キューに書き込むように古いバージョンを教えました。キュープロセッサは準備ができています。 古いバージョンが戦闘に投入されます。 キューは山積みになっていますが、これまでのところはレイクされていません。



次に、すでに蓄積されたデータをあるデータベースから別のデータベースに転送する必要があります。 約500ギガバイトです。 どうやってやるの？ ありがとうアレックスQ =）

チャレンジ：

古いSQLデータベースからMySQLへの大きなテーブル（最大1億5千万レコード）の移行。 同時に、構造は（わずかに）変更できます。たとえば、古いSQLデータベースでは、ブール型フィールドはCHAR（1）でした（非表示には値 ''または 'H'を使用できます）。MySQLではTINYINTになります（非表示は0または1になります）。

データ転送に加えて、古いデータベースでデータを追加および変更できます。 この問題は、古いデータベースのどのデータが変更または追加されたかについての情報が書き込まれるキューを作成することで解決されます。 テーブルの移行中、「事前同期」のジョブはキューに蓄積されます。 その後、キューは別のスクリプトで解析されます。

移行：

1. INSERTを使用するよりもはるかに高速であるため、文字列の1000（デフォルトでは、スタートアップキーによってオーバーライドされる）のパックでLOAD DATA INFILEを介してMySQLにインポートします。
2. FIFOパイプをデータ転送ファイルとして使用します。これは、すべてのデータがディスクに書き込まずにメモリを通過するためです。 ファイルを使用するよりも大幅に高速になります。
3. このスクリプトは、古いSQLデータベース（たとえば、10000）からN行を読み取ります。
4. スクリプトは子プロセスを解析します。 このプロセスでは、読み取り用のFIFOが開かれ、そこからMySQLでLOAD DATA INFILEが実行されます。
5. 親はfifoにK行（たとえば1000）を書き込みます。 各パックの後、パイプのファイルハンドルを閉じ、子プロセスが終了するまで待機し、ステップ1で取得したデータがなくなるまでステップ2から繰り返します。

2013年2月26日-最初のコミット。 2013年3月6日までに、作業バージョンが準備できます。 着信テーブル（古いSQLデータベース）と出力テーブル（MySQL）old_to_MySQL（）の説明を取得する関数を作成し、すべての処理を実行しました。 突然のfakap中にゼロから開始しないように、old_migrate MySQLテーブルに各テーブルの最後に移行された行のIDを保存します。



LOAD INFILE IGNOREではなくLOAD INFILE REPLACEを使用しているため、fakapから回復するときに、古いSQLデータベースのデータ変更が失われることはありません。



3月15日、デフォルト値の問題は一時的に解決されました。古いSQLデータベースからNULLが発生し、MySQLのNOT NULL DEFAULT列が0の場合、NULLを挿入しようとするとクラッシュします。 スキームの説明には、必要なキー列のセットがあります。残りはすべて、NULLが来た場合にDEFAULTを挿入します。



3月20日、SIGPIPEとの戦争が始まりました。



戦争の段階：

• $ SIG {PIPE}を追加しました。これは、保存された位置からの古いパラメーターを使用してold_to_MySQL（）の呼び出しを繰り返します。 長い間、すべてが機能していました。
• 11月13〜14日、SIGPIPEが反撃。 パイプを操作する手順を修正しました。まず、読み取り用にfifoを開き、次に書き込み用にfifoを開きます。 sigipeとの戦いの間に、die / warnの代わりにcroak / carpを追加し、Carpのバグ72467（解放されたスカラーをコピーしようとする）に遭遇し、すべてを元に戻しました。
• 助けにはなりませんでした 睡眠は、読書のためにパイプを開いた後すぐに助けにはなりませんでした。 一時ファイルに登りました。 それはすべての睡眠を緩めたことにより著しく速くなり、シギペとの戦いで松葉杖として役立った。 良くなりました。

シグシプ戦争は、11月13日と14日に2日間続きました。 とても忙しい2日間でした。

合計で、これらの500ギガバイトを転送するのに14日かかりました。

転送の進行中、新しいAPIのアルファ版（Perl、fast_cgi）は既に準備されていました。



データを転送し、企業ユーザー向けのテストモバイルバージョンを開始しました。 見て、テストします。 偶然、古いバージョンのログで、背中の1つで、小さなperjochkaがDBDモジュールがないことを誓うというエラーに気付きました。 これは、前からのジョブがキューを離れておらず、ベースが一貫していないことを意味します。 ああ、クソ 私はすべてを再び転送しなければなりませんでした。 14日が経過しました=）。



これで、データ転送後、キューのレイクを開始でき、約3億の巨大なジョブが蓄積されました。



ハンドラーの開始-遅すぎる。 私たちはブレーキの原因を探していましたが、ターンしたプレートのインデックスが必要であることがわかりました。 私は本当に14日間再び待ちたくありませんでした。 別の同じプレートを作成しましたが、インデックスがあります。 彼女たちは古いバージョンを公開し、彼女はインデックス付きの新しい版に書いた。 それはInnoDBでした。 インデックスを追加しました。 彼らはタブレットをかき集めて殺しました。 すべての名前を元に戻しました。



うまくいくようです。 どうぞ



新しいAPIは、両方のデータベースに書き込むことができる必要があります。 あまりにも多くの時間を待たないように非同期に書き込みます。 これを行うには、新しいデータベースのテーブルで、自動インクリメントの初期位置を使用してidで予約します。 たとえば、古いデータベースでは質問の最大IDは1000で、新しいデータベースの同様のテーブルでは、自動インクリメント2000の初期位置を設定します。



新しいAPIを使用して質問を追加し、識別子2001を見つけ、古いデータベースに追加し、そこに識別子1001を追加し、識別子2001でレコードを更新し、識別子1001でレコードに変換します。したがって、エンティティの識別子はデータベースで一致します。

その後、マッスルを再起動するか、テーブルを変更した後、自動インクリメントがプライマリキーの最大値にリセットされることを学びました。 したがって、これを回避するために、自動インクリメントの開始番号に等しい大きな識別子を持つエンティティデータベースをMySQLに追加しました。

必要なエンティティを再同期するためのタスクをキューに追加することにより、さらにすべてのphakapsが解決されました。



私はもう少し思い出しました：運用部門から、どういうわけか、データセンターの1つを完済しなければならないかもしれないというニュースを聞きました。モバイルバージョンはすでに戦い中であり、古いデータベースを持つサーバーがこのデータセンターにあるという事実を考えると、別の新しいMySQLデータベース-それは完全に悲しくなりました。 しかし、幸いなことに、予測は実現しませんでした。



何が起こったのか想像してみてください。



データセンターに古いデータベースを返済しました-その後、すぐに別のデータセンターの前面を丸くし（このニュースを知ったときすぐにそれを行いました）、モバイルバージョンを読み取り専用モードに切り替え、全員をモバイルバージョンにリダイレクトします。



データセンターに新しいデータベースを返済しました-同期のためにキューの記録をオフにします。 データセンターが機能し始めた後、問題の発生後に作成されたすべてのエンティティをキューに入れ、静かに再同期します。



3月、モバイル版が発売されました。 1日約50万人のユニークな人々がそこに来ました。 負荷を抑え、すべてがスマートに機能します。



プロジェクトのアーキテクチャは次の形式を取りました。

名	行き先	CPU	ラム、GB	hdd	メモ
男爵	正面	2xE5-2620	32	2 x sata	httpd + mod_fcgid、大きな電力マージン
バーボン	正面	2xE5-2620	32	2 x sata	httpd + mod_fcgid、大きな電力マージン
ベレザ	拠点	2xE5-2609	96	2 x SATA + 10 x ssd	mysqlマスター
ソスナ	拠点	2xE5-2609	96	2 x SATA + 10 x ssd	mysqlレプリカ
ピフタ	拠点	2xE5-2609	96	2 x SATA + 10 x ssd	mysqlレプリカ
荷馬車	メンケシュ	2xE5-2620	64	2 x sata	2つのmemcachedインスタンス

検索エンジンとJSが無効になっている人向けのサーバーバージョンの作成を開始しました。



彼らはそれをし、モスクワ地方に巻き込んだ。 1秒あたり800リクエストの負荷で、Apacheが燃えていることがわかりました。 最初はmod_fcgidに疑念がありましたが、犯人はmod_rpafであることが判明しました。 Monsのおかげで、彼はApache Apacheクラストを巧みにプレイしました。



彼らはmod_rpafを放棄し、nginxを使用してX-Real-IPヘッダーからIPを投げました。



彼らはロシア中にそれを転がしました、我々は負荷を保ちます。 彼らは新しい「ビッグ」バージョンを作成し、全員をリダイレクトし始めました。 11月19日、古いバージョンは終了しました。



プリムスバランサーの地獄の制限を削除しました（1つのIPから毎秒15リクエスト）。 負荷を通常に保ちます。 APIからの1秒あたり約950リクエスト。



出席者は1日あたり平均650万人です。



すべてのサーバーでCentOS 64ビットを使用し、RPMパッケージを介して戦闘への展開が行われます。 現時点では、perlachkaはまだApache2（mod_fcgid）の下で回転しています。 yumがバッグをロールバックした後、ベックを順番に再起動します。



前面では、次のものを使用します。

proxy_next_upstream timeout error http_502 http_504;







つまり、ユーザーが502または504を受け取った場合、ユーザーは別のバックエンドの使用を許可されるため、Apacheの再起動による不快感が最小限に抑えられます。



負荷チャートはこちらにあります 。



このメモが、私たちが歩いたレーキを踏まないようにするのに役立つことを願っています！ 覚えておいてください、あなた自身からよりも他人の間違いから学ぶ方が良いです！ :)