Chạy các cụm Spark có khả năng chịu lỗi và tối ưu hóa chi phí bằng cách sử dụng Amazon EMR trên Phiên bản dùng ngay EKS và Amazon EC2

Chạy các cụm Spark có khả năng chịu lỗi và tối ưu hóa chi phí bằng cách sử dụng Amazon EMR trên Phiên bản dùng ngay EKS và Amazon EC2

Dấu thời gian: ngày 19 tháng 2022 năm 4 57:XNUMX chiều
Nút nguồn: 1778247

Amazon EMR trên EKS là một tùy chọn triển khai trong Amazon EMR cho phép bạn chạy các công việc Spark trên Dịch vụ Kubernetes đàn hồi của Amazon (Amazon EKS). Đám mây điện toán đàn hồi Amazon (Amazon EC2) Phiên bản Spot giúp bạn tiết kiệm tới 90% so với Phiên bản theo yêu cầu và là một cách tuyệt vời để tối ưu hóa chi phí cho khối lượng công việc Spark chạy trên Amazon EMR trên EKS. Vì Spot là một dịch vụ có thể bị gián đoạn nên nếu chúng tôi có thể di chuyển hoặc sử dụng lại các tệp xáo trộn trung gian, điều đó sẽ cải thiện độ ổn định tổng thể và SLA của công việc. Các phiên bản mới nhất của Amazon EMR trên EKS đã tích hợp các tính năng Spark để kích hoạt khả năng này.

Trong bài đăng này, chúng ta thảo luận về các tính năng này—Tái sử dụng nút Ngừng hoạt động và Yêu cầu khối lượng liên tục (PVC)—và tác động của chúng đối với việc tăng khả năng chịu lỗi của các công việc Spark trên Amazon EMR trên EKS khi tối ưu hóa chi phí bằng Phiên bản dùng ngay EC2.

Amazon EMR trên EKS và Spot

Phiên bản dùng ngay EC2 là dung lượng EC2 dự phòng được cung cấp với mức chiết khấu cao lên tới 90% so với giá Theo nhu cầu. Phiên bản Spot là lựa chọn tuyệt vời cho khối lượng công việc linh hoạt và phi trạng thái. Cảnh báo trước về mức chiết khấu và dung lượng dự phòng này là Amazon EC2 có thể làm gián đoạn một phiên bản bằng cảnh báo chủ động hoặc phản ứng (2 phút) khi phiên bản đó cần dung lượng trở lại. Bạn có thể cung cấp năng lực điện toán trong cụm EKS bằng Phiên bản Spot sử dụng nhóm nút được quản lý hoặc tự quản lý và cung cấp khả năng tối ưu hóa chi phí cho khối lượng công việc của bạn.

Amazon EMR trên EKS sử dụng Amazon EKS để chạy các công việc với Thời gian chạy EMR cho Apache Spark, có thể được tối ưu hóa chi phí bằng cách chạy Người thi hành Spark tại chỗ. Nó cung cấp đến Chi phí thấp hơn 61% và cải thiện hiệu suất lên đến 68% đối với khối lượng công việc Spark trên Amazon EKS. Ứng dụng Spark khởi chạy trình điều khiển và bộ thực thi để chạy tính toán. Spark là một khuôn khổ chịu lỗi bán kiên cường để mất người thi hành do bị gián đoạn và do đó có thể chạy trên EC2 Spot. Mặt khác, khi trình điều khiển bị gián đoạn, công việc không thành công. Do đó, chúng tôi khuyên bạn nên chạy trình điều khiển trên các phiên bản theo yêu cầu. một số thực hành tốt nhất để chạy Spark trên Amazon EKS có thể áp dụng với Amazon EMR trên EKS.

Các phiên bản EC2 Spot cũng giúp tối ưu hóa chi phí bằng cách cải thiện thông lượng tổng thể của công việc. Điều này có thể đạt được bằng cách tự động thay đổi quy mô cụm bằng cách sử dụng Bộ tự động chia tỷ lệ cụm (đối với nhóm nút được quản lý) hoặc thợ mộc.

Mặc dù trình thực thi Spark có khả năng phục hồi khi bị gián đoạn Spot, nhưng các tệp xáo trộn và dữ liệu RDD sẽ bị mất khi trình thực thi bị giết. Các tệp xáo trộn bị mất cần được tính toán lại, điều này làm tăng thời gian chạy tổng thể của công việc. Apache Spark đã phát hành hai tính năng (trong phiên bản 3.1 và 3.2) giải quyết vấn đề này. Amazon EMR trên EKS đã phát hành các tính năng như ngừng hoạt động nút (phiên bản 6.3) và tái sử dụng PVC (phiên bản 6.8) để đơn giản hóa việc khôi phục và tái sử dụng các tệp xáo trộn, giúp tăng khả năng phục hồi tổng thể cho ứng dụng của bạn.

