高負荷のアプリケーションアーキテクチャ。 分散システムのスケーリング。 パート1

しばらく前に、モスクワBadoo開発オフィスの副部長であるAlexei RybakとIT-Kompotのプレゼンターは、ポッドキャスト「高負荷アプリケーションのアーキテクチャ」のリリースを録音しました。 分散システムのスケーリング。」



これで、ポッドキャストを解読し、読み取り可能な形式に変換し、2つの部分に分割しました。



最初の部分で彼らが話したこと：

• Badooプロジェクトに関する一般情報：技術スタック、ワークロードの性質と量、トラフィック。
• プロジェクトの水平スケーリング：

-Webサーバー、キャッシュ、監視など。

-プロジェクトをスケーリングする際の落とし穴。

-データベースのスケーリング、シャーディングの方法。





プレゼンター： みなさん、こんにちは。ITCompotポッドキャストの第45号を聞いており、Anton KopylovとAnton Sergeyevがホストを務めています。

今日は、バックエンド、Web開発、より具体的には負荷の高いアプリケーションのアーキテクチャと分散システムのスケーリング方法についてお話しすることにしました。 ゲストのAleksey Rybakがこれをお手伝いします。 こんにちはAlexey！



Alexey Rybak：こんにちは！



Ved。：「My Circle」というサイトは、アレックス-プラットフォーム開発および代理の責任者だと言っています。 Badooのモスクワ事務所の長。 Alexeyはずっと前から、Pinbaサーバーの監視などを含むさまざまなテクノロジーを使用して、さまざまな複雑な分散高負荷システムを開発してきました。 多分私は何かを知らない-アレクセイは私を補うか、修正します。 さらに、ゲストは会議に積極的に参加し、PHPConfの大規模で強力な会議であるHighLoad組織委員会のメンバーです。



AR：少し修正したいと思います。 ピンバは私の同僚のアントン・ドヴガルによって作成され、最初のバージョンは一般的にアンドレイ・ニグマトゥリンによって作成されました。 そこに何か提案し、発明しました。

そして、はい、私は本当にBadoo開発の次長であり、主にプラットフォームプロジェクトを担当し、大規模な「オープンソース」プロジェクトを監督しています。 一般に、私が言うことはすべて、自分ではなく、私たちの人によって行われる可能性が高いです。 かなり大きなエンジニアのチームがあります。 私たちはマンバの時代から多くの人々と仕事をしています。 したがって、私がそのような巨大なシステムを一人で開発すると言うのはもちろん間違っています-私は管理作業にもっと関与しており、最近、いくつかの開発チームを率いてきました。



ヴェーダ： なるほど。 しかし、いわば、あなたを他の開発者のバックグラウンドから大きく引き上げるつもりはありませんでした。 チームに関する質問はまだありますが、聴衆はコメントでそのような質問をしました。



リスナーに小さな計画を発表します。 アレクセイは、自分自身、どのように始めたのか、何をしたのか、何に来たのかなどについて簡単に説明します。 誰かがプロジェクトが何かわからない場合は、Badooとは何かについて話します。 水平スケーリングの問題に触れ、一般的なスケーリング方法、そこにあるテクノロジー、問題とは何か、大規模なサービスの経験を使用して、このすべてを検討します。 また、今日おもしろい非常に興味深いトピックは、負荷の高いシステム（ジョブキュー、メッセージキュー）でのあらゆる種類の非同期タスクについてです。



アレクセイ、あなたがどのように開発の世界に来たのか、今何をしているのか、そして一般的に将来何をするつもりなのか、あなたの計画は何ですか。



AR：そうですね。 要するに、私は学校にいたときにプログラマーになるつもりはなく、一般的にはまったくプログラミングをしませんでした。 9年生から10年生のときに、Fortranを勉強するために大学に行きましたが、これらのクラスに入る前に、しばしばどこかでビールやワインを飲みに行きました。 一般に、私はどういうわけかプログラミングでまったくうまくいかず、モスクワ州立大学の物理学科に入り、物理学を勉強したかった。 しかし、90年代に物理学をすることにあまり意味がなかったため、友人全員が去り、ウェブ開発に参加することにしました。 そして、私が最初にしたことは、実際にウェブプログラミングではありませんでした-私はウェブマスターでした。 Perlでいくつかのスクリプトを書いて自動化したという事実に加えて、バナーを描いたり、Photoshopで何かをカットしたりしました。 その後、彼はさまざまな会社で働き、私は幸運でした-2004年に私はマンバに着きました。 これは非常に大規模なプロジェクトであり、ロシア語圏の国ですぐに普及しました。



