\documentclass{beamer}

\usepackage{algorithm}
\usepackage{algorithmic}
\usepackage{beamerthemesplit}
\usepackage{graphicx}
\usepackage[T1]{fontenc}
\usepackage[latin1]{inputenc}

\title{Éléments techniques sur Azure}
\author{Matthieu Durut}
\date{\today}

\begin{document}

\begin{frame}
\titlepage
\end{frame}

\begin{frame}
\frametitle{Qu'est-ce que le Cloud ?}
\begin{itemize}
\item HPC et Commodity Hardware
\item Grid puis P2P
\item Cloud
\end{itemize}
\end{frame}

\begin{frame}
\frametitle{Différences Grid/Cloud}
\begin{itemize}
\item Unicité du domaine administratif
\item Credentials + contrôle d'identité/ d'activité
\item Shift du modèle économique de la possession du bien de production à la location de service
\item MultiTenancy et Elasticité => mutualisation comme en assurance...
\item Pas de maintenance, machines remplacées instantanément grâce à la virtualisation
\end{itemize}
\end{frame}

\begin{frame}
\frametitle{XaaS}
\begin{itemize}
\item SaaS : GMail, Google Search, Facebook, Picasa, ...
\item PaaS : Amazon MapReduce avec Simple Storage Service (S3), Microsoft Azure, BungeeLabs, ...
\item IaaS : Amazon Elastic Cloud Compute (EC2)
\item HaaS : RackSpace, ...
\end{itemize}
\end{frame}

\begin{frame}
\frametitle{XaaS}
\begin{figure}
    \centering
    \includegraphics[scale=0.6]{../../Pictures/HardwareSchemes/PaaS.png}
    \caption{Paas, Iaas, SaaS}
\end{figure}
\end{frame}

\begin{frame}
\frametitle{Compromis}
\begin{itemize}
\item compromis abstraction/contrôle
\item compromis scalability/coût de développement
\end{itemize}
\end{frame}

\begin{frame}
\frametitle{Software Stack dans le cas PaaS}
\begin{figure}
    \centering
    \includegraphics[scale=0.6]{../../Pictures/Cloud/msparallel.jpg}
    \caption{Les différentes stacks les plus utilisées/abouties}
\end{figure}
\end{frame}

\begin{frame}
\frametitle{SQL}
\begin{itemize}
\item Système très orienté applicatif : Relational DataBase Managemement System (RDBMS)
\item Données structurées
\item Invariants logiques
\item Requêtage et index secondaires
\item Quantum de modification : la transaction
\item Possibilités de rollback
\end{itemize}
\end{frame}

\begin{frame}
\frametitle{Propriétés ACID des bases SQL}
\begin{itemize}
\item Atomicity
\item Consistency
\item Isolation
\item Durability
\end{itemize}
\end{frame}

\begin{frame}
\frametitle{Les différentes notions de la Consistency}
\begin{itemize}
\item Unicité de la mémoire : consistency = invariants logiques ne sont pas cassés
\item Storage réparti : Strong Consistency = toutes les updates appliquées sur tous les noeuds au même temps logique
\item Storage réparti : Eventual Consistency = si le système est laissé au repos pendant un temps suffisant, il fournit une version consistente des données
\item Difficulté et coût de la consistency dans le cas réparti. Double-commit protocol, ...
\end{itemize}
\end{frame}

\begin{frame}
\frametitle{Stockage réparti : les propriétés principales}
\begin{itemize}
\item Strong Consistency
\item Partition tolerance
\item Availability
\item Faible latence
\item CAP theorem et ses limites
\end{itemize}
\end{frame}

\begin{frame}
\frametitle{Mouvement NoSQL}
\begin{itemize}
\item Remise en cause des features : Facebook, Twitter, Youtube, ... Consistency encore primordiale ?
\item Evolution de la contrainte d'échelle : cf slide suivant
\item Evolution sur les contraintes métiers : latence rédhibitoire : Google Search. Très faible contrainte de latence : photos Facebook
\item => design de nouveaux systèmes
\end{itemize}
\end{frame}

\begin{frame}
\frametitle{Un exemple par les chiffres, Facebook}
\begin{itemize}
\item Facebook en 2010, c'était :
\item 500 millions d'utilisateurs actifs
\item 690 milliards de pages vues par mois
\item 6 milliards d'éléments de contenu partagés par semaine
\item entre 60 000 et 100 000 serveurs
\item 300 To de données en RAM avec Memcached
\item Un ingénieur Facebook pour 1.1 millions d'utilisateurs
\end{itemize}
\end{frame}

\begin{frame}
\begin{itemize}
\item Quelles features relâcher ?
\item La latence comme paramètre d'ajustement
\item Les différents choix de différents systèmes : Cassandra, Azure, ...
\end{itemize}
\end{frame}

\begin{frame}
\frametitle{Taxonomie des storages cloud}
\begin{itemize}
\item Document oriented DB : CouchDB, MongoDB. SimpleDB
\item Graph DB :Horton, FlockDB, ...
\item Key-value pairs DB: Cassandra, Dynamo, Velocity, BigTable, Azure BlobStorage, ...
\end{itemize}
\end{frame}

\begin{frame}
\frametitle{Windows Azure Storage system (WAS)}
\begin{itemize}
\item Usage interne : Bing, XBox Gaming Network, ...
\item Usage externe : Storage as a Service.
\end{itemize}
\end{frame}

\begin{frame}
\frametitle{Les composants du storage d'Azure}
\begin{itemize}
\item Azure QueueStorage
\item Azure BlobStorage
\item Azure TableStorage
\item Azure SQL
\end{itemize}
\end{frame}

\begin{frame}
\frametitle{Cas d'usage fréquent du storage pour une appli cloud}
\begin{itemize}
\item I/O de l'application avec l'extérieur par le BlobStorage
\item Instructions générales du flow d'exécution par des messages dans le QueueStorage
\item Résultats intermédiaires dans le TableStorage ou le BlobStorage
\end{itemize}
\end{frame}

\begin{frame}
\frametitle{Azure QueueStorage}
\begin{itemize}
\item Mécanisme de communication asynchrone faiblement couplé (loosely coupled)
\item 500 messages/queue/seconde (étonnamment faible)
\item Pas de garantie FIFO, mais comportement FIFO dans la pratique si non stressée.
\item Garantie que chaque message est retourné au moins une fois.
\item Nécessité d'idempotence des messages
\item Message limité à 8 Ko => en pratique même moins
\end{itemize}
\end{frame}

\begin{frame}
\frametitle{Azure BlobStorage}
\begin{itemize}
\item Stocke des fichiers ou des instances de classes sérialisées.
\item Chaque élément est stocké dans un "blob" : Binary Large OBject
\item Chaque blob a une taille comprise entre quelques Ko et 50 Go
\item Strong Consistency garantie ! (cf infra)
\end{itemize}
\end{frame}

\begin{frame}
\frametitle{Azure BlobStorage 2}
\begin{itemize}
\item Key: ContainerName/BlobName
\item Contraintes sur le nommage de la Key et erreurs inattendues
\item 3 à 63 caractères
\item Seulement des lettres, des chiffres, et le symbole "-"
\item Pas de majuscule
\end{itemize}
\end{frame}


\begin{frame}
\frametitle{Azure BlobStorage 2}
\begin{itemize}
\item Opérations disponibles : Get/Put/List
\item mécanisme de "Optimistic nonblocking atomic read-modify-write" via storage stamp appelé Etag
\item Pas d'atomicité multi-blobs, même dans le même container
\item Notion de "logique atomique" intra-blob
\end{itemize}
\end{frame}

\begin{frame}
\frametitle{Azure BlobStorage 3}
\begin{itemize}
\item Logique de réplication inter datacenter
\item Logique de réplication intra datacenter (3 replicas min)
\item Notion de storage stamp (cf infra)
\item Compromis latence/consistence. Quel choix pour Azure ?
\end{itemize}
\end{frame}

\begin{frame}
\frametitle{Azure TableStorage}
\begin{itemize}
\item Comparable au BlobStorage
\item Key/Value pair Storage
\item clé constituée de deux parties : PartitionKey/RowKey
\item Une Entity possède une liste de paires de (Name/Typed Value) appelées Properties
\item Exemple
\end{itemize}
\end{frame}

\begin{frame}
\frametitle{Azure TableStorage 2}
\begin{itemize}
\item Le schéma est flexible pour chaque Entity
\item => pas d'index secondaire, toute requête entraine un scan linéaire des données...
\item Notion d'atomicité au sein d'une même PartitionKey par paquet de 100 Entity max
\item Restrictions : que des Insert, des Delete ou des Update.
\end{itemize}
\end{frame}

\begin{frame}
\frametitle{Partitionning et Load Balancing}
\begin{itemize}
\item Partitionnement manuel et automatique
\item Frontière : la PartitionKey
\item Un Partition Server adresse les requêtes de plusieurs Partitions (même si n serveurs de stockage derrière) 
\item Le WAS monitore l'utilisation et peut dynamiquement reconfigurer le map entre partitions et partition servers.
\end{itemize}
\end{frame}

\begin{frame}
\frametitle{Partitionning et Load Balancing}
\begin{itemize}
\item Compromis Atomicité/Scalabilité dans le cas du TableStorage
\item Comment choisir ? Domain Driven Design ? ...
\end{itemize}
\end{frame}

\begin{frame}
\frametitle{Mécanique interne du WAS}
\begin{itemize}
\item Tous les détails dans \cite{AzureStorage}
\end{itemize}
\end{frame}

\begin{frame}
\frametitle{BlobStorage ou TableStorage ?}
\begin{itemize}
\item Atomicité : propriété nécessaire pour le projet ?
\item Supériorité du BlobStorage pour les gros objets 
\item Aspect financier en faveur du TableStorage
\item BlobStorage plus simple d'utilisation
\item Le TableStorage est moins abouti pour le moment niveau stabilité
\end{itemize}
\end{frame}

\begin{frame}
\frametitle{Considérations sur le développement d'applis sur Azure}
\begin{itemize}
\item Idempotence (cf scénarii du slide suivant)
\item Pas d'affinité CPU/Disque-dur, au contraire même
\item Communication inter-machines
\end{itemize}
\end{frame}

\begin{frame}
\frametitle{Considérations sur le développement d'applis sur Azure 3}
\begin{figure}
    \centering
    \includegraphics[scale=0.5]{../../Schemes/idempotencyIssues.pdf}
    \caption{Idempotency}
\end{figure}
\end{frame}

\begin{frame}
\frametitle{Communication inter-machines}
\begin{itemize}
\item Pas de shared-memory efficace
\item Pas de MPI
\item Pas de framework P2P
\item MapReduce trop peu expressif
\item Dryad abandonné
\item Utilisation du WAS: Queue et Blob
\item Eviter les écritures concurrentes
\item Lokad.Cloud, Lokad.CQRS
\end{itemize}
\end{frame}

\begin{frame}
\frametitle{Primitives de synchro : les compteurs}
\begin{itemize}
\item Compteurs idempotents, scalable
\item Cas d'utilisation : égalité de lecture et d'écriture. 
\item Sharded counters à la Facebook ne marchera pas
\item Des compteurs custom
\end{itemize}
\end{frame}

\begin{frame}
\frametitle{Dimensionnement d'Azure aujourd'hui}
\begin{itemize}
\item Taille des VM: Extra small, small, medium, large, extra-large
\item Débit en écriture/lecture dans le storage. Cas idéal et le vôtre
\item Puissance des CPU. Cas idéal et le vôtre
\item Contrainte de l' "aggregated bandwidth"
\end{itemize}
\end{frame}

\begin{frame}
\frametitle{Les prix}
\begin{itemize}
\item 1 millions de transactions storage/workers = 1 dollar
\item 1 heure de calcul = 10 cents
\item 1 Go stocké par mois = 1 dollar
\end{itemize}
\end{frame}

%\begin{frame}
%\frametitle{Introducing Lokad.Cloud}
%\begin{itemize}
%\item higher level abstractions
%\end{itemize}
%\end{frame}

%\begin{frame}
%\frametitle{Azure BlobStorage}
%\begin{itemize}
%\item objects up to 50 GB
%\item consistency ?
%\item Key/value system
%\end{itemize}
%\end{frame}
%
%\begin{frame}
%\frametitle{Azure TableStorage}
%\begin{itemize}
%\item Tables/Entities/Properties
%\item key/value pair also
%\end{itemize}
%\end{frame}
%
%\begin{frame}
%\frametitle{Azure QueueServices}
%\begin{itemize}
%\item SOA
%\item Queue consumers
%\end{itemize}
%\end{frame}
%
%\begin{frame}
%\frametitle{ACID/BASE constraints on Cloud}
%\begin{itemize}
%\item ACID
%\item BASE
%\item CAP Theorem
%\item CLAP system
%\end{itemize}
%\end{frame}
%
%\begin{frame}
%\frametitle{ACID/BASE constraints on Azure}
%\begin{itemize}
%\item Availability : No
%\item Internet and Electricity neither
%\item Consistency : ?
%\end{itemize}
%\end{frame}
%
%\begin{frame}
%\frametitle{Consistency on Azure : replicas and consistency}
%\begin{itemize}
%\item Block commits
%\item Etag
%\item very few overwrites
%\end{itemize}
%\end{frame}
%
%\begin{frame}
%\frametitle{Consistency on Azure : transactionality}
%\begin{itemize}
%\item The SQL trick
%\end{itemize}
%\end{frame}
%
%\begin{frame}
%\frametitle{Azure tradeoffs choices}
%\begin{itemize}
%\item read/write tradeoff
%\item Responsivity/efficiency
%\item Synchronous replication/Asynchronous replication ?
%\end{itemize}
%\end{frame}
%
%\begin{frame}
%\frametitle{BlobStorage or TableStorage ?}
%\begin{itemize}
%\item Partition Key and locality
%\item size of objects
%\item efficiency of Blobstorage for objects larger than 4Kbytes
%\item Price
%\end{itemize}
%\end{frame}
%
%\begin{frame}
%\frametitle{Abstractions performances}
%\begin{itemize}
%\item BlobStorage Read : 13MBytes/sec/worker. Aggregated bounded to 393 MBytes/sec
%\item BlobStorage Write : 5MBytes/sec/worker. Aggregated bounded to 124 MBytes/sec
%\item Direct worker communication : 55MBytes/sec on very large messages
%\item VM : from 1 to 8 cores
%\item Queues throughput : 500 messages/sec
%\end{itemize}
%\end{frame}
%
%
%\begin{frame}
%\frametitle{Redesign of the algorithm}
%\begin{itemize}
%\item SOA
%\item No Master
%\item All workers can be switched
%\item No worker/data per affinity but ...
%\item Scaling up as an initiative in PaaS
%\item No exact workers count
%\item Pinging queues as a tradeoff between cost and simplicity
%\item Queue Messages count
%\item idempotent jobs
%\end{itemize}
%\end{frame}
%
%\begin{frame}
%\frametitle{Redesign of the algorithm (2)}
%\begin{itemize}
%\item Idempotent Counters
%\item Workers communication ?
%\end{itemize}
%\end{frame}
%
%\begin{frame}
%\frametitle{Proposed Algorithm}
%\begin{itemize}
%\item Scheme
%\end{itemize}
%\end{frame}
%
%\begin{frame}
%\frametitle{Difficulty to anticipate speedUp}
%\begin{itemize}
%\item Serialization/Deserialization. DataContract ? BinaryFormat ? GoogleProtoBuf ?
%\item variability of the bandwidth
%\item latency due to pinging queues
%\item a worker can fail, a VM can be killed
%\item Storage unavailability
%\item Stragglers issues ?
%\end{itemize}
%\end{frame}
%
%\begin{frame}
%\frametitle{Is time to load data important ?}
%\begin{align*}
%T_{P}^{Load} & = \frac{nd*SoD}{P * \max(Bandwidth^{read}, \frac{MaxReadThroughput}{P})}\\
%\end{align*}
%\begin{align*}
%T_{P}^{Load} << T_{P}^{Comp}
%\end{align*}
%Implicit supposition : loading is run once.
%\begin{align*}
%\frac{SoD}{3IK*T^{flop} * \max(Bandwidth^{read}, \frac{MaxReadThroughput}{P})} << 1
%\end{align*}
%
%\end{frame}
%
%
%\begin{frame}
%\frametitle{Communication modelisation}
%\begin{align*}
%T_{P}^{comm, per iteration} & = ~Time ~to ~read ~1 ~blob ~"simultaneously" ~by ~P ~workers\\
%& + ~Time ~to ~write ~P ~blobs ~"simultaneously"\\
%& + ~Time ~to ~read ~P ~blobs ~by ~1 ~worker\\
%& + ~Time ~to ~merge ~the ~different ~centroids ~version\\
%& + ~Time ~to ~write ~1 ~blob ~per ~1 ~worker\\
%\end{align*}
%\end{frame}
%
%\begin{frame}
%\frametitle{Communication modelisation(2)}
%\begin{align*}
%T_{P}^{comm, per iteration} & = \frac{Kd *SoD}{Min(Bandwidth^{read}, \frac{BlobReadThroughput}{P} )} \\
%& + \frac{Kd * SoD}{Min(Bandwidth^{write}, \frac{MaxWriteThroughput}{P})}\\
%& + \frac{PKd* SoD}{Bandwidth^{read}} \\
%& + (P-1)Kd * 5floatOperations * T^{flop}\\
%& + \frac{Kd * SoD}{Bandwidth^{write}}\\
%\end{align*}
%\end{frame}
%
%\begin{frame}
%\frametitle{Communication modelisation(3)}
%\begin{align*}
%T_{P}^{comm} & \simeq \frac{IPKd*SoD}{Bandwidth^{read}} \\
%\end{align*}
%\end{frame}
%
%\begin{frame}
%\frametitle{SpeedUp}
%\begin{align*}
%SpeedUp & = \frac{T_{1}^{comp}}{T_{P}^{Comp} + T_{P}{comm}}\\
%& \simeq \frac{3IKdnT^{flop}}{\frac{3IKdnT^{flop}}{P} +\frac{IPKd*SoD}{Bandwidth^{read}} } \\
%& \simeq \frac{3nT^{flop}}{\frac{3nT^{flop}}{P} + \frac{P*SoD}{Bandwidth^{read}}}
%\end{align*}
%\end{frame}
%
%\begin{frame}
%\frametitle{Optimal Number of workers}
%\begin{align*}
%P^{*}  = \sqrt{\frac{3nT^{flop}Bandwidth^{read}}{SoD}}
%\end{align*}
%\end{frame}
%
%\begin{frame}
%\frametitle{Numerical Example}
%\begin{itemize}
%\item n = 432 000
%\item K = 657
%\item d = 168
%\item I = 100
%\item PMax = 64
%\item $Bandwidth^{read} = 20 Mbytes/sec  (resp. 5Mbytes/sec )$
%\end{itemize}
%\end{frame}
%
%\begin{frame}
%\frametitle{Results}
%\begin{align*}
%Sequential ~KMeans ~time = 14300 seconds
%\end{align*}
%\begin{align*}
%Optimal ~number ~of ~workers = 57 (resp 28)
%\end{align*}
%\begin{align*}
%SpeedUp = 28,5 (resp 14)
%\end{align*}
%\end{frame}
%
%\begin{frame}
%\frametitle{Improvements : more reducers ?}
%scheme
%\end{frame}
%
%\begin{frame}
%\frametitle{Direct worker communication ?}
%\end{frame}

\bibliographystyle{plain}
\bibliography{../../biblio/biblio}

\end{document} 