Twitterパークの概要

Twitterは、データセンターに専門メーカーの機器を設置するのが慣習だった時代から生まれました。 それ以来、サーバーフリートを継続的に開発および更新し、最新のオープンテクノロジー標準の恩恵に努めるとともに、機器の効率を高めてユーザーに最高のエクスペリエンスを提供しています。



現在の機器の分布は次のとおりです。

ネットワークトラフィック

2010年の初めに、サードパーティのホスティングを離れ始めました。 これは、インフラストラクチャを独自に構築および保守する方法を学習する必要があったことを意味します。 基本的なインフラストラクチャのニーズについて漠然と考えていたため、ネットワークアーキテクチャ、機器、および製造業者にさまざまなオプションを試してみました。



2010年末までに、最初のネットワークアーキテクチャプロジェクトが完了しました。 ホスティング事業者で経験したスケーリングとメンテナンスの問題を解決することになっていた。 サービストラフィックのバーストを処理するためのディープバッファを備えたToRスイッチと、このレベルでオーバーサブスクライブしないカーネルお​​よびキャリアクラスのスイッチがありました。 キャッスル・イン・ザ・スカイの公開後、2014 FIFAワールドカップ開催中のTPSレコード（1秒あたりのツイート数）など、いくつかの顕著なエンジニアリング成果を達成したTwitterの初期バージョンをサポートしました。



数年前にさかのぼると、すでに5つの大陸にプレゼンスポイントを持つネットワークと、数十万のサーバーがあるデータセンターがありました。 2015年の初めに、サービスアーキテクチャの変更と電力要件の増加に起因する成長の問題がいくつか発生し始め、メッシュトポロジが新しいラックへの追加機器の追加に耐えられなかったときに、最終的にデータセンターのスケーラビリティの物理的限界に達しました。 さらに、既存のデータセンターのIGPは、ルーティングの規模の拡大とトポロジの複雑さにより、予測できない動作を開始しました。



これに対処するために、既存のデータセンターをClos + BGPトポロジに転送し始めました。これは、ライブネットワークで実行する必要があった変換です。 複雑さにもかかわらず、比較的短時間でサービスへの影響を最小限に抑えて完成しました。 これで、ネットワークは次のようになります。









新しいアプローチのキーポイント：

• 単一のデバイス障害からのより小さい衝撃半径。
• 水平帯域幅スケーリング機能。
• CPUのルーティングエンジンのオーバーヘッドが小さい。 ルーティングの変更をより効率的に処理します。
• CPUオーバーヘッドの削減によるルーティング容量の増加。
• 各デバイスおよび各接続のルーティングルールのより詳細な制御。
• 過去に発生した最も深刻なインシデントの根本原因に遭遇する可能性はもうありません。プロトコル収束時間の増加、ルーティングされたルートの問題、OSPF固有の複雑さによる予期しない問題。
• 結果なしでラックを移動する機能。

ネットワークインフラストラクチャを詳しく見てみましょう。

データセンターのトラフィック

タスク

最初のデータセンターは、ホスティングプロバイダーにインストールされた有名なシステムの容量とトラフィックプロファイルのモデルに基づいて構築されました。 わずか数年で、データセンターは元の設計よりも400％増加しました。 そして、アプリケーションスタックが進化し、Twitterの分散が進んだ今、トラフィックプロファイルも変化しました。 ネットワーク設計が最初に開発された最初の前提は、もはや関係ありません。



トラフィックはデータセンター全体をやり直す時間よりも速く成長しているため、突然の移行ではなく、一貫して容量を追加できる拡張性の高いアーキテクチャを作成することが重要です。



広範なマイクロサービスシステムには、さまざまなトラフィックに耐えることができる信頼性の高いネットワークが必要です。 私たちのトラフィックは、長寿命のTCP接続から特別なMapReduceタスクや非常に短いマイクロバーストまでさまざまです。 当初、このさまざまな種類のトラフィックを展開するために、ディープパケットバッファーを備えたネットワーク機器を展開しましたが、そのため、コストが高くなり、ハードウェアが複雑になるという問題がありました。 後のプロジェクトでは、より標準的なバッファサイズとエンドツーエンドスイッチング機能を使用し、より洗練されたマイクロバースト処理のために、より適切に調整されたサーバー側TCPスタックを使用しました。

