thắc mắc Backend của 1 app check trạng thái Covid gần 100 triệu active users, làm sao để nó không lag

[Buonnguqua6]

Dùng Amazon Lambda mà làm serverless services nhé, ngồi copy paste 1 ngày cũng có cái backend hơn các ông . Database thì làm cái 3 cassandra cluster ở 3 data center bắc /trung/nam, có tý data thế mà cũng "bài toán" gì. Chắc ông này chưa thấy Netflix backend.

Hic, ở đây 99.999% toàn chân đất chưa ra khỏi ao làng, có ai làm ở FAANG đâu anh ơi

 

[Buonnguqua6]

dạng app này user có tương tác gì với nhau đâu thì scale đơn giản thôi, chưa kể CCU cũng không cao dù tổng số user là cao vì có phải user mở app thường xuyên đâu, 1 tuần chắc user mở app được 1 lần

Anh tự kỷ ở nhà làm MMO hay sao mà 1 tuần mở app được 1 lần

 

[noneedname]

tính sơ sơ:
DB, chủ yếu read/write trên single user. Chơi Bigtable. 2 node tháng 1k$, 40k ops/s .
Application: cluster gke luôn scale cho sướng, 40 core, 240GB ram. tháng 600 - 1k$
Cache : vm 8 core 128GB ram, 2 con . tháng 700 - 1k$
Mấy cái Cloud flare, FCM bla bla -> 1k$ nữa
Report : BigQuery : tháng 1k$
SMS: cái này chát, tính riêng
Tổng: tháng 5k$ + SMS

 

[Buonnguqua6]

Read thì cũng chỉ tối đa 100 triệu record tương đương 1 người 1 record. Cũng ko cần realtime, delay vài phút mới cập nhật là chấp nhận đc. Nói chung đơn giản. Dùng cái gì cũng làm đc, chỉ cần đảm bảo cache là xong.

Con lạy mẹ
Read mà delay vài phút dân nó tế
Giữa Sài Gòn nắng chang chang đứng ngoài cửa quán cafe chờ quét QR code vài phút mới được vào nó lại chả quan hệ với mẹ app liên tục

 

[kedangghet]

• Đầu tiên tách mẹ cái nhập của nhân viên y tế ra 1 con riêng, cái này phải đảm bảo cho nhân viên y tế họ nhập đảm bảo nhanh mà không bị error, không bị lag. Dữ liệu này méo cần realtime với mấy cái còn lại.
• Trên app thì cache ở app, call api làm méo gì mà lắm (Hiện tại bấm phát lại gửi request 1 phát thì phải, request lỗi thì chưa tiêm luôn => méo hiểu )
• Truy vấn search là chủ yếu thì thiết kế lại index với cache cho đống dữ liệu ấy, chứ request nào cũng like %% thì chịu
• Phiên bản web thì cũng tách ra 1 cái riêng không ảnh hưởng đến mấy cái kia,

 

[Fire Of Heart]

hệ thống này thì các anh dẹp vụ AWS đi là vừa
các quan ko cho xài cloud nc ngoài đâu )

Thêm cái đó vô requirement đi là vừa.

Chưa kể user ở VN là chính thì đẩy qua Sing làm gì :-/

Về cơ bản cứ caching đầy đủ từng lớp là đã giảm tải dc 1 đống rồi. Mà đếch hiểu sao tụi nó ko làm :-/
dựng 3 con cache 16GB thôi là đủ xài rồi, vì cái này có cái mịa gì đâu, 1 cái uid + status (chích/ko chích/chích 1-2 mũi).
Chưa kể cache trong device nữa thì

 

[zulu]

tính sơ sơ:
DB, chủ yếu read/write trên single user. Chơi Bigtable. 2 node tháng 1k$, 40k ops/s .
Application: cluster gke luôn scale cho sướng, 40 core, 240GB ram. tháng 600 - 1k$
Cache : vm 8 core 128GB ram, 2 con . tháng 700 - 1k$
Mấy cái Cloud flare, FCM bla bla -> 1k$ nữa
Report : BigQuery : tháng 1k$
SMS: cái này chát, tính riêng
Tổng: tháng 5k$ + SMS

Cache cái qq j mà nhiều thế thím. vl 128GB để cache ko.

 

[Le1tuan]

