Thiết kế kiến trúc hệ thống 11 triệu người dùng trên Amazon AWS

Giới Thiệu

Làm sao để xây dựng một hệ thống 11 triệu người dùng truy cập trong ngày. Joel Williams, Kiến Trúc Sư Hệ Thống của Amazon Web Service, đã có một bài nói chuyện tuyệt vời về chính chủ đề này: AWS re:invent Phát triển hệ thống đến 10 triệu người dùng đầu tiên.

Nếu bạn là một người dùng đầy kinh nghiệm của AWS, bài viết này không dành cho bạn. Nhưng bài viết này là một cách tuyệt vời để bắt đầu, nếu bạn là người mới với AWS, với điện toán đám mây, hoặc bạn không theo dõi thường xuyên những tính năng mới mà Amazon “bơm” ra liên tục.

Đúng như bạn đã nghĩ, bài viết này là từ Amazon, nên dịch vụ Amazon sẽ là giải pháp trung tâm cho mọi vấn đề. Nền tảng của họ rất ấn tượng và nhiều chỉ dẫn. Rất rõ ràng để thấy các thành phần được ghép lại với nhau như thế nào. Amazon đã làm rất tốt chuyện đáp ứng mọi nhu cầu của người dùng, bảo đảm rằng họ có sản phẩm đáp ứng mọi phân khúc nhu cầu.

Một vài điểm chính trong bài viết này:

• Bắt đầu với SQL, và chỉ chuyển sang NoSQL khi cần thiết.
• Chiến lược chính là tạo các thành phần và cách ly chúng ra. Điều này cho phép các thành phần mở rộng và hư hỏng một cách độc lập với nhau. Áp dụng cho việc phân thành các tầng và phân thành các micro-services.
• Chỉ đầu tư vào những nhiệm vụ giúp ích cho mảnh kinh doanh của bạn nổi bật, đừng “phát minh lại bánh xe”.
• Tính mở rộng và tính trùng lặp không phải hai khái niệm tách rời nhau, bạn hoàn toàn có thể làm cả hai cùng lúc.
• Không có đề cập đến chi phí. Có thể thêm điều đó vào bài viết này vì đó là một trong những sự chỉ trích nhiều nhất với các giải pháp của AWS.

Cơ bản

• AWS có 12 Region ở khắp thế giới
  • Mỗi Region là một địa điểm vật lý ở thế giới, nơi mà Amazon có nhiều Availability Zones. Có các Region ở: Bắc Mỹ, Nam Mỹ, Châu Âu, Trung Đông, Châu Phi và Châu Á Thái Bình Dương.
  • Một Availability Zone (AZ) thông thường là một Data Center đơn lẻ, mặc dù chúng có thể được xây dựng bởi gộp của nhiều Data Center.
  • Các AZ được tách biệt đủ để chúng có nguồn điện và kết nối internet riêng.
  • Kết nối duy nhất giữ các AZ là một mạng có độ trễ thấp. AZ có thể cách nhau từ 5 đến 15 dặm, ví dụ vậy. Mạng kết nối có thể nhanh đủ để ứng dụng của bạn hoạt động như thể tất cả các AZ đang ở cùng một data center.
  • Mỗi Region có tối thiểu 1 AZ. Có tất cả 32 AZ cả thảy.
  • Sử dụng AZ, bạn có thể tạo một kiến trúc có tính sẵn sàng cao cho ứng dụng của bạn.
  • Có tối thiểu 9 hoặc nhiều hơn AZ và nhiều hơn 4 Region sẽ được thêm vào năm 2016
• AWS có 53 “edge location” (vị trí biên) ở khắp thế giới
  • Edge location được sử dụng bởi CloudFront, Amazon’s Content Distribution Network (CDN) và Route53, máy chủ quản lý DNS của Amazon.
  • Edge location cho phép người dùng truy xuất nội dụng với độ trễ rất thấp, bất kể họ ở nơi nào ở khắp thế giới.
