支撑Twitter的基础设施：规模

2 年 ago

文, 翔

2 minutes

推特背后的基础设施：规模

Twitter船的简介

Twitter在物理企业供应商硬件主导数据中心的年代诞生。从那以后，我们利用最新的开放标准技术高效利用硬件，不断重新审查和更新船的设计，以提供最佳体验。

目前硬件配置如下:

网络流量。

2010年初，我们开始从外部托管平台进行迁移。这意味着我们需要学习在内部搭建和运营基础设施的方法，并且由于未能准确洞察核心基础设施的需求，我们不断尝试使用不同的网络设计、硬件设备和供应商来逐渐采纳适宜的方案。

2010年後半には、共有ホスティングで過去発生していたスケールとサービスの問題に対処するために、最初のネットワークアーキテクチャを完成させました。バッファの深いTop of Rackで突発のサービストラフィックをサポートし、キャリアグレードのコアスイッチでオーバーサブスクリプションのないレイヤーを実現しました。これにより、「天空の城ラピュタ」や「ワールドカップ2014」で達成した秒間ツイート数の記録など、注目すべきエンジニアリングの成果を通じて、Twitterの初期バージョンをサポートすることができました。

それから数年が経ち、私たちは5つの大陸にPOPを持ち、何十万ものサーバーを持つデータセンターを運営していました。2015年初頭には、サービスアーキテクチャの変更や容量ニーズの増加により、成長痛が発生し始め、最終的には、フルメッシュトポロジでは新しいラックを追加するために必要なハードウェアをサポートできなくなり、データセンターの物理的なスケーラビリティの限界に到達しました。さらに、既存のデータセンター用IGPは、ルーティングの規模が大きくなり、トポロジーが複雑になることで、予期せぬ動作をするようになりました。

このため、既存のデータセンターをClosトポロジ＋BGPに変換する作業を開始しました。この変換はアクティブなネットワーク上で行う必要がありましたが、複雑であるにもかかわらず、比較的短期間でサービスへの影響を最小限に抑えて完了することができました。現在のネットワークはこのようになっています。

新的方法的亮点 de de

影響を与えないラックマイグレーションを可能に

以下是对网络基础设施的说明。

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

挑战

私たちの最初のデータセンターは、共有サーバーの既存システムから容量とトラフィック特性をモデル化して構築されたものでした。しかし、それからわずか数年で、私たちのデータセンターは当初の設計よりも400%も大きくなってしまいました。そして今、私たちのアプリケーションスタックが進化し、Twitterがより分散化するにつれて、トラフィック特性も変化しています。初期のネットワーク設計の前提は、もはや正しいとは言えません。

トラフィックはデータセンター全体を再設計するよりも早く成長するため、リフト&シフトマイグレーションではなく、段階的に容量を追加できるような拡張性の高いアーキテクチャを構築することが重要なのです。

高吞吐量的微服务需要一个高可靠性的网络来处理各种流量。我们的流量范围广泛，包括长时间的TCP连接、即席的MapReduce作业，以及极短的微缓冲等等。我们最初的解决方案是引入具有深度数据包缓冲的网络设备，但这会带来高成本和更复杂的硬件问题。后来，我们采用了更标准的缓冲区大小和裁剪传送功能，并适当调整了服务器端的TCP堆栈，以便更有效地处理微缓冲。

学习所得之经验

经过多年的改进，我们得出了一些教训。

一時的な変更や回避策というものは存在しない。ほとんどの場合、回避策は技術的負債となります。

背景流量

チャレンジ

当社のバックボーン・トラフィックは年々劇的に増加していますが、データセンター間でトラフィックを移動する際には、通常の3～4倍のバーストが発生することがあります。このため、MPLSRSVPプロトコルのように、突然のバーストではなく、何らかの形で徐々に増加することを想定して設計されていない従来のプロトコルには、特有の課題があります。可能な限り高速な応答時間を得るために、これらのプロトコルのチューニングに膨大な時間を費やさなければなりませんでした。さらに、トラフィックの急増に対応するため（特にストレージのレプリケーション）、優先順位付けを行いました。