Vedas： 誰もがこの出会い系サイトを知っていると 思い ます。これは最初の有名なソーシャルネットワークです。 少なくとも、私はインターネットの「ダイヤルアップ」の時から彼女を覚えています。



Vedas： はい。ドメインをこのシステムに固定し、ユーザーからコミッションを得る際に、「Mamba」と「アフィリエイト」を行うことは非常に人気があったことを覚えています。



AR： 「マンバ」であり、大小のパートナーを犠牲にして開発されました。 それは大きな前進であり、私のキャリアにおける革命でした。 とても小さいけれど、とてもプロフェッショナルなチームでした。 そこには、自分の間違いから部分的に学ぶ必要がありました。 特に数年前の開発に関連する膨大な数のミスを犯しました。 しかし、彼は生き残った-このプロジェクトはまだ生きています。 確かに、ほとんどの場合、すべてがすでにやり直されています。 2006年または2005年末のどこかで、私たちはこのプロジェクトに関与していません。現在、私たちは独自のチームを持ち、Badooプロジェクトに取り組み始めました。



当初から、Badooには非常に小さなチームがあり、一般的には、リモートの従業員やシステム管理者など、文字通り12人のエンジニアがいました。 それ以来、会社は成長しました。 そこで、Cデーモンを除く、バックエンドのサーバー側の開発全体、つまり、サイトの開発だけを目的として、主要機能のすべての展開を担当しました。 実際、もう1人の「テクノマネージャー」しかいませんでした。テクニカルディレクターは、まだ管理者と「シシュニク」の長でした。



ヴェーダ： しかし、私は知りたかった。 あなたはあなたのバックエンドがsyshnyであると言ったばかりです-あなたのアプリケーションには本当に多くのsoshコードがありますか？



AR：実際には多くのコードがありますが、もしそうなら、なぜこのような技術スタックがあるのか​​を少しお話しします。



ヴェーダ： 良い。 アレクセイ、あなたはすでに良い荷物を持っていて、出会い系サービスの開発の経験があり、そこで何をする必要があり、何をする必要がないかについてのいくつかのアイデアがあり、それが実際にBadooに入ったのですか？



AR：はい、私たちは過去数年間で非常に成長してきたため、開発を辞めなければなりませんでした。 しかし、ここで蓄積した経験は非常に興味深いものであり、それを記事に、スピーチに変換します。 大規模プロジェクトの開発に関するセミナーも開催しています。 したがって、このトピックは私にとって非常に興味深いものであり、私たちが学んだこと、使用する方法などについてお話させていただきます。



テクノロジースタックに関しては、Linuxと一連の「オープンソース」ソフトウェアを使用しています。 また、CまたはC ++で何も開発していなくても、何らかのアンダーグラウンドノックが発生することがよくあり、それが何であるかはわかりません。 社内で能力を身につける必要があります。それは、取得、オープンソース、読み取り、理解、修正です。 プロジェクトの特定の規模から、特定の負荷から、そのような能力があるべきです。 優れたシステム管理者がいて、原則として優れたシステム管理者がCコードを読み取れるとします。 しかし、これを読んで修正できるスタッフがいるなら、これは一般的に素晴らしいことです。 したがって、シシュニクが私たちの国で扱っている分野の1つは、さまざまな種類の「オープンソース」ソフトウェアの改良と開発です。



ヴェーダ： うん。 基本的に、私が知る限り、BadooはネイティブPHPで記述されていますか？



AR：はい、基本的にはPHP言語であり、MySQLをデータベースとして使用しています。つまり、非常に単純に見えるテクノロジーです。 それにもかかわらず、すべてはそれらで行うことができます-素晴らしいと素晴らしい。



ヴェーダ： はい。 そして、毎日何人のアクティブなオーディエンスがいますか？



AR：いい質問です。 おそらく今は特定の数字を覚えていないでしょう。数十パーセント間違えられる可能性があります。 毎日または毎月に興味がありますか？ 私は、1千万人の地域の毎日の聴衆だと思います。 これは、許可されたユーザーの話です。 そして、たまにいくつかのプロファイルを見に来た人について話すと、2000万人いると思います。



