Badooバックエンド開発者に尋ねてください。 パート1.プラットフォーム

RedditのAMA（私に質問してください）形式が本当に好きです。誰か（この場合は開発チーム）がAMA subredditに来て、質問に答える準備ができていると言います。 最も記憶に残る「Ask Me Anything」セッションのうち、たとえばSpace X エンジニアまたはGoogleエンジニアのチーム、そして現在の米国大統領バラク・オバマでさえ、4年前にRedditに関する質問に答えました 。 最近、 AndroidチームがAMAを実施し、開発者からのオンラインの質問に回答しました。



しかし、ロシアにはRedditはありません。 しかし、Habrがあります。 そのため、「質問する」形式でここに来ることにしました。 そして、AMAのルールが言うように、手ぶらではありません。 トピックを理解しやすくするために、チームの1つ（「プラットフォーム」）を選択し、子供たちに何をしていて、何をプログラミングしていて、チームの存在中に達成したことを教えてもらいました。 そして、2016年の発信の小さな結果を要約しました。 行こう！

目次

1.「プラットフォーム」の機能

2.サービス：ピンバ、ソフトモックなど

3.システムプログラミング。 Goの使用を開始した方法とそれがもたらしたもの

4.写真

5.スクリプトクラウド

6. LSD：ライブストリーミングデーモン

7. Cassandra Time Series：内容と仕組み

8. Badoo AMA：プラットフォームの開発者に質問する



これが本当に私たちであることの証明 。

プラットフォームは何をしますか

アントン・ポバロフ 、 einstein_man 、プラットフォーム長

ミハイル・クルマエフ 、 demi_urg 、Aチーム代表



「プラットフォーム」とは、他の部門を支援するインフラストラクチャチームです。 私たちの主な目標は、すべての人が幸せであること、すべてが機能すること、プログラマーが幸せであること、あらゆる種類の複雑なものを見ることなく安全にコードを書くことができることを確認することです。 私たちはバックエンドのバックエンドです。



「プラットフォーム」は2つのチームで構成されます。Cプログラマーのチーム（Cで記述されていますが、最近ではGoで記述されています）とAチーム（PHPで記述され、Goで記述されることもあります）。 Syshersはサービスを記述し、PHP拡張機能を作成します。 A-Teamは、PHPとデータベースインフラストラクチャ、および他のチーム向けのツールの開発とサポートに従事しています。



ユーザーが見るもの（使用するもの）の観点から特定のプロジェクトについて話す場合、私たちは次のことに従事します。

• 写真：ストレージと配信のインフラストラクチャ全体が私たちにあります。
• 独自のスクリプトクラウドがあります（これは「分散クラウン」であり、マシンのクラウド上でオフラインハンドラーを実行できます）。
• サービスのすべての「ラッパー」を担当します（他のBadooチームにサービスへの便利なアクセスを提供します。シャーディングがあるため、自己記述型の複製方法があります）。

私たちは「ラッパー」に責任があります。なぜなら、作業を単純化し、メインタスクからのすべてが突然中断したときの予期しない状況を防ぐために、他のチームのバックエンド開発者からこれらの内部をすべて隠したいからです。

サービス：ピンバ、ソフトモックなど

当社の内部サービスの一部は、時間の経過とともに本格的な製品に成長し、PHPエコシステムの事実上の標準になりました。 それらの中で最も有名なのはPHP-FPM（現在はWebの標準PHP配信の一部になっています）、Andrey Nigmatulin（ このトピックに関するレポートはこちらで確認できます ）、およびPinba（http://pinba.org/）収集するオーバーヘッド（UDP）なしで実行中のアプリケーションからリアルタイム統計を受信します 。これにより、いつでもアプリケーションのパフォーマンスで何が起こっているかを簡単に理解できます。