お客様のトラフィックの配信は常に保証する必要がありますが、SLAが数日に及ぶような優先度の低いストレージレプリケーションのジョブの配信を遅らせることは可能です。こうすることで、ネットワークは利用可能な容量をすべて使用し、リソースを最大限に効率的に利用することができます。お客様のトラフィックは、常に優先度の低いバックエンドのトラフィックよりも重要なのです。さらに、RSVPの自動帯域幅につきもののビンパッキングの問題を解決するために、TE++を導入しました。トラフィックが増加するとLSPを追加作成し、トラフィックが減少するとそれを削除する仕組みになっています。これにより，大量の LSP を維持するための CPU 負荷を軽減しつつ，リンク間のトラフィックを効率的に管理することができるようになりました．

もともとバックボーンにはトラフィックエンジニアリングがありませんでしたが、私たちの成長に合わせて拡張できるように追加されました。そのために、コアとエッジのルーティングをそれぞれ専用のルーターで行うという役割分担を完了させました。これにより、複雑なエッジ機能を持つルーターを購入する必要がなくなり、費用対効果の高い方法で拡張することが可能になりました。

エッジ側では、すべてを接続するコアがあるため、非常に水平に拡張することができます（つまり、すべてを相互接続するコア層があるため、サイトごとに数台のルーターではなく、数十台のルーターを持つことができます）。

ルーターのRIBを拡張するために、ルートリフレクションを導入してスケール需要に合うようにする必要がありましたが、これを行うことで、階層型デザインに移行し、ルートリフレクターを自分自身のルートリフレクターのクライアントにもしてしまいました

学到的东西 (Xué de

昨年から、デバイスの設定をテンプレートに移行し、定期的に監査しています。

エッジトラフィック

Twitterの世界的なネットワークは、世界中の多くのデータセンターにある3,000以上のユニークなネットワークと直接相互接続しています。トラフィックの直接配信は、私たちの最優先事項です。トラフィックの60%をグローバルネットワークバックボーン経由で相互接続ポイントやPOPに運び、ローカルフロントエンドサーバーでクライアントセッションを終了させるなど、できる限りお客様の近くにいることを心がけています。

挑战

世界各地で起こる予測不可能な出来事は、同様に予測不可能なバーストトラフィックを発生させます。スポーツ、選挙、自然災害、その他ニュースになるような大きなイベント時のバーストは、ほとんど事前通告なしにネットワークインフラ（特に写真とビデオ）に負荷をかけます。このようなイベントのために容量を確保し、利用率の大幅な上昇（ある地域で大きなイベントが予定されているときは、通常の3～10倍のピークになることもあります）に備えて計画を立てています。トラフィックは年々大幅に増加しているため、容量を確保することは本当に大変なことです。

私たちは、すべてのお客様のネットワークと可能な限りピアリングを行っていますが、これには課題があります。意外なことに、ネットワークやプロバイダーがホーム拠点から離れた場所での相互接続を好んだり、ルーティングポリシーによって拠点から離れたPOPにトラフィックが到着してしまうことがよくあるのです。Twitterはトラフィックを観測するすべての主要ネットワークとオープンにピアリングしていますが、すべてのISPがそうしているわけではありません。私たちは、ルーティング・ポリシーを最適化し、できるだけユーザーの近くで、できるだけ直接的にトラフィックを提供できるよう、多大な時間を費やしています。

学んだこと

歴史的に、誰かが「www.twitter.com」を要求したとき、そのDNSサーバーの場所に基づいて、サーバーの特定のクラスターにマッピングするために、異なる地域のIPを渡しました。この方法論「GeoDNS」は、ユーザーが正しいDNSサーバーにマッピングすることや、DNSサーバーが世界のどこに物理的に配置されているかを信じることができないという事実のために、部分的に不正確です。また、インターネットのトポロジーは、必ずしも地理的な条件と一致しません。

これを解決するために、私たちは「BGPエニーキャスト」モデルに移行し、すべての場所から同じルートを発表し、お客様から私たちのPOPまでの最適な経路を取るようにルーティングを最適化しました。こうすることで、インターネットのトポロジーの制約の中で可能な限り最高のパフォーマンスを得ることができ、DNSサーバーの存在に関する予測不可能な仮定に依存する必要がありません。

ストレージ

毎日、何億ものツイートが送信されます。それらは処理され、保存され、キャッシュされ、提供され、分析されます。このような膨大なコンテンツには、それに見合ったインフラが必要です。ストレージとメッセージングがTwitterのインフラストラクチャーの45％を占めています
。
ストレージとメッセージングのチームは、以下のサービスを提供しています。

Blobstoreクラスタ：すべてのラージオブジェクト（ビデオ、画像、バイナリファイルなど）用

キャッシュクラスタ

メッセージングクラスタ
リレーショナルストア（MySQL、PostgreSQL、Vertica)