Hic, ở đây 99.999% toàn chân đất chưa ra khỏi ao làng, có ai làm ở FAANG đâu anh ơi

ae ở đây nh fang mà :sexy: fpt axon niteco nastech grab gmo

 

[Buonnguqua6]

ae ở đây nh fang mà
fpt axon niteco nastech grab gmo

Thế hóa ra tôi cũng là cựu nhân viên FAANG à

 

[qkhanhpro1]

Tôi mạn phép hỏi các anh cao nhân Backend Dev trong đây bàn giải pháp như tech stack, băng thông và server cần cấu hình như thế nào, AWS thì cần gói bao nhiêu tiền 1 tháng ?

Mai rảnh tôi có thể code và spawn thử 1 hệ thống như này lên xem. Chắc không đến $5K 1 tháng như anh gì ở trên nói đâu

Tôi cũng không hiểu ở đây chúng ta cần cache để làm gì trong khi tuyệt đại đa số người dùng query 1-2 lần một phút... có lẽ là 10-20 lần trong cả cuộc đời. Trong khi bản chất query đã "identified" cho mỗi người rồi... nó quá lãng phí tài nguyên từ góc nhìn của tôi

 

[greans]

Con lạy mẹ
Read mà delay vài phút dân nó tế
Giữa Sài Gòn nắng chang chang đứng ngoài cửa quán cafe chờ quét QR code vài phút mới được vào nó lại chả quan hệ với mẹ app liên tục

Không phải là quét QR chờ phút mà là cần thời gian để system update data. Chẳng lẽ anh chích ngừa xong anh phi ngay ra quán luôn.

Theo CAP theorem thì anh phải chấp nhận đánh đổi consistency thôi, không có hệ thống nào có thể đáp ứng cả 3 yếu tố được.

Mấy anh # đầu mô tả hợp lý rồi đấy. Cũng không phải gì cao siêu bài toán read điển hình. quan trọng là tầng cache thôi.

Cloud vẫn có thể làm được, như thằng AWS có hỗ trợ private cloud đấy, nó xách giải pháp của nó áp lên datacenter của chính phủ luôn.

 

[qkhanhpro1]

Dùng Amazon Lambda mà làm serverless services nhé, ngồi copy paste 1 ngày cũng có cái backend hơn các ông . Database thì làm cái 3 cassandra cluster ở 3 data center bắc /trung/nam, có tý data thế mà cũng "bài toán" gì. Chắc ông này chưa thấy Netflix backend.

Bài toán này trong thực tế áp dụng lambda là khá ... dở
Điểm mạnh cũng là điểm yếu của lamdba là scale out. 1 container serve 1 request. Khi bạn scale out ra 1000 running container lập tức db bạn bị starve connection count và từ chối phục vụ

 

[Mazda Support]

Bài toán này trong thực tế áp dụng lambda là khá ... dở
Điểm mạnh cũng là điểm yếu của lamdba là scale out. 1 container serve 1 request. Khi bạn scale out ra 1000 running container lập tức db bạn bị starve connection count và từ chối phục vụ

kết nối tới DB thông qua RDS Proxy chứ ai lại kết nối trực tiếp từ lambda function

 

[Gâu Gâu Gâu Gâu]

Con lạy mẹ
Read mà delay vài phút dân nó tế
Giữa Sài Gòn nắng chang chang đứng ngoài cửa quán cafe chờ quét QR code vài phút mới được vào nó lại chả quan hệ với mẹ app liên tục

Chích xong chờ 15p mới đc về. Làm như chích xong vào cafe luôn vậy

Mai rảnh tôi có thể code và spawn thử 1 hệ thống như này lên xem. Chắc không đến $5K 1 tháng như anh gì ở trên nói đâu

Tôi cũng không hiểu ở đây chúng ta cần cache để làm gì trong khi tuyệt đại đa số người dùng query 1-2 lần một phút... có lẽ là 10-20 lần trong cả cuộc đời. Trong khi bản chất query đã "identified" cho mỗi người rồi... nó quá lãng phí tài nguyên từ góc nhìn của tôi

