LinkedInスケーリングの簡単な歴史

翻訳者のメモ ： 私たちLaterは、通信事業者向けの請求書作成に取り組んでいます。 システムの機能と開発の詳細については、Habréのブログ（たとえば、フォールトトレランスの確保に関するブログ）で説明しますが、他社の経験から興味深いことを学ぶことができます。 本日、LinkedInのチーフエンジニアであるJosh Clemによるソーシャルネットワークインフラストラクチャのスケーリングプロセスに関するメモの翻訳をご紹介します。







LinkedInサービスは、ビジネスの連絡先のネットワークを作成および維持し、就職活動の機会を拡大することを目的として2003年に開始されました。 最初の週には、2,700人がネットワークに登録しました。 数年後、製品数、顧客ベース、サーバー負荷が著しく増加しました。



現在、LinkedInには世界中で3億5,000万人以上のユーザーがいます。 私たちは毎日、毎秒何万ものWebページをチェックしています。 現在、 モバイルデバイスは世界中のトラフィックの50％以上を占めています。 ユーザーはバックエンドシステムにデータを要求し、バックエンドシステムは毎秒数百万の要求を処理します。 どのようにしてこれを達成しましたか？

初期：レオ

今日、他の多くのサイトが作成されるのと同じ方法で、すべてのタスクに対処するモノリシックアプリケーションの形で、LinkedInサイトを作成し始めました。 このアプリケーションはレオと呼ばれます。 すべてのWebページに対応するWebサーブレットをホストし、ビジネスロジックを考慮して、複数のLinkedInデータベースへの接続を提供しました。







古き良きウェブサイトの開発-すべてがとても簡単でシンプル

ユーザー数

ソーシャルネットワークでは、まず、ユーザー間の接続を確立する必要があります。 効率と生産性を高めるには、既存のグラフの接続に関するデータを要求し、ネットワークメモリに保存するシステムを作成する必要がありました。 プロファイルを使用するこの新しいアプローチでは、Leoとは独立してシステムをスケーリングする必要がありました。 そこで、ユーザーグラフ用に別のシステムを用意しました。これをクラウドと呼びます。これが最初のLinkedInサービスになりました。 この別個のサービスとLeoアプリケーションを、Javaで実装されたRPCテクノロジー（リモートプロシージャコール）の助けを借りてリンクしました。



同じ頃、検索エンジンを作成する必要性について考えました。 ユーザーのグラフに基づくサービスは、 Luceneに基づく新しい検索サービスに情報を送信し始めました。

データベースのコピー

サイトが成長するにつれて、レオも成長しました。その重要性と影響力とともに、アプリケーションの複雑さも増大しました。 複数のLeoインスタンスが動作しているため、負荷分散により複雑さが軽減されました。 ただし、負荷の増加は、最も重要なLinkedInシステムであるユーザープロファイルデータベースの動作に影響を及ぼしました。



最も単純なソリューションは、従来の垂直スケーリングでした。システムにプロセッサとメモリを追加しました。 そのため、少し時間をかけましたが、さらにスケーリングを実行する必要がありました。 プロファイルデータベースはデータの読み取りと書き込みの両方を担当したため、データベースのドーターコピー（スレーブ）がいくつか作成され、最初のバージョンのデータバス （現在はオープンソース）を使用してメインデータベース（マスター）と同期しました。 。 これらのコピーはすべてのデータを読み取るように設計されており、メインデータベースからよりもレプリカからデータを読み取る方が安全で賢明な時期を判断するためのロジックを構築しました。







* Master-Slaveモデルは中期的なソリューションであったため、データベースを分割することにしました



私たちのサイトはますます多くのトラフィックを集め、そのため私たちのモノリシックLeoアプリケーションは頻繁にフリーズし始めました。 原因を見つけて修正し、新しいコードでアプリケーションをデバッグするのはそれほど簡単ではありませんでした。 LinkedInでは、高い復元力が非常に重要です。 したがって、「レオを殺す」必要があり、多くの機能を持ち、以前の状態に関する情報を保存しない多くの小さなサービスに分割する必要があることは明らかでした。







「キル・レオ」-これは数年間当社のモットーでした...

サービス指向アーキテクチャ

開発中、マイクロサービスはAPIとビジネスロジックの接続で際立ってきました。プロファイルとグループを検索、通信、作成するためのプラットフォームが一例です。 その後、採用や一般的なプロファイルなどの分野について、プレゼンテーションのレベルが強調されました。 Leoアプリ以外では、新製品向けのまったく新しいサービスが作成されています。 時間が経つにつれて、各機能領域は独自の垂直スタックを形成します。



