چگونه Logz.io به توصیه های ML و راه حل های تشخیص ناهنجاری با Amazon SageMaker

بازنشر افلاطون

دنبال: 0

Logz.io یک شریک فناوری پیشرفته شبکه شریک AWS (APN) است شایستگی‌های AWS در DevOps، امنیت، و داده‌ها و تجزیه و تحلیل. Logz.io یک نرم‌افزار به‌عنوان یک سرویس (SaaS) پلتفرم مشاهده‌پذیری را ارائه می‌کند که بر اساس بهترین راه‌حل‌های نرم‌افزار منبع باز در کلاس برای تجزیه و تحلیل گزارش، متریک و ردیابی است. مشتریان حجم فزاینده ای از داده ها را از منابع داده های مختلف به Logz.io ارسال می کنند تا سلامت و عملکرد برنامه ها و خدمات خود را مدیریت کنند. برای کاربران جدیدی که به دنبال پیمایش در داشبوردهای مختلف ساخته شده در طول زمان، پردازش اعلان‌های هشدار مختلف و اتصال نقاط هنگام عیب‌یابی مشکلات تولید هستند، می‌تواند بسیار سخت باشد.

میانگین زمان شناسایی (MTTD) و میانگین زمان برای تفکیک (MTTR) معیارهای کلیدی برای مشتریان ما هستند. آنها با اندازه‌گیری زمانی محاسبه می‌شوند که کاربر در پلتفرم ما شروع به بررسی یک موضوع (مانند سرویس تولید پایین می‌کند) تا جایی که از انجام اقدامات مرتبط با تحقیق خاص در پلتفرم خودداری کند.

برای کمک به مشتریان در کاهش MTTD و MTTR، Logz.io به یادگیری ماشین (ML) روی آورده است تا توصیه هایی برای داشبوردها و پرس و جوهای مربوطه ارائه دهد و تشخیص ناهنجاری را از طریق خودآموزی انجام دهد. در نتیجه، کاربر معمولی به تجربه کل شرکت خود مجهز شده و از خرد بسیاری استفاده می کند. ما دریافتیم که راه حل ما می تواند MTTR را تا 20٪ کاهش دهد.

با کاهش MTTD، کاربران می توانند مشکل را شناسایی کرده و سریعتر آن را حل کنند. لایه معنایی داده ما حاوی معنایی برای شروع و توقف یک تحقیق است و میزان محبوبیت هر اقدامی که کاربر با توجه به یک هشدار خاص انجام می دهد.

در این پست نحوه استفاده از Logz.io را به اشتراک می گذاریم آمازون SageMaker برای کاهش زمان و تلاش برای اثبات مفهوم (POC)، آزمایش‌ها از تحقیق تا ارزیابی تولید، و اینکه چگونه هزینه استنتاج تولید خود را کاهش دادیم.

چالش

تا زمانی که Logz.io از SageMaker استفاده می‌کرد، زمان بین تحقیقات تا آزمایش POC و آزمایش‌ها روی تولید بسیار طولانی بود. این به این دلیل بود که برای جمع‌آوری، تمیز کردن و عادی‌سازی داده‌ها نیاز به ایجاد مشاغل Spark داشتیم. DevOps برای خواندن هر منبع داده به این کار نیاز داشت. DevOps و مهارت های مهندسی داده بخشی از تیم ML ما نیستند و این باعث وابستگی زیادی بین تیم ها شد.

چالش دیگر ارائه خدمات استنباط ML به محصولاتمان در عین دستیابی به نسبت هزینه بهینه در مقابل عملکرد بود. سناریوی بهینه ما پشتیبانی از هر چه بیشتر مدل‌های ممکن برای یک واحد محاسباتی است، در حالی که همزمانی بالایی از مشتریان با بسیاری از مدل‌ها ارائه می‌کند. ما در زمان استنتاج خود انعطاف پذیری داشتیم، زیرا پنجره اولیه جریان داده برای سرویس استنتاج 5 دقیقه سطل گزارش است.

مرحله تحقیق

علم داده یک فرآیند تکراری است که به یک محیط توسعه تعاملی برای تحقیق نیاز دارد که خروجی داده را در هر تکرار و پردازش داده تأیید می کند. بنابراین، ما محققان ML خود را به استفاده از نوت بوک تشویق می کنیم.