学んだ教訓

何年もの間、私たちが行った改善の後、私たちは言及する価値のあるいくつかのことに気付きました。

• 元の仕様と要件を超えて設計し、トラフィックがネットワークに配置された容量の上限に近づくと、大胆かつ迅速な変更を行います。
• データとメトリックに依存して、適切な技術設計の決定を下し、これらのメトリックがネットワークオペレーターに明確であることを確認します。これは、ホスティングまたはクラウドで特に重要です。
• 一時的な変更や回避策などはありません。ほとんどの場合、回避策は技術的な義務です。

バックボーントラフィック

タスク

バックボーントラフィックは毎年劇的に増加しました。データセンター間でトラフィックを移動すると、通常のトラフィックから3〜4倍のスパイクが発生します。 これは、このために設計されていない歴史的なプロトコルに固有の課題をもたらします。 たとえば、 MPLSのRSVPプロトコルは、突然のバーストではなく、ある程度トラフィックが徐々に増加することを意味します。 最速の応答時間を得るために、これらのプロトコルのセットアップに多くの時間を費やす必要がありました。 さらに、トラフィックの急増に対処するために（特にストレージシステムで複製する場合）、優先システムを実装しました。 ユーザートラフィックの配信を常に保証する必要がありますが、毎日のSLAを使用して、ストレージシステムからの低優先度のレプリケーショントラフィックの遅延を許可することができます。 したがって、当社のネットワークは利用可能なすべての帯域幅を使用し、リソースを可能な限り効率的に使用します。 ユーザートラフィックは、優先度の低いバックエンドトラフィックよりも常に重要です。 さらに、 RSVP自動スループットに関連するビンパッキングの問題を解決するために、トラフィックが増加すると追加のLSPを作成し、トラフィックが減少するとそれらを削除するTE ++システムを実装しました。 これにより、接続間のトラフィックを効果的に管理しながら、多数のLSPをサポートするために必要なCPU負荷を軽減できます。



もともと誰もバックボーン用のトラフィックを設計していませんでしたが、後に成長に合わせて拡張できるように追加されました。 これを行うために、カーネルトラフィックと境界トラフィックをそれぞれルーティングするための個別のルーターで役割の分離を実行しました。 また、複雑な境界機能を備えたルーターを購入する必要がないため、予算モードで拡張することもできました。



境界では、これは、ここでカーネルがすべてに接続され、非常に水平方向にスケーリングできることを意味します（たとえば、コア相互接続がすべてを接続するため、カップルではなく、1か所に多数のルーターをインストールします）。



ルーターのRIBをスケーリング要件を満たすようにスケーリングするには、ルートリフレクションを実装する必要がありましたが、これを行って階層構造に移行し、独自のルートリフレクターにルートリフレクタークライアントも実装しました！

学んだ教訓

過去1年間、デバイス構成をテンプレートに転送し、現在は定期的にそれらを確認しています。

国境交通

グローバルなTwitterネットワークは、世界中の多くのデータセンターにある3,000以上のユニークなネットワークと直接相互接続しています。 直接トラフィック配信は最優先事項です。 トラフィックの60％をグローバルネットワークバックボーンを介して相互接続およびプレゼンスポイント（POP）に移動します。POPには、クライアントセッションを閉じるローカルフロントエンドサーバーがあり、すべてユーザーに可能な限り近い場所にあります。

タスク

世界の出来事の予測不可能性は、同じ予測不可能なトラフィックのバーストをもたらします。 スポーツ、選挙、自然災害、その他の重要なイベントなどの主要なイベント中のこれらの爆発により、ネットワークインフラストラクチャ（特に写真やビデオ）がストレスにさらされます。 それらはまったく予測することも、警告なしに発生することも困難です。 そのようなイベントに対応し、大きな飛躍に備えます。この地域で大きなイベントが計画されている場合、通常のピークレベルの3〜10倍になることがよくあります。 年間の著しい成長により、必要なボリュームの容量を増やすことは重要なタスクです。