• Những dịch vụ nền tảng
  • AWS đã tạo ra nhiều dịch vụ mà bên trong đó dùng nhiều AZ để bảo đảm tính sẵn sàng và tính chịu lỗi. Đây là danh sách các dịch vụ và nơi mà các dịch đó được cung cấp.
  • Bạn có thể dùng các dịch vụ này trong ứng dụng của bạn, với một mức phí, mà không cần phải lo nghĩ để làm cho ứng dụng của bạn có tính sẵn sàng cao.
  • Một vài dịch vụ tồn tại bên trong một AZ: CloudFront, Route53, S3, DynamoDB, Elastic Load Balancing, EFS, Lambda, SQS, SNS, SES, SWF.
  • Một kiến trúc có tính sẵn sàng cao có thể được tạo ra nhờ sử dụng những dịch vụ này, ngay cả khi chúng tồn tại bên trong một AZ đơn lẻ.

Một người dùng

• Trong trường hợp này bạn là người dùng duy nhất và bạn muốn có một trang web chạy được.
• Kiến trúc của bạn có thể giống như thế này:
  • Chạy trên một instance duy nhất, có thể là loại t2.micro. Loại instance bao gồm tổ hợp của CPU, RAM, ổ cứng, và dung lượng mạng và cho phép bạn linh động chọn một tổ hợp thích hợp cho ứng dụng của bạn.
  • Instance đó sẽ chạy toàn bộ web stack, ví dụ: web app, database, quản lý,…
  • Dùng Amazon Route53 cho DNS
  • Gắn một địa chỉ Elastic IP cho instance đó.
  • Sẽ chạy tốt trong một khoảng thời gian

Mở rộng theo chiều dọc

• Bạn cần một cái hộp lớn hơn. Cách mở rộng đơn giản nhất là dùng một loại instance lớn hơn. Có thể là c4.8xlarge hoặc m3.2xlarge.
• Cách tiếp cận này gọi là mở rộng theo chiều dọc.
• Chỉ cần dừng instance lại, chọn một loại instance mới là hệ thống bạn chạy với một sức mạnh mới.
• Danh sách cấu hình hardware để lựa chọn có rất nhiều. Bạn có thể có một hệ thống 244 GB RAM (2 TB RAM sẽ sớm xuất hiện). Hoặc là hệ thống có CPU 40 nhân. Có những instance có Input/Ouput nhiều, instance có CPU tốc độ cao, instance có lưu trữ dữ liệu lớn.
• Một vài dịch vụ Amazon có lựa chọn Provisioned IOPS để bảo đảm hiệu suất. Ý tưởng là bạn có thể dùng một loại instance nhỏ hơn, nhưng tận dụng những dịch vụ Amazon như DynamoDB để có thể cung cấp những ứng dụng mở rộng được, mà bạn không cần phải tự mở rộng.
• Mở rộng theo chiều dọc có một vấn đề lớn: không có dự phòng, không có tính trùng lắp. Nếu instance có vấn đề, trang web của bạn sẽ ‘chết’. Tất các các trứng của bạn đang nằm trong một rổ.
• Dần dần instance duy nhất của bạn sẽ lớn đến hết mức co thể. Bạn cần một cách khác.

Người dùng > 10

• Tách một host thành nhiều host
  • Một host cho website
  • Một host cho database. Chạy bất kỳ database nào bạn muốn, nhưng bạn phải chú ý phần quản trị database.
  • Dùng nhiều host tách biệt cho phép bạn mở rộng website và database một cách độc lập. Ví dụ database của bạn có thể cần máy mạnh hơn website.
• Hoặc thay vì tự chạy một database, bạn có thể dùng một dịch vụ database
  • Bạn có phải là một database Admin? Bạn có thực sự muốn lo lắng về backup dữ liệu? Tính sẵn sàng cao? các miếng vá? Hệ điều hành?
  • Một lợi thế lớn của việc sử dụng dịch vụ là bạn có thể có một database ở nhiều AZ, chỉ với một cái bấm chuột. Bạn không cần lo lắng về replication hay những thứ giống như vậy. Database của bạn sẽ có độ sẵn sàng cao và luôn đáng tin cậy.
• Như có thể bạn đã tưởng tượng, Amazon có nhiều dịch vụ database được quản lý hoàn toàn, để bán cho bạn:
  • Amazon RDS (Relational Database Service). Có nhiều lựa chọn: Microsoft SQL Server, Oracle, MySQL, PostgreSQL, MariaDB, Amazon Aurora.
  • Amazon DynamoDB: Một NoSQL database.
  • Amazon Redshift: hệ thống database có thể mở rộng đến Petabyte.