برای تسریع چرخه تکرار، می‌خواستیم کد نوت‌بوک‌هایمان را روی داده‌های تولید واقعی آزمایش کنیم، در حالی که آن را در مقیاس اجرا می‌کنیم. علاوه بر این، ما می‌خواستیم از تنگنای DevOps و مهندسی داده در طول آزمایش اولیه در تولید جلوگیری کنیم، در حالی که توانایی مشاهده خروجی‌ها و تلاش برای تخمین زمان اجرای کد را داریم.

برای پیاده سازی این، ما می خواستیم به تیم علم داده خود کنترل کامل و مسئولیت سرتاسری از تحقیق تا آزمایش اولیه در تولید را ارائه دهیم. ما به آنها نیاز داشتیم تا به راحتی داده ها را جمع آوری کنند، در حالی که مدیریت دسترسی به داده ها را حفظ کرده و این دسترسی را نظارت می کنیم. آنها همچنین نیاز داشتند تا نوت‌بوک‌های POC سفارشی خود را به‌صورتی مقیاس‌پذیر و در عین حال نظارت بر زمان اجرا و هزینه‌های مورد انتظار، به‌راحتی وارد تولید کنند.

مرحله ارزیابی

در طول این مرحله، ما چند پلتفرم ML را به منظور پشتیبانی از نیازهای آموزشی و خدماتی مورد ارزیابی قرار دادیم. ما دریافتیم که SageMaker برای موارد استفاده ما مناسب‌ترین است زیرا هم از آموزش و هم استنتاج پشتیبانی می‌کند. علاوه بر این، قابل تنظیم است، بنابراین ما می‌توانیم آن را مطابق با فرآیند تحقیق ترجیحی خود تنظیم کنیم.

در ابتدا از نوت بوک های محلی شروع کردیم و کتابخانه های مختلف را آزمایش کردیم. ما در استخراج داده های عظیم از تولید با مشکل مواجه شدیم. بعداً، ما در مرحله‌ای از مرحله مدل‌سازی گیر کردیم که ساعت‌ها روی یک ماشین محلی طول کشید.

ما راه حل های زیادی را ارزیابی کردیم و در نهایت معماری زیر را انتخاب کردیم:

دیتا پلیت – نسخه منبع باز از دیتا پلیت با استفاده از Spark به ما کمک کرد تا داده های خود را به راحتی جمع آوری کرده و به آنها بپیوندیم آمازون EMR خوشه ها با یک SQL ساده، در حالی که دسترسی به داده ها را نظارت می کنند
نمونه نوت بوک SageMaker و کارهای پردازش – این به ما در مقیاس‌پذیری زمان اجرا و انعطاف‌پذیری انواع ماشین‌ها و چارچوب‌های ML کمک کرد، در حالی که کدهایمان را از طریق اتصال Git با هم همکاری می‌کردیم.

معماری راه حل فاز تحقیق

نمودار زیر معماری حل فاز تحقیق را نشان می دهد و از اجزای زیر تشکیل شده است:

نوت بوک SageMaker - دانشمندان داده از اینها استفاده می کنند نوت بوک تا تحقیقات خود را انجام دهند.
عملکرد AWS Lambda - AWS لامبدا یک راه حل بدون سرور است که یک کار پردازشی را در صورت تقاضا اجرا می کند. این کار از یک ظرف Docker با نوت بوکی که می‌خواهیم در طول آزمایش خود اجرا کنیم، به همراه همه فایل‌های رایج ما که نیاز به پشتیبانی از نوت بوک دارند، استفاده می‌کند.requirements.txt و کد توابع چند پردازشی در یک نوت بوک جداگانه).
آمازون ECR - رجیستری ظروف الاستیک آمازون (Amazon ECR) ظرف داکر ما را ذخیره می کند.
کار پردازش SageMaker - ما می توانیم این را اجرا کنیم کار پردازش داده در هر ماشین ML، و نوت بوک ما را با پارامترها اجرا می کند.
دیتا پلیت – این سرویس به ما کمک می کند از SQL استفاده کنیم و به چندین منبع داده به راحتی بپیوندیم. آن را به کد Spark ترجمه می کند و آن را بهینه می کند، در حالی که دسترسی به داده ها را نظارت می کند و به کاهش نقض داده ها کمک می کند. نسخه Xtra حتی قابلیت های بیشتری را ارائه کرد.
آمازون EMR – این سرویس استخراج داده های ما را به صورت بار کاری روی Spark اجرا می کند و با تمام منابع داده ما تماس می گیرد.