挑战

この規模ではさまざまな課題がありますが、マルチテナントは特に克服しなければならない課題の一つです。多くの場合、お客様は既存のテナントに影響を与えるようなコーナーケースを持ち、私たちは専用のクラスタを構築することを余儀なくされます。専用クラスタが増えれば、それを維持するための運用負荷も増えます。

私たちのインフラには驚くようなものはありませんが、興味深いものをいくつか紹介します。

SQL: MySQL、PostgreSQL、Verticaが含まれます。MySQLやPostgreSQLは、広告キャンペーンや広告取引所、社内ツールなど、強い一貫性が必要な場所で使用されます。Verticaは、営業やユーザー組織をサポートするTableauのバックエンドとしてよく使われるカラムストアです。

Hadoop/HDFSは、Scribeベースのログパイプラインのバックエンドでもありますが、アグリゲーターへの選択的なクライアントのレート制限/スロットルの欠如、カテゴリーの配信保証の欠如、メモリ破壊の問題の解決などの制限に対処するために、Apache Flumeへの置き換えを最終テスト段階で行っています。私たちは1日あたり1兆通以上のメッセージを扱い、これらはすべて500以上のカテゴリに処理され、統合された後、すべてのクラスタに選択的にコピーされます。

时间序列中的演变

TwitterはMySQLで構築され、当初はすべてのデータがMySQLに保存されていました。小さなデータベース・インスタンスから大きなデータベース・インスタンスへ、そして最終的には多くの大きなデータベース・クラスタへと移行していきました。MySQLインスタンス間でデータを手動で移動させるには、多くの時間を消費する手作業が必要でした。そこで2010年4月に、分散データストアを作成するためのフレームワークであるGizzardを導入しました。

那时的生态系统越发无法适应。

Gizzardベースのシャード化されたMySQLクラスタ

是的。

2010年5月にGizzardをリリースした後、GizzardとMySQLをベースにしたグラフストレージソリューションのFlockDBを発表し、2010年6月にはユニークIDサービスのSnowflakeを発表しました。2010年は、Hadoopに投資した年でもあります。元々はMySQLのバックアップを保存するためのものでしたが、現在は分析に多用されています。

2010年頃、ストレージソリューションとしてCassandraも追加しました。オートインクリメント機能がないため、MySQLの完全な代替にはなりませんでしたが、メトリクスストアとして採用されました。トラフィックが飛躍的に増加したため、クラスタの増強が必要となり、2014年4月にリアルタイム・マルチテナント分散データベースであるManhattanを立ち上げました。それ以来、Manhattanは私たちの最も一般的なストレージレイヤーの1つとなり、Cassandraは非推奨となりました。

2012年12月、Twitterは写真のネイティブアップロードを可能にする機能をリリースしました。その裏には、新しいストレージ・ソリューションであるBlobstoreがありました。

我所学到的东西

長年にわたり、より良い可用性、より低いレイテンシ、より簡単な開発を利用するために、MySQLからManhattanにデータを移行してきました。また、トラフィックパターンに対応するために、追加のストレージエンジン（LSM、b+treeなど）を採用してきました。さらに、インシデントから学び、バックプレッシャーシグナルを送信し、クエリフィルタリングを有効にすることで、ストレージ層を不正使用から保護するようになりました。

私たちは、仕事に適したツールを提供することに引き続き注力していますが、これは、あらゆる可能性のあるユースケースを正当に理解することを意味します。「一つのやり方がすべてにフィットする」解決法が機能することはほぼありません。一時的な解決策ほど永続的なものはないので、コーナーケース用のショートカットを作ることを避けています。最後に、解決策を過剰に売り込んではいけません。すべてのものには長所と短所があり、現実的な感覚を持って採用する必要があります。