可能な限り、すべてのクライアントネットワークとピアツーピア接続を確立しますが、これには問題がないわけではありません。 驚くべきことに、ネットワークやプロバイダーは、国内市場から遠く離れた相互接続を確立するか、ルーティングルールのために、トラフィックを市場外のプレゼンスポイントに向けることを好みます。 また、Twitterはトラフィックが発生するすべての最大（ユーザー数）ネットワークとのピアツーピア接続をオープンに確立しますが、すべてのインターネットプロバイダーが同じことを行うわけではありません。 ルーティングルールの最適化にかなりの時間を費やし、トラフィックをできるだけユーザーの近くに誘導します。

学んだ教訓

これまで、誰かがDNSサーバーの場所に基づいてwww.twitter.com



にリクエストを送信すると、特定のサーバークラスターに向けて異なる地域IPアドレスを与えました。 このような方法（GeoDNS）は部分的に不正確です。ユーザーが正しいDNSサーバーを選択することや、DNSサーバーが世界のどこに物理的に存在するかを正確に判断する能力に頼ることができないからです。 さらに、インターネットのトポロジは常に地理に対応するとは限りません。



問題を解決するために、BGPエニーキャストモデルに切り替え、すべての場所から同じルートをアナウンスし、ユーザーからプレゼンスポイントまでの最適なルートを作成するようにルーティングを最適化しました。 そうすることにより、インターネットトポロジの制限を考慮し、DNSサーバーの場所に関する予測不可能な仮定に依存せずに、最高のパフォーマンスを得ることができます。

保管

毎日何億ものツイートが公開されています。 それらは処理、保存、キャッシュ、配信、分析されます。 この量のコンテンツには、適切なインフラストラクチャが必要です。 ストレージとメッセージングは​​、Twitterのインフラストラクチャ全体の45％を占めています。



ストレージおよびメッセージンググループは、次のサービスを提供します。

1. コンピューティングおよびHDFS用のHadoopクラスター。
2. すべての低レイテンシキーバリューストア用のマンハッタンクラスター。
3. シャードされたMySQLクラスターのグラフストレージ。
4. すべての大きなオブジェクト（ビデオ、画像、バイナリファイルなど）のBlobstoreクラスター。
5. クラスターキャッシング 。
6. メッセージングクラスター
7. リレーショナルリポジトリ（ MySQL 、PostgreSQL、およびVertica ）。

タスク

このレベルにはさまざまな問題がありますが、克服しなければならない最も注目すべき問題の1つはマルチテナンシーでした。 多くの場合、ユーザーは既存の所有物に影響を与え、専用クラスターの構築を余儀なくされる境界状況を持っています。 専用クラスターが多いほど、それらをサポートする運用負荷が大きくなります。



私たちのインフラストラクチャに驚くべきことは何もありませんが、ここにいくつかの興味深い事実があります。

• Hadoop：私たちの多くのクラスターは、500 PB以上を4つのグループ（リアルタイム、処理、データストレージ、コールドストレージ）に分けて保存します。 最大のクラスターでは、1万以上のノード。 15万のアプリケーションがあり、1日あたり1億3千万のコンテナが起動されます。
  
  
  
  
• マンハッタン（ツイート、プライベートメッセージ、ツイッターアカウントなどのバックエンド）：さまざまなタスクのクラスターがいくつかあります。これらは複数の所有権を持つ大規模なクラスターであり、異常なタスクの場合は小さく、トラフィックが多い場合の読み取り専用および読み取り/書き込みクラスターです読み取りおよび書き込み用。 読み取り専用クラスターは1秒あたり数千万のリクエスト（QPS）を処理し、読み取り/書き込みクラスターは数百万のQPSを処理します。 各データセンターには、最高のパフォーマンスを備えたクラスター、つまり数千万件のレコードを処理する可観測性クラスターがあります。
  
  
  
  
• グラフ：歴史的なGizzard / MySQLベースのグラフストレージ用シャードクラスター。 私たちのソーシャルグラフFlockは、数千万のQPSのピーク負荷に対処し、平均で30〜45,000 QPSのMySQLサーバーに配信します。
  
  
  
  
• Blobstore：画像、ビデオ、および数千億のオブジェクトを含む大きなファイルのリポジトリ。
  
  
  
  
• キャッシュ：RedisおよびMemcacheクラスターは、ユーザー、タイムライン、ツイートなどをキャッシュします。
  
  
  
  
• SQL：MySQL、PostgreSQL、Verticaが含まれます。 MySQL / PosgreSQLは、広告キャンペーン、広告交換、および内部ツールの管理に厳格な整合性が必要な場合に使用されます。 Verticaは、Tableauサポートおよびユーザー組織での販売のバックエンドとしてよく使用される列ストレージです。

