Twitterを支えるインフラストラクチャ - ネットワークのスケールアップ，ストレージ，プロビジョニング

Twitterエンジニアリングチームは先頃，同社のソーシャルメディアサービスを支える独自のデータセンタ・インフラストラクチャと，その背後にあるコア技術の発展およびスケールアップに関する情報を公開した。そこに含まれるおもな教訓は，当初の仕様と要件を越えるアーキテクト; トラフィック傾向が設計能力の上限に迫った時に実施する迅速かつ大胆な変更; “一時的な変更や回避策”というものものはない，回避策は技術的負債である; 作業に適したツールを提供する – これはとりもなおさず，考えられるすべてのケースを適確に理解することでもある; 内部およびコミュニティのベストプラクティスの資料化が“増力装置(force multiplier)”となる，といったものだ。

ソーシャルネットワーキングとオンラインニュースサービスを提供するTwitterが誕生したのは2006年だ。当時は物理的なエンタープライズベンダのハードウェアが“データセンタを支配”していた，とTwitter Engineering Blogの先日の記事にはある。ローンチに先立つ10年の間，ユーザベースの急激な成長が，ハードウェア層において多くの技術的課題を生み出していた。Twitterはパブリッククラウドにおいて“大きな存在感”を持つ一方で，自社のプライベートインフラストラクチャにも多くの投資を続けている。2010年に同社は，サードパーティ配備のホスティングからプライベートなデータセンタインフラストラクチャへの移行を実施した。それから6年間，“テクノロジとハードウェア効率において最新のオープン標準を活用するため[...]，ハードウェアのエンジニアリングとアップデートの継続的な実施”を積み重ねている。

2010年末には，それまでのサードパーティ所有インフラストラクチャで遭遇したスケールとサービスの問題に対処して設計された，最初のインハウス・ネットワーク・アーキテクチャを完成させている。当初はディープバッファトップ・オブ・ラック(ToR)によるキャリア仕様のコアネットワークスイッチを採用して，ワールドカップ サッカー2014のような世界的イベントが作り出す，前例のないボリュームのトランザクション数(TPS)をサポート可能にしていた。しかしTwitterインフラストラクチャチームは，その後数年間でネットワークのポイント・オブ・プレゼンス(PoP)を新たに5大陸で立ち上げた後，2015年にはそれまでの階層型データセンタネットワークワークトポロジを廃して，Border Gateway Protocol(BGP)を使用したClosネットワークにルーティングを移行している。Closアプローチで注目されるのは，単一デバイスの障害による‘爆発半径’が小さいこと，水平方向のバンド幅拡張能力，CPUオーバーヘッドの低さとルート能力の高さなどだ。

Twitterのエンジニアリングチームは，同社のネットワークインフラストラクチャをスケールアップする過程で，非常に多くの教訓を学んだ。

• 当初の仕様と要件を越えたアーキテクト，トラフィック傾向が設計能力の上限に迫った時の迅速かつ大胆な変更の実施。
• データおよび指標に基づいた適切な技術的設計判断の実施。使用する指標はネットワークオペレータに理解可能なものであること。ホスト環境やクラウド環境ではこれが特に重要だ。
• “一時的な変更あるいは回避策”といったものは存在しない。ほとんどの場合において，回避策とは技術的負債である。