• Thông tin về Amazon Aurora:
  • Lưu trữ tự động, có thể tự động mở rộng đến 64TB. Bạn không còn phải provision hệ thống dữ liệu nữa.
  • Hỗ trợ đến 15 read read-replicas
  • Liên tục (incremental) backup vào S3
  • 6-way replication xuyên suốt 3 AZ. Điều này giúp bạn khắc phục những hư hỏng.
  • Tương thích với MySQL
• Bắt đầu bằng SQL database thay vì NoSQL database
  • Lời đề nghị là nên bắt đầu bằng MySQL
  • Công nghệ đã ổn định
  • Có rất nhiều code mẫu, cộng đồng, nhóm hỗ trợ, sách, và công cụ.
  • Bạn sẽ không bao giờ làm hu được SQL database với 10 triệu người dùng đầu tiên. Ngay cả khi gần hư cũng không thể (trừ phi dữ liệu của bạn rất rất lớn)
  • Có mẫu kiến trúc rõ ràng để mở rộng
• Khi nào thì bạn cần bắt đầu với NoSQL database?
  • Nếu bạn cần lưu trữ > 5 TB trong một năm hoặc bạn có lưu lượng xử lý dữ liệu phi thường nhiều.
  • Ứng dụng của bạn cần độ trễ cực thấp
  • Bạn thực sự cần throughput cao. Bạn cần thực sự tinh chỉnh IO ở cả đọc và ghi.
  • Bạn không có dữ liệu quan hệ

Người dùng > 100

• Dùng host riêng cho tầng web
• Lưu dữ liệu ở Amazon RDS. Nó sẽ làm mọi thứ cho bạn.
• Đó là tất cả những gì bạn cần

Người dùng > 1000

• Kiến trúc ứng dụng của bạn gặp vấn đề về tính sẵn sàng. Nếu host web hư, website của bạn sẽ sập.
• Bạn sẽ cần một web instance ở một AZ khác. Điều này vẫn OK vì độ trễ giữa các AZ tính bằng vài mili giây, hầu như chúng nằm ở kế nhau.
• Bạn sẽ cần một Slave database RDS chạy ở một AZ khác. Nếu có vấn đề với master, ứng dụng của bạn sẽ tự động chuyển sang slave. Không cần thay đổi ứng dụng của bạn ở giải pháp dự phòng này, bởi vì ứng dụng của bạn sử dụng một endpoint duy nhất.
• Một Elastic Load Balancer (ELB) được thêm vào cấu hình, để chia tải người dùng giữa 2 host instance nằm ở hai AZ.
• Elastic Load Balancer (ELB)
  • ELB là một bộ chia tải có độ sẵn sàng cao. ELB tồn tại ở tất cả AZ. Nó là endpoint DNS duy nhất của ứng dụng của bạn. Chỉ cần chỉa Route53 về nó, là nó sẽ chia tải web của bạn ra các host intance.
  • ELB có Health Checks (kiểm tra sức khỏe) và luôn bảo đảm rằng lưu lượng web không chảy vào host đã hư.
  • Nó tự mở rộng mà không cần bạn phải làm gì cả. Nếu nó gặp lưu lượng web tăng lên, nó tự mở rộng cả theo chiều ngang và chiều dọc. Bạn không cần quản lý nó. Khi mà ứng dụng của bạn mở rộng, ELB sẽ mở rộng theo.

Người dùng > 10,000 – 100,000

• Ở cấu hình trước bạn có 2 instance nằm sau ELB, trong thực tế bạn có thể có 1000 instance nằm sau ELB. Đây gọi là mở rộng theo chiều ngang.
• Bạn cần nhiều replicas cho database RDS. Điều này sẽ giảm tải bớt cho write master.
• Cần xem xét hiệu suất và hiệu quả bằng cách giảm tải cho tầng web của bạn, bằng cách di chuyển vài lưu lượng ra nơi khác. Mang những nội dung tĩnh của ứng dụng ra Amazon S3 và Amazon CloudFront. CloudFront là Amazon’s CDN, lưu trữ dữ liệu của bạn ở 53 edge location ở toàn thế giới.
• Amazon S3 là kho lưu trữ object
  • Nó không giống EBS, nó không phải là bộ lưu trữ gắn vào một EC2 instance. Nó là một object store, không phải block store.
  • Nó là một nơi rất tốt để lưu trữ nội dung tĩnh, như javascript, css, hình ảnh, video. Những loại nội dung này không cần phải nằm ở trên một EC2 instance.
  • Có độ bền cao.
  • Mở rộng không giới hạn. Ném vào bao nhiêu dữ liệu tùy thích.
  • Hỗ trợ object lớn đến 5TB
  • Có hỗ trợ mã hóa. Bạn có thể sử dụng mã hóa của Amazon, mã hóa của bạn, hay một dịch vụ mã hóa bên ngoài.
