Hoe Imperva de ontwikkeling en samenwerking van ML versnelt via Amazon SageMaker-notebooks

Dit is een gastpost van Imperva, een leverancier van oplossingen voor cybersecurity. 

Imperva is een leider op het gebied van cyberbeveiliging, met hoofdkantoor in Californië, VS, wiens missie het is om gegevens en alle paden ernaartoe te beschermen. De afgelopen jaren hebben we gewerkt aan de integratie van machine learning (ML) in onze producten. Dit omvat het detecteren van kwaadaardige activiteiten in databases, het automatisch configureren van beveiligingsbeleid en het clusteren van beveiligingsgebeurtenissen in betekenisvolle verhalen.

Terwijl we onze detectiemogelijkheden willen verbeteren, investeren we in ML-modellen voor onze oplossingen. Imperva biedt bijvoorbeeld een API Security-service. Deze service is bedoeld om alle API's te beschermen tegen verschillende aanvallen, inclusief aanvallen die traditionele WAF niet gemakkelijk kunnen stoppen, zoals beschreven in de OWASP-top 10. Dit is een belangrijk investeringsgebied voor ons, dus hebben we stappen ondernomen om ons ML-ontwikkelingsproces te versnellen, zodat we meer terrein kunnen bestrijken, API-aanvallen efficiënt kunnen onderzoeken en ons vermogen kunnen vergroten om waarde voor onze klanten te leveren.

In dit bericht delen we hoe we de ML-ontwikkeling en samenwerking hebben versneld via Amazon Sage Maker notitieboekjes.

Jupyter Notebooks: het gemeenschappelijke onderzoeksterrein

Onderzoeksprocessen op het gebied van datawetenschap hebben de aandacht van grote technologiebedrijven en de ontwikkelingsgemeenschap naar nieuwe hoogten getild. Het is nu eenvoudiger dan ooit om een ​​datagestuurd project te starten met behulp van beheerde ML-services. Een mooi voorbeeld hiervan is de opkomst van burgerdatawetenschappers, die volgens Gartner zijn “krachtige gebruikers die zowel eenvoudige als redelijk geavanceerde analytische taken kunnen uitvoeren waarvoor voorheen meer expertise nodig was.”

Met de verwachte groei van ML-gebruikers wordt het delen van experimenten tussen teams een cruciale parameter in de ontwikkelingssnelheid. Een van de belangrijkste stappen voor datawetenschappers die een project starten, is onder meer het openen van een nieuwe Jupyter-notebook en het aangaan van de uitdaging die voor ons ligt.

Jupyter-notebooks zijn een kruising tussen een IDE en een document. Het biedt de onderzoeker een gemakkelijke en interactieve manier om verschillende benaderingen te testen, de resultaten in kaart te brengen, te presenteren en te exporteren, terwijl hij een taal en interface naar keuze gebruikt, zoals Python, R, Spark, Bash of andere.

Amazon SageMaker is een volledig beheerde service die elke ontwikkelaar en datawetenschapper de mogelijkheid biedt om ML te bouwen, trainen en implementeren. SageMaker bevat deze exacte mogelijkheid en meer als onderdeel van de SageMaker-notebookfunctie.

Iedereen die Jupyter Notebooks in een team heeft geprobeerd te gebruiken, heeft waarschijnlijk een punt bereikt waarop ze een notebook van iemand anders probeerden te gebruiken, om er vervolgens achter te komen dat dit niet zo eenvoudig is als het klinkt. Vaak heeft u gewoon geen toegang tot het benodigde notebook. Bij andere gelegenheden worden notebooks lokaal gebruikt voor onderzoek, en dus is de code vaak bezaaid met hardgecodeerde paden en is deze niet vastgelegd in een opslagplaats. Zelfs als de code in een of andere repository is vastgelegd, worden de benodigde gegevens (hopelijk) niet vastgelegd. Kortom: het is niet eenvoudig om met Jupyter Notebooks samen te werken.

In dit bericht laten we u zien hoe we datawetenschappelijke onderzoekscode delen bij Imperva, en hoe we SageMaker-notebooks gebruiken met extra functies die we hebben toegevoegd om onze aangepaste vereisten te ondersteunen en de samenwerking te verbeteren. We delen ook hoe al deze inspanningen hebben geleid tot een aanzienlijke vermindering van de kosten en de tijd die aan het huishouden wordt besteed. Hoewel deze architectuur goed bij ons past, kunt u verschillende configuraties kiezen, zoals volledige resource-isolatie met een afzonderlijk bestandssysteem voor elke gebruiker.