100tr record và lượng ccu rất lớn, con sql của anh sẽ bị stress vô ích. Ngoài ra việc tạo qr code như hiện tại là quá đơn giản, chỉ cần 1 cái chụp màn hình thẻ xanh của thằng khác là hack thành công hệ thống à? Nó cần phải có secret key bên trong và thay đổi thường xuyên, có thể 5 hoặc 10s đổi 1 lần. Thiết bị scan do đó cũng phải verify qr code bằng server. Nói cái này read ít là sai lầm.

 

[qkhanhpro1]

kết nối tới DB thông qua RDS Proxy chứ ai lại kết nối trực tiếp từ lambda function

thêm 1 tầng cồng kềnh cho hệ thống. AWS nó nhận ra quá sai lầm với cái cầu Lambda-RDS này nên 2019 mới rush ra cái RDS Proxy để share connection. Thời điểm tôi làm Lambda production gần như là một trong nhưng công ty adopt sớm. Claim lên enterprise spport thì nó mới bảo bọn tao đã aware và đang tìm hướng xử lý. Lúc RDS Proxy mới roll-out ra us-west chạy phọt phà phọt phẹt

Chừa luôn

 

[qkhanhpro1]

100tr record và lượng ccu rất lớn, con sql của anh sẽ bị stress vô ích. Ngoài ra việc tạo qr code như hiện tại là quá đơn giản, chỉ cần 1 cái chụp màn hình thẻ xanh của thằng khác là hack thành công hệ thống à? Nó cần phải có secret key bên trong và thay đổi thường xuyên, có thể 5 hoặc 10s đổi 1 lần. Thiết bị scan do đó cũng phải verify qr code bằng server. Nói cái này read ít là sai lầm.

1/ Phần QR tôi chưa hiểu cách bạn sẽ design QR generation và tại sao nó phải phụ thuộc vào việc read liên tục vào DB. Có thể chia sẻ chăng?

2/ Tôi nói cache gần như vô dụng vì kể cả đem bài toán QR scan vào đây. 1 record được query theo ID (Xin tạm loại bỏ các khó khăn về Identify cư dân trong thực tế) tra cứu vaccine theo Phone/National ID. Mỗi buổi sáng 30 triệu người trưởng thành đi làm và họ sẽ query liên tục theo ID của họ
30 triệu câu query độc lập chỉ dành riêng cho họ! Well. Nếu sẵn tiền để đưa hết 30 triệu hot active record lên MEM thì tốt cho bạn thôi ( Trường hợp đó thí thay DB bằng on-mem storage hoặc setting agressive cache ngay trên DB cho rồi? ). Còn không thì bạn nghĩ cache hit rate sẽ được bao nhiêu...

 

[noneedname]

Cache cái qq j mà nhiều thế thím. vl 128GB để cache ko.

VM rẻ bèo, như a gì bảo ở trên đấy, cache luôn 100tr user . Tôi est chơi vì thực tế có rất nhiều bài toán nảy sinh lúc implement 1 hệ thống lớn ntn, lại tầm quốc gia. Vẽ ra cái system high level thì cần gg tầm tiếng là ra cả rổ, vấn đề detail implement mới nhiều cái khoai sắn nảy sinh. Tôi đi làm gặp rất nhiều anh SA mõm rồi.

 

[meohen2109]

Làm cái này cũng phải tính đến trường hợp bị ddos chứ nhỉ?
Nó ko cần làm sập hệ thống, chỉ cần delay tra cứu mất vài phút là thành công rồi.

 

[funspark247]

tính sơ sơ:
DB, chủ yếu read/write trên single user. Chơi Bigtable. 2 node tháng 1k$, 40k ops/s .
Application: cluster gke luôn scale cho sướng, 40 core, 240GB ram. tháng 600 - 1k$
Cache : vm 8 core 128GB ram, 2 con . tháng 700 - 1k$
Mấy cái Cloud flare, FCM bla bla -> 1k$ nữa
Report : BigQuery : tháng 1k$
SMS: cái này chát, tính riêng
Tổng: tháng 5k$ + SMS

vl chơi cache, có thừa tiền cũng ko đến mức này
cái lối suy nghĩ tăng hardware để tăng performance thì nó cũng có mức giới hạn thôi,
sẽ có 1 cái limit mà bottleneck ở đâu đó khiến cho có tăng thêm tiền nó cũng ko tăng dc performance được

 

[alexTVr1]

đa phần các thím chọn cache nhỉ, cache mọi nơi, trên thiết bị, proxy, server