• Amazon CloudFront là bộ đệm cho nội dung của bạn
  • Nó cache nội dung của bạn vào edge location, cung cấp cho người dùng của bạn độ trễ truy nhập nhỏ nhất có thể.
  • Nếu không có CDN, người dùng của bạn sẽ phải chịu độ trễ cao hơn khi truy nhập vào nội dung của bạn. Máy chủ của bạn sẽ chịu tải cao hơn, vì chúng vừa phải phục vụ nội dung, vừa phải phục vụ các truy nhập web.
  • Khi một người dùng cần truy nhập vào nội dung với tốc độ 60Gps, tầng web không biết thậm chí không biết chuyện đó đang xảy ra. Trong khi CloudFront sẽ xử lý các chuyện đó.
• Bạn có thể giảm tải hơn nữa bằng cách đẩy việc lưu trữ trạng thái session ra khỏi tầng web.
  • Lưu trạng thái session vào ElastiaCache hoặc DynamoDB
  • Cách tiếp cận này đồng thời chuẩn bị cho hệ thống của bạn có thể hỗ trợ tính năng ‘tự mở rộng’ trong tương lai.
• Bạn cũng còn có thể giảm tải bằng cách caching dữ liệu từ database vào ElasticCache.
  • Database không cần phải xử lý mọi việc đọc dữ liệu. Một bộ đệm có thể xử lý rất nhiều việc như vậy, và để cho database của bạn xử lý những việc quan trọng hơn.
• Amazon DynamoDB – một NoSQL database
  • Bạn chỉnh lý lưu lượng dữ liệu mà bạn muốn. Bạn tự chọn lựa hiệu năng đọc ghi mà bạn muốn.
  • Hỗ trợ hiệu năng nhanh chóng, và ước lượng được.
  • Hoàn toàn phân tán và chịu được lỗi. Tồn tại ở nhiều AZ.
  • Là hệ thống lưu trữ key-value. Có hỗ trợ JSON.
  • Document có kích thước 400KB được hỗ trợ.
• Amazon ElasticCache – hệ thống Memcachedhoặc Redis
  • Quản lý một cluster memcache không tạo thêm tiền cho bạn vì vậy nên để Amazon làm điều đó cho bạn.
  • Cluster sẽ tự động được mở rộng cho bạn. Nó là một kiến trúc tự sửa lỗi. Nếu một node bị lỗi, nodes mới sẽ tự động khởi động.
• Bạn cũng có thể giảm tải bằng cách dời các nội dung động sang CloudFront
  • Nhiều người biết rằng CloudFront có thể xử lý nội dung tĩnh, như là các file, nhưng mà nó có thể xử lý nội dung động.Chủ đề này không được trình bày thêm ở bài viết này, nhưng đây là link tham khảo

Auto Scaling

• Nếu bạn chuẩn bị đủ dung lượng để hệ thống luôn luôn có thể xử lý lưu lượng đỉnh, ví dụ Black Friday, bạn đang phí tiền. Sẽ tốt hơn nếu bạn cung cấp năng lực xử lý theo đúng nhu cầu. ‘Auto Scaling’ cho phép bạn làm điều đó, tự động co dãn cluster của bạn.
• Bạn luôn có thể định ra số tối thiểu và tối đa cho “hồ chứa” (pool) của bạn. Là người dùng, bạn có quyền định con số instance tối thiểu và tối đa là bao nhiêu.
• CloudWatch là một dịch vụ quản lý được nhúng vào tất cả các ứng dụng
  • Các event của CloudWatch sẽ kích hoạt quá trình mở rộng
  • Bạn sẽ mở rộng độ sử dụng CPU? Mở rộng theo giảm độ trễ? lưu lượng mạng?
  • Bạn có thể tự tải lên hệ số đo của chính bạn lên CloudWatch. Nếu bạn muốn mở rộng theo một yếu tố nào đó thuộc ứng dụng của bạn, bạn có thể đẩy yếu tố đó lên CloudWatch, và báo cho “Auto Scaling” rằng bạn muốn mở rộng theo hệ số đo đó.