با چرخه عمر نمونه نوت بوک SageMaker، می توانیم حداکثر زمان اجرا نمونه نوت بوک را با استفاده از autostop.py قالب اسکریپت

پس از آزمایش چارچوب‌های ML، هسته SageMaker MXNet را برای فازهای خوشه‌بندی و رتبه‌بندی خود انتخاب کردیم.

برای آزمایش کد نوت‌بوک روی داده‌های تولیدمان، نوت‌بوک را با کپسوله‌سازی آن از طریق Docker در Amazon ECS اجرا کردیم و آن را به عنوان یک کار پردازشی برای اعتبارسنجی حداکثر زمان اجرا در انواع مختلف ماشین‌ها اجرا کردیم.

ظرف Docker همچنین به ما کمک می کند تا منابع را در بین تست های نوت بوک به اشتراک بگذاریم. در برخی موارد، یک نوت‌بوک نوت‌بوک‌های دیگر را فراخوانی می‌کند تا با تقسیم فریم‌های داده‌های بزرگ به فریم‌های داده کوچک‌تر، که می‌توانند به طور همزمان روی هر vCPU در یک نوع ماشین بزرگ اجرا شوند، از یک فرآیند چندگانه استفاده کنند.

راه حل استنتاج تولید بلادرنگ

در مرحله تحقیق از پارکت استفاده کردیم سرویس ذخیره سازی ساده آمازون فایل های (Amazon S3) برای حفظ توصیه های ما. اینها یک بار در روز از خط لوله مهندسی ما مصرف می شوند تا توصیه ها را به مکانیسم هشدارهای ما متصل کنیم.

با این حال، نقشه راه ما به یک راه حل با نرخ تازه سازی بالاتر نیاز دارد و کشیدن یک بار در روز در دراز مدت کافی نیست، زیرا ما می خواهیم حتی در حین بررسی توصیه هایی ارائه کنیم.

برای پیاده سازی این راه حل در مقیاس، ما اکثر راه حل های نقطه پایانی SageMaker را در تحقیقات تشخیص ناهنجاری خود آزمایش کردیم. ما 500 مدل از پیش ساخته شده را با یک ماشین نقطه پایانی از انواع مختلف آزمایش کردیم و از کلاینت های چند رشته ای همزمان برای انجام درخواست ها به نقطه پایانی استفاده کردیم. ما زمان پاسخ، CPU، حافظه و سایر معیارها را اندازه‌گیری کردیم (برای اطلاعات بیشتر، رجوع کنید به Amazon SageMaker را با Amazon CloudWatch مانیتور کنید). ما دریافتیم که نقطه پایانی چند مدلی برای موارد استفاده ما مناسب است.

یک نقطه پایانی چند مدلی می‌تواند هزینه‌های ما را در مقایسه با یک نقطه پایانی یا حتی Kubernetes برای استفاده از سرویس‌های وب Flask (یا سایر Python) کاهش دهد. اولین فرض ما این بود که باید یک نقطه پایانی واحد را با استفاده از یک ماشین کوچک 4-vCPU برای هر مشتری ارائه دهیم، و به طور متوسط چهار مدل اختصاصی را جستجو کنیم، زیرا هر vCPU یک مدل را ارائه می دهد. با نقطه پایانی چند مدلی، می‌توانیم مشتریان بیشتری را در یک دستگاه چند نقطه پایانی جمع کنیم.

ما به ازای هر مشتری یک مدل و فایل های رمزگذاری داشتیم و پس از انجام تست های بارگذاری، مشخص کردیم که می توانیم به 50 مشتری خدمات ارائه دهیم که هر کدام از 10 مدل و حتی از کوچکترین نمونه ml.t2.medium برای راه حل های خود استفاده می کنند.

در این مرحله استفاده را در نظر گرفتیم نقاط پایانی چند مدلی. نقاط پایانی چند مدل راه حلی مقیاس پذیر و مقرون به صرفه برای استقرار تعداد زیادی مدل ارائه می دهند و شما را قادر می سازند چندین مدل را با یک ظرف استنتاج واحد میزبانی کنید. این امر با بهبود استفاده از نقطه پایانی در مقایسه با استفاده از چندین نقطه پایانی کوچک تک مدلی که هر کدام به یک مشتری خدمت می کنند، هزینه های میزبانی را کاهش می دهد. همچنین سربار استقرار را کاهش می دهد زیرا SageMaker بارگذاری مدل ها را در حافظه مدیریت می کند و آنها را بر اساس الگوهای ترافیکی به آنها مقیاس می دهد.

