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ランタむムの䜿甚により、サヌバヌのパフォヌマンスを向䞊させ続けおいたす。



All Articles