4日前

Twitter を作るのはなぜ難しいのか

アーキテクチャオタクらしくアーキテクチャの話をします。 前: https://togetter.com/li/1975837
244
@fushiroyama

お父さん、博士課程 Software Engineer @microsoft 👨🏻‍💻 / ex-@amazon All opinions are my own.

note.com/fushiroyama/

@fushiroyama

Twitterみたいな緩いつながり、TLひとつ実装するだけでも普通のウェブシステムみたいなクエリでは取れなくてちょっと考えれば非常に複雑なシステムであることは明白だし、システムアーキテクチャの試験の定番トピックだったりするので「誰でも作れる」とか「簡単」みたいなのはご指摘申し上げたくなる

2022-11-22 02:16:50
@fushiroyama

昔つぶやきましたが例えばこの記事を読むと分かりやすいです。 twitter.com/fushiroyama/st… "Grokking the system design interview" にもTwitterクローンを作る的なのがあった気がします。とにかくsimplifyしてもまだとても難しい。どうやって今の状態を支えているのか本当に頭が下がります。

2022-11-22 02:28:14
@fushiroyama

秒間120万つぶやきを処理、Twitterシステムの“今” - @IT atmarkit.co.jp/news/201004/19… Clubhouseで話したのこれです。10年前のTwitterのアーキテクチャだけど初めて読んだ時は割と感動した。 秒間120万レコードずつ増えるシステムから自分の最新つぶやき20件をどう表示するか考えながら読んで欲しい☺️

2021-03-17 11:57:55
@fushiroyama

実はこういう、素直にテーブル設計すると絶対にスケールしないアーキテクチャに関する問題は米テック企業のシステム設計の面接で好んで出題されたりする。 Grokking the System Design Interview という有料のコースにはこういう良問が沢山あるのでおすすめ。

2021-03-17 12:00:14
Yuta Okamoto @okapies

で、その後の10年でさらに増え続けたトラフィックに対して2010年のアーキテクチャですらナイーブで、既成の要素技術では間に合わず、彼らのシステムの要件に合う専用のデータベースシステムを内製することまでしている。それが、例の図に名前が登場している Manhattan。 wired.com/2014/04/twitte… twitter.com/fushiroyama/st…

2022-11-22 09:41:30
Alex Xu @alexxubyte

Twitter Architecture 2022 vs. 2012. What’s changed over the past 10 years? Thank you, @elonmusk for the transparency. {1/2} pic.twitter.com/Fvbn7EDoOS

2022-11-20 01:42:44
拡大
Yuta Okamoto @okapies

なお、たかだか一プロダクトのために専用のデータベースシステムを内製するというのは、一般的には正気の沙汰ではない。Wired の記事に載ってる三人は、おそらく「コアエンジニア」なんて気軽な表現では間に合わないような方たちだと思う。 wired.com/2014/04/twitte…

2022-11-22 09:54:28
リンク WIRED This Is What You Build to Juggle 6,000 Tweets a Second When you open the Twitter app on your smartphone and all those tweets, links, icons, photos, and videos materialize in front of you, they're not coming from one place. They're coming from thousands of places. 1 user
Yuta Okamoto @okapies

2022年現在の Manhattan の守備範囲がどこまでか、というのはちょっとよく分からないんだけど、分かりやすく言うと、おそらく「バルスで落ちない Twitter」の中核を担う要素技術の一つだと思われる。

2022-11-22 10:08:23
Yuta Okamoto @okapies

Twitter のようなシステムを大規模に作る時の基本的な課題意識として、まず、最低限、この記事に書かれていることを踏まえる必要があって、その上で、これがさらに10倍100倍とスケールしていった時に高い耐障害性と運用性をどう実現するか、という課題に応えてきたのが現在。 atmarkit.itmedia.co.jp/news/201004/19…

2022-11-22 10:15:22
Yuta Okamoto @okapies

この手のワークロードを処理するノウハウを確立するために最先端のソフトウェアエンジニアたちが日々奮闘していた黎明期、そこから生まれた要素技術がまだ未成熟だった頃に起きた地獄絵図として有名なスライド。 slideshare.net/TakehiroToriga…

