Hoàn tất di chuyển cơ sở dữ liệu PostgreSQL chỉ với 11 giây downtime

 (gds.blog.gov.uk)
2 điểm bởi GN⁺ 2024-01-19 | 1 bình luận | Chia sẻ qua WhatsApp
  • GOV.UK Notify đã giảm downtime xuống khoảng 11 giây khi chuyển cơ sở dữ liệu PostgreSQL 11 dung lượng 400GB sang PostgreSQL 15 trên RDS trong tài khoản AWS riêng của họ, phù hợp với việc PaaS ngừng hoạt động
  • Với DB đích, họ chỉ tạo bảng trước rồi sao chép dữ liệu bằng DMS full load, sau đó mới áp dụng chỉ mục và ràng buộc khóa để rút ngắn thời gian nạp dữ liệu quy mô lớn
  • DB nguồn có khoảng 1,3 tỷ hàng, 85 bảng, 185 chỉ mục, 120 khóa ngoại, và vào ngày làm việc thường phát sinh khoảng 1.000 thao tác chèn/cập nhật mỗi giây cùng số lượng đọc tương tự
  • Do việc tái triển khai ứng dụng mất khoảng 5 phút, họ chuẩn bị sẵn cùng thông tin xác thực và chuyển đổi trọng số DNS bằng Route53 để giảm thời gian chuyển đổi thực tế
  • DMS được chọn vì dễ nhận hỗ trợ từ PaaS và AWS, nhưng với bài toán di chuyển giữa các PostgreSQL, các lựa chọn như pglogical có thể đã đơn giản hơn

Di chuyển cơ sở dữ liệu Notify trong bối cảnh PaaS ngừng hoạt động

  • GOV.UK Notify đang được lưu trữ trên GOV.UK Platform as a Service, và do PaaS ngừng hoạt động nên toàn bộ hạ tầng phải được chuyển sang tài khoản AWS riêng
  • Cơ sở dữ liệu của Notify là AWS RDS PostgreSQL trong tài khoản AWS của PaaS, lưu trữ từ dữ liệu gửi thông báo đến nội dung của hàng trăm nghìn mẫu mà các nhóm dịch vụ sử dụng
  • Trong quá trình di chuyển, cơ sở dữ liệu cũ được gọi là source database, còn cơ sở dữ liệu mới là target database
  • Thách thức cốt lõi không phải là tạo một cơ sở dữ liệu PostgreSQL mới, mà là giảm thiểu downtime trong lúc chuyển toàn bộ dữ liệu và đổi đích kết nối của ứng dụng

Quy mô của cơ sở dữ liệu nguồn và các ràng buộc dịch vụ

  • Cơ sở dữ liệu nguồn là PostgreSQL 11 có dung lượng khoảng 400GB
    • khoảng 1,3 tỷ hàng
    • 85 bảng
    • 185 chỉ mục
    • 120 khóa ngoại
  • Vào một ngày làm việc thông thường, hệ thống phát sinh khoảng 1.000 thao tác chèn hoặc cập nhật mỗi giây, cùng số lượng đọc tương tự
  • GOV.UK Notify gửi hàng triệu thông báo quan trọng và cần tính kịp thời mỗi ngày, như cảnh báo lũ lụt hay trạng thái xử lý hồ sơ hộ chiếu
  • Mọi lần gửi thông báo đều cần truy cập cơ sở dữ liệu, nên thời gian gián đoạn dịch vụ phải được giữ ở mức rất ngắn

Cấu trúc nạp dữ liệu ban đầu và sao chép liên tục bằng DMS

  • Nhóm PaaS cung cấp phương án di chuyển cơ sở dữ liệu bằng AWS Database Migration Service
  • DMS chịu trách nhiệm chuyển dữ liệu từ cơ sở dữ liệu nguồn sang cơ sở dữ liệu đích, và có thể chạy trong tài khoản AWS của nguồn hoặc đích
  • Tác vụ DMS được chia thành hai giai đoạn
    • full load: sao chép toàn bộ dữ liệu đã tồn tại đến một thời điểm nhất định theo từng bảng
    • sao chép liên tục: phát lại các giao dịch mới từ cơ sở dữ liệu nguồn sang cơ sở dữ liệu đích để giữ hai bên đồng bộ
  • Việc chuyển ứng dụng sang sử dụng cơ sở dữ liệu đích thay cho cơ sở dữ liệu nguồn do chính nhóm Notify phụ trách