Số người dùng > 500,000

• Điều cần thêm vào trong cấu hình trước đây là thêm ‘Auto Scaling Group’ vào tầng web. Auto scaling group bao gồm 2 AZ, nhưng có thể nới rộng thành 3 AZ hoặc tới tổng số lượng AZ của region đó. Instance ở nhiều region không chỉ phục vụ cho tính mở rộng, mà còn ở tính sẵn sàng (availability).
• Ví dụ bạn có 3 instance ở tần web hoặc có thể có đến 1000 instance. Hoặc bạn có thể muốn cấu hình tối thiểu 10 instance và tối đa 1000 instance.
• ElasticCache được đùng để chia tải những tác vụ đọc thông thường từ database.
• DynamoDB được dùng để chia tải dữ liệu Session
• Bạn cần phải thêm vào các phần Theo Dõi (monitoring), đo lường (metric) và báo cáo (logging)
  • Đo lường ở cấp độ host. Xem xét thông số CPU ở instance trong cùng một autoscaling-group và tìm hiểu xem chuyện gì đang xảy ra.
  • Đo lường ở cấp độ tổng hợp. Xem xét thông số của Elastic Load Balancer để cảm nhận hiệu suất của toàn bộ tập hợp instance.
  • Phân tích log. Xem xét những gì ứng dụng báo cho bạn biết thông qua log của CloudWatch. CloudTrail có thể giúp bạn phân tích và quản lý log.
  • Đánh giá hiệu suất của site từ bên ngoài. Biết khách hàng – người dùng cuối – đang thấy những gì. Dùng dịch vụ như New Relic hay Pingdom.
• Bạn cần phải biết khách hàng đang nói gì. Độ trễ có đang tệ lắm không. Họ có đang gặp phải lỗi khi truy xuất vào trang web của bạn không.
• Ép được càng nhiều hiệu suất từ cấu hình hiện tại càng tốt. Auto Scaling có thể giúp đỡ được trong trường hợp này. Bạn không muốn một hệ thống mà trong đó CPU chỉ dùng có 20%.
  Tự động hóa
• Kiến trúc đang ngày càng lớn, có thể lớn tới 1000 instance. Chúng ta có replicas cho thao tác đọc, chúng ta có mở rộng theo chiều ngang, nhưng chúng ta cần tự động hóa để quản lý toàn bộ chúng, chứ không phải quản lý từng instance riêng lẻ.
• Có cả một hệ thống các công cụ tự động hóa.
  • Tự làm: Amazon EC2, AWS CloudFormation.
  • Dịch vụ cấp cao hơn: AWS Elastic Beanstalk, AWS OpsWorks
  • AWS Elastic Beanstalk: quản lý kiến trúc của ứng dụng của bạn. Rất tiện, nhưng không có nhiều sự kiểm soát lắm.
  • AWS OpsWorks: một môi trường mà bạn xây dựng ứng dụng của bạn trên các lớp, rồi dùng Chef recipe để quản lý các lớp ứng dụng này.
  • Có thể cho phép khả năng dùng Continuous Integration và deployment
• AWS CloudFormation: là cái xuất hiện lâu nhất
  • Cung cấp nhiều tính linh động nhất bởi vì nó cung cấp một cái nhìn khuôn mẫu về toàn bộ stack. Nó có thể được sử dụng để xây dựng nên toàn bộ stack hay một vài thành phần của stack.
  • Nếu bạn muốn cập nhật stack, bạn chỉ cần cập nhật khuôn mẫu của CloudFormation, nó sẽ cập nhật đúng bộ phận đó trong stack của bạn.
  • Nhiều quyền điều khiển, nhưng ít tiện hơn.
