פריסת עומס עבודה של למידת מכונה באצווה

במדריך הזה נדגים איך להשתמש ב-Google Kubernetes Engine ‏(GKE) כדי לנהל עומסי עבודה (workload) של אצווה עמידים בכשלים, תוך שמירה על עלויות נמוכות. במדריך הזה מוסבר איך להשתמש במשימות ובתצורות Spot Pods שעברו אופטימיזציה של העלויות, וגם איך להגדיר תור משימות של Redis בתוך האשכול ב-GKE.

רקע

עומס עבודה באצווה הוא תהליך שבדרך כלל מתוכנן כך שיהיה לו נקודת התחלה ונקודת סיום. כדאי לשקול שימוש בעומסי עבודה של אצווה ב-GKE אם הארכיטקטורה שלכם כוללת קליטה, עיבוד ופלט של נתונים במקום שימוש בנתונים גולמיים. בתחומים כמו למידת מכונה, בינה מלאכותית (AI) ומחשוב עתיר ביצועים (HPC), יש סוגים שונים של עומסי עבודה באצווה, כמו אימון מודלים אופליין, חיזוי באצווה, ניתוח נתונים, סימולציה של מערכות פיזיות ועיבוד וידאו.

אם תתכננו עומסי עבודה (workloads) של אצוות בתוך קונטיינרים, תוכלו ליהנות מהיתרונות הבאים של GKE:

  • תקן פתוח, קהילה רחבה ושירות מנוהל.
  • יעילות בעלויות שנובעת מתיאום יעיל של עומסי עבודה ותשתית וממשאבי מחשוב ייעודיים.
  • בידוד וניידות של יצירת קונטיינרים, שמאפשרים להשתמש בענן כקיבולת עודפת תוך שמירה על אבטחת מידע.
  • זמינות של קיבולת זמנית, ואחריה הקטנה מהירה של אשכולות GKE.

מטרות

המדריך הזה מיועד למהנדסי למידת מכונה או למדעני נתונים שרוצים ללמוד איך להריץ עומסי עבודה של למידת מכונה באצווה ב-GKE, בארכיטקטורה הבאה שהיא חסכונית וניתנת להרחבה:

במדריך הזה מוסבר איך:

  1. יוצרים אשכול GKE Autopilot. לחלופין, אפשר להשתמש באשכול GKE Standard במדריך הזה.
  2. יוצרים נפח אחסון Filestore NFS.
  3. יוצרים תור משימות של Redis באשכול.
  4. מעבירים מערכי נתונים לנפח ה-NFS ומכניסים אותם לתור כדי שעומס העבודה יוכל להשתמש בהם.
  5. מריצים עומס עבודה לדוגמה של למידת מכונה באצווה באשכול GKE.

עלויות

במסמך הזה משתמשים ברכיבים הבאים של Google Cloud, והשימוש בהם כרוך בתשלום:

כדי להעריך את ההוצאות בהתאם לתחזית השימוש שלכם, אתם יכולים להיעזר במחשבון העלויות.

משתמשים חדשים של Google Cloud ? יכול להיות שאתם זכאים לתקופת ניסיון בחינם.

לחצו על תראו לי איך כדי לקרוא הסבר מפורט על המשימה ישירות במסוף Google Cloud :

תראו לי איך

לפני שמתחילים

  1. נכנסים לחשבון Google Cloud . אם אתם משתמשים חדשים ב- Google Cloud, צרו חשבון כדי שתוכלו להעריך את הביצועים של המוצרים שלנו בתרחישים מהעולם האמיתי. לקוחות חדשים מקבלים בחינם גם קרדיט בשווי 300$ להרצה, לבדיקה ולפריסה של עומסי העבודה.

  2. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Roles required to select or create a project

    • Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
    • Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

    Go to project selector

  3. Verify that billing is enabled for your Google Cloud project.

  4. Enable the Compute Engine, GKE, and Filestore APIs.

    Roles required to enable APIs

    To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.

    Enable the APIs

  5. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Roles required to select or create a project

    • Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
    • Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

    Go to project selector

  6. Verify that billing is enabled for your Google Cloud project.

  7. Enable the Compute Engine, GKE, and Filestore APIs.

    Roles required to enable APIs

    To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.

    Enable the APIs

    8.

  8. במסוף Google Cloud , מפעילים את Cloud Shell.

    הפעלת Cloud Shell

    בחלק התחתון של Google Cloud המסוף יתחיל סשן של Cloud Shell ותופיע הודעה של שורת הפקודה. Cloud Shell היא סביבת מעטפת שבה ה-CLI של Google Cloud מותקן ומוגדרים ערכים לפרויקט הקיים. הסשן יופעל תוך כמה שניות.