ピンバは、常にデータを収集できるという点で便利です。 そして、問題の原因を理解する必要がある場合、このデータは常に手元にあります。 これは便利で、問題を見つけて修正するのにかかる時間を大幅に短縮します。 さらに重要なことは、Pinbaがユーザーにまだ影響を与えていないときに、問題を事前に確認するのに役立つという事実です。



また、SoftMocksを発明して作成しました。これは、ユニットテストを容易にする独自のフレームワークであり、テストでクラスと関数を置き換えることができます。 インタープリターの内部アーキテクチャが大幅に再設計され、古いRunkitが機能しなくなったPHP7への移行に関連して作成する必要がありました。 当時、約5万のユニットテストがあり、その大部分は何らかの方法でmokiを使用して外部環境を分離し、Runkit / Uopzより強力な可能性のある別のアプローチを試すことにしました。



SoftMocksの主な利点の1つは、インタープリターの内部構造からの独立性と、サードパーティのPHP拡張機能が不要であることです。 これは、当社が選択したアプローチにより実現されます-実行中のプログラムのソースコードを書き換え、インタプリタ内の動的な置換ではありません。 現時点では、 プロジェクトはオープンソースでレイアウトされており 、誰でも使用できます。



Badooには非常に強力なPHP開発者チームがいることをご存知かもしれません。 したがって、2016年にこのような規模のプロジェクト（Badooなど）をPHP 7に移行した最初の企業の1つであることは驚くことではありません。 この記事に出てきた経緯、出会ったこと、得たものについて読むことができます。

システムプログラミング。 Goの使用を開始した方法とそれがもたらしたもの

Marco Kevats 、 mkevac 、C / C ++プログラマー



C / C ++部門では、毎秒数十万件のリクエストを処理し、数百ギガバイトのデータをメモリに保存する高性能のインメモリデーモンを開発しています。 その中でも、ビットマップインデックスを使用する検索デーモンや自己記述JITを使用した検索デーモン、またはすべてのモバイルクライアントの接続とリクエストを処理するスマートプロキシなどを見つけることができます。 必要に応じて、PHP言語をニーズに合わせて拡張します。 いくつかのパッチはアップストリームに送られ、いくつかは私たちにとってあまりにも具体的で、いくつかはロード可能なモジュールの形で行うことができます。 NGINXのモジュールを作成および保守し、URLやデータの暗号化、高速のオンザフライ写真処理などを処理します。



私たちは筋金入りのシステムプログラマーですが、C / C ++プログラミングのすべての欠点（開発の遅延、潜在的なエラー、スレッドを使用したプログラミングの複雑さ）を完全に理解しています。



Googleの新しい、若々しく、有望な言語であるGoの登場以来、私たちはそれに興味を持ち始めました。 そして、2012年に最初の安定バージョンがリリースされた直後に、本番環境での使用の可能性を検討し始めました。



Goは、私たちの愛するCに精神とパフォーマンスを近づけることを約束しましたが、プロトタイプや最終製品でさえも、より速く、エラーを少なくすることができました。 そして、Goがそのチャネルやgoroutinesとの競争の同義語であるという事実は、特に私たちの想像力を刺激しました。



その瞬間、私たちは現実世界の人々の間の交差点を見つけるという新しいクールで非常に緊急の課題を抱えていました。 要件を聞いた後、私たちは合唱でほとんど叫びました：「これはGoのタスクです！」多数のユーザー座標ストリーミングを処理し、時間を含むいくつかの「座標」で正しく交差させ、何らかの結果を生成することが必要でした。 部品間の多くの相互作用、多くの並列計算。 一言で言えば、まさにGoの基本的なタスクは何ですか。



プロトタイプは1週間で3人によって作成されました。 彼は働いた。 彼はよく働いた。 そして、Goが私たちと共に定着することを認識しました。 2015年、 Anton Povarovが Badooの囲aboutについて詳しく説明しました。



しかし、私たちのロマンスが完璧だったとは言えません。 当時のGoは多くの問題を抱えた非常に若い言語であり、すぐに1秒あたり数万のリクエストを処理し、ほぼ100ギガバイトのメモリを消費する製品の作成を開始しました。