Hadoop / HDFSはScribeベースのロギングシステムのバックエンドでもありますが、 Apache Flumeへの移行をテストする最終段階はほぼ完了しています。 個々の顧客のアグリゲーターへのトラフィックの制限/帯域幅の制限、カテゴリごとの配信の保証がないなどの制限を克服するのに役立つはずです。 また、メモリ破損の問題の解決にも役立ちます。 1日に1兆を超えるメッセージを処理し、それらはすべて500を超えるカテゴリで処理および配信され、結合された後、クラスター全体に選択的にコピーされます。

時系列進化

TwitterはMySQL上に構築され、最初はすべてのデータがMySQLに保存されていました。 小さなデータベースから大きなインスタンスに移動し、その後、多数の大きなデータベースクラスターに移動しました。 MySQLインスタンス間でデータを手動で移動するには時間がかかり、2010年4月に分散データウェアハウスを作成するためのフレームワークであるGizzardを導入しました。



そのとき、エコシステムは次のようになりました。

• 複製されたMySQLクラスター。
• GizdardベースのシャードMySQLクラスター。

2010年5月のGizzardのリリースに続いて、GizzardとMySQLの上にグラフを保存するためのソリューションであるFlockDBと、2010年6月に独自の識別子マッピングサービスであるSnowflakeを導入しました 。 2010年は、 Hadoopに投資した年でした。 もともとはMySQLバックアップを保存するために設計されたものですが、現在では分析に多用されています。



2010年頃、データストレージソリューションとしてCassandraも導入しました。自動段階的増加機能がないため、MySQLを完全に置き換えることはできませんでしたが、インジケーターの格納に使用し始めました。 トラフィックが指数関数的に増加したため、クラスターを拡大する必要があったため、2014年4月に分散マルチテナントリアルタイムデータベースであるManhattanを立ち上げました 。 それ以来、マンハッタンは主要なストレージレベルの1つになり、Cassandraは無効になりました。



2012年12月、Twitterは写真のアップロードを許可しました。 ファサードの背後で、これは新しいBlobstoreストレージソリューションによって可能になりました。

学んだ教訓

長年にわたり、データをMySQLからマンハッタンに移行してアクセシビリティを改善し、レイテンシーを短縮し、開発を容易にしたため、トラフィックパターンをよりよく提供するために、追加のデータストレージエンジン（LSM、b +ツリーなど）も実装しました。 さらに、インシデントから学び、圧力信号を送り返し、クエリフィルタリングをアクティブにすることで、データストレージレベルを悪用から保護し始めました。



私たちは仕事に適切なツールを提供することに集中し続けていますが、そのためにはすべてのユースケースを理解する必要があります。 「すべてに適合する」などの普遍的なソリューションはほとんど機能しません。一時的なソリューションほど永続的なものはないため、境界の状況で角を切ることは避けてください。 最後に、決定を過大評価しないでください。 すべてに長所と短所があり、現実との接触を失うことなくすべてを適応させる必要があります。

キャッシュ