现金

キャッシュは私たちのインフラの3％程度ですが、Twitterにとって重要なものです。キャッシュは、重い読み取りトラフィックからバックストアを保護し、ハイドレーションコストの高いオブジェクトの保存を可能にします。私たちは、RedisやTwemcacheなど、いくつかのキャッシュ技術を大規模に使用しています。具体的には、専用クラスタとマルチテナントのTwitter memcached（twemcache）クラスタ、そしてNighthawk（シャード化されたRedis）クラスタが混在している状態です。運用コストを下げるために、主要なキャッシュのほぼすべてをベアメタルからMesosに移行しています。

チャレンジ

Cacheにとって、スケールとパフォーマンスは主要な課題です。私たちは、320Mパケット/秒のパケットレートを持つ数百のクラスタを運用し、120GB/秒を超えるパケットをお客様に提供しています。イベントスパイクが発生した場合でも、99.9%および99.99%の遅延制約で各レスポンスを配信することを目指しています。

高スループットと低レイテンシーのサービスレベル目標（SLO）を達成するためには、システムのパフォーマンスを継続的に測定し、効率的な最適化を検討する必要があります。これを実現するために、私たちはrpc-perfを作成し、キャッシュシステムのパフォーマンスをより深く理解できるようにしました。これは、専用機から現在のMesosインフラに移行する際のキャパシティプランニングに欠かせないものでした。これらの最適化努力の結果、レイテンシーを変えずに、マシンあたりのスループットを2倍以上にすることができました。私たちは、まだ大きな最適化効果が得られると信じています。

学んだこと

Mesosへの移行は、運用面で大きな成果をもたらしました。構成を体系化し、ヒットレートを維持するためにゆっくりとデプロイし、永続ストアに負担をかけないようにし、この層をより確実に成長、拡張できるようになりました。

twemcacheインスタンスあたり何千もの接続があるため、プロセスの再起動やネットワークの急変化、その他の問題があれば、キャッシュ層に対してDDoSのような接続攻撃が発生する可能性がありました。規模を拡大するにつれ、これはより大きな問題となりました。ベンチマークを通じて、高い再接続率によってSLOに違反することになる場合、各キャッシュへの接続を個別にスロットルするアップテイクルールを実装しました。

キャッシュはユーザー、ツイート、タイムラインなどで論理的に分割され、一般的にすべてのキャッシュクラスタは特定のニーズに応じてチューニングされています。クラスタのタイプに応じて、10Mから50M QPSを処理し、数百から数千のインスタンスを実行します。

合实

Haploについても紹介しましょう。これはTweet Timelineの主要なキャッシュで、Redisのカスタマイズバージョン（HybridListの実装）によってバックアップされています。HaploはTimeline Serviceから読み取り専用で、Timeline ServiceとFanout Serviceから書き込まれます。また、これはまだMesosに移行していない数少ないキャッシュサービスの1つです。

サービスリクエストの集約 800K/秒

附加阅读材料

请查看 Yao Yue (@thinkingfish) 的视频和最近的博客文章，她花了多年时间撰写关于我们使用的Redis以及更新的Pelikan代码库等与缓存相关的出色演讲和论文。

大规模运营Puppet

私たちは、Kerberos、Puppet、Postfix、Bastions、Repositories、Egress Proxiesなど、さまざまなコアインフラストラクチャサービスを稼働させています。私たちは、これらのサービスの拡張、ツールの構築、管理、およびデータセンターとPOP（Point of Presence）の拡張のサポートに注力しています。ちょうどこの1年、私たちはPOPインフラを多くの新しい地域拠点に大幅に拡張し、新しい拠点の計画、起動、立ち上げの方法を完全に再設計する必要がありました。

私たちは、すべての構成管理とシステムのポストキックスタートパッケージのインストールにPuppetを使用しています。このセクションでは、私たちが克服した課題の一部と、構成管理インフラストラクチャの方向性について詳しく説明します。

挑战