Hoe we onze ML-ontwikkeling hebben versneld

Onze workflow is vrij standaard: we nemen een subset van gegevens, laden deze in een Jupyter-notebook en beginnen de gegevens te verkennen. Nadat we de gegevens goed hebben begrepen, beginnen we te experimenteren en verschillende algoritmen te combineren totdat we met een goede eerste oplossing komen. Wanneer we een proof of concept (POC) hebben die goed genoeg is, gaan we verder met het valideren van de resultaten in de loop van de tijd, terwijl we experimenteren en het algoritme aanpassen. Uiteindelijk, als we een hoog niveau van vertrouwen bereiken, wij leveren het model en ga door met het valideren van de resultaten.

In eerste instantie was dit proces volkomen logisch. We hadden kleine projecten waarvoor niet veel rekenkracht nodig was, en we hadden genoeg tijd om er solo aan te werken totdat we een POC bereikten. De projecten waren voor ons eenvoudig genoeg om het model zelf te implementeren, te bedienen en te monitoren, of in andere gevallen het model als Docker-container te leveren. Als prestaties en schaal belangrijk waren, gaven we het eigendom van het model over aan een ontwikkelteam met behulp van een specificatiedocument met pseudocode. Maar de tijden veranderen en naarmate het team en de projecten groeiden en zich ontwikkelden, hadden we een betere manier nodig om dingen te doen. We moesten onze projecten opschalen toen er enorme computerbronnen nodig waren, en een betere manier vinden om het eigendom over te dragen zonder gebruik te maken van saaie en uitgebreide specificatiedocumenten.

Bovendien, wanneer iedereen een externe virtuele machine gebruikt of Amazon Elastic Compute-cloud (Amazon EC2) om hun Jupyter-notebooks uit te voeren, hebben hun projecten de neiging documentatie te missen en rommelig te worden.

SageMaker-notitieboekjes

SageMaker-notebooks komen binnen: een beheerd Jupyter Notebooks-platform dat wordt gehost op AWS, waar u eenvoudig een notebook-instantie kunt maken: een EC2-instantie (virtuele computer) waarop een Jupyter Notebooks-server draait. Naast dat de notebook zich nu in de cloud bevindt en overal toegankelijk is, kunt u de notebookinstantie eenvoudig opnieuw schalen, zodat u over zoveel computerbronnen beschikt als u nodig heeft.

Het hebben van onbeperkte computerbronnen is geweldig, maar dat was niet de reden waarom we besloten om SageMaker-notebooks te gaan gebruiken. We kunnen de doelstellingen die we wilden bereiken samenvatten in drie hoofdpunten:

• Onderzoek makkelijker maken – Het creëren van een gemakkelijke, gebruiksvriendelijke werkomgeving die snel toegankelijk is en gedeeld kan worden binnen het onderzoeksteam.
• Gegevens en code organiseren – Het verminderen van de rommel door het gemakkelijker te maken om toegang te krijgen tot gegevens en een gestructureerde manier te creëren om code te bewaren.
• Het opleveren van projecten – Het creëren van een betere manier om onderzoeksspeeltuin en productie te scheiden, en het vinden van een betere manier om onze ideeën met ontwikkelingsteams te delen zonder gebruik te maken van uitgebreide, saaie documenten.

Makkelijker onderzoek

SageMaker-notebooks bevinden zich in de cloud, waardoor ze vrijwel overal toegankelijk zijn. Het starten van een Jupyter-notebook duurt slechts een paar minuten en al uw uitvoer van de vorige run wordt opgeslagen, waardoor het heel eenvoudig is om er meteen weer in te springen. Onze onderzoeksvereisten omvatten echter een aantal aanvullende aspecten waarvoor een oplossing nodig was:

• Snelle weergaven – Het te allen tijde beschikbaar hebben van de notebooks om de resultaten van eerdere runs te bekijken. Als de instantie waarin u uw code bewaart, niet beschikbaar is, moet u deze starten om alleen naar de uitvoer te kijken. Dit kan frustrerend zijn, vooral als u een dure instance gebruikt en alleen maar naar uw resultaten wilt kijken. Hierdoor werd de tijd die elk teamlid moest besteden aan het wachten tot de instantie startte, teruggebracht van 5 tot 15 minuten naar 0.
• Gedeelde opvattingen – De mogelijkheid hebben om notebooks met meerdere exemplaren te verkennen. SageMaker-notebookinstanties worden standaard voorzien van speciale opslag. We wilden deze muur doorbreken en het team in staat stellen samen te werken.
• Persistente bibliotheken – Bibliotheken worden tijdelijk opgeslagen in SageMaker-notebookinstanties. We wilden dit veranderen om de tijd die nodig is om alle vereiste bibliotheken volledig te installeren, te verkorten en met 100% te verkorten, van ongeveer 5 minuten naar 0.
• Kosteneffectieve dienstverlening – Het optimaliseren van de kosten en het minimaliseren van de betrokkenheid van onderzoekers. Standaard wordt het in- en uitschakelen van een instance handmatig gedaan. Dit kan leiden tot onnodige kosten als gevolg van menselijke fouten.

Om de kloof te overbruggen tussen de standaard SageMaker-configuratie en wat we zochten, hebben we slechts twee hoofdingrediënten gebruikt: Amazon elastisch bestandssysteem (Amazon EFS) en levenscyclus configuratie in SalieMaker. De eerste is, zoals de naam al aangeeft, een bestandssysteem, en de tweede is in feite een stukje code dat wordt uitgevoerd wanneer de notebook wordt gestart of voor het eerst wordt gemaakt.

Gedeelde en snelle weergaven

We hebben dit bestandssysteem met al onze notebookinstanties verbonden, zodat ze allemaal een gedeeld bestandssysteem hebben. Op deze manier kunnen we onze code opslaan in Amazon EFS, in plaats van het bestandssysteem van de notebookinstantie te gebruiken, en er toegang toe krijgen vanaf elke notebookinstantie.

Dit maakte de zaken eenvoudiger omdat we nu een alleen-lezen, kleine, supergoedkope notebook-instantie kunnen maken (laten we dit voor dit bericht de viewer-instantie noemen) die altijd aan blijft, en deze kunnen gebruiken om eenvoudig toegang te krijgen tot code en resultaten zonder te hoeven starten de notebookinstantie waarop de code is uitgevoerd. Bovendien kunnen we nu gemakkelijk code onderling delen, omdat deze op een gedeelde locatie wordt opgeslagen in plaats van in meerdere verschillende notebookinstanties te worden bewaard.

Dus, hoe verbind je eigenlijk een bestandssysteem met een notebookinstantie?

We hebben een levenscyclusconfiguratie gemaakt die een EFS verbindt met een notebookinstantie, en deze configuratie hebben we gekoppeld aan elke notebookinstantie waarvan we wilden dat deze deel uitmaakte van de gedeelde omgeving.

In deze sectie leiden we u door het levenscyclusconfiguratiescript dat we hebben geschreven, of om preciezer te zijn: we hebben schaamteloos gebruik gemaakt van de voorbeelden van AWS en deze samengevoegd.

Het volgende scriptvoorvoegsel is een standaardboilerplate:

#!/bin/bash
set -e

Nu verbinden we de notebook met een EFS. Zorg ervoor dat u de naam van de EFS-instantie kent:

EFS_NAME=EFS_INSTANCE_NAME.efs.REGION.amazonaws.com
mkdir -p /home/ec2-user/SageMaker/efs
sudo mount -t nfs4 -o nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport $EFS_NAME:/ /home/ec2-user/SageMaker/efs
sudo chmod go+rw /home/ec2-user/SageMaker/efs

Duurzame en kosteneffectieve service