Chuẩn bị cơ sở dữ liệu đích và full load

  • Một instance DMS được tạo trong tài khoản AWS của nguồn
    • Nhóm PaaS đã cấu hình sẵn instance DMS trong tài khoản nên có thể chuẩn bị nhanh chóng
    • Instance DMS cần thông tin xác thực để kết nối tới cả cơ sở dữ liệu PostgreSQL nguồn và đích
  • Vì instance DMS và cơ sở dữ liệu đích nằm ở hai VPC khác nhau, họ thiết lập VPC peering để lưu lượng DMS từ VPC của PaaS được định tuyến sang VPC riêng mà không đi qua Internet công cộng
  • Instance RDS đích được tạo trong tài khoản AWS riêng, và do PostgreSQL 11 sắp hết hỗ trợ nên cơ sở dữ liệu mới được cấu hình là PostgreSQL 15
  • Họ dùng pg_dump để dump schema của cơ sở dữ liệu nguồn, tạo file SQL tái tạo schema, và ban đầu chỉ áp dụng phần khai báo bảng lên cơ sở dữ liệu đích
  • Khóa ngoại không được áp dụng tại thời điểm full load
    • vì DMS full load không sao chép dữ liệu theo thứ tự phù hợp với ràng buộc khóa ngoại
  • Khóa chính và chỉ mục cũng không được tạo trước khi full load
    • vì mỗi lần chèn sẽ phải cập nhật chỉ mục, có thể làm tăng đáng kể tổng thời gian khi nạp hàng tỷ hàng
    • sao chép hết dữ liệu trước rồi mới thêm chỉ mục là cách nhanh hơn
  • Tác vụ full load sao chép dữ liệu tồn tại ở thời điểm nhấn nút bắt đầu
    • dữ liệu mới hoặc cập nhật phát sinh sau đó không nằm trong full load
    • quá trình full load mất khoảng 6 giờ
  • Sau full load, họ áp dụng phần còn lại của file schema để thêm chỉ mục và ràng buộc khóa, việc này mất khoảng 3 giờ

Duy trì sao chép trong 10 ngày rồi chuyển lưu lượng

  • Sau khi full load hoàn tất, cơ sở dữ liệu đích khớp với dữ liệu nguồn tại thời điểm full load bắt đầu, nhưng sau đó ở nguồn vẫn tiếp tục có chèn, cập nhật và xóa
  • Họ khởi động tác vụ sao chép liên tục của DMS, tức change data capture, để gửi các giao dịch trong transaction log của cơ sở dữ liệu nguồn phát sinh sau thời điểm bắt đầu full load sang cơ sở dữ liệu đích
  • Mất vài giờ để quá trình sao chép bắt kịp, sau đó họ theo dõi độ trễ sao chép của DMS để kiểm tra trạng thái đồng bộ
  • Sao chép DMS chạy nền trong khoảng 10 ngày, giữ cho hai cơ sở dữ liệu đồng bộ đến thời điểm chuyển lưu lượng đã được thông báo trước cho người dùng
  • Quy trình chuyển lưu lượng được họ viết sẵn thành script Python
    • dừng lưu lượng ứng dụng đi tới cơ sở dữ liệu nguồn
    • xác nhận sao chép đã bắt kịp hoàn toàn
    • cho phép ứng dụng kết nối tới cơ sở dữ liệu đích
  • Họ phải tránh tình trạng một số ứng dụng dùng DB nguồn còn số khác dùng DB đích
    • vì các thay đổi phát sinh trên DB đích không được phản ánh ngược lại về DB nguồn, điều này có thể khiến người dùng nhìn thấy dữ liệu không nhất quán
  • Script được xây dựng để rõ ràng hơn thao tác thủ công, có thể lặp lại, và chạy nhanh; nó đã được dùng ít nhất 40 lần trong các đợt kiểm thử và diễn tập trước đó
  • Mục tiêu downtime là dưới 5 phút, và thời điểm di chuyển được chọn vào một tối thứ Bảy tương đối yên tĩnh nhưng không phải giữa đêm