הכנת הסביבה

  1. משכפלים את המאגר לדוגמה שבו השתמשנו במדריך הזה:

    git clone https://github.com/GoogleCloudPlatform/kubernetes-engine-samples
cd kubernetes-engine-samples/batch/aiml-workloads

  2. יוצרים אשכול GKE Autopilot:

    gcloud container clusters create-auto batch-aiml \
    --location=us-central1

    השלב הזה יכול להימשך עד 5 דקות.

הגדרת אחסון של מערך נתונים באמצעות Network File System ‏ (NFS)

עומס העבודה של למידת המכונה דורש פתרון אחסון למערכי הנתונים ולקובצי הפלט. בקטע הזה יוצרים מופע של Filestore ומעניקים גישה למופע באמצעות PersistentVolume ו-PersistentVolumeClaim.

מידע נוסף זמין במאמרים איך מתכננים אסטרטגיית אחסון אופטימלית ואיך ניגשים למופעי Filestore מאשכולות GKE.

יצירת מופע Filestore

  1. יוצרים מכונת Filestore:

    gcloud filestore instances create batch-aiml-filestore \
    --zone=us-central1-b \
    --tier=BASIC_HDD \
    --file-share=name="NFSVol",capacity=1TB \
    --network=name="default"

    הפקודה הזו מציינת את האפשרויות הבאות:

    • ‫tier: רמת השירות של מופע Filestore. בדוגמה הזו נעשה שימוש ברמה הבסיסית. מידע על האפשרויות האחרות זמין במאמר מסלולי שירות.

    • ‫network=name: השם של רשת הענן הווירטואלי הפרטי (VPC) של מכונת Filestore. אשכול GKE צריך להיות באותה רשת VPC כמו מכונת Filestore.

    • ‫capacity: הגודל הרצוי של אמצעי האחסון. מציינים את ערך האחסון באחת מהיחידות הנתמכות שמתוארות במאמר בנושא כמויות משאבים.

  2. מוודאים שמופע Filestore נפרס:

    gcloud filestore instances list \
    --project=PROJECT_ID \
    --zone=us-central1-b

    מחליפים את PROJECT_ID במזהה הפרויקט ב- Google Cloud.

    הפלט אמור להיראות כך:

    INSTANCE_NAME: batch-aiml-filestore
LOCATION: us-central1-b
TIER: BASIC_HDD
CAPACITY_GB: 1024
FILE_SHARE_NAME: NFSVol
IP_ADDRESS: 203.0.113.54
STATE: READY
CREATE_TIME: 2022-03-15T18:23:51

  3. שימו לב לערך בשדה IP_ADDRESS כדי להשתמש בו בקטע הבא.

יצירת נפח אחסון מתמיד

מפרט של PersistentVolume ב-Kubernetes מאפשר לאשכול GKE להתחבר למופע Filestore.

  1. מעדכנים את הקובץ kubernetes-manifests/persistent-volume.yaml עם כתובת ה-IP של מופע Filestore:

    sed -i "\
  s/<FILESTORE_IP_ADDRESS>/IP_ADDRESS/g" \
  kubernetes-manifests/persistent-volume.yaml

    מחליפים את IP_ADDRESS בכתובת ה-IP שרשמתם כשיצרתם את מכונת Filestore בקטע הקודם.

  2. פריסת נפח האחסון המתמיד:

    kubectl apply -f kubernetes-manifests/persistent-volume.yaml

יצירת בקשה לנפח אחסון מתמיד

PersistentVolumeClaim ב-Kubernetes מאפשר לקבוצות Pod ולמשימות ב-Kubernetes לגשת למשאבי האחסון של PersistentVolume.

פורסים את PersistentVolumeClaim:

kubectl apply -f kubernetes-manifests/persistent-volume-claim.yaml

שימוש ב-PersistentVolumeClaim

אחרי שמגדירים את PersistentVolume ואת PersistentVolumeClaim באשכול GKE, אפשר להגדיר את שרת Redis ואת משימות האצווה כך שישתמשו ב-PersistentVolumeClaim. הוא מופיע כנפח אחסון שאפשר לטעון.

בודקים את הקבצים kubernetes-manifests/redis-pod.yaml ו-kubernetes-manifests/workload.yaml. הגדרות המניפסט דומות להגדרות הבאות:

  spec:
  …
  containers:
  - name: workload
    image: "us-central1-docker.pkg.dev/gke-batch-aiml/batch-aiml-docker-repo/workload"
    volumeMounts:
    - mountPath: /mnt/fileserver
      name: workload-pvc
  volumes:
  - name: workload-pvc
    persistentVolumeClaim:
      claimName: fileserver-claim
      readOnly: false