Twitterのインフラストラクチャ面積の45%を占めるのがストレージとメッセージングだ。インフラストラクチャチームは社内ユーザに対してHadoopクラスタ，独自のManhattan(Apache Cassandra的な)分散データベースクラスタ， FlockDBグラフストレージクラスタ(Gizzardと共有型MySQLを使用)，Blobstoreクラスタ，共有型キャッシュクラスタのTwemcacheと‘Nighthawk’，DistributedLogメッセージクラスタ(Heronで処理するためのもの)，リレーショナルストア(MySQL，PostgreSQL，Verticaなど，さまざまなサービスを提供している。2010年には計測値のストレージソリューションとしてCassandraが加わったが，2014年4月にManhattanがローンチされた以降は，社内的に使用不可となっている。

Twitterの主要なキャッシュの大部分は，ベアメタルから，オープンソースのApache Mesosクラスタ管理システムの巨大なデプロイメントに移行している(TwitterはMesosコードベースの主要なコントリビュータの１社でもある)。代表的な例外はTweetのタイムラインである‘Haplo’で，カスタマイズバージョンのRedisを使用して実装されている。320Mパケット/秒という集約パケットレートを持つ数百のクラスタを運用し，クライアントに120GB/秒を提供するTwitterにとって，スケールアップとパフォーマンスは最も大きなテーマだ。高スループットかつ低レイテンシというサービスレベル目標値(SLO)を満足するために，エンジニアたちは継続的にシステムのパフォーマンスを計測し，効果的な最適化方法を探っている。例えば，同社のエンジニアが開発したオープンソースのキャッシュパフォーマンステストツールであるrpc-perfを使用することで，さまざまなロードシナリオ下でキャッシュシステムがどのような動作をするかを理解できる。

ストレージおよびキャッシュ実装に関するおもな教訓は次のようなものだ。

• サービス固有のトラフィックパターンの改善手段として，Twitterでは，同社のManhattan分散データベースにストレージエンジン(LSM, B+ツリーなど)を追加する方法を採用している。また，バックプレッシャ信号を送信し，クエリのフィルタリングを可能にすることにより，ストレージ層を乱用から保護している。
• ジョブに対する適切なツールの提供に注力することで，考えられるすべてのユースケースを正しく理解することが可能になる。“フリーサイズ(one size fits all)”ソリューションがうまく行くことはめったにない。また，コーナーにショートカットを作るような方法は避けるべきである。いずれも一時的なものに過ぎず，恒久的な解決にはなり得ないからだ。
• Mesosへの移行は，Twitterにとって“運用的な大成功”であった。これによってインフラストラクチャ構成の体系化が実現し，計画的なデプロイが可能になると同時に，永続的ストレージ層においてはキャッシュヒット率を維持し，問題の発生を未然に回避できるようになった。
• キャッシュはユーザ，Twitter，タイムラインなどに論理的に分割され，基本的にすべてのキャッシュクラスタがそれぞれのニーズに合わせて調整されている。

Twitterでは，社内システムの構成管理と起動後のパッケージインストールのすべてにPuppetを使用している。同社には１ヶ月あたり100を越えるコードへのコミットがあり，500以上のモジュール，1.000を越えるロールがある。Puppetには環境毎に３つのブランチがある。これによってテストと並行リリース(canarying)の管理が可能になると同時に，最終的に変更内容を本番環境にプッシュすることができる。Puppetコードベースの拡張過程においてもっとも効果的だった変更は，コードのリンティング(lintimng)，スタイルチェック用のフック，ベストプラクティスの文書化，正規の勤務時間の保持などだ。

• 組織全体で100人以上のPuppetコミッタの存在と，資料化された社内およびコミュニティのベストプラクティスが“増力装置(force multiplier)”となっている。
• 参照する資料をひとつにすることで，リリースするコードの品質とスピードが向上した。
• 営業時間内での支援を確保しておく(場合によっては依頼する)ことで，チケットやチャネルで十分なレベルの通信帯域を提供できなかったり，あるいは実行したいことの概要を伝えられなかったりする場合でも，1:1のヘルプが可能になる。

Twitterプラットフォームを支えるインフラストラクチャのスケールアップに関しては，Twitter Engineering Blogの記事“The Infrastructure behind Twitter: Scale”に詳しく説明されている。補足関係にある以前のブログ記事“The infrastructure behind Twitter: Efficiency and Optimization”では，TwitterのプライベートなPaaS(Platform as a Service)の発展に重点が置かれている。