Chuyển DNS tạo ra 11 giây downtime

  • Việc ngắt lưu lượng tới cơ sở dữ liệu nguồn được xử lý bằng cách gọi pg_terminate_backend trên các kết nối ứng dụng, mất chưa đến 1 giây
  • Họ cũng đổi mật khẩu người dùng PostgreSQL để ứng dụng không thể kết nối lại vào DB nguồn, khiến các lần kết nối lại bị lỗi xác thực
  • DMS tạo một bảng trạng thái sao chép trong cơ sở dữ liệu đích và cập nhật mỗi phút, script di chuyển dùng bảng này để kiểm tra độ trễ giữa nguồn và đích
  • Như một lớp an toàn bổ sung, sau khi ứng dụng ngừng truy cập DB nguồn, script ghi một bản ghi duy nhất vào DB nguồn rồi chờ đến khi nó xuất hiện trong DB đích
  • Thông tin kết nối cơ sở dữ liệu của ứng dụng được cung cấp qua biến môi trường SQLALCHEMY_DATABASE_URI
    • dạng cũ là postgresql://...@random-identifier.eu-west-1.rds.amazonaws.com:5432, bao gồm tên người dùng, mật khẩu và vị trí RDS
    • để thay đổi vị trí cơ sở dữ liệu hoặc thông tin xác thực thì cần tái triển khai ứng dụng, và việc này mất khoảng 5 phút
  • Để tránh thêm downtime do tái triển khai, trước khi di chuyển họ chuẩn bị hai việc
    • tạo người dùng có cùng tên đăng nhập và mật khẩu trên cả cơ sở dữ liệu nguồn và đích
    • tạo bản ghi DNS database.notifications.service.gov.uk trên AWS Route53 và đặt TTL là 1 giây
  • Bản ghi DNS ban đầu có trọng số nguồn 100% và đích 0%
  • URI của ứng dụng được đổi trước để dùng tên người dùng, mật khẩu chung và tên miền mới
  • Khi chuyển thực tế, script đổi trọng số DNS trên AWS sang 100% cho đích rồi chờ TTL 1 giây hết hạn
  • Tại thời điểm chuyển đổi vào tối thứ Bảy ngày 4 tháng 11 năm 2023, độ trễ giữa cơ sở dữ liệu đích và nguồn chỉ ở mức vài giây
  • Kết quả chạy script di chuyển cho thấy ứng dụng ngừng truy cập DB nguồn và bắt đầu dùng DB đích mới, với downtime khoảng 11 giây

