Giaosucan's blog - Chia sẻ kiến thức theo cách bá đạo

Ticker

20/recent/ticker-posts

Kiến trúc FAANG 3 - Netflix DevOps

Tiếp theo phần 2



Ta đã biết Netflix sử dụng kiến trúc Microservices, bài này sẽ tìm hiểu cách Netflix build code và deploy những microservices này lên infra như thế nào. Nhưng trước tiên xem Netflix có gì

Netflix mỗi ngày có khoảng 1K+ thay đổi trên production

Khoảng 10K+ server running

Mỗi giây có 100K+ end user tương tác

Khoảng 11K+ developer fulltime làm việc trên mấy K repos, trong đó độ 200+ repos đang public, còn lại private




Một team tên là Edge Engneering được thành lập bao gồm Ops và SRE engineering để phát triển hệ thống CICD cho Netflix

Netflix build code thế nào

Hệ thống Netflix có hàng nghìn microservice được phát triển bởi nhiều team riêng biệt, ngôn ngữ chính để viết microservice vẫn là Java,

Để build Java code, lúc đầu Netflix sử dụng Apache Ant nhưng do tool này dùng XML để mô tả project khó quản lý nên sau đó Netflix chọn Gradle build

Trước khi code được commited thì vẫn cần phải build, test locally, cách mà developer ngày nay vẫn thường dùng. Đối với hệ thống nhỏ, code ít thì không thành vấn đề. Tuy nhiên, với một hệ thống lớn như Netflix thì cách truyền thống có issue

Hãy xem xét tình huống sau

Khi developer build một ứng dụng Java, luôn cần phải có thư viện depedency (artifact) đi kèm, ví dụ junit, log4j. Một số thư viện common anh dev Java nào cũng xài, add thư viện càng lắm thì thời gian build càng lâu, do phải tải đống artifact trên artifactory về

Netflix thì có hàng trăm team, và cả nghìn developer trên khắp thế giới. Tưởng tượng mỗi anh dev sẽ có 1 bản clone của repos trên máy local và chạy file gradle

build.

implementation 'org.springframework.boot:spring-boot-starter-actuator'
implementation 'org.apache.commons:commons-text:1.9'
implementation 'xxx'

Trăm ông dev thì phải 90% ông để add mấy cái common depedencies như junit, log4j vào gradle build. Cái này gọi là khái niệm “boilerplate”, những đoạn code cứ lặp đi lặp lại để thực hiện chức năng nào đó. Chi tiết cụ thể lên GG tra

Kết quả khi cả trăm ông dev build đều phải tải cùng đống common depedencies như trên, thành ra duplicate time không cần thiết

Netflix đã phát triển Nebula , một thư viện Gradle plugin , giúp giải quyết vấn đề boilerplate như trên, không phải down cùng 1 artifact nhiều lần, hỗ trợ build caching và incremental build, (chỉ build những phần thay đổi) để tiết kiệm thời gian build code. Quan trọng nhất là re-usable những build common đã đc thực hiện trước đó.

Sau khi source code được build test chạy OK thì code được commit lên Git, Netflix sử dụng GitHub enterpise để lưu trữ code của mình. các repos nằm trong các Git organizations  như Netflix, Spinnaker. Cách này thì common, nhiều công ty cũng hay làm như vậy

Vấn đề là developer của Github cả nghìn người, quản lý nhóm thanh niên này để các cụ không commit ẩu, merge code bát nháo thì phải có tool riêng. Netflix phát triển HubCommander, một slackbot để quản lý Git organization cho phép tạo/xóa repos, listing PR, enable/disable branch protection. Vậy thay vì thuê một GitHub admin quản lý repos bằng cơm thì tất cả chuyển qua Chatbot, developer cần gì thì ping ChatBot xử lý như ở dưới

Để bảo mật thì DUO MFA được tích hợp

Sau khi code được commit, thì Jenkins jobs dùng Nebula để build, code test đóng gói thành package để chuẩn bị deployment

Quá trình deploy Netflix sử dụng patten Immutable Server pattern, tạo ra những Baked AMI chứa environment và app package để chạy . Mấy khái niệm này, search Google đọc tiếng Anh xác định là phù não. Hiểu nhanh theo kiểu giaosucan’s blog thì như thế này

Bạn có 1 con server production đang chạy app code version 1.