• AWS Code Deploy: deploy code của bạn lên ‘hạm đội’ các instance của bạn.
  • Có thể deploy lên một hoặc hàng ngàn instance.
  • Code Deploy có thể chỉ lên một cấu hình Auto Scaling, vì thế code có thể được deploy lên một nhóm các instance.
  • Có thể dùng chung với Chef và Puppet.
    Tách biệt kiến trúc
• Sử dụng SOA/Microservice. Lấy các component từ các tầng của bạn và tách biệt chúng ra. Tạo nhiều dịch vụ tách biệt ra, giống như bạn đã tách tầng web và tầng database.
• Những dịch vụ đơn lẻ có thể được mở rộng một cách độc lập nhau. Điều này cho phép bạn linh động rất nhiều để mở rộng và tăng tính sẵn sàng.
• SOA là thành phần chính của các kiến trúc xây dựng bởi Amazon
• Tính kết nối lỏng (loose coupling) giúp bạn tự do.
  • Bạn có thể thể mở rộng các thành phần một cách độc lập. Các thành phần có thể bị hư hỏng một các độc lập với nhau.
  • Nếu một worker node thất bại trong việc tải công việc từ SQS về thi có chuyện không? Không hề, chỉ cần khởi động một cái node khác. Mọi thứ đều sẽ có thể hư hỏng, hãy xây dựng những kiến trúc có thể xử lý hư hỏng.
  • Thiết kế mọi như như là một hộp đen
  • Tách biệt các sự tương tác
  • Nên chọn các dịch vụ có sẵn tính lặp lại (redundancy) và tính mở rộng, hơn là dịch vụ tự mình xây dựng
    Đừng phát minh lại bánh xe
• Chỉ xây dựng những dịch vụ giúp bạn tách biệt ở khía cạnh kinh doanh
• Amazon có rất nhiều dịch vụ được thừa kế tính chịu lỗi bởi vì chúng trải dài ở nhiều AZ. Ví dụ: queuing, email, transcoding, search, database, monitoring, metric, logging, compute. Bạn không cần chính mình xây dựng lại chúng.
• SQS: dịch vụ xếp hàng (queuing)
  • Dịch vụ đầu tiên mà Amazon cung cấp
  • Nó trải dài ở nhiều AZ nên nó có tính chịu lỗi
  • Có tính mở rộng, an toàn và đơn giản.
  • Queuing có thể giúp cho kiến trúc của bạn bằng cách giúp bạn truyền các message giữa các thành phần với nhau trong kiến trúc.
  • Ví dụ một CMS quản lý hình ảnh. Hệ thống thu thập hình ảnh và hệ thống xử lý chúng có thể là 2 hệ thống khác nhau. Và chúng có thể được mở rộng độc lập với nhau. Chúng phải liên kết với nhau một cách lỏng lẻo. Nhận vào một tấm hình, xếp vào hàng đợi, các worker sẽ kéo chúng ra khỏi hàng đợi và làm gì đó với chúng.
• AWS Lambda: cho phép bạn chạy code mà không cần phải cài đặt và quản lý server.
  • Là công cụ tuyệt vời cho phép bạn tạo ra các sự tách biệt trong ứng dụng của bạn
  • Trong ví dụ quản lý hình ảnh ở trên, Lambda có thể đáp ứng một sự kiện từ S3, vì thế khi một file được thêm vào S3, hàm Lambda xử lý tương ứng sẽ được kích hoạt.
  • Chúng ta đã xong việt mà không cần dùng EC2. Nó tự mở rộng cho bạn và không có OS để cần phải quản lý.
    Người dùng > 1,000,000+
• Khi đạt trên một triệu người dùng, chúng ta cần mọi thứ ở trên
  • Nhiều AZ
  • Elastic Load Balancing giữa các tầng. Không những chỉ ở tầng web, mà còn ở tầng ứng dụng, tầng dữ liệu, và tất cả các tầng mà bạn có.
  • Tự động mở rộng
  • SOA – Service Oriented Architecture (Kiến trúc hướng dịch vụ)
  • Cung cấp nội dung một cách thông minh bằng S3 và CloudFront
  • Đặt caching ở trước DB
  • Dời các dữ liệu trạng thái ra khỏi tầng web
• Sử dụng Amazon SES để gửi email
• Dùng CloudWatch để theo dõi trạng thái hệ thống
  Người dùng > 10,000,000+