不要なメモリ割り当てを直接行わないように、またGoコンパイラがこれらの割り当てを行うことを決定しないように、サービスを最適化する必要がありました。 そして、ここでGoの美しさと便利さが再び現れました。 Goは最初から、コンパイラがスタックではなくヒープにピースを割り当てることを決定するために、パフォーマンス、メモリ消費をプロファイリングするための優れたツールを持っていました。 これらのツールの存在により、最適化は小麦粉ではなく、興味深く有益な冒険になりました。



最初のプロジェクトでは、Cで記述された既存の地理計算ライブラリを使用する必要がありました。そのため、これら2つの言語の相互作用の問題とニュアンスの非常に厚い部分に突入しました。



Goはボトムアップのイニシアチブであったため、同僚やマネージャーがすぐにアイデアを拒否しないようにする必要がありました。 Goプロジェクトを操作側のCプロジェクトと変わらないようにする必要があることを理解しました：JSONの同じ構成、同じ対話プロトコル（JSONのメインのprotobufとセカンダリ）、同じ標準統計RRD。 GoでのエンジニアリングプロジェクトのリリースがCのプロジェクトとまったく異なることを確認する必要がありました。同じGit + TeamCity Flow、TeamCityでの同じビルド、同じ計算プロセスです。 そしてそれをやった。



管理者、運用、およびリリースエンジニアは、プロジェクトの内容について考えません。 新しいツールは実際には完全に証明されているため、新しいツールを使用することを恥ずかしがり屋ではないことに気付きました（重要ではないタスクで、開始する必要があります）。



ゼロから何も作成しませんでした-Goを長年にわたって存在するインフラストラクチャに組み込みました。 この事実は、Goの標準的なものの使用を制限しました。 しかし、私たちがすぐに深刻な高負荷プロジェクトを書き始めたという事実と相まって、この事実が、私たちが真っ先に言語の頭に突入することを可能にしました。 私たちは汚いことで有名ですが、この近接性は私たちがこの美しい言語と「共に成長する」のに役立ちました。



Goの各バージョンで、子供が大人になって成長する様子を見るのは面白かったです。 新しいバージョンごとにデーモンのGCが一時停止するのを見ましたが、これはコードを変更することなく行われます！



この言語での4年間の作業の後、3つのチームでGoの約10の最も多様なサービスと、さらにいくつかの新しい計画があります。 囲はしっかりと兵器庫に入っています。 私たちは、それを「調理」する方法と、いつ使用するかを知っています。 何年も経った後、プログラマーが「Goでプロトタイプをすばやくスケッチする」や「並列処理と相互作用が非常に多いので、これはGoに適している」などのことを定期的に言っているのを聞くのは興味深いことです。

写真

Artyom Denisov 、 bo0rsh201 、シニアPHPプログラマー



写真は製品の観点からBadooの重要なコンポーネントの1つであり、私たちは単にそれらの保管と表示のためのインフラストラクチャに多くの注意を払う義務があります。 現時点では、約3 PBの写真を保存し、ユーザーは毎日約350万の新しい写真をアップロードし、各サイトでの読み込み負荷は約80k req /秒です。



概念的には、次のように構成されています。 当社は、3つのデータセンター（マイアミ、プラハ、香港）に3つの拠点を置いており、ほとんどのターゲット市場に地域を提供しています。



インフラストラクチャの最初の層は、着信トラフィックの98％を処理する高速SSDを備えたサーバーをキャッシュし、独自のミニCDNを実行します。これは、負荷の性質に最適化されたキャッシュプロキシであり、多くの実用的/製品ロジック（ACL、サイズ変更、オーバーレイフィルターとウォーターマークのオンザフライ、サーキットブレーカーなど）。



次の層は、長期保管を担当するサーバーのペアのクラスターです。

そのうちのいくつかは、写真が直接保存されるローカルディスクを持ち、いくつかは3番目の層であるストレージエリアネットワークに光学的に接続されています。