フロントエンドサーバーをインストールして、異なるドメインからデータを取得し、プレゼンテーションロジックを考慮し、JSPテクノロジ（JavaSever Pages）を使用してHTMLページを作成できるようにしました。 さらに、APIを介してデータへのアクセスを提供する中間レベルのサービスと、ユーザーデータを保存してデータベース/データベースへの信頼できるアクセスを提供するバックエンドサービスを開発しました。 2010年までに、すでに150以上の個別のサービスがありました。 現在、その数は750を超えています。







LinkedInサービス指向アーキテクチャの例



状態は保存されないため、いずれかのサービスの新しいインスタンスを起動し、ロードバランサーを使用してスケーリングを実行できます。 必要なリソースをすべて割り当て、パフォーマンスを監視する手段を用意し、各サービスが耐えられる負荷の種類を積極的に監視し始めました。

キャッシング

同社は急速な成長を経験し、さらに拡大する予定でした。 キャッシュレベルの数を増やすことで、全体の負荷を減らすことができることはわかっていました。 多くのアプリケーションでは、たとえばMemcachedやCouchbaseの場合のように、中間キャッシュレベルが導入され始めました。 また、データベースのキャッシュを増やし、必要に応じて事前に計算された結果でVoldemortリポジトリを使用し始めました。



時間が経つにつれて、多くの中間キャッシュレベルが削除されました。 さまざまなドメインから抽出されたデータを保存しました。 一見、キャッシュは負荷を軽減する明白な方法のように見えますが、無効化の複雑さとコールグラフの構造は過度に高くなっています。 キャッシュをデータストアに最も近い場所に配置すると、待ち時間が短縮され、水平スケーリングが可能になり、認知的負荷が軽減されます。

カフカ

増加するデータ量をまとめるために、LinkedInはデータフローを送信およびキューイングするためのいくつかのタイプのパイプラインを開発しました。 たとえば、ストレージにデータを転送し、分析のためにHadoopワークフロー間でデータパケットを送信し、各サービスのログとページビュー数などのさまざまな統計インジケーターを収集し、inMailメッセージングシステムにキューシステムを作成し、さらに発行する必要がありましたプロファイルを更新した直後のユーザーに関する最新情報。



サイトが拡大するにつれて、より多くのパイプラインが登場しました。 サイトをスケーリングする必要があったため、個々のパイプラインもスケーリングする必要がありました。 何かを犠牲にしなければなりませんでした。 その結果、 Kafkaと呼ばれる分散メッセージングシステムを開発しました。 これは、実行される格納操作の原則に基づいて、速度とスケーラビリティの向上の可能性を考慮したユニバーサルコンベヤーになりました。 Kafkaは、データウェアハウスへのほぼ瞬時のアクセスを提供し、Hadoopを使用して空室の操作を支援し、 リアルタイム分析を実施し、サイトと通知システムの 監視を大幅に改善し、コールグラフを視覚的に表示し、その変更を監視することも可能にしました。 現在、Kafka は 1日に5,000億を超えるリクエストを処理しています 。







データ転送の普遍的な手段としてのカフカ

反転

スケーリングは、組織を含むさまざまな観点から検討できます。 2011年の終わりに、LinkedInはInVersionと呼ばれる内部プロジェクトを開始しました。 彼のおかげで、私たちは個々の機能の開発を中断しました。彼は会社全体が機器、インフラストラクチャ、実装、開発者の生産性に集中できるようにしました。 その結果、今日の新しいスケーラブルな製品の開発に必要な一定レベルの柔軟性に達しました。

私たちの日々：Rest.li

Leoからサービス指向アーキテクチャに切り替えた後、JavaのRPCを介してアクセスしたチームのAPIは互換性がなく、プレゼンテーションのレベルに密接に関連していることが判明しました。 時間が経つにつれて、状況は悪化しました。 この問題を解決するために、新しいAPIモデルを作成し、 Rest.liという名前を付けました。 Rest.liは、データモデル中心のアーキテクチャへの一歩です。 単一のステートレスRESTful APIモデルに基づいて構築されました。 会社全体がこのモデルを使用できるようになりました。



その結果、HTTPの代わりに使用されるようになった新しいJSON APIにより、Javaで記述されていないクライアントアプリケーションでの作業が容易になりました。 今日、ほとんどのLinkedIn開発者はJavaでプログラムしていますが、同社には、フルタイムの従業員とLinkedIn買収企業のプログラマーの両方が開発したPython、Ruby、Node.js、C ++のクライアントが多数あります。



RPCを拒否したことで、プレゼンテーションレベルへの依存度が低くなり、以前のバージョンとの互換性の問題から解放されました。 さらに、Rest.liと共に動的デバイス検出サービス（D2）を使用すると、負荷分散、デバイス検出、および各サービスのクライアントAPIのスケーリングのプロセスを自動化できました。