ユーザーのニーズを満たすために成長する中で、私たちはすぐに標準的なツールやプラクティスを追い越していきました。私たちは月間100を超えるコミッター、500のモジュール、1000を超えるロールを抱えています。最終的には、コードベースの品質を向上させながら、ロール数、モジュール数、コード行数を削減することができました。

分歧

我们有三个分支供Puppet作为环境的参考。通过这些分支，我们可以适当地在测试环境、金丝雀环境和最终的生产环境中推送更改。我们还允许自定义分支以更好地进行独立的测试。

現在、テストから本番環境に変更を移すには、手作業で少し手助けする必要がありますが、私たちは、自動統合/バックアウトプロセスを備えた、より自動化されたCIシステムへと移行しています。

代码库 mǎ kù)

私たちのPuppetリポジトリには100万行以上のコードが含まれており、Puppetのコードだけでも1ブランチあたり10万行以上あります。最近、私たちは、死んだコードや重複するコードを減らすために、コードベースのクリーンアップに大規模な努力をしました。

这个图表展示了我们公司从2008年到今天的总代码行数（不包括自动更新的各种文件）。

このグラフは、2008年から今日までの総ファイル数（自動更新された各種ファイルを含まない）を示しています。

このグラフは、2008年から今日までの平均ファイルサイズ（自動更新された各種ファイルを除く）のグラフです。

重大的成就

对于我们的代码库来说，最重要的成果是代码审查、风格检查钩子、最佳实践文档化以及定期举办的办公时间。

linting ツール (puppet-lint) を使って、コミュニティの一般的な linting 標準に準拠することができました。コードベースにおけるlintingのエラーや警告を何万行も減らし、コードベースの20%以上に手を入れました。

最初のクリーンアップの後、コードベースの小さな変更が容易になり、バージョン管理フックとして自動スタイルチェックを組み込むことで、コードベース内のスタイルエラーを劇的に減らすことができました。

組織全体で100人以上のPuppetコミッターがいるため、内部およびコミュニティのベストプラクティスをドキュメント化することで、力を発揮することができました。参照できる単一の文書があることで、コードを出荷する際の品質と速度が向上しました。

チケットやチャットチャンネルが十分な情報量を提供しない場合や、達成しようとしていることの全体像を伝えられない場合、支援のための定期的なオフィスアワーを開催し（時には招待制）、1対1のヘルプを可能にしました。その結果、ほとんどのコミッターはコミュニティやベストプラクティス、最適な変更の適用方法を理解することで、コードの品質と速度を向上させることができました。

监测

システムメトリクスは一般的に有用ではありませんが（Caitlin McCaffreyのMonitoramaの2016年の講演はこちら）、私たちが有用と判断したメトリクスに追加のコンテキストを提供します。

我们发出警告并对其进行图表化的最有用的度量标准包括以下内容。

ファイルリソース数。フェッチされているファイルの数。

これらの各メトリクスは、ホストごとに収集され、役割ごとに集計されます。これにより、特定の役割、役割のセット、またはより広範な影響を及ぼすイベントにわたって問題が発生した場合、即座に警告と特定を行うことができます。

冲击

Puppet 2からPuppet 3への移行とPassengerのアップグレード（いずれもこんど別記事で）により、Mesosクラスタ上での平均Puppet実行時間を30分以上から5分未満に短縮することができました。

这个图表显示了在Mesos集群上使用Puppet的平均执行时间，以秒为单位。

对于对Puppet基础设施支持有兴趣的人，现在征集中。

より一般的なシステムのプロビジョニングプロセス、メタデータデータベース（Audubon）、ライフサイクル管理（Wilson）に興味があれば、プロビジョニングエンジニアリングチームは最近我々の#Computeイベントで発表し、その模様はここに収録されています。

これは、Twitterエンジニアリングの皆さんの努力と献身があったからこそ実現できたことです。Twitterの信頼性を築き、貢献した現・元エンジニアに賞賛を送ります。

对于为这篇博客文章做出贡献的Brian Martin、Chris Woodfield、David Barr、Drew Rothstein、Matt Getty、Pascal Borghino、Rafal Waligora、Scott Engstrom、Tim Hoffman、Yogi Sharma特别感谢。