علاوه بر این، مزیت نقطه پایانی چند مدل این است که اگر نرخ استنتاج بالایی از مشتریان خاص داشته باشید، چارچوب آن آخرین مدل‌های سرویس را برای عملکرد بهتر در حافظه حفظ می‌کند.

پس از برآورد هزینه‌ها با استفاده از نقاط پایانی چند مدل در مقابل نقاط پایانی استاندارد، متوجه شدیم که به طور بالقوه می‌تواند منجر به کاهش تقریباً 80 درصدی هزینه شود.

نتیجه

در این بخش به بررسی مراحل و نتیجه فرآیند می پردازیم.

ما از پیکربندی نوت بوک چرخه حیات برای فعال کردن نوت بوک ها به عنوان کارهای پردازشی استفاده می کنیم، با کپسوله کردن نوت بوک در یک ظرف Docker به منظور اعتبارسنجی سریعتر کد و استفاده از مکانیسم توقف خودکار:

#!/bin/bash # Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
#
# Licensed under the Apache License, Version 2.0 (the "License"). You
# may not use this file except in compliance with the License. A copy of
# the License is located at
#
# http://aws.amazon.com/apache2.0/
#
# or in the "license" file accompanying this file. This file is
# distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF
# ANY KIND, either express or implied. See the License for the specific
# language governing permissions and limitations under the License. set -e # OVERVIEW
# This script installs the sagemaker_run_notebook extension package in SageMaker Notebook Instance
#
# There are two parameters you need to set:
# 1. S3_LOCATION is the place in S3 where you put the extension tarball
# 2. TARBALL is the name of the tar file that you uploaded to S3. You should just need to check
# that you have the version right.
sudo -u ec2-user -i <<'EOF'
# PARAMETERS
VERSION=0.18.0
EXTENSION_NAME=sagemaker_run_notebook
# Set up the user setting and workspace directories
mkdir -p /home/ec2-user/SageMaker/.jupyter-user/{workspaces,user-settings}
# Run in the conda environment that the Jupyter server uses so that our changes are picked up
source /home/ec2-user/anaconda3/bin/activate JupyterSystemEnv
# Install the extension and rebuild JupyterLab so it picks up the new UI
aws s3 cp s3://aws-emr-resources-11111111-us-east-1/infra-sagemaker/sagemaker_run_notebook-0.18.0-Logz-latest.tar.gz ./sagemaker_run_notebook-0.18.0-Logz-latest.tar.gz
pip install sagemaker_run_notebook-0.18.0-Logz-latest.tar.gz jupyter lab build
source /home/ec2-user/anaconda3/bin/deactivate
EOF # sudo -u ec2-user -i <<'EOF'
# PARAMETERS
for PACKAGE in pandas dataplate awswrangler==2.0.0 ipynb==0.5.1 prison==0.1.3 PyMySQL==0.10.1 requests==2.25.0 scipy==1.5.4 dtaidistance joblib sagemaker_run_notebook-0.18.0-Logz-latest.tar.gz fuzzywuzzy==0.18.0; do echo $PACKAGE # Note that "base" is special environment name, include it there as well. for env in base /home/ec2-user/anaconda3/envs/*; do source /home/ec2-user/anaconda3/bin/activate $(basename "$env") if [ $env = 'JupyterSystemEnv' ]; then continue fi pip install --upgrade "$PACKAGE" source /home/ec2-user/anaconda3/bin/deactivate done
done
jupyter lab build # Tell Jupyter to use the user-settings and workspaces directory on the EBS
# volume.
echo "export JUPYTERLAB_SETTINGS_DIR=/home/ec2-user/SageMaker/.jupyter-user/user-settings" >> /etc/profile.d/jupyter-env.sh
echo "export JUPYTERLAB_WORKSPACES_DIR=/home/ec2-user/SageMaker/.jupyter-user/workspaces" >> /etc/profile.d/jupyter-env.sh # The Jupyter server needs to be restarted to pick up the server part of the
# extension. This needs to be done as root.
initctl restart jupyter-server --no-wait # OVERVIEW
# This script stops a SageMaker notebook once it's idle for more than 2 hour (default time)
# You can change the idle time for stop using the environment variable below.
# If you want the notebook the stop only if no browsers are open, remove the --ignore-connections flag
#
# Note that this script will fail if either condition is not met
# 1. Ensure the Notebook Instance has internet connectivity to fetch the example config
# 2. Ensure the Notebook Instance execution role permissions to SageMaker:StopNotebookInstance to stop the notebook
# and SageMaker:DescribeNotebookInstance to describe the notebook.
# PARAMETERS
IDLE_TIME=3600 echo "Fetching the autostop script"
wget https://raw.githubusercontent.com/aws-samples/amazon-sagemaker-notebook-instance-lifecycle-config-samples/master/scripts/auto-stop-idle/autostop.py echo "Starting the SageMaker autostop script in cron" (crontab -l 2>/dev/null; echo "*/5 * * * * /usr/bin/python $PWD/autostop.py --time $IDLE_TIME --ignore-connections") | crontab -

