2022/05/02 16:37
pwatermark
コレ性能試験の結果とか書いてないんだけど、1000万ユーザに耐えるかどうかは論理で判定しろ(読み解け)ってこと？
2022/05/02 16:50
prograti
"これらの機能ははRDBにはないので、NoSQLを使います。" シャーディングがあるのでは？
2022/05/02 16:55
everybodyelse
NoSQLで作った以上って感じ。データ保存方法を変更したらデータがおかしくなって死にそう感。実際にはDynamoDB streamとかでRDSに流し込んでデータを正規化しておくと良さそう。/ 特に1000万という数字に理由はなさそうだな。
2022/05/02 17:05
north_korea
耐えるの定義が曖昧。1000万人全員が残り全員をフォローすれば破綻するはず。
2022/05/02 17:21
UDONCHAN
後で読む
2022/05/02 17:46
mattn
出来れば 1000 万ユーザに耐える根拠が欲しかった。
2022/05/02 18:12
wwolf
AWSくんが頑張ってくれるから1000万人乗っても大丈夫！的な感じかな
2022/05/02 18:12
taruhachi
一人あたりのフォロワー数を平均100人、一日のツイート数を100回とすると、1人あたり毎日1万レコードの追加、1,000万人利用で毎日1,000億レコードづつ肥大化する。耐えられるかは負荷試験まち。
2022/05/02 18:20
programmablekinoko
こういうのはなんというか最後は金の力の気がする
2022/05/02 18:20
onesplat
素人かよ
2022/05/02 18:22
Shinwiki
秒間リクエスト何本なの
2022/05/02 18:30
mysql8
30億のデバイスで走るJavaScriptの方が信憑性高そう
2022/05/02 18:47
stk132
dynamodbを金でぶん殴った結果も書いといて欲しかった
2022/05/02 19:08
m50747
負荷テストの結果次第かな。それやって評価しないと俺の考えた最強のサーバーインフラで終わってしまう。 負荷テストにお金かかるやつ。
2022/05/02 20:02
circled
クラウドが日々進化してるので、年々スケールしやすいサービスを作りやすくなってるのは確かだけど、問題は、例えば飲み会の参加人数が不明なのに1000人入れる宴会場準備してる奴がいたら頭おかしいよね？って話。
2022/05/02 20:05
turanukimaru
タイトルは盛りすぎだけどDynamoDBでいくらでもスケールさせられる構成を作る例としては良いものでは。特にAPIを作ってから対応するデータ構造を作る、というのは重要だ。フロント側が雑な要求をすると酷いことになる。
2022/05/02 20:27
cuttoff19
ぶこめ
2022/05/02 20:32
uva
1000万ならAmazon Aurora/Cloud Spannerでいけちゃいました、みたいな話を聞きたいかな
2022/05/02 20:44
earu
RDBならすげーなと思ったがDynamoかと思い真面目に読めなかった
2022/05/02 20:54
mayumayu_nimolove
1000万ユーザーの根拠が書かれてないような。。エンジニアならそこちゃんと書こうよ。
2022/05/02 21:54
heguro
"ツイートをしたら、そのユーザのフォロワーのタイムラインにツイートを書き込む" Mastodonの実装だ(こちらはPostgres+Redis) / Mastodonサーバ連合全体の統計で320万ユーザらしい / TLを一定数しか保持しなければ肥大化しない
2022/05/02 22:00
b-wind
お財布事情を考えなければこういうので行けるのかね。1000万ユーザーというのが同時接続だったら凄いけど。
2022/05/02 22:06
hiroomi
“監視をしてボトルネックを見つけてから判断しても、遅くはないでしょう。”
2022/05/02 23:44
yamadashy
実際に負荷試験されてないけどアプローチとしては勉強になった。フォロワー多い人問題に関してもっと根拠ある解答だったらなあ。
2022/05/02 23:52
threetea0407
DynamoDB の Quota を緩和する手順が抜けてる
2022/05/03 00:28
aox
人をいっぱい雇えば電話とFaxでもいけるのでは。なんでもピコピコでやろうとすると人間だめになります
2022/05/03 02:27
tettekete37564
何気に参考になりそう
2022/05/03 02:33
geerpm
フォロワー数多い人のツイート書き込み対策別途だと片手落ち感。それならRDBでRead対策別途でも良いのでは。実際の費用シュミレーションも気になるなあ
2022/05/03 02:59
toritori0318
1000万の根拠はわからないけどスケールはしそう（DynamoDBのWrite高いのでコストかかりそうだけど
2022/05/03 03:09
nutahuate
後で読む、NoSQLあんまり使えてないので
2022/05/03 03:41
sin20xx
何を言いたいのかわからないなぁ。1000万ユーザーの定義が不明だしSnowflakeネタとして見てももう時代的にも昔のネタすぎる気もするが。単純に高性能DBを使いました以上の説明がないのだけども。一体これは何を言いたいの
2022/05/03 05:28
odakaho
1000万規模だとユーザが全世界にいるからリージョンが落ちた時の対策も考えとかんと
2022/05/03 05:35
ken39arg
軽く実装見たけどCUがヤバそうなのでquotaに直ぐ捕まりそう。1000万ユーザーの定義がわからないけど多分同接とフォロー関係がそれなりにあったらうまくいかないパターンかと。
2022/05/03 06:18
eos2323
どうやって1000万なのかが読めなかったので八百万のユーザだと思って読む
2022/05/03 07:12
shields-pikes
参考になるかな。読んでみる。
2022/05/03 07:14
youichirou
このタイトルだと語弊がある気がするので「1000万ユーザーのアクセスに耐えるアプローチ」くらいだと納得感あるかも
2022/05/03 07:26
revert
ユーザー規模が大きいサービスの開発経験は無さそう。フォロワーが多くいるユーザーがいるとうまく動かない、おそらく数万ユーザー程度が限界なんじゃないかな。「完全に理解した」レベルの開発者の記事。
2022/05/03 08:01
hiby
KVMだと札束でぶん殴ってもどっかでサチると思うんだけどそこが知りたかった感じ。
2022/05/03 08:47
t2y-1979
dynamodb を使っているなら普通に作れば耐えるでしょう
2022/05/03 10:04
ponpon_qonqon
いや、ちょっと･･･プロジェクトのリポジトリ名に「twitter」って他社の商標をまんま入れてしまうんかい。どんなに技術力があろうがその時点でエンジニアとしての経験値がないと見なしてアウトだよ･･･
2022/05/03 10:59
weakref
"～データの再配置が必要です。これらの機能ははRDBにはないので" ネタ？本気？
2022/05/03 11:07
remonoil
机上で作ったみた vs 机上で叩く
2022/05/03 12:29
zemuriya
結局普通のクラウド構成。DynamoDBの性能次第？
2022/05/03 17:08
asuka0801
せめて1000万ユーザーに耐える根拠と見積り金額は出した方が良いと思った。月数百万くらいは飛んでく構成じゃない？
2022/05/03 20:25
pascal256
後で読む