2022-11-22 17:09:52
Yuta Okamoto @okapies

補足すると、Twitter も当初はこの Cassandra を使おうとしていたが、おそらくいろいろあったんでしょう。で、結果的にこれが Manhattan に置き換えられた。 twitter.com/okapies/status…

2022-11-23 15:21:32
chokudai(高橋 直大)🍆@AtCoder社長 @chokudai

AtCoder(株)代表取締役社長(競技プログラミングの会社)/競プロ世界ランカー(ICFPC優勝4回等)/筑駒中高→慶應SFC卒/たこやき/ぷよぷよ(PS4 MaxR:2813)/モバマスまゆ小日向でしてP まゆドリフ全一/チュウニズム虹レ/書籍『最強最速アルゴリズマー養成講座』著者/NewsPicksプロピッカー

chokudai.net

chokudai(高橋 直大)🍆@AtCoder社長 @chokudai

よく「なんでTwitterは生TLを流すという当たり前のことをしてくれないんだ!」みたいなのを見るけど、「生TLを流すのって技術的にめちゃめちゃ難しいので全く当たり前じゃなくない……?」って思ってしまう。 よくTweetDeck生きてるなーって思ってる。

2022-11-22 15:42:03
chokudai(高橋 直大)🍆@AtCoder社長 @chokudai

@SSRS_cp Twitterの月間アクティブユーザが3.3億とからしいので、頂点数3.3億、辺は適当に100億くらい?のクエリに高速に答えないとダメで、サーバー分割とかするとどう並列に動かすかとかがむずかしい!

2022-11-22 15:44:30
chokudai(高橋 直大)🍆@AtCoder社長 @chokudai

@SSRS_cp 雑に考えて、各ユーザのTLにpushする方式と、読み込んだ時にpullする方式が考えられるんだけど、pullする方式だとリアルタイムにTL更新するとかは無理だし、pushする方式だと自分がツイートするたびにめっちゃpush走ってヤバそう、みたいなのが容易に考えられるよね。

2022-11-22 15:47:44
Yuta Okamoto @okapies

初期の頃に、中の人が「ナイーブに実装したら100万フォロワーのセレブがツイートするたびに100万ユーザーのタイムラインに push が走ってシステムが落ちまくって大変だったんですよ」って話してる記事があった覚えがある。 twitter.com/chokudai/statu…

2022-11-22 21:06:13
Yuta Okamoto @okapies

もし、もう少し初期の Twitter について詳しい話が知りたい人はこの記事もいいかも。だいぶ話が複雑になってきているが、これでも2013年頃。例の図に出てくるサブシステムのいくつかは、すでにこの時期には登場している。 highscalability.com/blog/2013/7/8/… pic.twitter.com/2z8KVonYQF

2022-11-22 22:44:43
拡大
リンク highscalability.com The Architecture Twitter Uses to Deal with 150M Active Users, 300K QPS, a 22 MB/S Firehose, and Send Tweets in Under 5 Seconds - Toy solutions solving Twitter’s “problems” are a favorite scalabi... 47 users 1138
Yuta Okamoto @okapies

2013年のこの記事ですら、こういう書き出しで始まっている。「Twitterの『問題』を解決するオモチャの解決法を考えるのはスケーラビリティあるあるだ。誰もがTwitterは簡単で、少し手を振ればスケーラブルなTwitterができると思っている。だが、VPoEのRaffi Krikorianにとってはそうではないようだ。」

2022-11-22 22:55:21
Yuta Okamoto @okapies

雑な言い方をすると、なにかをバラまいたり集約したりするのを、あらゆる規模で効率的にやる方法って自明じゃないんですよね。

2022-11-22 23:18:34
\ Tgから毎日100名様にお好きなポイントプレゼント /

コメント