Vedas： 同時に、かなり大きな異種アプリケーションがあります。 モバイルプラットフォームで積極的に表現されていることを意味します。これらは、携帯電話、タブレット、Webバージョンです... XboxやPlayStationのコンソールには、たぶん欠席していますか？



AR：これは興味深い質問です。 実際、開発が実際に行われ、大まかに言えば、JavaScriptがあればそこに去勢されたTVで機能するようになりました。 どのアプリケーションについて話したら、Badooはソーシャルネットワークと出会い系サイトのハイブリッドです。 しかし、Badooの機能を何らかの形で単純に繰り返す個別のアプリケーションがあります。 しかし、それらは完全に分離できます。 Facebook上のアプリケーションでも、電話でのアプリケーションでも、どれほど悪くても、チャネルを介して個別に配布される場合があります。 メインのBadooウェブサイト、アプリケーションがあります-単に「投票投票」があります：美しい写真かどうか、良いかどうか。 あらゆる種類のもの。 本当にたくさんのアプリケーションがあります、そして、私はすでにそれらの数十があるのではないかと思います。 しかし、とにかく、それらすべてのバックエンドはPHPとデータベース（使用する場合はMySQL）です。



Vedas： これがプロジェクトの始まりです。 彼にとって、これがユーザーにとって本当に成功した興味深いプロジェクトである場合、聴衆は急速に成長し始めます。 したがって、サービスが適切に応答するように、サービスが落ちないように、何らかの形でこの全体を適切にサポートする必要があります。 したがって、ここでは、怠け者だけが今話しているような非常にありふれたものは水平スケーリングです。 さまざまな方法とテクノロジーがあります-AmazonではなくAmazon、クラウド、物理ホスティング。 PHP、Python、Ruby、Java、私にはわかりません... Erlangさえも-誰かがすぐにそれを使う人かもしれません。 どのようにこれにアプローチしましたか、何を使用していますか、なぜこれらのテクノロジーを使用したのですか？



AR：最も一般的な方法で答えるのは難しいです。使用するものについて詳しく説明します。 世界の「技術動物園」は、この技術やその技術を選択した多くの人が遅かれ早かれ自転車を発明することを余儀なくされているように思えます。 しかし、コミュニティは1つまたは別の言語を中心に十分に大きいため、最終的にこの自転車はコミュニティ全体の自転車となり、何らかの方法で1つまたは別の言語を選択するため、スケーリングの問題は解決される可能性が最も高くなります。



アプリケーションサーバーを直接スケーリングする方法を簡単に学びました。 比較的言えば、アプリケーションサーバーをスケーリングするために必要なのは、アプリケーション内の状態ストレージを可能な限り少なくし、リクエスト処理が1つのアプリケーションサーバーから別のアプリケーションサーバーに簡単に流れるようにし、プロセッサに負荷がかかりました。 ここでスクリプト言語を使用することはあまり良くありません。



ここで解決したタスクは、主にスケーリングではなく、信頼性に関連していました。 2005年以来、私の意見では、PHPにパッチを適用しています。 その結果、プロジェクトはいわゆるPHP FastCGIプロセスマネージャーまたはPHP-FPMに変わり、2008年または2009年にPHPのコアになりました。 これが実際の開発です。 Andrei Nigmatulinは最初にこれをすべて行いましたが、これは拡張性のためではなく、サポートの便宜のために行われたため、スムーズに再起動することができます。



また、アプリケーションサーバーを直接スケーリングすることは非常に簡単で、トラフィックを正しく分散する必要があります。 データベースのスケーリング時に問題が発生します。データベースのスケーリングを直接水平にする方法は次のとおりです。 また、キャッシュを使用すると、すべてが非常に単純になります。キャッシュは単純な方法で汚すことができるため、新しいサーバーを追加する場合、1つのサーバーから完全に転送するこのデータ拡散があれば大丈夫です。もう一つ。 このようなデータの再スミアリングでキャッシュを使用してシステムを持ち上げることができない場合、ほとんどの場合、アーキテクチャに何か問題があります。つまり、サーバーの「追加」またはデータの再分散はごみです。