これらのマシンのペアは同じユーザー範囲を提供し、マスター-マスターモードで動作し、非同期キューを介して相互に完全に複製およびバックアップします。 このようなペアが存在することにより、ハードディスクレベルだけでなく、物理ホスト（カーネルパニック、再起動、ブラックアウトなど）のレベルでもフォールトトレランスを実現できます。また、スケジュールされた作業を実行し、サービスを低下させることなく障害に耐えることができます。スケールは珍しくありません。



写真を使用した作業の詳細については、 Artyom Denisovが今年Highload ++で 講演しました 。

スクリプトクラウド

どのプロジェクトでも、ユーザーのリクエストのコンテキストで実行されるアクションに加えて、延期された、または特定のスケジュールに従って実行されるバックグラウンドタスクが多数あることは秘密ではありません。 通常、彼らは何らかの種類のバックグラウンドワーカースケジューラを使用します（最も単純な場合、これはcronです）。



そのようなタスクの数とそれらによって消費されるリソースの量が増加すると、徐々に1つ、場合によっては数十の物理マシンに適合しなくなり、これらのクラウンを管理し、クラスター内の各ノードの負荷を手動で調整することが難しくなります。 そのため、開発タスクを透過的に起動するための柔軟なインフラストラクチャであるクラウドを作成する必要がありました。



次のように機能します。



1）開発者は、いくつかのインターフェイス（クラウンスクリプト、キューパーサー、データベースクローラーなど）の1つを実装するPHPクラスの形式でジョブを説明します。



2）Webインターフェイスを介してクラウドに追加し、起動頻度、タイムアウト、およびリソース制限のパラメーターを選択します。



3）次に、システム自体がクラウドに割り当てられた分散インフラストラクチャでこのジョブを起動し、その実装を監視し、クラスターの負荷を分散します。 開発者は、ジョブの作業のステータスを監視し、Web UIを介してログを確認することしかできません（実行されているインスタンスの数、設定の終了、開始方法など）。



現時点では、クラウドには2つのDC〜48k CPUコア/ 84Tbメモリに約2000のホストがあります。 1800のユーザージョブは、1秒あたり約4,000の開始を生成します。



こことここでクラウドについて話しました 。

LSD：ライブストリーミングデーモン

何らかの方法で大量のデータを扱うすべての人は、それらをストリーミングするタスクに直面しています。 原則として、多数の異なるソースからのデータを1か所にストリーミングして、そこで一元的に処理できるようにします。 さらに、このデータのタイプはしばしば役割を果たしません。アプリケーションログ、統計、ユーザーイベントなどをストリーミングします。 概念的には、2つの異なるアプローチを使用してこの問題を解決します。



1）製品/アプリケーションロジックに関連するイベントを配信するためのキューサーバーの独自の実装。



2）さまざまなログ、統計メトリック、および多数のノードからの単純に大量のデータをストリーミングするためのシンプルなメカニズム。これらは、一元的に集約され、1つの場所で大きなバンドルで処理される必要があります。



2番目のタスクでは、 Facebook Scribeを長い間使用していましたが、そこを介して送られるデータ量が増加するにつれて、予測しにくくなり、長い間忘れられていました。



その結果、ある時点で（このタスクはそれほど難しくないように見えるので）独自のソリューションを作成するほうが収益性が高くなり、メンテナンスが容易になります。



独自のストリーミングイベントLSD：Live Streaming Daemonを呼び出しました。



LSDの主な機能：

• プレーンファイルからの文字列形式のトランスポート（クライアントにとって、ローカルFSファイルにデータを書き込むことほど信頼できるものはありません）。
• すべての宛先サーバーが利用できない場合でも、記録中にクライアントはブロックされません（バッファーはローカルFSに蓄積されます）。
• ネットワーク/ディスクリソースの消費の制限の透過的な制御/設定。
• 互換性のある記録形式/レシーバーでのファイル集約の方法を記録します。