ngừng hoạt động nút

Tính năng ngừng hoạt động của nút hoạt động bằng cách ngăn việc lập lịch trình cho các công việc mới trên các nút sắp ngừng hoạt động. Nó cũng di chuyển bất kỳ tệp xáo trộn hoặc bộ đệm nào có trong các nút đó sang các bộ thực thi khác (ngang hàng). Nếu không có bộ thực thi khả dụng nào khác, các tệp xáo trộn và bộ nhớ đệm sẽ được chuyển đến bộ lưu trữ dự phòng từ xa.

Ngừng hoạt động nút

Hình 1: Ngừng hoạt động nút

Hãy xem xét các bước ngừng hoạt động chi tiết hơn.

Nếu một trong các nút đang chạy bộ thực thi bị gián đoạn, bộ thực thi sẽ bắt đầu quá trình ngừng hoạt động và gửi thông báo tới trình điều khiển:

21/05/05 17:41:41 WARN KubernetesClusterSchedulerBackend$KubernetesDriverEndpoint: Received executor 7 decommissioned message
21/05/05 17:41:41 DEBUG TaskSetManager: Valid locality levels for TaskSet 2.0: NO_PREF, ANY
21/05/05 17:41:41 INFO KubernetesClusterSchedulerBackend: Decommission executors: 7
21/05/05 17:41:41 DEBUG TaskSchedulerImpl: parentName: , name: TaskSet_2.0, runningTasks: 10
21/05/05 17:41:41 INFO BlockManagerMasterEndpoint: Mark BlockManagers (BlockManagerId(7, 192.168.82.107, 39007, None)) as being decommissioning.

21/05/05 20:22:17 INFO CoarseGrainedExecutorBackend: Decommission executor 1.
21/05/05 20:22:17 INFO CoarseGrainedExecutorBackend: Will exit when finished decommissioning
21/05/05 20:22:17 INFO BlockManager: Starting block manager decommissioning process...
21/05/05 20:22:17 DEBUG FileSystem: Looking for FS supporting s3a

Người thi hành tìm kiếm các tệp RDD hoặc xáo trộn và cố gắng sao chép hoặc di chuyển các tệp đó. Đầu tiên, nó cố gắng tìm một người thực thi ngang hàng. Nếu thành công, nó sẽ chuyển các tệp sang trình thực thi ngang hàng:

22/06/07 20:41:38 INFO ShuffleStatus: Updating map output for 46 to BlockManagerId(4, 192.168.13.235, 34737, None)
22/06/07 20:41:38 DEBUG BlockManagerMasterEndpoint: Received shuffle data block update for 0 46, ignore.
22/06/07 20:41:38 DEBUG BlockManagerMasterEndpoint: Received shuffle index block update for 0 46, updating.

Tuy nhiên, nếu không thể tìm thấy trình thực thi ngang hàng, nó sẽ cố gắng di chuyển các tệp sang bộ lưu trữ dự phòng nếu có.

Lưu trữ dự phòng

Hình 2: Lưu trữ dự phòng

Người thi hành sau đó ngừng hoạt động. Khi một trình thực thi mới xuất hiện, các tệp xáo trộn được sử dụng lại:

22/06/07 20:42:50 INFO BasicExecutorFeatureStep: Adding decommission script to lifecycle
22/06/07 20:42:50 DEBUG ExecutorPodsAllocator: Requested executor with id 19 from Kubernetes.
22/06/07 20:42:50 DEBUG ExecutorPodsWatchSnapshotSource: Received executor pod update for pod named amazon-reviews-word-count-bfd0a5813fd1b80f-exec-19, action ADDED
22/06/07 20:42:50 DEBUG BlockManagerMasterEndpoint: Received shuffle index block update for 0 52, updating.
22/06/07 20:42:50 INFO ShuffleStatus: Recover 52 BlockManagerId(fallback, remote, 7337, None)

Ưu điểm chính của quy trình này là nó cho phép di chuyển các khối và xáo trộn dữ liệu, do đó giảm tính toán lại, điều này làm tăng thêm khả năng phục hồi tổng thể của hệ thống và giảm thời gian chạy. Quá trình này có thể được kích hoạt bởi một tín hiệu gián đoạn Spot (Sigterm) và rút cạn nút. Việc thoát nút có thể xảy ra do lập lịch tác vụ ưu tiên cao hoặc độc lập.