Hôm qua khách yêu cầu thêm chức năng mới, bạn code thêm version 2

Nếu deploy thẳng app version 2 vào con server production thì sẽ rất rủi ro, nhỡ app chạy lỗi, server không tương thích lăn quay ra chết thì xác cmnd

Như vậy phải launch ra một server thứ 2, deploy cái app version 2 vào đó, test chạy ngon chán chê thì switch ELB sang con server đó, còn nếu trục trặc thì giữ nguyên. Tóm lại server thứ 2 hoạt động giống như chuột bạch để developer test trước khi full operation, gọi là immutable server

Pattern này được áp dụng khá nhiều ko chỉ trong IT mà giới checker thiên địa hội cũng áp dụng khá nhiều, khi có em zalo mới onboard, sẽ đội phán quan, bánh đi kiểm định trước sau đó về report lại, gọi là review, nếu ổn em đó chính thức được go-live, còn nếu hàng công nghiệp bát nháo sẽ được đưa vào blacklist, treo bím, giúp anh e checker tránh mất tiền ngu, giảm thiệt hại.

Việc tạo AMI, anh em đã quen với Packer, tool do hashicorp phát triển. Tuy nhiên, Netflix phát triển tool riêng để tạo AMI gọi là animator, cơ chế hoạt động của animator thì vẫn same same Packer, customized AMI từ một base AMI có sẵn

Creating an instance store-backed AMI.

Base AMI là một Linux environment cơ bản như Ubuntu, Centos, launch instance từ Base AMI này rồi cài cắm các app package vào, sau đó launch ra một AMI #2 gọi là customized AMI

Sau khi AMI được tạo ra, chúng được deploy lên infra bằng tool Asgards, một web UI tool để Devops engineer launch AMI lên các cụm EC2 clusters, mỗi version tương ứng với một EC2 cluster


Version mới được đăng ký vào service discovery gọi là eureka

Spring Cloud Netflix Eureka - The Hidden Manual - Non Compos Mentis

Eureka hoạt động giống như quản lý (Eureka Server) của mấy quán massage, mỗi khi có em gái (app service) nào on-board sẽ đăng ký tên tuổi, zalo, giấy khám sức khỏe cho quản lý. Mỗi khi khách đến (application client), họ sẽ hỏi locker (Eureka Client) gọi cho anh em này , em kia, quản lý sẽ kiểm tra trong DB để xem em đó có avaible không hay đang tiếp khách , nếu ok thì locker đưa vào phòng.

Sau khi AMI được tạo giờ là deploy lên server, do server Netflix có cả ngàn nên kỹ sư Netflix phát triển một platform riêng Spinnaker để làm việc này, Netflix team đã hợp tác với Google và Microsoft cho phép Spinnaker manage CD workflow trên GCP hay Azurem , deploy trên multi-cloud như AWS, GCP, Azure

Các spinnker pipline được trigger từ Jenkins để deploy các backed AMI lên hàng nghìn sever EC2

Hệ thống hiện tôi đang làm cũng sử dụng cách na ná như Netflix đang làm là dùng packer để deploy các Baked AMI, rồi run Spinnaker Pipeline để deploy lên ec2.

Nhưng sau này hệ thống chuyển sang containerized thì cách này đã bỏ, và chuyển thành ArgoCD deploy container lên GKE cluster (Container orchestration)

Còn Netflix thì họ tự build platform container orchestration riêng, gọi là Titus , platform này build on top của Mesos  để deploy microservices. 

Nhìn sơ sơ tên mấy platform do Netflix phát triển cũng thấy văn hóa của các công ty Silion Valley. Nếu như Việt Nam hay đặt tên đường phố theo danh nhân văn hóa , lãnh đạo cách mạng như Lê Duẩn Trần Phú thì họ sử dụng tên dự án theo thần thoại Hi Lạp như Athena, Prometheus , hay theo phim như Asgard, Obiwan (Startwar), hoàng đế La Mã (Titus). Hi vọng sau nãy kĩ sư của VN có thể phát triển nhưng platform open source cho cộng đồng lấy tên diễn viên JAV nổi tiếng như project YUI Mukakmi , Ozawa...

Cụ thể Titus này thế nào, đòn đọc phần sau

Đăng nhận xét

0 Nhận xét