ما کلون می کنیم Sagemaker-Run-Notebook پروژه GitHub را انجام دهید و موارد زیر را به ظرف اضافه کنید:

مورد نیاز پیپ ما
توانایی اجرای نوت‌بوک‌ها از داخل یک نوت‌بوک، که ما را قادر می‌سازد رفتار چند پردازشی را برای استفاده از تمام هسته‌های نمونه ml.m5.12x بزرگ انجام دهیم.

این ما را قادر می‌سازد تا گردش‌های کاری را اجرا کنیم که شامل بسیاری از نوت‌بوک‌هایی است که به‌عنوان کارهای پردازشی در یک خط کد اجرا می‌شوند، در حالی که نوع نمونه‌ای را برای اجرا تعریف می‌کنیم.

از آنجایی که می‌توانیم پارامترهایی را به نوت‌بوک اضافه کنیم، می‌توانیم پردازش خود را با اجرای همزمان در ساعت‌ها، روزها یا ماه‌های مختلف برای جمع‌آوری و پردازش داده‌ها، مقیاس‌بندی کنیم.

همچنین می‌توانیم کارهای زمان‌بندی ایجاد کنیم که نوت‌بوک‌ها را اجرا می‌کنند (و حتی زمان اجرا را محدود می‌کنند).

ما همچنین می توانیم آخرین اجراها و جزئیات آنها مانند زمان پردازش را مشاهده کنیم.

با آسیاب کاغذی که در ظرف استفاده می شود، می توانیم خروجی هر اجرا را مشاهده کنیم، که به ما در رفع اشکال در تولید کمک می کند.

بررسی خروجی نوت بوک ما به شکل یک نوت بوک استاندارد فقط خواندنی است.

استفاده از چند پردازش به ما کمک می کند تا در پردازش هر نوت بوک مقیاس کنیم و از تمام هسته های آن استفاده کنیم. ما توابعی را در نوت‌بوک‌های دیگری ایجاد کردیم که می‌توانند پردازش سنگین انجام دهند، مانند موارد زیر:

JSON ها را منفجر کنید
در حالی که نوت بوک اصلی DataFrame را به دو قسمت تقسیم می کند، ردیف های مرتبط را در یک DataFrame پیدا کنید #cpu-cores عناصر
خوشه‌بندی را برای هر نوع هشدار به‌طور همزمان اجرا کنید

سپس این نوت بوک های کاربردی را به ظرفی اضافه می کنیم که نوت بوک را به عنوان یک کار پردازشی اجرا می کند. فایل Docker زیر را ببینید (به دستورات COPY توجه کنید):

ARG BASE_IMAGE=need_an_image
FROM $BASE_IMAGE ENV JUPYTER_ENABLE_LAB yes
ENV PYTHONUNBUFFERED TRUE COPY requirements.txt /tmp/requirements.txt
RUN pip install papermill jupyter nteract-scrapbook boto3 requests==2.20.1
RUN pip install -r /tmp/requirements.txt ENV PYTHONUNBUFFERED=TRUE
ENV PATH="/opt/program:${PATH}" # Set up the program in the image
COPY multiprocessDownloadNormalizeFunctions.ipynb /tmp/multiprocessDownloadNormalizeFunctions.ipynb
COPY multiprocessFunctions.ipynb /tmp/multiprocessFunctions.ipynb
COPY run_notebook execute.py /opt/program/
ENTRYPOINT ["/bin/bash"] # because there is a bug where you have to be root to access the directories
USER root