• Khi hệ thống lớn hơn, chúng ta sẽ gặp rắc rối với tầng dữ liệu. Bạn có tiềm năng gặp phải vấn đề với cơ sở dữ liệu ở phần tranh nhau ghi vào master. Căn bản có nghĩa là bạn đang có quá nhiều lưu lượng ghi vào master.
• Làm thế nào để giải quyết vấn đề này
  • Federation
  • Sharding
  • Chuyển vài tính năng tới những loại cơ sở dữ liệu khác (NoSQL, graph, etc)
• Federation – chẻ ra nhiều DB dựa vào tính năng
  • Ví dụ, tạo ra Forum DB, User DB và Product DB. Bạn có lẽ có chúng ở một DB duy nhất trước đây, bây giờ thì dàn trải chúng ra nhiều DB.
  • DB khác nhau có thể được mở rộng một cách độc lập.
  • Mặt xấu là bạn không còn có thể tạo các câu truy vấn xuyên-databases. Điều này làm chậm trễ khả năng bạn dùng chiến lược thứ kế tiếp, là sharding
• Sharding – chẻ một dataset ra nhiều host
  • Phức tạp hơn ở tầng ứng dụng, nhưng sẽ không còn giới hạn ở tính mở rộng
  • Ví dụ trong một User DB, ¹⁄₃ người dùng được gửi tới 1 shard, ¹⁄₃ kế tiếp tới 1 shard, và ¹⁄₃ cuối cùng tới một 1 shard nữa.
• Dời một vài tính năng tới một loại DB khác
  • Bắt đầu nghĩ về NoSQL DB
  • Nếu bạn có loại dữ liệu mà không cần kết bảng phức tạp, ví dụ leaderboard, clickstream/log data, dữ liệu tạm, hot tables, metadata/lookup tables, có thể xem xét dời qua NoSQL DB.
  • Điều này có nghĩa là chúng có thể được scale độc lập với nhau
    Người dùng > 11 triệu
• Mở rộng là một quá trình lặp đi lặp lại. Khi hệ thống càng lớn, bạn luôn luôn có nhiều việc có thể làm hơn
• Tinh chỉnh ứng dụng của bạn
• Dùng nhiều hơn các kiến trúc/tính năng hướng dịch vụ (SOA)
• Chuyển từ việc dùng đa AZ sang đa vùng
• Sẽ phải bắt đầu xây dựng những giải pháp riêng mình, để giải quyết những vấn đề mà trước đó chưa ai phải giải quyết. Nếu bạn cần phải phục vụ hàng tỉ người, bạn sẽ phải cần tự xây dựng những giải pháp riêng bạn.
• Phân tich sâu toàn bộ tầng kiến trúc của bạn

Kết luận

• Dùng kiến trúc multi-AZ để tăng độ tin cậy
• Tận dụng các dịch vụ có tính năng tự mở rộng như ELB, S3, SQS, DynamoDB, …
• Xây dựng tính lặp lại (redundancy) ở mọi cấp. TÍnh mở rộng và tính lặp lại không phải là những khái niệm quá độc lập nhau, bạn có thể làm cả hai cùng lúc.
• Bắt đầu bằng một cơ sở dữ liệu quan hệ truyền thống.
• Cache dự liệu ở cả trong lẫn ngoài kiến trúc của bạn.
• Sử dụng những công cụ tự động trong kiến trúc của bạn.
• Bảo đảm rằng bạn luôn có sẵn các công cụ đo lường/theo dõi/logging tốt. Bảo đảm rằng bạn luôn biết người dùng đang trải nghiệm như thế nào với ứng dụng của bạn.
• Chia tầng ra nhiều dịch vụ đơn lẻ (SOA) để chúng có thể mở rộng hoặc gặp lỗi độc lập với nhau.
• Dùng Auto Scaling khi bạn đã sẵn sàng.
• Đừng phát minh lại bánh xe. Dùng những dịch vụ có sẵn thay vì tự viết code, trừ phi điều đó hoàn toàn cần thiết.
• Chuyển sang dùng NoSQL khi điều đó bắt đầu hợp lý.

Link gốc: http://vn.aucfan.com/posts/2016/04/05/million-scalable-system/