キャッシュはインフラストラクチャの約3％しか占有していませんが、バックエンドリポジトリを大量の読み取りトラフィックから保護し、高いコストでオブジェクトを保存できるため、Twitterにとって重要です。 RedisやTwemcacheなど、いくつかのキャッシングテクノロジーを大規模に使用しています。 具体的には、Twitter memcached（twemcache）クラスター、専用またはマルチテナントクラスター、Nighthawkクラスター（Redisの影付き）が混在しています。 コアベアメタルキャッシングのほぼすべてをMesosに移行して、運用コストを削減しました。

タスク

スケーリングとパフォーマンスは、キャッシングシステムの重要なタスクです。 1秒あたり3億2000万パケットの総パケット転送速度を備えた数百のクラスターがあり、お客様に120 GB /秒を提供します。また、トラフィックのピーク時でも99.9％から99.99％の遅延ですべての応答を提供することを目指しています。重要なイベント中。



高スループットと低レイテンシの観点でサービスレベル目標（SLO）を満たすには、システムのパフォーマンスを継続的に測定し、効率を最適化するオプションを探す必要があります。 このために、キャッシュシステムの動作をよりよく理解するのに役立つrpc-perfプログラムを作成しました。 これは、専用サーバーから現在のMesosインフラストラクチャに切り替えたため、容量計画にとって重要です。 この最適化の結果、レイテンシを犠牲にすることなく、サーバーあたりの帯域幅を2倍以上にすることができました。 ここでも大きな最適化が可能であると考えています。

学んだ教訓

Mesosへの切り替えは、運用上の大きな勝利でした。 構成を体系化し、徐々に展開して、キャッシュヒット率を維持し、永続的なデータストレージの問題を回避できます。 このレベルの成長とスケーリングは、より大きな自信を持って行われます。



twemcacheインスタンスごとに数千の接続、プロセスの再起動、ネットワークトラフィックの急増、またはその他の問題が発生すると、DDoSのようなキャッシュレベルへの接続が流入する可能性があります。 規模が拡大するにつれて、これは深刻な問題以上になりました。 DDoSの場合に、高レベルの再接続で個々のキャッシュへの接続の帯域幅を狭めるのに役立つベンチマークを導入しました。そうしないと、サービスレベルの観点から規定された目標から逸脱します。



キャッシュをユーザー、ツイート、タイムラインなどで論理的に分割するため、一般的に各キャッシングクラスターは特定の用途に合わせて構成されます。 クラスターのタイプに応じて、1,000万から5,000万のQPSを処理でき、数百から数千のインスタンスの数で実行できます。

ハプロ

ハプロを紹介しましょう。 これは、Twitterタイムラインのメインキャッシュであり、カスタマイズされたバージョンのRedis（HybridListを使用）で実行されます。 Haploからの読み取り操作はタイムラインサービスによって実行され、書き込み操作はタイムラインサービスおよびファンアウトサービスによって実行されます。 これは、Mesosにまだ移行されていないキャッシュの1つでもあります。

• 毎秒4,000万から1億のチームの総数。
• ネットワークI / Oホストあたり100 Mbit / s。
• サービスリクエストの総数は1秒あたり80万です。

さらに読むために

Yao Yue（ @thinkingfish ）は長年にわたっていくつかの優れた講義を行っており、Redisの使用や新しいPelikanコードベースなど、キャッシングに関する多くの記事を公開しています。 これらのビデオを視聴し、最近のブログ投稿を読むことができます。

大規模な人形劇

Kerberos、Puppet、Postfix、Bastions、Repositories、Egress Proxiesなどのカーネルインフラストラクチャサービスが多数あります。 スケーリング、ツールの作成、これらのサービスの管理、およびデータセンターとプレゼンスポイントの拡大のサポートに重点を置いています。 昨年だけでも、プレゼンスポイントの地理を大幅に拡大しました。そのため、新しい場所の計画、準備、および立ち上げ方法のアーキテクチャを完全に変更する必要がありました。



すべての構成を管理するには、Puppetを使用して、システムに初期バッチインストールをインストールします。 このセクションでは、解決しなければならなかったタスクのいくつかと、構成管理インフラストラクチャを使用して行うことを計画しています。

タスク

