アメリカの議会図書館がすべてのツイートの保存をやめて今後は選ばれたツイートのみ

アメリカの議会図書館(Library of Congress)が今日(米国時間12/26)、7年前に意欲的な試みとして始まったすべての公開ツイートの文書館への保存をやめる、と発表した。その理由として挙げているのは、このところツイートの量が前よりも大幅に多くなっていることと、Twitterの決定により文字数制限が140から280に倍増したことだ。1月1日より同図書館は、保存するツイートを選ぶ、と白書で述べている。

その説明によると、“今後は、選挙や特定の政策など、一定のテーマやイベント、国民の関心事に関連しているツイートを保存していく”そうだ。トランプ大統領のツイートはたぶんすべて保存されるけど、あなたの朝食の写真はだめでしょうね。

2010年に、同図書館はすべての公開ツイートの保存を開始した。“それは、そのほかの素材を収集するのと同じ理由、すなわち、議会およびアメリカ国民のために知識と創造性の記録を取得し保存するためだ”、と今日の発表は言っている。Twitterから同図書館への寄贈により、それにはTwitterがローンチした2006年からのすべての公開ツイートのバックログも含まれる。

しかし今やツイートは量が膨大で、しかも今後はより長くなるから、ひとつ残らずの悉皆的な収集は無理になった。しかも同図書館が保存するのは今後もテキストだけなので、画像やビデオやリンクの多い最近のツイートは、同図書館的にはあまり価値がない。

“本図書館は一般的に、網羅的な収集は行わない”、とも述べられている。“文書館への寄贈が最初に企画されたときはソーシャルメディアの方向性が定かではなかったので、公開ツイートだけを例外として取り上げた。今やソーシャルメディアは一般的に定着しているので、本図書館の収集方針〔==網羅的でない〕に合った収集の実践を行うべきである”。

同図書館がふつうの人びとの体験や記憶を史料として記録している例として、ほかにAmerican Folklife Centerが挙げられる。ここはVeterans History Projectの実行主体として、主に方言の記録を収集している。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

Googleのデータセンターのネットワーキングインフラストラクチャ、10年間の進化の過程

2014-09-30_1420

Googleは今日(米国時間8/18)、家庭のWiFiの高速化技術を発表したが、同社内部ではこれまで長年、それよりもずっと複雑なネットワーキングの問題に取り組んできた。Googleのデータセンターを構成するマシンの数は数十万のオーダーだから、そこらのふつうのルータやスイッチでそれらを接続することはできない。サーバ間を流れるすべてのデータを管理するためにGoogleは、独自のハードウェアとソフトウェアを作ってきたが、今日は同社の研究部門のブログ記事などで、同社のネットワーキングインフラストラクチャの進化の軌跡を紹介している。

Googleの内部ネットワークの現在のセットアップはJupiterネットワークと呼ばれ、その容量は第一世代のネットワークの100倍、全体の二分割帯域幅(bisection bandwidth)*は毎秒1ペタバイトに達する。Googleによると、このスピードは、10万台のサーバが合衆国国会図書館のデジタル化された全データを、1/10秒以下で読み取る速度に相当する。〔*: bisection bandwidth, ネットワークを二分割したとき両部分間に存在する全帯域の合計。〕

ブログ記事の中で筆者のAmin Vahdat(Googleのフェロー)は。“このようなネットワークパフォーマンスがGoogleのサービスの能力をすさまじく強力にしてきた”、と書いている。“しかも帯域の高低差がないから、技術者たちは帯域のいろんなレベルに合わせてコードを最適化する必要がない。たとえば初期には、サーバの配置によって性能やエラー率に差が生じたため、データをどこに置くかという悩ましい問題がつねにあった。すべてのサーバをラックの最上位の(最高速の)スイッチにぶら下げたりすると、たった一つのスイッチのトラブルで大きな被害が生じたりするのだ”。

image02

10年前のGoogleのネットワークは、まだこれほどの性能に達していなかった。当時はYouTubeを買収する前、そしてGmailやGoogle Earth、Google Mapsなどのサービスを立ち上げた直後だった。そのあとの短い10年間で、同社のネットワーキングニーズはきわめて急速に変わっていったのだ。

2005年当時のマシンは、こんな感じだ:

  1. fh10_board.jpg

  2. firehose1-1_chassis.png

  3. copy-of-fh_cabling-1.jpg

その10年を振り返った論考によれば、同社は2004年にはまだ、標準的なサーバクラスタを配置していたが、上図の2005年のマシンは、同社のFirehose 1.0データセンターアーキテクチャで配置(デプロイ)したネットワークの最初の機種だ。その2005年のマシンの目標は、1万台のサーバ間で1 Gpsの二分割帯域幅を実現することだった。それを達成するためにGoogleは、スィッチングのファブリックを内製のサーバに直接統合しようとしたが、しかしそうすると、“サーバのアップタイムが理想に達しなかった”。

Firehose 1.1でGoogleは初めて、カスタムのデータセンタークラスタファブリックをデプロイした。“FH1.0の経験から、通常のサーバにスイッチのチップを入れてはいけないことを学んだ”、と当時の技術者の一人が書いている。そこでGoogleはカスタムのエンクロージャーを作り、Closアーキテクチャと呼ばれるデータセンターネットワークへ移行した。

2008年に、FH 1.1はWatchTowerへと進化した。ケーブルは、通常のネットワーキングケーブルではなく10Gのファイバを使った。Googleはこのバージョンのデータセンターネットワークを、全世界のデータセンターで展開した。

それは、こんなラックだ:

WT2

1年後に、WatchTowerはSaturnに変身した。WatchTowerのファブリックは87 Tbpsまでスケールできたが、Saturnはその混みあったラック上で207 Tbpsまでスケールアップした。

  1. saturn_chassis.png

  2. wtbundles.jpg

  3. pluto-png.jpg

Saturnは、Googleによく仕えた。その後3年間もGoogleのデータセンターネットワークのアーキテクチャは、Saturnで十分間に合ったのだ。

上記論考には、こう書かれている: “サーバ一台あたりの帯域要求が継続的に成長していくだけでなく、データセンターのすべてのクラスタの、むらのない均一な帯域も求められた。40G対応の高密度商用チップの登場に伴い、Closファブリックをデータセンター全体に拡張して、クラスタ間ネットワーキングの層もそこへ入れることを、検討できるようになった”。

それは、一つのデータセンターを一つの巨大なコンピュータのように扱えるアーキテクチャだ。ソフトウェアが計算資源とストレージ資源の分散を管理し、ネットワーク上のすべてのサーバからそれらを可利用にしている。

Jupiterのハードウェアはたしかに、同社の初期の内製ネットワーキングハードウェアとは外見的にも異なっているが、しかし多くの点で、同社がそもそもの初期からSoftware Defined Networking(SDN)の考え方を採用して、イノベーションのスピードを上げてきたことも事実だ。

Googleは今日、同社のネットワーキングのセットアップを、いろんな側面から詳説する4つの小論を発表した。Googleは現行のハードウェアやソフトウェアのアーキテクチャの限界に他社よりも早くぶつかる方だから、Googleからのこの種の情報提供によって同社の外での新しいイノベーションが、これまでも生まれてきている。

すべてのスタートアップが自前のデータセンターを構えるわけではないが、でも他のデータセンターの運用者たちは確実に、これらの論考の細部から多くを学び、自らのソリューションに、そして結果的にはユーザの利益に、反映していくことだろう。

Jupiter-superblock3

[原文へ]
(翻訳:iwatani(a.k.a. hiwa