במניפסט הזה:

  • ‫spec.volumes מציין את PersistentVolumeClaim לשימוש.
  • ‫spec.containers.volumeMounts מציין את נתיב הקובץ המקומי שדרכו ה-Pod יכול לגשת לשיתוף הקבצים של Filestore.

הגדרת תור משימות של Redis

עומס העבודה מעבד נתונים באצוות כדי לאמן באופן איטרטיבי מודל לזיהוי הונאות. כדי לנהל את קבוצות הנתונים שעוברות כרגע עיבוד או שנמצאות עדיין בתור, צריך לפרוס את שרת Redis באשכול GKE.

במדריך הזה, מתחילים מכונה אחת של Redis. כדי לפרוס את Redis בצורה שניתנת להרחבה ועם יתירות, אפשר לעיין במאמר יצירת אפליקציית אינטרנט מרובת שכבות באמצעות Redis ו-PHP.

  1. פורסים את המפרט של שרת Redis.

    kubectl apply -f kubernetes-manifests/redis-pod.yaml

  2. מוודאים שה-Pod פועל:

    kubectl get pods

    הפלט אמור להיראות כך:

    NAME           READY   STATUS    RESTARTS   AGE
redis-leader   1/1     Running   0          118s

    יכול להיות שיחלפו עד שתי דקות עד שה-Pod יתחיל לפעול.

  3. מעבירים את הקבצים שמכילים את מערכי הנתונים לאימון ולבדיקה לנפח NFS.

    sh scripts/transfer-datasets.sh

    הסקריפט הזה מעתיק את הקבצים ממאגר קוד לדוגמה לספרייה /mnt/fileserver/datasets/ ב-Pod‏ redis-leader.

  4. מאכלסים את התור של Redis.

    sh scripts/queue-jobs.sh

    הסקריפט הזה מעביר את נתיבי הקבצים של מערכי הנתונים לאימון לרשימה בשם datasets במסד הנתונים של Redis. עומס העבודה ישתמש בתור הזה כדי לאתר את מערך הנתונים הבא לעיבוד.

  5. פורסים את השירות כדי ששרת Redis יהיה ניתן לגילוי באשכול GKE.

    kubectl apply -f ./kubernetes-manifests/redis-service.yaml

הפעלת עומס העבודה של האצווה

בשלב הזה, הכנתם את אשכול GKE, את תור העבודות של Redis ואת שיתוף הקבצים. עכשיו אפשר להריץ את עומס העבודה באצווה.

בקטע הזה משתמשים בקובץ אימג' של קונטיינר של עומס עבודה לדוגמה כדי לאמן מודל לזיהוי הונאות באמצעות אצוות של נתוני עסקאות פיננסיות. תהליך האימון יכול להיות מסוכם באופן הבא:

  1. לקוח Redis תובע בעלות על משימות (נתיבי קבצים למערכי נתונים) בתור של Redis, ומסיר אותן מהתור כשהן מסתיימות.

  2. מחלקת ניהול אימון מודלים, FraudDetectionModelTrainer, טוענת אצווה חדשה של נתונים, ואופציונלית, מצב שמור של מודל למידת מכונה. מערך הנתונים משמש לשיפור המודל (תהליך שנקרא אימון"התנעה חמה").

  3. המצב החדש של המודל ודוח עם פרטי האצווה וציוני הביצועים נשמרים בנפח Filestore NFS, שאפשר לגשת אליו באשכול GKE באמצעות PersistentVolumeClaim.

מידע נוסף זמין בקוד המקור.

הגדרת העבודה

קובץ המניפסט הבא מתאר את משימת Kubernetes עבור תמונת עומס העבודה של האצווה. ב-Kubernetes, בקר משימות יוצר פוד אחד או יותר ועוזר לוודא שהם מבצעים משימה ספציפית בהצלחה.

apiVersion: batch/v1
kind: Job
metadata:
  name: workload
spec:
  parallelism: 1
  template:
    metadata:
      name: workload
    spec:
      nodeSelector:
        cloud.google.com/gke-spot: "true"
      containers:
      - name: workload
        image: "us-docker.pkg.dev/google-samples/containers/gke/batch-ml-workload"
        volumeMounts:
        - mountPath: /mnt/fileserver
          name: workload-pvc
      volumes:
      - name: workload-pvc
        persistentVolumeClaim:
          claimName: fileserver-claim
          readOnly: false
      restartPolicy: OnFailure