現在、LinkedInにはRest.liモデルに基づいて975を超えるリソースがあり、当社のデータセンターは1日に1,000億を超えるRest.liリクエストを処理しています。







Stack Rest.li R2 / D2

スーパーブロック

サービス指向アーキテクチャは、ドメインの分離とサービスの独立したスケーリングに最適です。 しかし、否定的な側面があります。 私たちのアプリケーションの多くは、さまざまなタイプのデータを処理し、クライアント側に数百の呼び出しを行います。 これらすべての呼び出しは、通常、「呼び出しグラフ」と「分岐」の概念に還元されます。 たとえば、プロファイルページへの各アクセスは、プロファイルデータだけでなく、写真、連絡先、グループ、サブスクリプション、ブログ投稿、グラフの関連度、推奨事項などの情報も引き起こします。 このグラフは管理が非常に難しく、その複雑さは次第に増加しました。



スーパーブロックの原理を使用しました。これは、APIへの単一アクセスでバックエンドサービスのグループを形成することです。 この原則のおかげで、当社の専門家チームはブロックの最適化に従事し、同時に各クライアントのコールグラフを監視しています。

マルチユーザーデータセンター

顧客ベースが拡大している国際企業として、トラフィックの処理に複数のデータセンターを使用してスケールアップする必要があります。 数年前にこの問題を解決し始めました。最初は、ロサンゼルスとシカゴにある2つのデータセンターが共通の顧客プロファイルを提供し始めました。



それらをテストした後、データ複製、さまざまなソースからのフィードバック、一方向データ複製のイベントを確立し、ユーザーを彼/彼女に近いデータセンターに接続するために、サービスを改善することにしました。



データベースのほとんどは、当社の最新のマルチユーザーデータウェアハウスであるエスプレッソに保存されています。 マルチユーザーデータセンターの要件を考慮して構築されました。 Espressoは、Master-Masterサポートを提供し、より洗練された複製技術を担当します。



いくつかのデータセンターの存在は、サイトと高いフォールトトレランスを維持するために非常に重要です。 個々のサービスだけでなく、サイト全体でも、わずかな誤動作の存在を回避する必要があります。 LinkedInには現在、3つの主要なデータセンターがあり、世界中にいくつかの追加拠点があります。







2015年時点でのさまざまなタイプのLinkedIn機器の場所（円はデータセンターを示し、菱形は存在点を示します）

他に何を達成しましたか？

ご存知のように、実際、スケーリングははるかに困難です。 過去数年にわたって、当社の開発およびエンジニアリングチームは巨匠の仕事を行ってきました。この仕事から、いくつかの別個のプロジェクトを強調する価値があります。



当社の特に重要なシステムの多くは、スケーリングの過程で独自の豊かな開発の歴史を持っています。 それとは別に、 ユーザーグラフ （Leoアプリケーション外の最初のサービス）、 検索 （2番目のサービス）、ニュースフィード、 通信プラットフォーム 、およびユーザープロファイルを表示するためのサーバーアプリケーションを強調する価値があります。



長期的な成長のための情報インフラストラクチャを開発しました。 DatabusとKafkaの作成後に初めて感じました。 その後、データストリームを扱うSamza 、ストレージツールとしてEspressoとVoldemort、システムやその他のユーザーソリューションを分析するPinotが登場しました。 とりわけ、私たちの機器はずっと良くなったので、開発者はこのインフラストラクチャを独立して使用できるようになりました。



「知っている人」、「似たようなプロファイル」、「成功した卒業生」、プロファイルの場所などの情報を事前に提供するために、 HadoopおよびVoldemortデータウェアハウスを使用したオフラインのビジネスプロセス管理システムを開発しました。



クライアント側のテンプレート （「 プロファイルページ 」、「 大学ページ 」）を追加して、フロントエンドへのアプローチを修正しました。 アプリケーションに対話性を追加し、JSONで部分的または完全に記述されたオブジェクトのみをサーバーに要求します。 さらに、テンプレートはCDNネットワーク（コンテンツ配信ネットワーク）とブラウザーのキャッシュに分類されます。 また、 BigPipeとPlayフレームワークの使用を開始し、モデルをストリーミングWebサーバーからノンブロッキングおよび非同期に変更しました 。



アプリケーションコードに加えて、Apache Traffic ServerとHAProxyを使用して負荷分散、データセンターへの接続、セキュリティ、スマートルーティング、サーバー側レンダリングなどを行うプロキシサーバーのいくつかのレベルを導入しました。



さらに、ハードウェアの最適化、高度なメモリシステムの調整、最新のJavaランタイムの使用により、サーバーのパフォーマンスを向上させ続けています。