また、データベースではそのようには動作しません。 それらをスケーリングするにはいくつかの方法がありますが、それらのすべては、何らかの方法で、使いやすさに基づいている必要があります。 現時点では、どこかで間違えている可能性があることを覚えていませんが、約500台のデータベースサーバーがあります。 実際、かなり大規模なインストールでは、すべてが複数のデータセンターに存在し、実際には1人で管理されます。 データベースの担当者は1人です。 最適な利便性を実現するためにすべてを行っています。



Vedas： しかし、自動化、新しいノードの作成、バックアップなどによって1人の管理を達成しましたか？



A.R。：はい。



ヴェーダ： これに独自のツールはありますか、それともソリ​​ューションを使用していますか？



AR：事実、おそらく、現在考えられる解決策がいくつかあるということです。 しかし、そのような研究は高価であり、2005年にすべてを設計しましたが、当時はそのようなものはありませんでした。 したがって、私たちがすでに持っているものの枠組みの中で仕事をする方が、今ではより有益です。 つまり、すべてをゼロから考え直すことはお勧めしませんが、2005年に策定されたテクノロジーの枠組み内にいます。 しかし、私たちはそれらを十分にクールにしたと言わなければなりません-私たちは1つのデータセンターから2つに移動しました。 3番目のデータセンターがあれば、さらに冷静に拡張します。おそらく、このスタックは変わらないでしょう。 その意味は次のとおりです。最初にデータベースのスケーリングを開始するときに犯す主な間違いの1つは、サーバーにデータを分散させることです。 私はこのアプローチを決定論的と呼びます-キーによって、つまり、大雑把に言えば、最も単純な例はキー値の何らかの機能です。



ヴェーダ： うん。



AR：部門の残り、ログインの最初の文字、あらゆる種類の方法があります-それらはすべてサポートで動作しません。 つまり、それらはシンプルで美しいものですが、すべてがサポートされているわけではありません。 ある種のノードがクラッシュし、何らかの理由で10台のサーバーではなく8台のサーバーをすぐに使用する必要があることが判明したら、2つのノードを一時的にオフにする必要があり、それらからのデータをどこかに転送する必要があるため、待ち伏せが表示されますこの式が失敗すること。 さらに、何らかの形でサポートと連携する人々は、何らかの方法でこの方法を変更する必要があることを理解し、あらゆる種類のトリックを思いつきますが、すでに半決定的であることが判明しています。



最も便利な方法は、いわゆる仮想バケットまたは仮想バスケット、仮想「シャード」です。 重要なのは、同じ識別子または何かのマッピングをいくつかの番号に使用することですが、この番号は仮想であり、それらの多くがあります。 そして、すでにこれらの仮想番号または仮想シャードは、特別な構成ファイルによって物理テーブルまたはサーバーに「マッピング」されています。 この方法で、2つのタスクが一度に解決されます。1つのタスクは、マッピングがとにかく、何らかの方法でデータをルーティングすることです-データのロード先またはデータの保存先です。 関数が計算しやすいという意味で、決定論的であることがわかりました。 一方、ノードに障害が発生した場合、管理者は構成ファイルを変更するだけで済みます。バックアップがある場合は、データを「転送」して本番環境ですべてを開始します。 ほとんどすべてのプロジェクトがそこで停止しますが、この問題はいくつかのデータセンターの問題と接続の問題を解決しません。



ユーザーはある国から別の国に移動しました。 まだ決定論的な部分があるため、ユーザーを常に1つの特定のシャードのみに「マッピング」できます。 条件付きで、はい、そうです、関数が私たちのために働くからです。 具体的に言うと、このユーザーはあるシャードから別のシャードに移動しています。 そして、すべてがより速く動作するようにユーザーデータセンター間を移行することがあるため、このような問題があります。 しかし、これを行うには、最も困難なマッピングを行う必要があります。つまり、各ユーザーを特定のシャードに関連付けます。大まかに言えば、個別のストレージ-非常に高速なストレージですが、シャード間で1人のユーザーを具体的に再配置できます。



このように、おそらく、データベースの水平スケーリングに関連するあらゆる方法のソリューション-単純な決定論、仮想バケットを使用し、各ユーザーが自分のシャードに関連付けられていること-について説明しました。



Vedas： ところで、ユーザーAndreiからこれについて尋ねられます。 「Alexei、データストレージアーキテクチャ、キャッシュ、データベースをどのように持っているのだろうか？」と尋ねます。 そして、ユーザーを移動する必要があるかどうか、つまり、このユーザーが別のシャードに移動する必要がある理由をどのように判断しますか。 どのように定義しますか？