cyphergoodluck @cyphergoodluck 4日前
「コンピュータの中に入ってる文章に含まれる単語の出現回数を数え上げる」→ サイズNのread only ストリームデータでO(log N)のread/writeメモリで頻度・中央値などは厳密には数え上げ不可能ということが証明されていますね。Yao's min-max principleの応用。
4
cyphergoodluck @cyphergoodluck 4日前
「さて、間に合いますかどうか。」→上場廃止で100%株式取得の時点で根こそぎリセットして更地に作り直すのではないか?
8
オサダゴワア @FiKXADhe1qceZ0T 4日前
最初にtwitterやってびっくりしたのがスクロールすると無限にテキストが出てくるとこ。でも既読ツイは表示されにくいようにして欲しいのは難しいかな
29
風のSILK @PSO_SILK 4日前
SEやってる人間なら、一度は「Twitterみたいなの」や「Facebookみたいなの」や「LINEみたいなの」を作れとか作れないかとか言われたことあるんじゃない?(私は2度言われた)私は真面目に設計せずに勘で「無理」って答えたけど、真面目に設計してみた人もいるんじゃないかしらね。実際どうなんだろう。興味はある。
39
ひととせ @hitotose_bloom 4日前
技術的な問題抜きにしても、SNSが提供するメインコンテンツって=利用者だから利用者の数が足りないならそれはもうTwitterではないのよ
14
aa @aa60006342 4日前
新卒研修でLINEみたいなチャットアプリを作れってのはやった。仕組みだけなら割と簡単なんだけど、スケール考えると一気に難しくなるんだよな
36
𝙉͟⃟͟𝙖͟⃟͟𝙜͟⃟͟𝙖͟⃟͟𝙩͟⃟͟𝙨͟⃟͟𝙪͟⃟͟𝙠͟⃟͟i @i_dnt_need_u2 4日前
イーロン・マスクの今までやり遂げてきた事業のスケールを考えれば他の誰も口は出せない。
16
まーむるもーま @hellowo10607338 4日前
基本的に莫大なデータからアイテムを探すのって一意な値や組み合わせがある事が前提なんだけど、Twitterの単語検索は文字列の中にその単語が存在している、という条件でコンピュータ的に負荷も時間も掛かるものなのにも関わらず、データの莫大さは普通のサービスと比較してとんでもない桁違いな訳だから、そこにとんでもない手間と工夫が掛けられているのは想像に難くない
3
まーむるもーま @hellowo10607338 4日前
指定のユーザー群のツイートをタイムライン順に並び替えて表示するのは楽だが(それでもフォロワー数が莫大になってくると色々工夫が必要そうだけど)、全てのユーザーのツイートからこの文字列を含むもの、となると何をどうやって実現してんのか… ハッシュタグなんて分かりやすい目印を使ってないツイートでさえも拾ってこれるし
2
ねや @AriaSub 4日前
PSO_SILK 100人が使う「ツイッターみたいなもの」なら本家より良い仕様で作れると思うけど、1000人になると露骨に嫌な顔する。1万人になるなら逃げる。 既存ソリューションの紹介一覧作って逃げた。
39
ひろっぴ@(自称)鉄道記録屋 @hiroppi1969 4日前
30年くらい前に乗換案内の劣化版(始発駅と終着駅を入力すると料金をはじき出す)を作ろうとしてたことがあったけど料金データのテーブルづくりや例外処理をどうやってやるかを思いつけなくて挫折したな
4
IT土方 @s_takepon 4日前
1から作るのと出来てるものを調整したり弄ったりするのはまた難易度が違うからなぁ
1
あさき @asaki_knnk 4日前
規模の経済ってプログラミング?インターネットサービス?の世界だと成り立たないというかむしろ負荷になるのか 面白いな
1
キケリキー @KIKERIKI17 3日前
ちなみに、普通のHTTPサーバーだって、アクセス量が増えると難易度は爆上げになる。アクティブ会員数10万程度の規模でも、適当に安価なWEB屋に頼んでWordPressかなんかでポイっとHPを作られた場合、ニュース配信の直後503が返ったりする。ソシャゲ開発にSQLデータベースの技術屋が参加したら問題が一気に解決した都市伝説、界隈なら一度は聞いたことがあるだろう。
6
ヘリオドール @heliodor_ruby 3日前
twitterの一番基本的な部分、投稿した文・画像などをサーバーに保存し順番に表示していくとか、フォローした人の投稿データをサーバーから読み出して表示するだけを小規模に作るなら、まぁシステム構築する人なら頑張れば出来そうな気はする。
0
ヘリオドール @heliodor_ruby 3日前
heliodor_ruby (続き)ただ、億単位の利用者の投稿データを時系列で整理するとか、RTされたらその数億人のデータのなかから探してきて当事者のタイムラインに入れ込む(他のフォローしてる人にも反映)とかを破綻しないよう処理できるかと言ったら正気の沙汰じゃ無いんだろうなぁ…。 システム構築の事は分からないけど、分からなくてもとんでもないということだけは想像つく
3
カレーうどん @kareudon14 3日前
確かに3億もユーザーいること考えると内部のシステムとかアレコレ超絶難しそう。ただ、多分旧経営陣に反発して今のイーロンtwtterに残ったエンジニアもいるし、これから新規につよつよエンジニアが採用されたりするので意外と上手く乗り切れるのかも?ソフトウェアが腐るかどうかはまとめの方の意見だと半年~1年でわかるみたいですね。
2
すいか @pear00234 3日前
確か最初は「見た目超リッチなIMAP4」みたいな構造だったと聞いたな。ユーザー一人ひとりが自身のタイムラインデータベーステーブルをもってて、ツイートしたら自身のタイムラインとフォロワーのタイムラインにツイートをフィードするっていうやつ。自分のタイムライン出すのも他人のタイムライン見るのも順に読み出せるし、速報性も結構スケールするとかなんとか。ただし、横断検索性が悪いんだよねこれやると。
0
煮込みカツ定食 @SbXyVN5gp95BpWu 3日前
FiKXADhe1qceZ0T ユーザーの側に無限のキャッシュ機能でも作らなきゃユーザーxフォロワー数x閲覧データとかいう恐ろしいデータを蓄積せにゃならんのだが、分からんか
0
煮込みカツ定食 @SbXyVN5gp95BpWu 3日前
AriaSub 1つのツイートは水滴1つだとしてもそれを貯めるのに琵琶湖ぐらいのタンクが必要が必要という
0
紅芋タートル @benimoturtle 3日前
cyphergoodluck 開発を「リセット」できたら誰も苦労しないんだよなぁ……
0
紅芋タートル @benimoturtle 3日前
エンジニアを人手さえあれば容易に代替可能と思われちゃうのは人月商売の悲劇というかなんというか……
1
YOGAKUTIME @YOGAKUTIMEMAN 3日前
AriaSub 「100人しか使えないツイッターみたいなもの」になら需要があると思うのですが実際に作れないもんですか? 本当にお友達や知り合いしかアクセスできない完全に閉鎖されたSNS体系。
0
ねや @AriaSub 2日前
YOGAKUTIMEMAN 一つのシステムをIDで100人ごとに区切るだと、100人x100グループでユーザーが一万人になってしまうので、100人しか使えないシステムではなく一万人で使うシステムですね。検索等の設計は多少楽にはなるんですが共有部分が多すぎるので。 100人サーバーを100セット別々の場所に作るなら可能、イニシャルやランイングコストが大きい 考え方としてはMustdonのインスタンスが近いですね
1
高見知英 @TakamiChie 1日前
この辺マストドンとかどうなってるんだろう? 確かに1サーバーで1000人10,000人をホストするのは難しいかもしれないけど、そもそも単一サーバーでそれを賄う必要がないのがマストドンなわけで。ActivityPubも億単位のユーザーの前には無力なのか、可能性はゼロじゃないのか。 Tumblrが興味を示すくらいだからそんな数千人オーダーが限度の仕様じゃないような気もするけど。
0
Yuta Okamoto @okapies 20時間前
TakamiChie やってみないと分からないとしか言えませんが、例えばインスタンス間接続がボトルネックになる可能性はあると思います。実際に問題になるかはトポロジー次第かなぁと。
1