Đánh giá về việc chọn DMS và công việc tiếp theo

  • DMS được chọn vì được hỗ trợ tốt trong GOV.UK PaaS và cũng có thể nhận hỗ trợ từ AWS
  • Nếu trong tương lai phải thực hiện lại việc di chuyển cơ sở dữ liệu giữa các PostgreSQL, họ dự định xem xét kỹ hơn các công cụ thay thế như pglogical
  • DMS có thể đã làm tăng thêm độ phức tạp và đưa vào một quy trình sao chép ít quen thuộc hơn so với các công cụ khác
  • Sau khi hoàn tất di chuyển cơ sở dữ liệu, bước tiếp theo là di chuyển ứng dụng
  • Ứng dụng GOV.UK Notify sẽ được chuyển sang AWS Elastic Container Service, và quá trình này sẽ được chia sẻ sau

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-01-19
Các ý kiến trên Hacker News

  • Chúng tôi cũng đã thực hiện một migration tương tự bằng AWS RDS Blue-Green Deployments; cơ sở dữ liệu còn lớn hơn một chút, nhưng downtime chỉ khoảng 20 giây và khối lượng công việc cũng ít hơn rất nhiều. Khá ngạc nhiên là trong thread này vẫn chưa ai nhắc đến
    Về cơ bản, khi bạn tạo một triển khai Blue/Green mới với các thay đổi mong muốn, AWS sẽ đồng bộ triển khai green bằng logical replication trong khi cấu hình blue hiện tại vẫn tiếp tục xử lý traffic
    Trên green, miễn là không ghi dữ liệu, bạn có thể chỉnh sửa, kiểm thử, thậm chí load test; các ghi vẫn tiếp tục đi vào blue đang live rồi được replicate sang green
    Khi đã sẵn sàng, bạn chạy lệnh switch, và AWS sẽ xử lý việc kiểm tra đồng bộ, ngắt ghi và kết nối, chờ replication bắt kịp, đổi tên cơ sở dữ liệu, rồi nối lại kết nối và ghi
    Với chúng tôi, downtime dưới 20 giây, và toàn bộ cấu hình gồm primary cùng nhiều read replica đã chuyển đổi suôn sẻ. AWS cũng đổi luôn URL cơ sở dữ liệu nên không cần thay đổi cấu hình; green trở thành blue, blue cũ trở thành old blue và có thể xóa sau
    Rất khuyến nghị, nhưng vẫn có các giới hạn, chẳng hạn có thể không dùng được trong trường hợp di chuyển giữa các tài khoản: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/blue-...

    • +1 cho Blue/Green. Tuy vậy, trường hợp này có lẽ không dùng được vì di chuyển giữa các tài khoản. Tôi đã dùng với cả MySQL lẫn Postgres; với MySQL, số query mỗi giây cao hơn bài viết hai chữ số, nhưng cả hai đều diễn ra trơn tru
      Cần đọc đi đọc lại tài liệu, đặc biệt là phần hạn chế. Nên chạy thử trong môi trường dev dưới tải, rồi thử lại ở staging
      Hoặc cứ YOLO đưa thẳng vào production thì có lẽ cũng ổn
    • Tôi đã dùng RDS Blue/Green deployment khi nâng cấp phiên bản engine major từ MySQL 5.7 lên 8.0, và xét về downtime thì rất tuyệt. Downtime quan sát được từ API hình như khoảng 13 giây
      Tuy nhiên, tôi đã phải học theo cách khó rằng RDS Blue/Green không dùng được cho mọi thay đổi tùy ý. Trong trường hợp của chúng tôi, nó chỉ dùng được để nâng phiên bản engine, không dùng để hạ xuống
      Trên MySQL 8.0 có một stored procedure rất thỉnh thoảng bị lỗi nên chúng tôi đã xem xét phương án quay lại 5.7, nhưng điều đó là không thể
    • Tôi tò mò không biết đã có ai mã hóa RDS storage vốn chưa được mã hóa bằng Blue/Green chưa
    • Tôi tò mò họ đã dừng và khởi động lại các ứng dụng truy cập cơ sở dữ liệu như thế nào. Chúng tôi có nhiều tác vụ chạy trên ECS, có thể mất 1 phút để hạ xuống và vài phút để lên lại
    • +1 cho Route53 Groups và cấu hình Blue/Green. Chúng tôi cũng đã làm tương tự khi nâng cấp PostgreSQL, dùng AWS R53 groups và bản vá transaction Rails ActiveRecord tự viết để retry các query đang chạy, nên xử lý được mà không có downtime
      Trade-off là một số request bị chậm trong vài giây
      Kết hợp DNS Groups với retry là một cơ chế khá hữu dụng cho những việc như thế này
      Công cụ đã dùng: https://github.com/shayonj/pg_easy_replicate

  • Có nhiều cách để “tạm dừng” các query Postgres đi vào; ví dụ có thể dùng pgbouncer để không làm chúng fail, mà trì hoãn cho đến khi replication bắt kịp rồi tiếp tục trên cơ sở dữ liệu mới
    Nếu có gì đó sai và replication không bắt kịp, bạn có thể bỏ tạm dừng để các query đó chạy trên cơ sở dữ liệu cũ
    Như vậy, 11 giây downtime sẽ biến thành 0–11 giây thời gian tải trang bổ sung. Quan trọng hơn, trong số hàng nghìn người dùng cơ sở dữ liệu vốn chưa từng thấy query thất bại, nếu có đường xử lý lỗi bị bug hoặc chỉ một query thất bại cũng làm hỏng toàn bộ batch job, thì thiệt hại lan truyền sẽ giảm đi rất nhiều

    • Việc dừng query thì có thể làm được, nhưng tôi tò mò liệu có thể dừng cả các transaction đang chạy hay không. Cơ chế đó hoạt động như thế nào?

  • Thú vị khi so sánh với https://knock.app/blog/zero-downtime-postgres-upgrades. Thảo luận liên quan từng có ở https://news.ycombinator.com/item?id=38616181
    Phần lớn thảo luận khi đó đi đến kết luận kiểu “có phải quá phức tạp chỉ để tránh vài phút downtime không”. Trường hợp lần này trông như một minh chứng, và có vẻ chỉ cần dùng AWS Data Migration Service, đổi bản ghi DNS để chuyển sang vận hành, rồi chấp nhận 11 giây downtime

    • Ở đây không có chuyện “chỉ cần” làm vậy. Bài học cốt lõi nằm trong phần “những điều đã học”

      Lý do chúng tôi chọn DMS là vì nó được hỗ trợ tốt trên GOV.UK PaaS và cũng có thể nhận hỗ trợ từ AWS. Trong tương lai, nếu migrate database từ PostgreSQL sang PostgreSQL, chúng tôi sẽ dành thêm thời gian đánh giá các công cụ thay thế như pglogical. DMS có thể đã thêm vào nhiều độ phức tạp và một quy trình replication xa lạ hơn so với những gì chúng tôi sẽ gặp với công cụ khác. Điều này cũng phù hợp với những gì AWS trực tiếp nói về migration giữa các PostgreSQL
      Thông điệp ở đây không phải là “cứ dùng DMS là được”

    • Không biết có ai từng làm việc tương tự với https://cloud.google.com/database-migration/docs/postgres/qu... chưa. Nó hoạt động giống AWS DMS không?
    • DMS có vẻ dùng pglogical bên trong, nhưng có nhiều cạm bẫy. Vì không phải replication ở cấp phần cứng nên có thể gặp vấn đề với row lớn, column lớn, table lớn, và cũng không xử lý foreign key đúng cách
      Một số kiểu dữ liệu đặc thù thậm chí có thể không được xử lý. Sau khi migrate cũng phải cập nhật sequence, nếu không có thể gặp lỗi trùng primary key
      Nếu không có primary key phù hợp, cũng có thể phát sinh vấn đề vì không phải lúc nào nó cũng sao chép toàn bộ row một lượt
      Nếu database nằm trong cùng một tài khoản AWS và bạn chấp nhận được 4–5 phút downtime, replication ở cấp phần cứng bằng global database hoặc snapshot có khả năng sẽ dễ hơn

  • Gần đây tôi đã chuyển một database PostgreSQL 3TB tự host từ 12 lên 16, đồng thời chuyển từ Ubuntu 18 sang Ubuntu 22. Cùng lúc còn phải nâng cấp nhiều extension, đặc biệt Timescale không có phiên bản tương thích nào thỏa mãn mọi tổ hợp
    Chúng tôi làm bằng cách nâng cấp read-only replica: ban đầu là PG12, Ubuntu 18, TS2.9; trước tiên tạo một read-only replica trên Ubuntu 22 nhưng vẫn giữ PG12 và TS2.9
    Sau đó vào maintenance mode, dừng mọi service, tách read-only replica ra, rồi nâng PG12 lên PG15 trên Ubuntu 22 nhưng vẫn giữ TS2.9
    Tiếp theo nâng từ TS2.9 lên TS2.13 trên PG15, rồi cuối cùng nâng PG15 lên PG16 trên Ubuntu 22 trong khi giữ TS2.13
    Cuối cùng, kết nối lại các service vào database server mới, khởi động lại mọi service rồi thoát maintenance mode
    Mọi bước nâng cấp database đều đã được kiểm thử đầy đủ và tự động hóa bằng Ansible, nhưng đã phát sinh một vấn đề không xuất hiện trong lúc test, khiến downtime tăng lên khoảng 30 phút. Với nhu cầu của chúng tôi thì mức này hoàn toàn chấp nhận được
    Nếu dùng logical replication, có lẽ đã giảm được sự cố bất ngờ vào phút chót, và chúng tôi dự định xem xét cách tiếp cận này trong chu kỳ nâng cấp tiếp theo

    • Gần đây chúng tôi cũng đi theo gần như cùng một lộ trình nâng cấp. Tuy nhiên lúc đó Timescale chưa hỗ trợ PG16, nên chúng tôi dừng ở PG15 + TS 2.12
      Chúng tôi cũng xem xét logical replication để giảm downtime khi nâng cấp, nhưng vì schema database và các lệnh DDL không được replicate, nên có vẻ không được khuyến nghị khi có Timescale tham gia
      Những thay đổi schema nền tảng mà Timescale phải thực hiện nội bộ phần lớn sẽ là hàm của kích thước chunk hypertable và pattern ghi đến, nên có thể lập kế hoạch hoặc căn thời điểm, nhưng chúng tôi thấy độ phức tạp và rủi ro tiềm ẩn là quá lớn so với việc đặt một maintenance window ngắn trong lúc pg_upgrade hoàn tất

  • Kẻ thù của các migration ít downtime/không downtime kiểu này là query chạy lâu
    Ví dụ nếu có một query update đơn lẻ mất 30 phút, bạn phải kill query đó và rollback, hoặc chấp nhận mất khả dụng trong 30 phút
    Theo tôi biết thì hiện không có cách nào migrate các query đang chạy

    • Nếu là dự án kỹ nghệ phần mềm, tốt hơn nên giới hạn thời gian transaction ngắn hơn nhiều so với vậy. Thiết lập statement_timeout là bạn của bạn
      Nếu có transaction cực kỳ dài, nhiều khả năng bạn có thể tránh thời điểm nó chạy để thực hiện chuyển đổi. Hy vọng đó là kết quả của một tác vụ được lên lịch chứ không phải phát sinh ngẫu nhiên
      Bằng cách kết hợp giới hạn thời gian transaction, cấu hình failover, chẳng hạn làm primary cũ fail, cùng những thứ như pgbouncer, bạn có thể kiểm soát khá chính xác khoảng thời gian bị chậm thay vì downtime
      Thành thật mà nói, điều tôi lo hơn là toàn bộ stack và các DNS cache server bên ngoài mà nó phụ thuộc có tuân thủ đúng DNS TTL hay không
      Nhưng thường thì với ứng dụng, tránh hơn chục giây downtime không phải là chuyện sống còn, nên chọn giải pháp đơn giản hơn cho mình là đúng
    • Cá nhân tôi khó hình dung một query update 30 phút nếu nó không được viết cực kỳ kém hiệu quả, hoặc không phải là một đợt migration dữ liệu lớn dùng một lần
      Tất nhiên trường hợp đầu thực tế tồn tại rất nhiều. Tôi đã khá nhiều lần tận hưởng việc biến các tác vụ tính bằng phút hoặc giờ xuống còn tính bằng mili giây
    • Học được điều mới. Tôi tò mò những write kéo dài hơn 30 phút thường có tính chất gì
      Không biết loại dữ liệu nào và những người nào xử lý các thao tác ghi database như vậy, đến mức phải dựa vào DB engine làm việc lâu đến thế thay vì chia nhỏ tốt hơn thành queue ở tầng trên

  • Có điểm lạ ở đoạn nói rằng họ tạo bản ghi DNS AWS Route53 cho database.notifications.service.gov.uk với TTL 1 giây, rồi script migration đổi trọng số DNS của AWS để gửi 100% sang vị trí database đích, sau đó đợi 1 giây cho TTL hết hạn
    Họ nói rằng như vậy lần tiếp theo ứng dụng cố query database thì nó sẽ query database đích; điều này có nghĩa là ORM của họ hoặc hành vi mặc định của Python bị chặn vì thực hiện tra cứu DNS ở mỗi query sao?
    Tức là không cache địa chỉ đã phân giải trong một khoảng thời gian nào đó, cũng không connection pooling hay tái sử dụng kết nối à?

    • Có lẽ getaddrinfo hoặc gethostname của OS sẽ thực hiện hành vi này. Python hầu như không tự triển khai lại các lệnh gọi cấp hệ thống, nên nó phụ thuộc vào cấu hình hệ thống
      Nếu TTL 1 giây được tuân thủ thì nó sẽ được cache trong 1 giây, nhưng cũng không hiếm trường hợp thư viện tra cứu DNS, và đặc biệt là caching DNS server, không hoàn toàn tuân thủ TTL. Thành thật mà nói, điều đó cũng có thể giải thích một phần downtime đã quan sát được

  • Hay đấy. Chúng tôi vừa migration 3 cụm Postgres trên RDS, gồm khoảng 2TB dữ liệu và 8 database, từ Postgres 14 lên 16. Hệ thống ngừng từ 00:00 đến 04:00
    Trước tiên, chúng tôi bật “chế độ bảo trì”, một site thay thế rất nhẹ chạy trên Cloudflare Workers, rồi dùng Terraform scale down tất cả app dùng DB về 0
    Trong AWS web UI, chúng tôi bấm nút upgrade để chạy pg_upgrade từ 14→15 và đợi hoàn tất, rồi bấm lại để tiến hành 15→16
    Chúng tôi đợi cho đến khi database bắt đầu nhận kết nối; có vẻ nó đã nhận kết nối ngay cả trước khi được hiển thị là ready, và dường như AWS còn làm thêm việc gì đó ngoài pg_upgrade
    Sau đó chúng tôi bắt đầu VACUUM ANALYZE; REINDEX DATABASE CONCURRENTLY. Mục đích là để tránh vấn đề hiệu năng giữa các phiên bản và tận dụng các cải thiện hiệu năng của phiên bản mới
    Chúng tôi bắt đầu khởi động lại các app, đợi cho đến khi tất cả app đều có vài container đang chạy, rồi bắt đầu nhận traffic, tắt site bảo trì và đi ngủ
    REINDEX CONCURRENTLY chạy thêm 18 giờ trên DB lớn nhất nhưng không chặn gì cả
    Lần tới, chúng tôi dự định dùng AWS Blue/Green deployment để tránh downtime. Lần này không dùng được vì chúng tôi không ở phiên bản minor tối thiểu của 14 mà Blue/Green hỗ trợ, tức 14.9
    Nếu tự làm, tôi sẽ không trả chi phí AWS mà tự dựng Blue/Green bằng logical replication và load balancer

    • Nếu là tôi, tôi sẽ dùng pg_upgrade --hardlinks cho nâng cấp tại chỗ
      Tôi từng xử lý cả DB 2TB trong chưa đến 1 phút trên một instance Postgres tự vận hành on-premises

  • GOV.UK Notify là một phần trong bộ dịch vụ mà GDS cung cấp cho các cơ quan công quyền của Anh. Cùng với đó còn có GOV.UK Pay và GOV.UK PaaS, ban đầu được biết đến với tên Government As A Platform

  • DMS là một công cụ migration tệ hại. Tôi đã vật lộn gần một tháng với nhiều vấn đề migration rồi bỏ cuộc
    Nó không migration được kiểu text và json, và AWS Support cũng không đưa ra được giải pháp
    Tôi đã dùng AWS Blue/Green ở giai đoạn thử nghiệm ban đầu, và nhờ vậy việc upgrade gần như không downtime đã trở thành hiện thực

    • Nếu nghĩ DMS là công cụ migration tệ, hãy thử dùng nó để replication liên tục sang đích bên ngoài xem
      Nó hỏng hoàn toàn

  • Thú vị đấy, nhưng ngay từ đầu tôi không hiểu vì sao chính phủ lại dùng AWS. Đây không phải là một startup đang hack để tìm product-market fit, cũng không phải tình huống không dự đoán được lượng truy cập tăng vọt do marketing rồi phải ứng phó
    Họ biết dịch vụ kiểu này sẽ cần thiết trong dài hạn, và cũng có thể dự đoán khá tốt mô hình sử dụng
    Có thể xây dựng cloud cho khu vực công hoặc áp dụng cách tiếp cận on-premise hợp lý. Việc đó cần tiền, sự phối hợp và năng lực lãnh đạo kỹ thuật, nhưng về dài hạn sẽ tiết kiệm chi phí khổng lồ cho người đóng thuế
    IT khu vực công nhìn chung khá hỗn loạn, nhưng tôi biết trong đó vẫn có những kỹ sư giỏi

    • Với tư cách startup, lý do dùng “cloud”, tức PaaS, không phải để bắt kịp các đợt tăng vọt lưu lượng, mà là để tập trung
      Mỗi giờ chạy loanh quanh với ổ cứng và driver, hoặc phiên bản cloud của chúng như storage và Ansible, là một giờ không dùng để xây thứ khách hàng cần
      Vì sao chính phủ lại phải khác?
      Chúng ta không kỳ vọng chính phủ tự chế tạo ô tô, mà kỳ vọng họ mua từ Volkswagen hoặc Renault. Dù chính phủ rõ ràng có nhu cầu vận tải. Vậy tại sao lại cứ khăng khăng bắt họ tự xây hạ tầng IT thì tôi không hiểu
    • Nếu bạn nghĩ nhu cầu và mức cầu của chính phủ có thể dự đoán được, thì hẳn bạn đã không theo dõi chính trị, đặc biệt là chính trị Anh trong 10 năm qua
      Và còn có những việc hoàn toàn bất ngờ như đại dịch. Việc có thể mở rộng để đáp ứng nhu cầu trong đại dịch là một trong những ví dụ minh họa cốt lõi cho lý do khu vực công nên dùng cloud công cộng thương mại
    • Toàn bộ chính phủ Anh vận hành kết hợp các cloud công cộng lớn cùng một số on-premise và colocation
      Tôi khuyên nên xem bài trình bày hồi tháng 9 về nhiều lần lặp lại của Gov.UK và việc migration giữa các cloud https://youtube.com/watch?v=mpY1lxkikqM&pp=ygUOUmljaGFyZCB0b...
      Ít nhất trong chính phủ Anh, do các yêu cầu mua sắm công, cứ vài năm họ lại phải đưa báo giá theo mức sử dụng ra thị trường một lần
      Ví dụ nếu Oracle Cloud rẻ bằng một phần mười, khả năng cao họ sẽ thắng hợp đồng, khi đó trong thời hạn hợp đồng phải migration sang Oracle, rồi sau đó nếu xuất hiện cloud khác rẻ hơn thì có thể lại phải chuyển tiếp
    • Nhiều nước EU có lẽ đã xây cloud công cộng. Ở Croatia tôi đã trực tiếp trải nghiệm và từng là một trong những developer phải triển khai lên đó
      Đó là thứ tệ nhất tôi từng thấy trong đời. Kể cả khi tôi đã từng xử lý nhiều legacy như VB.NET, Web Forms, SharePoint cũ, Basic, thậm chí cả những ứng dụng mà toàn bộ gần như là một khối stored procedure khổng lồ
      AWS, Azure, Google Cloud ít nhất còn được xây dựng với người dùng cuối, tức developer, trong đầu. Còn cloud của chính phủ thì được thiết kế và xây dựng bởi nhà thầu giá thấp nhất, với mục tiêu số một là cắt chi phí ở mọi nơi có thể
    • Tôi không biết ở Anh thì sao, nhưng ở Mỹ AWS đã cung cấp GovCloud từ lâu, và nói thật so với nhiều hạ tầng tôi từng thấy thì nó gần như là một phước lành
      Ngược lại, tôi cũng từng gặp những người phụ trách hạ tầng và vận hành thực sự xuất sắc, từng vận hành datacenter nội bộ của một cơ quan y tế chính phủ Đức. Vấn đề ở đó 100% không phải là công nghệ hay con người, mà là ban quản lý và quy trình luôn trở thành nút thắt trong mọi tương tác giữa đội hạ tầng và đội engineering