Khi bạn sử dụng Amazon EMR trên EKS với nút được quản lý groups/Karpenter, quá trình xử lý gián đoạn Spot được tự động hóa, trong đó Amazon EKS rút cạn và cân bằng lại các nút Spot một cách nhẹ nhàng để giảm thiểu tình trạng gián đoạn ứng dụng khi một nút Spot có nguy cơ bị gián đoạn cao. Nếu bạn đang sử dụng nút được quản lý groups/Karpenter, quá trình ngừng hoạt động được kích hoạt khi các nút đang cạn kiệt và vì tính năng này chủ động nên sẽ cho bạn thêm thời gian (ít nhất 2 phút) để di chuyển các tệp. Trong trường hợp các nhóm nút tự quản lý, chúng tôi khuyên bạn nên cài đặt AWS Node Termination Handler để xử lý tình trạng gián đoạn và quá trình ngừng hoạt động được kích hoạt khi nhận được thông báo phản hồi (2 phút). Chúng tôi khuyên bạn nên sử dụng Karpenter với Phiên bản dùng ngay vì nó có lịch trình nút nhanh hơn với liên kết nhóm sớm và đóng gói theo nhóm để tối ưu hóa việc sử dụng tài nguyên.

Đoạn mã sau kích hoạt cấu hình này; thêm chi tiết có sẵn trên GitHub:

"spark.decommission.enabled": "true" "spark.storage.decommission.rddBlocks.enabled": "true" "spark.storage.decommission.shuffleBlocks.enabled" : "true" "spark.storage.decommission.enabled": "true" "spark.storage.decommission.fallbackStorage.path": "s3://<<bucket>>"

Tái sử dụng PVC

Apache Spark đã bật PVC động trong phiên bản 3.1, điều này rất hữu ích với phân bổ động vì chúng tôi không phải tạo trước các xác nhận quyền sở hữu hoặc khối lượng cho người thực thi và xóa chúng sau khi hoàn thành. PVC cho phép tách dữ liệu thực sự và xử lý khi chúng tôi đang chạy các công việc Spark trên Kubernetes, bởi vì chúng tôi có thể sử dụng nó làm bộ lưu trữ cục bộ để truyền các tệp đang xử lý. Phiên bản mới nhất của Amazon EMR 6.8 đã tích hợp tính năng tái sử dụng PVC của Spark, trong đó nếu một bộ thực thi bị chấm dứt do gián đoạn EC2 Spot hoặc bất kỳ lý do nào khác (JVM), thì PVC sẽ không bị xóa mà được duy trì và gắn lại với một bộ thực thi khác. Nếu có các tệp xáo trộn trong ổ đĩa đó, thì chúng sẽ được sử dụng lại.

Như với việc ngừng hoạt động của nút, điều này làm giảm thời gian chạy tổng thể vì chúng tôi không phải tính toán lại các tệp xáo trộn. Chúng tôi cũng tiết kiệm thời gian cần thiết để yêu cầu một tập đĩa mới cho người thực thi và các tệp xáo trộn có thể được sử dụng lại mà không cần di chuyển các tệp.

Sơ đồ sau minh họa quy trình làm việc này.

Tái sử dụng PVC

Hình 3: Tái sử dụng PVC

Hãy xem xét các bước chi tiết hơn.

Nếu một hoặc nhiều nút đang chạy bộ thực thi bị gián đoạn, các nhóm bên dưới sẽ bị chấm dứt và trình điều khiển sẽ nhận được bản cập nhật. Lưu ý rằng trình điều khiển là chủ sở hữu của PVC của những người thi hành và họ không bị chấm dứt. Xem đoạn mã sau:

22/06/15 23:25:07 DEBUG ExecutorPodsWatchSnapshotSource: Received executor pod update for pod named amazon-reviews-word-count-9ee82b8169a75183-exec-3, action DELETED
22/06/15 23:25:07 DEBUG ExecutorPodsWatchSnapshotSource: Received executor pod update for pod named amazon-reviews-word-count-9ee82b8169a75183-exec-6, action MODIFIED
22/06/15 23:25:07 DEBUG ExecutorPodsWatchSnapshotSource: Received executor pod update for pod named amazon-reviews-word-count-9ee82b8169a75183-exec-6, action DELETED
22/06/15 23:25:07 DEBUG ExecutorPodsWatchSnapshotSource: Received executor pod update for pod named amazon-reviews-word-count-9ee82b8169a75183-exec-3, action MODIFIED

ExecutorPodsAllocator cố gắng phân bổ các nhóm thực thi mới để thay thế các nhóm bị chấm dứt do gián đoạn. Trong quá trình phân bổ, nó chỉ ra có bao nhiêu PVC hiện có có tệp và có thể được sử dụng lại:

22/06/15 23:25:23 INFO ExecutorPodsAllocator: Found 2 reusable PVCs from 10 PVCs

ExecutorPodsAllocator yêu cầu một nhóm và khi khởi chạy nhóm đó, PVC sẽ được sử dụng lại. Trong ví dụ sau, PVC từ bộ thực thi 6 được sử dụng lại cho nhóm thực thi mới 11:

22/06/15 23:25:23 DEBUG ExecutorPodsAllocator: Requested executor with id 11 from Kubernetes.
22/06/15 23:25:24 DEBUG ExecutorPodsWatchSnapshotSource: Received executor pod update for pod named amazon-reviews-word-count-9ee82b8169a75183-exec-11, action ADDED
22/06/15 23:25:24 INFO KubernetesClientUtils: Spark configuration files loaded from Some(/usr/lib/spark/conf) : log4j.properties,spark-env.sh,hive-site.xml,metrics.properties
22/06/15 23:25:24 INFO BasicExecutorFeatureStep: Decommissioning not enabled, skipping shutdown script
22/06/15 23:25:24 DEBUG ExecutorPodsWatchSnapshotSource: Received executor pod update for pod named amazon-reviews-word-count-9ee82b8169a75183-exec-11, action MODIFIED
22/06/15 23:25:24 INFO ExecutorPodsAllocator: Reuse PersistentVolumeClaim amazon-reviews-word-count-9ee82b8169a75183-exec-6-pvc-0

Các tệp xáo trộn, nếu có trong PVC sẽ được sử dụng lại.

Ưu điểm chính của kỹ thuật này là nó cho phép chúng tôi sử dụng lại các tệp xáo trộn được tính toán trước ở vị trí ban đầu của chúng, do đó giảm thời gian thực hiện công việc tổng thể.

Điều này hoạt động cho cả PVC tĩnh và động. Amazon EKS Cung cấp ba dịch vụ lưu trữ khác nhau, cũng có thể được mã hóa: Cửa hàng đàn hồi Amazon (Amazon EBS), Hệ thống tệp đàn hồi Amazon (Amazon EFS) và Amazon FSx cho ánh. Chúng tôi khuyên bạn nên sử dụng PVC động với Amazon EBS vì với PVC tĩnh, bạn sẽ cần tạo nhiều PVC.

Đoạn mã sau kích hoạt cấu hình này; thêm chi tiết có sẵn trên GitHub:

"spark.kubernetes.driver.ownPersistentVolumeClaim": "true" "spark.kubernetes.driver.reusePersistentVolumeClaim": "true"

Để điều này hoạt động, chúng tôi cần kích hoạt PVC với Amazon EKS và đề cập đến các chi tiết trong cấu hình thời gian chạy Spark. Để biết hướng dẫn, hãy tham khảo Làm cách nào để sử dụng lưu trữ liên tục trong Amazon EKS? Đoạn mã sau chứa chi tiết cấu hình Spark để sử dụng PVC làm bộ nhớ cục bộ; các chi tiết khác có sẵn trên GitHub:

"spark.kubernetes.executor.volumes.persistentVolumeClaim.spark-local-dir-1.mount.readOnly": "false" "spark.kubernetes.executor.volumes.persistentVolumeClaim.spark-local-dir-1.options.claimName": "OnDemand" "spark.kubernetes.executor.volumes.persistentVolumeClaim.spark-local-dir-1.options.storageClass": "spark-sc" "spark.kubernetes.executor.volumes.persistentVolumeClaim.spark-local-dir-1.options.sizeLimit": "10Gi" "spark.kubernetes.executor.volumes.persistentVolumeClaim.spark-local-dir-1.mount.path": "/var/data/spill"

Kết luận

Với Amazon EMR trên EKS (6.9) và các tính năng được thảo luận trong bài đăng này, bạn có thể giảm thêm thời gian chạy tổng thể cho các công việc Spark khi chạy với Phiên bản Spot. Điều này cũng cải thiện khả năng phục hồi tổng thể và tính linh hoạt của công việc trong khi tối ưu hóa chi phí cho khối lượng công việc trên EC2 Spot.

Hãy thử EMR trên hội thảo EKS để cải thiện hiệu suất khi chạy khối lượng công việc Spark trên Kubernetes và tối ưu hóa chi phí bằng cách sử dụng Phiên bản dùng ngay EC2.

Lưu ý

Kinnar Kumar Sen là Kiến trúc sư giải pháp cấp cao tại Amazon Web Services (AWS) tập trung vào Điện toán linh hoạt. Là thành viên của nhóm Điện toán linh hoạt EC2, anh ấy làm việc với khách hàng để hướng dẫn họ các tùy chọn điện toán linh hoạt và hiệu quả nhất, phù hợp với khối lượng công việc chạy trên AWS của họ. Kinnar có hơn 15 năm kinh nghiệm làm việc trong ngành về nghiên cứu, tư vấn, kỹ thuật và kiến ​​trúc.

Dấu thời gian:

Thêm từ Dữ liệu lớn AWS