今年、LSDのソースコードを公開しましたが、プロジェクトで使用できるようになりました。

Cassandra Time Series：概要と仕組み

Evgeny Guguchkin 、 che 、シニアPHPプログラマー



Badooは、多くの関連コンポーネントで構成される複雑なシステムです。 このシステムの状態を評価するのは簡単なことではありません。 これを行うには、1秒あたり約200,000値の速度で2億5,000万を超えるメトリックを収集します。このデータは約10 TBかかります。



歴史的に、時系列の保存と視覚化には、よく知られたユーティリティRRDtoolを使用しました。これは、作業の利便性のためにフレームワークで「ラップ」しました。



RRDtoolで気に入ったのは、読み取り速度です。 ただし、重大な欠点があります。

• 多数のランダムアクセスI / Oによって引き起こされる高いディスク負荷（SSDとRRDcachedを使用してこの問題を解決しました）。
• 遡及的に記録する機能の欠如：つまり、ある時点の値を2016-01-01 00:00:00に記録した場合、2015-12-31 23:59:59の値を記録することはできなくなります。
• 疎データ用のディスクスペースのかなり無駄な使用。
• データへのアクセスはローカルで実行されます。箱から出して水平方向にスケーリングする分散システムを構築することは不可能です。

それがなければ、同じチャートに異なるサーバーからのメトリックを表示できなかったため、それが私たちにとって決定的になった最後のポイントでした。



その結果、時系列データベースの分野における既存のソリューションの詳細な分析を行い、誰も適切ではないことを確認し、Cassandraに基づいて独自のソリューションを作成しました。



現時点では、実際のデータの半分が新しいストレージに複製されています。 数字では、次のようになります。

• 9台のサーバー。
• 10 TBのデータ。
• 1秒あたり100,000値。
• 1億4000万のメトリック。

同時に、私たちが直面したほとんどすべてのタスクを解決しました。

• クラスター内の1つのノードに障害が発生しても、読み取りまたは書き込みはブロックされません。
• 「生の」データが1週間（データを変更できるウィンドウ、操作中に構成および変更できるウィンドウ）より古いものではない場合、追加することも「生の」データを書き換えることもできます。
• クラスターの単純なスケーリング
• 高価なSSDドライブを使用する必要はありません。
• さらに、HDDのRAIDアレイを冗長性なしで使用しないことも可能です。ディスクを交換すると、ノードは隣接レプリカからデータを回復できるからです。

既存のソリューションを分析し、新しいソリューションを構築するために行われた作業を非常に誇りに思っています。 Cassandraでの作業中に無数のレーキを踏んだので、喜んで質問に答え、経験を共有してください。

Badoo AMA：プラットフォームの開発者に質問する

そして今、実際に、なぜこの投稿を公開するのか。 本日12:00から19:00（モスクワ時間）、プラットフォームチームが質問に答えます。 チームの存続中に多くのことを経験しました。拡張、変更、研究、いくつかの問題に直面し、新しいプログラミング言語に取り組みました。 そして、私たちはあなたの経験をあなたと共有する準備ができています（feyl、fakapy、私たちの痛みについて話すことを含む）。



たとえば、次について質問します。

• 内部プロジェクトの配置（シャーディングの配置方法、統計の収集および描画方法、サービスとの通信方法）;
• どのようなレーキを踏んだのか、特定の決定を下した理由（1つのDC、1つのサーバーに適合しなくなったときに何をしたのか）
• PHP / Cプログラマーの強力なチームの作業のカスタマイズ。
• PHP 7への移行（発生する可能性のある問題）;
• 負荷の高いプロジェクトで作業する機能。
• PHPおよびGoプログラマへの推奨事項。
• 上記の投稿で説明されているすべて。

しかし、そこで止まらないでください！



UPD：質問を寄せてくれたすべての人に感謝します。AMAセッションを終了しますが、回答は続けますが、すぐには答えません。 したがって-もう一度質問してください。