פריסת עומס העבודה

  1. פריסת המשימה:

    kubectl apply -f ./kubernetes-manifests/workload.yaml

  2. בודקים אם הסטטוס של workload-XXX Pod הוא Completed:

    watch kubectl get pods

    התהליך עשוי להימשך כמה שניות. אפשר לחזור לשורת הפקודה בלחיצה על Ctrl+C.

    הפלט אמור להיראות כך:

    NAME             READY   STATUS      RESTARTS   AGE
redis-leader     1/1     Running     0          16m
workload-4p55d   0/1     Completed   0          83s

  3. בודקים את היומנים מהמשימה workload:

    kubectl logs job/workload

    הפלט אמור להיראות כך:

    Worker with sessionID: b50f9459-ce7f-4da8-9f84-0ab5c3233a72
Initial queue state: empty=False
Processing dataset: datasets/training/2018-04-04.pkl
Processing dataset: datasets/training/2018-04-03.pkl
Processing dataset: datasets/training/2018-04-02.pkl
Processing dataset: datasets/training/2018-04-01.pkl
Queue empty, exiting

    קבצי .pkl הם סריאליזציות של מערכי נתונים שמכילים קבוצה של עסקאות בכרטיסי אשראי, שמסומנות כעסקאות תקינות או כתרמיות. העבודה workload חוזרת על עצמה בקבצים האלה, פורקת את מערכי הנתונים ומשתמשת בהם כדי לאמן את מודל למידת המכונה, לפני שהיא מסירה אותם מתור Redis. עומס העבודה ממשיך לעבד את הנתונים באצוות, עד שהתור של Redis מתרוקן, ואז הוא יוצא בהצלחה.

עיון בנפח NFS

במהלך הפעולה, עומס העבודה יוצר קבצים בנפח ה-NFS המצורף, שאפשר לגשת אליהם בכל האשכול באמצעות משימות אצווה אחרות או אפליקציות אונליין.

  1. מפרטים את הקבצים שנוצרו על ידי עומס העבודה:

    kubectl exec --stdin --tty redis-leader -- /bin/sh -c "ls -1 /mnt/fileserver/output"

    הפלט צריך להיות:

    model_cpt_2018-04-01.pkl
model_cpt_2018-04-02.pkl
model_cpt_2018-04-03.pkl
model_cpt_2018-04-04.pkl
report.txt

    נקודות ביקורת למודל שאומן (שמות קבצים כמו model_cpt_XXX.pkl) ודוח על ביצועי המודל (report.txt) נוצרו בספרייה /mnt/fileserver/output בנפח האחסון של NFS.

  2. בודקים את דוח הביצועים של המודל:

    kubectl exec --stdin --tty redis-leader -- /bin/sh -c "cat /mnt/fileserver/output/report.txt"

    קטע מהפלט:

    Report generated on: 2022-02-09 14:19:42.303619
Training dataset: 2018-04-04.pkl
Model checkpoint: model_cpt_2018-04-04.pkl
---
Accuracy on training data: 0.9981112277019937
Accuracy on testing data: 0.9977204434773599

    הקובץ מכיל רשומות עם פרטים על זמן האימון, מערך הנתונים שבו נעשה שימוש, רמת הדיוק שהושגה ושם הקובץ של נקודת הבדיקה של המודל שמשויכת לאימון.

מידע נוסף על נפחי אחסון של NFS זמין במדריכים של Filestore.

הסרת המשאבים

כדי להימנע מחיובים בחשבון Google Cloud בגלל השימוש במשאבים שנעשה במסגרת המדריך הזה, אפשר למחוק את הפרויקט שמכיל את המשאבים, או להשאיר את הפרויקט ולמחוק את המשאבים בנפרד.

הסרת משאבים בודדים

כדי להסיר את המשאבים הבודדים שנוצרו במדריך הזה, מריצים את הפקודות הבאות.

  1. מחיקת האשכול:

    gcloud container clusters delete batch-aiml \
    --location=us-central1

  2. מוחקים את מופע Filestore:

    gcloud filestore instances delete batch-aiml-filestore \
    --zone=us-central1-b

מחיקת הפרויקט

  1. במסוף Google Cloud , נכנסים לדף Manage resources.

    כניסה לדף Manage resources

  2. ברשימת הפרויקטים, בוחרים את הפרויקט שרוצים למחוק ולוחצים על Delete.
  3. כדי למחוק את הפרויקט, כותבים את מזהה הפרויקט בתיבת הדו-שיח ולוחצים על Shut down.

המאמרים הבאים