Nadat we het bestandssysteem hadden aangesloten, begonnen we na te denken over het werken met notebooks. Omdat AWS kosten in rekening brengt voor elk uur dat de instantie actief is, hebben we besloten dat het een goede gewoonte zou zijn om de SageMaker-notebook automatisch uit te schakelen als deze een tijdje niet wordt gebruikt. We zijn begonnen met een standaardwaarde van 1 uur, maar door de tags van de instantie te gebruiken, konden gebruikers elke gewenste waarde instellen vanuit de SageMaker GUI. Het toepassen van de standaardconfiguratie van 1 uur kan worden gedefinieerd als globale levenscyclusconfiguratie, en het overschrijven ervan kan worden gedefinieerd als lokale levenscyclusconfiguratie. Dit beleid voorkwam effectief dat onderzoekers per ongeluk ongebruikte instances achterlieten, waardoor de kosten van SageMaker-instances met 25% werden verlaagd.

# get instance tags location
NOTEBOOK_ARN=$(jq '.ResourceArn' /opt/ml/metadata/resource-metadata.json --raw-output) # extract idle time parameter value from tags list
IDLE_TIME=$(aws sagemaker list-tags --resource-arn $NOTEBOOK_ARN | jq '.Tags[] | select(.Key=="idle") | .Value') # in case idle time not specified set to one hour (3600 sec) [[ -z "$IDLE_TIME" ]] && IDLE_TIME=3600 # fetch the auto stop script from AWS samples repo
wget https://raw.githubusercontent.com/aws-samples/amazon-sagemaker-notebook-instance-lifecycle-config-samples/master/scripts/auto-stop-idle/autostop.py # 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 - sudo -u ec2-user -i <<'EOF'
unset SUDO_UID

De notebook is nu dus verbonden met Amazon EFS en wordt automatisch uitgeschakeld als deze niet wordt gebruikt. Maar dit bracht een ander probleem met zich mee: Python-bibliotheken in SageMaker-notebookinstanties worden standaard geïnstalleerd in de kortstondige opslag, wat betekent dat ze worden verwijderd wanneer de instantie wordt gestopt en opnieuw moeten worden geïnstalleerd de volgende keer dat de instantie wordt gestart. Dit betekent dat we bibliotheken minstens één keer per dag opnieuw moeten installeren, wat niet de beste ervaring is en per pakket enkele seconden tot enkele minuten kan duren. We hebben besloten een script toe te voegen dat dit gedrag verandert en ervoor zorgt dat alle bibliotheekinstallaties persistent zijn door het installatiepad van de Python-bibliotheek te wijzigen naar de opslag van de notebookinstantie (Amazon elastische blokwinkel), elimineerde effectief elke tijdverspilling bij het opnieuw installeren van pakketten.

Dit script wordt elke keer uitgevoerd wanneer de notebookinstantie start, miniconda en enkele standaard Python-bibliotheken in de permanente opslag installeert en miniconda activeert:

# use an address within the notebook instance’s file system
WORKING_DIR=/home/ec2-user/SageMaker/custom-miniconda
# if this is the first time the lifecycle config is running - install miniconda
if [ ! -d "$WORKING_DIR" ]; then mkdir -p "$WORKING_DIR" # download miniconda wget https://repo.anaconda.com/miniconda/Miniconda3-latest-Linux-x86_64.sh -O "$WORKING_DIR/miniconda.sh" # install miniconda bash "$WORKING_DIR/miniconda.sh" -b -u -p "$WORKING_DIR/miniconda" # delete miniconda installer rm -rf "$WORKING_DIR/miniconda.sh" # create a custom conda environment source "$WORKING_DIR/miniconda/bin/activate" KERNEL_NAME="custom_python" PYTHON="3.9" conda create --yes --name "$KERNEL_NAME" python="$PYTHON" conda activate "$KERNEL_NAME" pip install --quiet ipykernel conda install --yes numpy pip install --quiet boto3 pandas matplotlib sklearn dill EOF
fi
# activate miniconda
source "$WORKING_DIR/miniconda/bin/activate"
for env in $WORKING_DIR/miniconda/envs/*; do BASENAME=$(basename "$env") source activate "$BASENAME" python -m ipykernel install --user --name "$BASENAME" --display-name "Custom ($BASENAME)"
Done # disable SageMaker-provided Conda functionality, leaving in only what we've installed
echo "c.EnvironmentKernelSpecManager.use_conda_directly = False" >> /home/ec2-user/.jupyter/jupyter_notebook_config.py
rm /home/ec2-user/.condarc
EOF

Snel opnieuw opstarten en we zijn klaar!

# restart the Jupyter server
restart jupyter-server

Gegevens- en code-organisatie

Herinner je je de EFS nog waar we het zojuist over hadden? Het is hier voor meer.

Nadat we al onze code op dezelfde locatie hadden opgeslagen, dachten we dat het misschien beter zou zijn om het een beetje te ordenen.

We hebben besloten dat elk teamlid zijn eigen notebookinstantie moet maken die alleen zij gebruiken. In plaats van het bestandssysteem van de instantie te gebruiken, gebruiken we echter Amazon EFS en implementeren we de volgende hiërarchie:

---Teamlid

—————-Project

--------code

-----------bronnen

Zo kunnen we allemaal makkelijk bij elkaars code, maar weten we toch wat van wie is.

Maar hoe zit het met afgeronde projecten? We hebben besloten een extra tak toe te voegen voor projecten die volledig gedocumenteerd en opgeleverd zijn:

---Teamlid

—————-Project

--------code

-----------bronnen

---Afgemaakte projecten

—————-Project

--------code

-----------bronnen

Dus nu onze code netjes is georganiseerd, hoe krijgen we toegang tot onze gegevens?

Wij bewaren onze gegevens Amazon eenvoudige opslagservice (Amazon S3) en krijg toegang via Amazone Athene. Dit maakte het heel eenvoudig om een ​​rol in te stellen voor onze notebookinstanties met toegangsrechten tot Athena en Amazon S3. Op deze manier kunnen we, door simpelweg een paar regels code te gebruiken, en zonder te rommelen met inloggegevens, gemakkelijk Athena bevragen en gegevens ophalen om aan te werken.

Bovendien hebben we een speciaal netwerk gecreëerd met behulp van Amazon virtuele privécloud (Amazon VPC), waardoor de notebookinstanties toegang kregen tot onze interne Git-repository en privé PyPI-repository. Dit maakte het gemakkelijk om toegang te krijgen tot nuttige interne code en pakketten. Het volgende diagram laat zien hoe het er allemaal uitziet op ons notebookplatform.

Verzending

Tot slot: hoe gebruiken we deze notebooks om projecten eenvoudig op te leveren?

Een van de geweldige dingen van Jupyter-notebooks is dat je, naast het schrijven van code en het weergeven van de uitvoer, eenvoudig tekst en koppen kunt toevoegen, waardoor een interactief document ontstaat.

In de volgende paar regels beschrijven we onze leveringsprocessen wanneer we het model overdragen aan een ontwikkelteam en wanneer we het model zelf implementeren.

Bij projecten waarbij schaal, prestaties en betrouwbaarheid hoge prioriteit hebben, dragen we het model over om te worden herschreven door een ontwikkelteam. Nadat we een volwassen POC hebben bereikt, delen we de notebook met de ontwikkelaars die aan het project zijn toegewezen met behulp van de eerder genoemde alleen-lezen notebookinstantie.

De ontwikkelaars kunnen nu het document lezen, de invoer en uitvoer voor elk codeblok bekijken en een beter inzicht krijgen in hoe het werkt en waarom, waardoor het voor hen gemakkelijker te implementeren is. In het verleden moesten we voor dit soort gevallen een specificatiedocument schrijven, wat in feite betekent dat de code werd herschreven als pseudocode met veel commentaar en uitleg. Nu konden we onze opmerkingen en uitleg eenvoudig integreren in het SageMaker-notebook, wat voor elk project vele dagen werk bespaarde.

Bij projecten waarvoor geen ontwikkelteam nodig is om de code te herschrijven, reorganiseren we de code in een Docker-container en implementeren we deze in een Kubernetes-cluster. Hoewel het misschien een gedoe lijkt om code van een notebook om te zetten in een Dockerized, standaard Python-project, heeft dit proces zijn eigen voordelen:

• Uitlegbaarheid en zichtbaarheid – In plaats van uit te leggen wat je algoritme doet door door je rommelige project te duiken, kun je gewoon het notitieboekje gebruiken waaraan je tijdens de onderzoeksfase hebt gewerkt.
• Doel scheiding – De onderzoekscode bevindt zich in het notitieboekje en de productiecode bevindt zich in het Python-project. Je kunt blijven onderzoeken zonder de productiecode aan te raken en deze pas bijwerken als je een doorbraak hebt gehad.
• Foutopsporing – Als uw model problemen ondervindt, kunt u deze eenvoudig in de notebook debuggen.

Wat is het volgende

Jupyter-notebooks bieden een geweldige speeltuin voor datawetenschappers. Op kleinere schaal is het erg handig om op uw lokale computer te gebruiken. Wanneer u echter in grotere teams aan grotere projecten gaat werken, zijn er veel voordelen verbonden aan de overstap naar een beheerde Jupyter Notebooks-server. Het mooie van SageMaker-notebooks is dat u uw notebook-instanties kunt aanpassen, zoals de instantiegrootte, het delen van code en automatiseringsscripts, kernelselectie en meer, waardoor u enorme hoeveelheden tijd en geld kunt besparen.

Simpel gezegd hebben we een proces gecreëerd dat de ML-ontwikkeling en samenwerking versnelt, terwijl de kosten van SageMaker-notebooks met minstens 25% worden verlaagd en de overheadtijd wordt verminderd die onderzoekers besteden aan installaties en wachten tot instances klaar zijn om te werken.

Onze huidige SageMaker-notebookomgeving bevat het volgende:

• Beheerde Jupyter-notebookinstanties
• Afzonderlijke, aanpasbare computerinstanties voor elke gebruiker
• Gedeeld bestandssysteem dat wordt gebruikt om projecten te organiseren en code eenvoudig te delen met collega's
• Levenscyclusconfiguraties die de kosten verlagen en het gemakkelijker maken om aan de slag te gaan
• Verbinding met gegevensbronnen, codeopslagplaatsen en pakketindexen

We zijn van plan deze omgeving nog beter te maken door een paar extra functies toe te voegen:

• Kostenbewaking – Om ons budget te bewaken, voegen we een speciale tag toe aan elke instantie om de kosten ervan bij te houden.
• Staat automatisch opslaan – We creëren een levenscyclusconfiguratie die automatisch de status van een notebook opslaat, zodat gebruikers de status van de notebook gemakkelijk kunnen herstellen, zelfs nadat deze is afgesloten.
• Systeem met beperkte machtigingen – We willen gebruikers uit verschillende groepen in staat stellen deel te nemen aan ons onderzoek en onze gegevens te verkennen door hen notebook-instanties te laten maken en toegang te krijgen tot onze gegevens, maar onder vooraf gedefinieerde beperkingen. Ze kunnen bijvoorbeeld alleen kleine, goedkope notebookinstanties maken en slechts toegang krijgen tot een deel van de gegevens.

Als volgende stap raden wij u aan om het uit te proberen SageMaker-notitieboekjes. Voor meer voorbeelden, bekijk de SageMaker-voorbeelden GitHub-opslagplaats.

Over de auteurs

Matan Leeuw is teamleider Data Science bij Imperva's Threat Research Group. Zijn team is verantwoordelijk voor het leveren van datagestuurde oplossingen en innovatie op het gebied van cyberbeveiliging voor het hele productportfolio van het bedrijf, inclusief de frontlinie van applicatie- en gegevensbeveiliging, waarbij gebruik wordt gemaakt van big data en machine learning.

Johnathan Azaria is Data Scientist en lid van Imperva Research Labs, een vooraanstaande onderzoeksorganisatie voor beveiligingsanalyse, ontdekking van kwetsbaarheden en expertise op het gebied van compliance. Voordat Johnathan aan de slag ging als datawetenschapper, was hij een beveiligingsonderzoeker gespecialiseerd in netwerk- en applicatiegebaseerde aanvallen. Johnathan heeft een B.Sc en een M.Sc in Bio-informatica aan de Bar Ilan Universiteit.

Yaniv Vaknin is Machine Learning-specialist bij Amazon Web Services. Vóór AWS bekleedde Yaniv leidinggevende posities bij AI-startups en Enterprise, waaronder mede-oprichter en CEO van Dipsee.ai. Yaniv werkt samen met AWS-klanten om de kracht van Machine Learning te benutten om echte taken op te lossen en waarde te ontlenen. In zijn vrije tijd speelt Yaniv graag voetbal met zijn jongens.

Bron: https://aws.amazon.com/blogs/machine-learning/how-imperva-expedites-ml-development-and-collaboration-via-amazon-sagemaker-notebooks/