نتایج

در طول مرحله تحقیق، گزینه اجرای نوت‌بوک‌هایمان را به‌عنوان آزمایش و ارزیابی نحوه عملکرد کد ما بر روی همه داده‌های مرتبط، نه فقط نمونه‌ای از داده‌ها، ارزیابی کردیم. ما متوجه شدیم که کپسوله کردن نوت‌بوک‌هایمان با استفاده از کارهای پردازشی می‌تواند برای ما مناسب باشد، زیرا نیازی به بازنویسی کد نداریم و می‌توانیم از قدرت نمونه‌های بهینه‌سازی شده و حافظه بهینه‌شده AWS استفاده کنیم و وضعیت فرآیند را به راحتی دنبال کنیم.

در طول ارزیابی استنتاج، ما راه‌حل‌های مختلف نقطه پایانی SageMaker را ارزیابی کردیم. ما متوجه شدیم که استفاده از یک نقطه پایانی چند مدلی می‌تواند به ما کمک کند به تقریباً 50 مشتری خدمت کنیم، که هر کدام دارای چندین مدل (تقریباً 10) در یک نمونه هستند، که می‌تواند محدودیت‌های تأخیر کم ما را برآورده کند و بنابراین تا 80 درصد از هزینه ما صرفه‌جویی کند. .

با این معماری راه حل، ما توانستیم MTTR مشتریان خود را کاهش دهیم، که معیار اصلی برای سنجش موفقیت با استفاده از پلتفرم ما است. کل زمان را از نقطه پاسخگویی به پیوند هشدار ما، که مشکلی را در سیستم‌های شما شرح می‌دهد، تا زمانی که بررسی مشکل با استفاده از پلتفرم ما به پایان رسید، کاهش می‌دهد. در طول مرحله بررسی، اقدامات کاربران را با و بدون راه حل توصیه ML خود اندازه گیری می کنیم. این به ما کمک می‌کند تا توصیه‌هایی برای بهترین اقدام برای حل سریع‌تر مشکل خاص و مشخص کردن ناهنجاری‌ها برای شناسایی علت واقعی مشکل ارائه دهیم.

نتیجه گیری و مراحل بعدی

در این پست، نحوه استفاده Logz.io از SageMaker برای بهبود MTTD و MTTR را به اشتراک گذاشتیم.

به عنوان گام بعدی، ما در حال توسعه راه حل با ویژگی های زیر هستیم:

ما شما را تشویق می کنیم که امتحان کنید نوت بوک SageMaker. برای مثال های بیشتر، بررسی کنید SageMaker مخزن GitHub را مثال می‌زند.

درباره نویسنده

آمیت گراس بخش تحقیقات Logz.io را رهبری می‌کند، که مسئولیت راه‌حل‌های هوش مصنوعی همه محصولات Logz.io، از مرحله تحقیقات تا مرحله یکپارچه‌سازی را بر عهده دارد. قبل از Logz.io، آمیت هر دو گروه تحقیقاتی علم داده و امنیت را در Here inc مدیریت کرده است. و Cellebrite Inc. آمیت دارای مدرک کارشناسی ارشد در علوم کامپیوتر از دانشگاه تل آویو است.

یانیو واکنین یک متخصص یادگیری ماشین در خدمات وب آمازون است. قبل از AWS، Yaniv سمت‌های رهبری را با استارت‌آپ‌های هوش مصنوعی و Enterprise از جمله بنیانگذار و مدیر عامل Dipsee.ai داشت. Yaniv با مشتریان AWS کار می کند تا از قدرت یادگیری ماشین برای حل وظایف دنیای واقعی و استخراج ارزش استفاده کند. یانیو در اوقات فراغت خود از بازی فوتبال با پسرانش لذت می برد.

ایتان سلا یک معمار راه حل های متخصص یادگیری ماشین با خدمات وب آمازون است. او با مشتریان AWS برای ارائه راهنمایی و کمک فنی کار می کند و به آنها کمک می کند راه حل های یادگیری ماشینی را در AWS بسازند و کار کنند. ایتان در اوقات فراغت خود از دویدن و خواندن جدیدترین مقالات یادگیری ماشین لذت می برد.