ユーザーのニーズを満たすために成長するにつれて、私たちは標準のツールとプラクティスを急速に成長させました。 毎月100人を超えるコミットの作成者、500を超えるモジュール、1000を超えるロールがあります。 最終的に、ロール、モジュール、コードの行数を削減すると同時に、コードベースの品質を向上させることができました。

枝

Puppetが環境と呼ぶ3つのブランチがあります。 これにより、作業環境への変更を適切にテストし、実行し、最終的に変更をリリースできます。 より分離されたテストのために、個別の特殊な環境も許可します。



現在、テストから作業環境に変更を転送するには、人間の関与が必要ですが、自動化された統合/ロールバックプロセスを備えた、より自動化されたCIシステムに移行しています。

コードベース

Puppetリポジトリには100万行を超えるコードが含まれており、各ブランチで10万行を超えるのはPuppetコードのみです。 最近、コードベースの大規模なクリーンアップを実行し、不要な重複コードを削除しました。







このグラフは、2008年から今日までのコードの合計行数（さまざまな自動更新ファイルを除く）を示しています。







このグラフは、2008年から現在までのファイルの総数（さまざまな自動更新ファイルを除く）を示しています。







このグラフは、2008年から今日までの平均ファイルサイズ（さまざまな自動更新ファイルを除く）を示しています。

大勝利

コードベースの最大の勝利は、静的コード分析（リンティング）、スタイルチェックフック、ベストプラクティスのドキュメント、および定期的なワークショップでした。



パペットリントツールを使用して、リンティングに関して一般に受け入れられている基準を満たすことができました。 コードベースのリンティングエラーと警告の数を数万行減らし、変換はコードベースの20％に影響しました。



最初のクリーンアップ後、コードベースに小さな変更を加えることが容易になり、バージョン管理のフックとして自動スタイルチェックが導入されたことで、コードベースのスタイルエラーの数が劇的に減少しました。



組織全体でPuppetに100人を超えるコミットライターがいるため、内部プラクティスとコミュニティ標準の両方のベストプラクティスプラクティスを文書化する重要性が高まっています。 単一の参照ドキュメントを持つことで、コードの品質と実装の速度が向上しました。



チャットでのチケットとチャンネルが十分なコミュニケーション密度を提供しないか、達成する必要があるものの全体像を反映できない場合、定期的なサポート会議（場合によっては招待による）を開催すると、1対1のサポートが提供されます。 その結果、会議の後、多くのコミット作成者がコードの品質と作業の速度を改善し、コミュニティの要件、ベストプラクティス、および変更の最適な適用方法を理解しました。

モニタリング

システムインジケーターは常に役立つとは限りません（Monitorama 2016でのCaitlin McCaffreyの講義を参照）が、役に立つと思われるこれらのインジケーターに追加のコンテキストを提供します。



アラートとチャートを生成するための最も有用なメトリックのいくつかは次のとおりです。

• 失敗：失敗したPuppet起動の数。
• 期間：Puppetクライアントがジョブを完了するのにかかる時間。
• 作業不足：予想される間隔で行われなかったPuppetの起動回数。
• ディレクトリサイズ：ディレクトリのサイズ（メガバイト単位）。
• ディレクトリーのコンパイル時間：ディレクトリーのコンパイルに必要な時間（秒単位）。
• コンパイルされたディレクトリの数：各マスターがコンパイルしたディレクトリの数。
• ファイルリソース：処理されたファイルの数。

これらのインジケータはすべて、ホストごとに収集され、役割ごとにまとめられます。 これにより、アラートを即座に発行し、特定のロール、ロールセット、またはより広範な問題に問題があるかどうかを判断できます。

効果

Puppet 2からPuppet 3に切り替えてPassengerを更新した後（両方のトピックに関する投稿を投稿します）、MesosクラスターでのPuppetプロセスの平均実行時間を30分以上から5分未満に短縮することができました。







このグラフは、MesosクラスターでのPuppetプロセスの平均実行時間を秒単位で示しています。



Puppetインフラストラクチャのサポートをご希望の場合は、ぜひご参加ください ！