AR：非常に簡単なケースを紹介します。ここには秘密はありません。 一般に多くの例がありますが、このケースは目立たず、少しばかげています。 2つのデータセンターがあり、1つはアメリカに、もう1つはヨーロッパにあります。 そして、アメリカのデータセンターを立ち上げたとき、誰をそこに「上陸」させたいかを考えました。アメリカ人、カナダ人、ラテンアメリカの住民をそこに着陸させる必要があることは明らかです。 一般的に、南アメリカと北アメリカに住んでいるすべての人。 いいね！ それで、私たちはしばらくの間住んでいて、突然、私たちの国ではアジアが非常に遅いことに気づきました。 そして、私たちはいくつかの調査を行い、ヨーロッパではなくアメリカにいくつかのアジアの国々があれば、それは素晴らしいことだと気づきました。 想像してみてください。すでに数百万人のアクティブユーザーがいる国があり、特にこれらのユーザーをあるデータセンターから別のデータセンターに移動する必要があるとします。 ここで、「壮大な」タスクは、最近わが国で解決されました。



Vedas： 素晴らしい、そして今あなたはシステム自体を手に入れました、自動化されたツールがあります。 このレイヤーを使用すると、必要に応じて柔軟かつ簡単にユーザーを再配布できます。 一般的に素晴らしい。



AR：私たちはもともとそれを作りました、はい。



Vedas： スケーリングについてもう1つ説明します。 , , . : « - , ». : , , , , , — .



..: , , - . - , . , . , . , , - . , , , , , . - , , . - , , , .



, , . - iPhone Android', «» http, , , . , html, - — , -, , , — , — , — storage-, .



, , , «» , , 0,1-0,2 , 0,2 — , , . , , , , . , 0,5 — , , . , . application- Pinba, - – url, , , , , URL.



.: , : , ? , - , - , « » - ?



..: , . , . , , : , - , ? , - — , - rebuild - - , ? ? , , , 100 , , . , , , , . — 0,001 100 — 100 000 . : 1000 , - , « », , - , . , . , . , - , - , , , . . : , .



.: , , .



..: , . , -. , , , .



2005 , — , , statement based. , data- , , , . , - , . , - , - — , - .



, , , ( — ), . , , , . . MySQL.



.: Mysqldump -, - , , - ?



..: . , , .



.: . , - , , ?



..: , , , , , .



.: : , ? «» ?



..: — — . , , , : , , data- . «» , . , , — 10-15 data-.



.: , - , front-end, — PHP, , ? , nginx?



..: , nginx.



.: , PHP-FPM. , , — , , , , — FlySoft, , FPM- PHP , , , Apache , nginx PHP-FPM, -, «». : - , , Amazon S3 , EC2 - . , - , data-?



..: data-. , , — , , , « », , , , . . - , - , , , . , , - . - , , . , , , : -, CDN, - — . «» , .



, , , , . . data-. , , , , - , - , . , . , , , , .



.: .



..: . CDN', , - , , . - - research connectivity, , - . CDN' - - — , CDN. , , - . , - — , , - research. , , . CDN. , - , - CDN CDN, .



.: , . , — , Vagrant, , , . ? memcached ?



..: , «» memcached — .



.: , - Redis', ?



..: , . production . - , , Redis - . production memcached.



.: , , , , , ?



..: , , ? , — , , ()… .



.: , , () . , : « ? - , ?» . : , , ORM , , - , , , , , , , ? ? , -, - , ORM . , , , ?



..: — ORM , , « — ». , , , , « »? — . - production , : - , , - , , , , . — «» , , , , .

そのような状況にあるエンジニアは、「いいえ、すべて嘘をつくようにし、機能しないようにします。私はすべてを正しく行います。」と言います。もちろん、私は誇張しています。しかし、多くの場合、エンジニアは最初からすべてをうまくやりたいと思っていて、曲がってやりたくないのです。最初に曲がって最初に行う必要がある場合もありますが、同時に近い将来にリファクタリングをすぐに行うことに同意します-これが最善の方法です。



続行するには...

そして、そのような形式が興味深いかどうか、および復号化のレイアウトを続行するかどうかについてのフィードバックを喜んで受け取ります。



完全なポッドキャストを聴く



ポッドキャストの問題をダウンロードする