コードで学ぶAWS入門

本書は，東京大学計数工学科で2021年度S1/S2タームに開講されている"システム情報工学特論"の講義資料として作成された．

本書の目的は，クラウドの初心者を対象とし，クラウドの基礎的な知識・概念を解説する． また， Amazon Web Services (以下， AWS) の提供するクラウド環境を実例として，具体的なクラウドの利用方法をハンズオンを通して学ぶ．

とくに，科学・エンジニアリングの学生を対象として，研究などの目的でクラウドを利用するための実践的な手順を紹介する． 知識・理論の説明は最小限に留め，実践を行う中で必要な概念の解説を行う予定である． 読者が今後，研究などでクラウドを利用する際の，足がかりとなれば本書の目的は十分達成されたことになる．

本書は以下のような三部構成になっている．

第一部は，クラウドの基礎となる概念・知識を解説する． セキュリティやネットワークなど，クラウドを利用する上で最低限おさえなければいけないポイントを説明する． ハンズオンでは，はじめての仮想サーバーを AWS に立ち上げる演習を行う．

第二部では，クラウド上で科学計算 (とくに機械学習) を走らせるための入門となる知識・技術を解説する． あわせて， Docker とよばれる仮想計算環境の使用方法を紹介する． 一つ目のハンズオンでは， AWS のクラウドで Jupyter Notebook を起動し簡単な機械学習の計算を走らせる課題を実践する． 二つ目のハンズオンでは，深層学習を用いた自然言語処理により，質問に自動で回答を生成するボットを作成する． 最後に，複数台の GPU インスタンスからなるクラスターを起動し，並列に深層学習のハイパーパラメータサーチを行う方法を紹介する．

第三部では，サーバーレスアーキテクチャとよばれる最新のクラウドのアーキテクチャを紹介する． これは，サーバーの処理能力を負荷に応じてより柔軟に拡大・縮小するための概念であり，それ以前 (Serverful としばしばよばれる) と質的に異なる設計思想をクラウドに導入するものである． ハンズオンでは，サーバーレスクラウドの主要なコンポーネントである Lambda, DynamoDB, S3 の演習を提供する． さらに，サーバーレスの技術を使用して簡単な SNS をクラウド上に作成する．

これらの豊富なハンズオンにより， AWS 上にクラウドシステムを開発するための知識と技術が身につくはずである． いずれのハンズオンも，実用性を重視したものになっており，これらをベースにカスタマイズを施すことで様々な応用が可能である．

本書のフィロソフィーを一言で表すなら， "ロケットで宇宙まで飛んでいって一度地球を眺めてみよう！" である．

どういうことか？

ここでいう"地球"とは，クラウドコンピューティングの全体像のことである． 言うまでもなく，クラウドという技術は非常に広範かつ複雑な概念で，幾多の情報技術・ハードウェア・アルゴリズムが精緻に組み合わさってできた総体である． そして，今日では科学研究から日常のインフラ設備に至るまで，我々の社会の多くの部分がクラウド技術によって支えられている．

ここでいう"ロケット"とはこの講義のことである． この講義では，ロケットに乗って宇宙まで飛び立ち，地球(クラウド)の全体を自身の目で眺めてもらう． その際，ロケットの成り立ちや仕組み (背後にある要素技術やプログラムのソースコード) を深くは問わない． 将来，自分が研究などの目的でクラウドを利用することになった際に，改めて学んでもらえば良い． 本書の目的はむしろ，クラウドの最先端に実際に触れ，そこからどんな景色が見えるか(どんな応用が可能か)を実感してもらうことである．

そのような理由で，本書はクラウドの基礎から応用まで幅広いテーマを取り扱う． 第一部はクラウドの基礎から始め，第二部では一気にレベルアップし機械学習(深層学習)をクラウドで実行する手法を解説する． さらに第三部では，サーバーレス・アーキテクチャというここ数年のうちに確立した全く新しいクラウドの設計について解説する． それぞれで本一冊分以上の内容に相当するものであるが，本書はあえてこれらを一冊にまとめ連続的に俯瞰するという野心的な意図をもって執筆された．

決して楽な搭乗体験ではないかもしれないが，このロケットにしがみついてきてもらえれば，とてもエキサイティングな景色が見られることを約束したい．

本書では，ハンズオン形式で AWS のクラウドを実際に動かす演習を提供する． 自分でハンズオンを実行してみたい読者は，各自で AWS のアカウントの作成をしていただく． AWS のアカウントの作成の仕方は巻末付録 (Section 15.1) に簡単に記載したので，必要に応じて参照していただきたい．

AWS にはいくつかの機能に対して無料利用枠が設定されており，いくつかのハンズオンは無料の範囲内で実行できる． 一方，ほかのハンズオン (とくに機械学習を扱うもの) では数ドル程度のコストが発生する． ハンズオンごとに発生するおおよそのコストについて記述があるので，注意をしながらハンズオンに取り組んでいただきたい．

また，大学などの教育機関における講義で AWS を使用する際は， AWS Educate というプログラムを利用することも可能である． これは，講義の担当者が申請を行うことで，受講する学生に対し AWS クレジットが提供されるというプログラムである． AWS Educate を利用することで金銭的な負担なしに AWS を体験することができる． また，講義を経由せず個人でも AWS Educate に参加することも可能である． AWS Educate からは様々な学習教材が提供されているので，ぜひ活用してもらいたい．

本書では， AWS 上にクラウドアプリケーションを展開するハンズオンを実施する． そこで紹介するプログラムを実行するためには，以下の計算機環境が必要である． インストールの方法については，巻末付録 (Section 15) に記してある． 必要に応じて参照し，環境構築を各自実施していただきたい．

本書を読むにあたり，要求する前提知識は大学初等程度の計算機科学の知識 (OS，プログラミングなど)のみである． それ以上の前提知識はとくに仮定しない． クラウドの利用経験もゼロで問題ない． が，以下の事前知識があるとよりスムーズに理解をすることができるだろう．

ハンズオンで使うプログラムや教科書のソースコードは以下のウェブページで公開している．

https://github.com/tomomano/learn-aws-by-coding

また，以下のような形式で注意やチップスを提供する．

クラウドとはなにか？ クラウドという言葉は，それ自身がとても広い意味をもつので，厳密な定義付けを行うことは難しい．

学術的な意味でのクラウドの定義づけをするとしたら，NIST(米国・国立標準技術研究所) による The NIST Definition of Cloud Computing が引用されることが多い． ここに記載されたクラウドの定義・モデルを図示したのが Figure 2 である．

これによると，クラウドとは以下の要件が満たされたハードウェア/ソフトウェアの総体のことをいう．

…​と，いわれても抽象的でよくわからないかもしれない．もう少し具体的な話をする．

個人が所有する計算機で， CPU をアップグレードしようと思ったら，物理的に筐体を開け，CPUソケットを露出させ，新しいCPUに交換する必要があるだろう． あるいは，ストレージがいっぱいになってしまったら，古いディスクを抜き取り，新しいディスクを挿入する必要がある． 計算機の場所を移動させたときには，新しい部屋の LAN ケーブルを差し込まないとネットワークには接続できない．

クラウドでは，これらの操作がプログラムからのコマンドによって実行できる． CPUが1000個欲しいと思ったならば，そのようにクラウドプロバイダーにリクエストを送れば良い． すると，数分もしないうちに 1000 CPUの計算資源が割り当てられる． ストレージを1TBから10TBに拡張しようと思ったならば，そのようにコマンドを送ればよい (これは，Google Drive や Dropbox などのサービスなどで馴染みのある人も多いだろう)． 計算資源を使い終わったら，そのことをプロバイダーに伝えれば，割り当て分はすぐさま削除される． クラウドプロバイダーは，使った計算資源の量を正確にモニタリングしており，その量をもとに利用料金の計算が行われる．

このように，クラウドの本質は物理的なハードウェアの仮想化・抽象化であり，利用者はコマンドを通じて，まるでソフトウェアの一部かのように，物理的なハードウェアの管理・運用を行うことができる． もちろん，背後では，データセンターに置かれた膨大な数の計算機が大量の電力を消費しながら稼働している． クラウドプロバイダーはデータセンターの計算資源を上手にやりくりし，ソフトウェアとしてのインターフェースをユーザーに提供することで，このような仮想化・抽象化を達成しているわけである． クラウドプロバイダーの視点からすると，大勢のユーザーに計算機を貸し出し，データセンターの稼働率を常時100%に近づけることで，利益率の最大化を図っているのである．

著者の言葉で，クラウドの重要な特性を定義するならば，以下のようになる．

先述の The NIST Definition of Cloud Computing に戻ると，クラウドプロバイダーによるクラウドサービスの形態としては，次の三つが定義されている (Figure 2)．

本書が扱うのは，主に IaaS におけるクラウド開発である． すなわち，開発者がクラウドのインフラを直接操作し，所望のネットワーク・サーバー・ストレージなどを一から構成し，そこにアプリケーションを展開するというクラウド開発である． この意味において，クラウドの開発とはクラウドインフラストラクチャーを定義・展開するプログラムを構築するステップとインフラ上で実際に走るアプリケーションを作成するステップの二つに分けることができる． この二つは，プログラマーの技術としてはある程度分業を行うことが可能であるが，最も効率化・最適化されたクラウドシステムを構築するためには両方の理解が必須である． 本書では，前者 (クラウドインフラの記述) に重きを置きつつ，アプリケーションレイヤーの話題も取り扱う． PaaS とは，開発者はアプリケーションレイヤーの開発に注力し，クラウドインフラの部分はクラウドプロバイダーに依存するという概念である． PaaS は，クラウドインフラの開発が不要になることで開発の時間が短縮されるが，細かなインフラの挙動はコントロールできないという限界がある． 本書では PaaS についてはとくに取り扱わない．

SaaS は本書の文脈では開発による"成果物"と捉えられるだろう． すなわち， IaaS を構成するプログラムを作成し展開することによって，一般の人が利用できるようなウェブ上の計算サービスやデータベースを提供することが開発の最終ゴールである． 本書のハンズオンではその実例として，シンプルな SNS の作成 (Section 13) などの演習を提供する．

なお，最近では Function as a Service (FaaS) やサーバーレスコンピューティングなども新たなクラウドのカテゴリとして認知されている． これらの概念については Section 12 などの章で詳しく触れていく． 本書を読み進める中で明らかになるように，クラウドの技術は日進月歩である． 本書では実用的・教育的な観点から，従来的なクラウドの設計概念に触れたあと，サーバーレスなどの最新の技術も網羅するので，楽しみにしながら読み進めていただきたい．

最後に，The NIST Definition of Cloud Computing によると，クラウドの運用形態について次のような定義がなされている (Figure 2)． 特定の組織・団体・企業の内部のみで使用されるクラウドを，プライベートクラウド (private cloud) とよぶ． 例えば，大学や研究機関では，その機関の構成員向けの大規模計算機サーバーが運用されていることが多い． プライベートクラウドは，組織の構成員ならば無料もしくは極めて割安のコストで計算を実行できる． しかし，使用できる計算資源の上限は限られる場合が多く，拡張時の柔軟性に欠ける場合もある．

一方，商用のサービスとして一般の顧客に向けたクラウドのことを，パブリッククラウド (public cloud) とよぶ． 有名なパブリッククラウドプラットフォームの例を挙げると， Google社が提供する Google Cloud Platform (GCP)， Microsoft 社が提供する Azure， Amazon 社が提供する Amazon Web Services (AWS) などがある． パブリッククラウドを利用する場合は，プロバイダーの設定した利用料金を支払うことになる． その分，巨大なデータセンターを運用する企業の計算資源にアクセスすることができるので，計算のキャパシティは無尽蔵にあるといって過言でない．

第三のクラウドの運用形態として，コミュニティクラウド (community cloud) が挙げられる． これは，例えば政府の省庁・機関など目的・役割を共有する団体・組織が共有して運用するクラウドを指す． 最後に，ハイブリッドクラウド (hybrid cloud) という形態もあり，これはプライベート・パブリック・コミュニティクラウドの二つ以上の組み合わせによって構成されるクラウドのことである． データ保護の観点から，いくつかの機密データやプライバシーに関わる情報はプライベートクラウドに保持し，残りのシステムをパブリッククラウドに依存する，などの形態が想定される．

本書で説明するのは，基本的にパブリッククラウドを使ったクラウド開発である． 特に，Amazon Web Services (AWS) を使用して，具体的な技術と概念を学んでいく． 一方で，サーバーのスケーリングや仮想計算環境などのテクニックはすべてのクラウドに共通な概念であるので，クラウドのプラットフォームが変わろうと一般に通用する知識も同時に身につくはずだ．

上述のように，クラウドとはプログラムを通じて自由に計算資源を操作することのできる計算環境である． ここでは，リアルなローカル計算環境と比べて，なぜクラウドを使うと良いことがあるのかについて述べたい．

とくに，1.の点は研究の場面では重要であると筆者は感じる． 研究をやっていて，四六時中計算を走らせ続けるという場合は少ない． むしろ，新しいアルゴリズムが完成したとき・新しいデータが届いたとき，集中的・突発的に計算タスクが増大することが多いだろう． そういったときに，フレキシブルに計算力を増強させることができるのは，クラウドを使う大きなメリットである．

ここまでクラウドを使うメリットを述べたが，逆に，デメリットというのも当然存在する．

本書では，クラウドの実践を行うプラットフォームとして， AWS を用いる． 実践にあたって，最低限必要な AWS の知識を本章では解説しよう．

AWS (Amazon Web Services) はAmazon社が提供する総合的なクラウドプラットフォームである． AWS は Amazon 社が持つ膨大な計算リソースを貸し出すクラウドサービスとして，2006年に誕生した． 2021年では，クラウドプロバイダーとして最大のマーケットシェア (約32%) を保持している (参照)． Netflix や Slack をはじめとした多くのウェブ関連のサービスで，一部または全てのサーバーリソースが AWS から提供されているとのことである． よって，知らないうちに AWS の恩恵にあずかっている人も少なくないはずだ．

最大のシェアをもつだけに，機能・サービスの幅広さはほかのクラウドプラットフォームと比べ抜きんでている． また，利用者数が多いことを反映して，公式あるいはサードパーティによる技術紹介記事が数多くウェブ上に存在しているだけでなく，ライブラリのユーザーコミュニティも大きく問題解決が捗るのも魅力の一つだ． 初期のころウェブビジネスを行う企業がユーザーの大半を占めていたが，最近は大学などでの科学研究用途としても頻繁に用いられるようになってきている．

Figure 4 は，執筆時点においてAWSで提供されている主要な機能・サービスの一覧である．

計算，ストレージ，データベース，ネットワーク，セキュリティなど，クラウドの構築に必要な様々な要素が独立したコンポーネントとして提供されている． 基本的に，これらを組み合わせることで一つのクラウドシステムができあがる．

また，機械学習・音声認識・AR/VR など，特定のアプリケーションにパッケージ済みのサービスも提供されている． これらを合計すると全部で170個以上のサービスが提供されているとのことである (参照)．

AWS の初心者が陥りがちなのは，大量のサービスの数に圧倒され，どこから手をつけたらよいのかわからなくなる，という状況である． たくさんのサービスの中から，どのサービスをどの順番で学んでいったらいいのか，その道筋すら明らかでなく，大きな参入障壁となっていることは間違いない． だが実のところ， AWS の基本的な構成要素はそのうちの数個のみに限られる． 基本要素となる機能の使い方を知れば， AWS のおおよそのリソースを使いこなすことが可能になる． ほかの機能の多くは，基本の要素を組み合わせて特定のアプリケーションに特化したパッケージとして AWS が用意したものである． そのポイントを認知することが， AWS の学習の最初のステップである．

ここでは， AWS 上でクラウドシステムを構築するときの基本となる構成要素を列挙する． これらは後のハンズオンで実際にプログラムを書きながら体験する． 現時点では，名前だけでも頭の片隅に記憶してもらえればよい．

AWS を使用する際に知っておかなければならない重要な概念として， リージョン (Region) と Availability Zone (AZ) がある (Figure 5)． 以下ではこの概念について簡単に記述する．

リージョン (Region) とは，おおまかに言うとデータセンターの所在地のことである． 執筆時点において， AWS は世界の25の国と地域でデータセンターを所有している． Figure 6 は執筆時点で利用できるリージョンの世界地図を示している． 日本では東京と大阪にデータセンターがある． 各リージョンには固有の ID がついており，例えば東京は ap-northeast-1, 米国オハイオ州は us-east-2，などと定義されている．

AWSコンソールにログインすると，画面右上のメニューバーでリージョンを選択することができる(Figure 7, 赤丸で囲った箇所)． EC2, S3 などのAWSのリソースは，リージョンごとに完全に独立である． したがって，リソースを新たにデプロイする際，あるいはデプロイ済みのリソースを閲覧する際は，コンソールのリージョンが正しく設定されているか，確認する必要がある． ウェブビジネスを展開する場合などは，世界の各地にクラウドを展開する必要があるが，個人的な研究用途として用いる場合は，最寄りのリージョン (i.e. 東京) を使えば基本的に問題ない．

Avaialibity Zone (AZ) とは，リージョン内で地理的に隔離されたデータセンターのことである． それぞれのリージョンは2個以上のAZを有しており，もし一つのAZで火災や停電などが起きた場合でも，ほかのAZがその障害をカバーすることができる． また， AZ 間は高速な AWS 専用ネットワーク回線で結ばれているため， AZ 間のデータ転送は極めて早い． AZ は，ビジネスなどでサーバーダウンが許容されない場合などに注意すべき概念であり，個人的な用途で使う限りにおいてはあまり深く考慮する必要はない．言葉の意味だけ知っておけば十分である．

AWS のクラウドの全体像がわかってきたところで，次のトピックとして，どのようにしてAWS上にクラウドの開発を行い，展開していくかについての概略を解説しよう．

AWS のリソースを追加・編集・削除するなどの操作を実行するには，コンソールを用いる方法と， API を用いる方法の，二つの経路がある．

ハンズオンのソースコードは GitHub の handson/ec2-get-started に置いてある．

まずは，ハンズオンを実行するための環境を整える． これらの環境整備は，後のハンズオンでも前提となるものなので確実にミスなく行っていただきたい．

あるいは， https://github.com/tomomano/learn-aws-by-coding のページに行って，右上のダウンロードボタンからダウンロードすることもできる．

Docker を使用する場合

Python, Node.js, AWS CDK など，ハンズオンのプログラムを実行するために必要なプログラム/ライブラリがインストール済みの Docker image を用意した． また，ハンズオンのソースコードもパッケージ済みである． Docker の使い方を知っている読者は，これを使えば，諸々のインストールをする必要なく，すぐにハンズオンのプログラムを実行できる．

使用方法については Section 15.8 を参照のこと．

SSH (secure shell) は Unix 系のリモートサーバーに安全にアクセスするためのツールである． 本ハンズオンでは， SSH を使って仮想サーバーにアクセスする． SSH に慣れていない読者のため，簡単な説明をここで行おう．

SSH による通信はすべて暗号化されているので，機密情報をインターネットを介して安全に送受信することができる． 本ハンズオンで，リモートのサーバーにアクセスするための SSH クライアントがローカルマシンにインストールされている必要がある． SSH クライアントは Linux/Mac には標準搭載されている． Windows の場合は WSL をインストールすることで SSH クライアントを利用することを推奨する (Section 1.4 を参照)．

SSH コマンドの基本的な使い方を次に示す． <host name> はアクセスする先のサーバーの IP アドレスや DNS によるホストネームが入る． <user name> は接続する先のユーザー名である．

SSH は平文のパスワードによる認証を行うこともできるが，より強固なセキュリティを施すため，公開鍵暗号方式(Public Key Cryptography)による認証を行うことが強く推奨されており， EC2 はこの方法でしかアクセスを許していない． 公開鍵暗号方式の仕組みについては各自勉強してほしい． 本ハンズオンにおいて大事なことは， EC2 インスタンスが公開鍵(Public key)を保持し，クライアントとなるコンピュータ(読者自身のコンピュータ)が秘密鍵(Private key)を保持する，という点である． EC2のインスタンスには秘密鍵を持ったコンピュータのみがアクセスすることができる．逆に言うと，秘密鍵が漏洩すると第三者もサーバーにアクセスできることになるので，秘密鍵は絶対に漏洩することのないよう注意して管理する．

SSH コマンドでは，ログインのために使用する秘密鍵ファイルを -i もしくは --identity_file のオプションで指定することができる． たとえば，次のように使う．

このハンズオンで作成するアプリケーションの概要を Figure 10 に示す．

このアプリケーションではまず，VPC (Virtual Private Cloud) を使ってプライベートな仮想ネットワーク環境を立ち上げている． そのVPCの public subnet の内側に，EC2 (Elatic Compute Cloud) の仮想サーバーを配置する． さらに，セキュリティのため， Security Group によるEC2インスタンスへのアクセス制限を設定している． このようにして作成された仮想サーバーに，SSHを使ってアクセスし，簡単な計算を行う．

Figure 10 のようなアプリケーションを，CDKを使って構築する．

早速ではあるが，今回のハンズオンで使用するプログラムを見てみよう (handson/ec2-get-started/app.py)．

それぞれについて，もう少し詳しく説明しよう．

さて，ハンズオンのコードの理解ができたところで，プログラムを実際に実行してみよう．繰り返しになるが， Section 4.1 での準備ができていることが前提である．

ここまでが，本書の第一部の内容である． 盛りだくさんの内容であったが，ついてこれたであろうか？

Section 2 では，クラウドの定義と用語の説明を行ったあと，なぜクラウドを使うのか，という点を議論した． 続いて Section 3 では，クラウドを学ぶ具体的なプラットフォームとして AWS を取り上げ， AWS を使用するにあたり最低限必要な知識と用語の説明を行った． さらに， Section 4 のハンズオンでは AWS CLI と AWS CDK を使って，自身のプライベートなサーバーを AWS 上に立ち上げる演習を行った．

これらを通じて，いかに簡単に (たった数行のコマンドで！) 仮想サーバーを立ち上げたり，削除したりすることができるか，体験できただろう． 筆者は，Section 2 でクラウドの最も重要な側面はダイナミックに計算リソースを拡大・縮小できることである，と述べた． この言葉の意味が，ハンズオンを通じてより明らかになっただろうか？ ここで学んだ技術を少し応用するだけで，自分のウェブページをホストする仮想サーバーを作成したり，大量のコアを搭載した EC2 インスタンスを用意して科学計算を実行するなど，いろいろなアプリケーションが実現できる．

次章からは，今回学んだクラウドの技術を基に，より現実に即した問題を解くことを体験してもらう． お楽しみに！

2010年頃に始まった第三次 AI ブームのおかげで，学術研究だけでなく社会・ビジネスの文脈でも機械学習に高い関心が寄せられている． とくに，深層学習 (ディープラーニング) とよばれる多層のレイヤーからなるニューラルネットワークを用いたアルゴリズムは，画像認識や自然言語処理などの分野で圧倒的に高い性能を実現し，革命をもたらしている．

深層学習の特徴は，なんといってもそのパラメータの多さである． 層が深くなるほど，層間のニューロンを結ぶ重みパラメータの数が増大していく． たとえば，最新の言語モデルである GPT-3 には1750億個ものパラメータが含まれている． このような膨大なパラメータを有することで，深層学習は高い表現力と汎化性能を実現しているのである．

GPT-3 に限らず，最近の SOTA (State-of-the-art) の性能を達成するニューラルネットワークでは，百万から億のオーダーのパラメータを内包することは頻繁になってきている． そのような巨大なニューラルネットを訓練 (最適化) させるのは，当然のことながら膨大な計算コストがかかる． 結果として，ひとつの計算機では丸一日以上の時間がかかる場合も珍しくない． 深層学習の発展の速度は目覚ましく，研究・ビジネス両方の観点からも，いかにスループットよくニューラルネットワークの最適化を行えるかが鍵となってくる． そのような問題を解決するのにとても有効な手段が，クラウドである！ Section 4 でその片鱗を見たように，クラウドを使用することでゼロから数千に至るまでの数のインスタンスを動的に起動し，並列に計算を実行することができる． さらに，深層学習を加速させる目的で，深層学習の演算に専用設計された計算チップ (GPU など) がある． クラウドを利用すると，そのような専用計算チップも無尽蔵に利用することができる． 事実，先述した GPT-3 の学習も，詳細は明かされていないが，Microsoft 社のクラウドを使って行われたと報告されている．

深層学習の計算で欠かすことのできない技術として， GPU (Graphics Processing Unit) について少し説明する．

GPU は，その名のとおり，元々はコンピュータグラフィックスを出力するための専用計算チップである． CPU (Central Processing Unit) に対し，グラフィックスの演算に特化した設計がなされている． 身近なところでは， XBox や PS5 などのゲームコンソールなどに搭載されているし，ハイエンドなノート型・デスクトップ型計算機にも搭載されていることがある． コンピュータグラフィックスでは，スクリーンにアレイ状に並んだ数百万個の画素をビデオレート (30 fps) 以上で処理する必要がある． そのため，GPUはコアあたりの演算能力は比較的小さいかわりに，チップあたり数百から数千のコアを搭載しており (Figure 17)，スクリーンの画素を並列的に処理することで，リアルタイムでの描画を実現している．

このように，コンピュータグラフィクスの目的で生まれた GPU だが，2010年前後から，その高い並列計算能力をグラフィックス以外の計算 (科学計算など) に用いるという流れ (General-purpose computing on GPU; GPGPU) が生まれた． GPUのコアは，その設計から，行列の計算など，単純かつ規則的な演算が得意であり，そのような演算に対しては数個程度のコアしかもたない CPU に比べて圧倒的に高い計算速度を実現することができる． 現在では GPGPU は分子動力学や気象シミュレーション，そして機械学習など多くの分野で使われている．

ディープラーニングで最も頻繁に起こる演算が，ニューロンの出力を次の層のニューロンに伝える畳み込み (Convolution) 演算である (Figure 18)． 畳み込み演算は，まさに GPU が得意とする演算であり， CPU ではなく GPU を用いることで学習を飛躍的に (最大で数百倍程度) 加速させることができる．

このように GPU は機械学習の計算で欠かせないものであるが，なかなか高価である． たとえば，科学計算・機械学習に専用設計された NVIDIA 社の Tesla V100 というチップは，一台で約百万円の価格が設定されている． 機械学習を始めるのに，いきなり百万円の投資はなかなか大きい． だが，クラウドを使えば，初期コスト０で GPU を使用することができる．

クラウドで GPU を使うには， GPU が搭載されたEC2インスタンスタイプ (P3, P2, G3, G4 など) を選択しなければならない． Table 3 に，代表的な GPU 搭載のインスタンスタイプを挙げる (執筆時点での情報)．

Table 3 からわかるとおり， CPU のみのインスタンスと比べると少し高い価格設定になっている． また，古い世代の GPU (V100 に対しての K80) はより安価な価格で提供されている． 1インスタンスあたりの GPU の搭載数は1台から最大で8台まで選択することが可能である．

GPU を搭載した一番安いインスタンスタイプは， g4dn.xlarge であり，これには廉価かつ省エネルギー設計の NVIDIA T4 が搭載されている． 後のハンズオンでは，このインスタンスを使用して，ディープラーニングの計算を行ってみる．

ハンズオン第二回では， GPU を搭載したEC2インスタンスを起動し，深層学習モデルの学習と推論を実行する演習を行う．

ハンズオンのソースコードは GitHub の handson/mnist に置いてある．

本ハンズオンの実行には，第一回ハンズオンで説明した準備 (Section 4.1) が整っていることを前提とする． それ以外に必要な準備はない．

このハンズオンで作成するアプリケーションの概要を Figure 19 に示す．

図の多くの部分が，第一回ハンズオンで作成したアプリケーションと共通していることに気がつくだろう． 少しの変更で，簡単にディープラーニングを走らせる環境を構築することができるのである！主な変更点は次の３点である．

ハンズオンで使用するプログラムのコードをみてみよう handson/mnist/app.py)． コードは第一回目とほとんど共通である．変更点のみ解説を行う．

DLAMI という新しい概念が出てきたので，説明しよう．

スタックの中身が理解できたところで，早速スタックをデプロイしてみよう．

デプロイの手順は，ハンズオン1とほとんど共通である． ここでは，コマンドのみ列挙する (# で始まる行はコメントである)． それぞれのコマンドの意味を忘れてしまった場合は，ハンズオン1に戻って復習していただきたい． シークレットキーの設定も忘れずに (Section 15.3)．

デプロイのコマンドが無事に実行されれば， Figure 21 のような出力が得られるはずである．AWSにより割り振られたIPアドレス (InstancePublicIp に続く文字列) をメモしておこう．

早速，デプロイしたインスタンスにSSHでログインしてみよう． ここでは，この後で使う Jupyter Notebook に接続するため，ポートフォワーディング (port forwarding) のオプション (-L) をつけてログインする．

ポートフォワーディングとは，クライアントマシンの特定のアドレスへの接続を， SSH の暗号化された通信を介して，リモートマシンの特定のアドレスへ転送する，という意味である． このコマンドの -L localhost:8931:localhost:8888 は，自分のローカルマシンの localhost:8931 へのアクセスを，リモートサーバーの localhost:8888 のアドレスに転送せよ，という意味である (: につづく数字はTCP/IPポートの番号を意味している)． リモートサーバーのポート8888には，後述する Jupyter Notebook が起動している． したがって，ローカルマシンの localhost:8931 にアクセスすることで，リモートサーバーの Jupyter Notebook にアクセスすることができるのである (Figure 22)． このようなSSHによる接続方式をトンネル接続とよぶ．

SSHによるログインができたら，早速， GPU の状態を確認してみよう． 次のコマンドを実行する．

Figure 23 のような出力が得られるはずである． 出力を見ると， Tesla T4 型のGPUが1台搭載されていることが確認できる． その他，GPU Driver や CUDA のバージョン， GPU の負荷・メモリー使用率などの情報を確認することができる．

Jupyter Notebook とは，インタラクティブに Python のプログラムを書いたり実行したりするためのツールである． Jupyter は GUI としてウェブブラウザを介してアクセスする形式をとっており，まるでノートを書くように，プロットやテーブルのデータも美しく表示することができる (Figure 24)． Python に慣れている読者は，きっと一度は使ったことがあるだろう．

このハンズオンでは， Jupyter Notebook を使ってディープラーニングのプログラムをインタラクティブに実行していく． DLAMI には既に Jupyter がインストールされているので，特段の設定なしに使い始めることができる．

早速， Jupyter を起動しよう． SSHでログインした先の EC2 インスタンスで，次のコマンドを実行すればよい．

このコマンドを実行すると， Figure 25 のような出力が確認できるだろう． この出力から，Jupyter のサーバーが EC2 インスタンスの localhost:8888 というアドレスに起動していることがわかる． また， localhost:8888 に続く ?token=XXXX は，アクセスに使うための一時的なトークンである．

先ほど，ポートフォワーディングのオプションをつけて SSH 接続をしているので， Jupyter の起動している localhost:8888 には，ローカルマシンの localhost:8931 からアクセスすることができる． したがって，ローカルマシンから Jupyter にアクセスするには，ウェブブラウザ (Chrome, FireFox など)から次のアドレスにアクセスすれば良い．

?token=XXXX の部分は，上で Jupyter を起動したときに発行されたトークンの値に置き換える．

上のアドレスにアクセスすると， Jupyter のホーム画面が起動するはずである (Figure 26)． これで， Jupyter の準備が整った！

PyTorch は Facebook AI Research LAB (FAIR) が中心となって開発を進めている，オープンソースのディープラーニングのライブラリである． PyTorch は 有名な例で言えば Tesla 社の自動運転プロジェクトなどで使用されており，執筆時点において最も人気の高いディープラーニングライブラリの一つである． 本ハンズオンでは， PyTorch を使ってディープラーニングの実践を行う．

本格的なディープラーニングの計算に移る前に， PyTorch ライブラリを使って， GPU で計算を行うとはどういうものか，その入り口に触れてみよう．

まずは，新しいノートブックを作成する． Jupyterのホーム画面の右上の "New" を押し，"conda_pytorch_p36" という環境を選択したうえで，新規ノートブックを作成する (Figure 27)． "conda_pytorch_p36" の仮想環境には， PyTorch がインストール済みである．

ここでは，次のようなプログラムを書いて，実行していく． (Figure 28)．

まずは， PyTorch をインポートする．さらに， GPU が使える環境にあるか，確認する．

出力:

次に，3x3 のランダムな行列を CPU 上に作ってみよう．

出力:

次に，行列を GPU 上に作成する．

そして，行列 x と y の加算を，GPU上で実行する．

出力:

最後に， GPU 上にある行列を， CPU に戻す．

出力:

以上の例は， GPU を使った計算の初歩の初歩であるが，雰囲気はつかめただろうか？ CPU と GPU で明示的にデータを交換するのが肝である． この例はたった 3x3 の行列の足し算なので， GPU を使う意味はまったくないが，これが数千，数万のサイズの行列になったとき， GPU は格段の威力を発揮する．

実際にベンチマークを取ることでGPUとCPUの速度を比較をしてみよう． 実行時間を計測するツールとして， Jupyter の提供する %time マジックコマンドを利用する．

まずは CPU を使用して，10000x10000 の行列の行列積を計算した場合の速度を測ってみよう． 先ほどのノートブックの続きに，次のコードを実行する．

出力は以下のようなものが得られるだろう． これは，行列積の計算に実時間で5.8秒かかったことを意味する (実行のたびに計測される時間はばらつくことに留意)．

次に， GPU を使用して，同じ演算を行った場合の速度を計測しよう．

出力は以下のようなものになるだろう． GPU では 553ミリ秒 で計算を終えることができた！

上記のベンチマークから，GPUを用いることで，約10倍のスピードアップを実現することができた． スピードアップの性能は，演算の種類や行列のサイズに依存する． 行列積は，そのなかでも最も速度向上が見込まれる演算の一つである．

ここまで，AWS上でディープラーニングの計算をするための概念や前提知識をながながと説明してきたが，ついにここからディープラーニングの計算を実際に走らせてみる．

ここでは，機械学習のタスクで最も初歩的かつ有名な MNIST データセットを使った数字認識を扱う (Figure 29)． これは，0から9までの手書きの数字の画像が与えられ，その数字が何の数字なのかを当てる，というシンプルなタスクである．

今回は， MNIST 文字認識タスクを，畳み込みニューラルネットワーク (Convolutional Neural Network; CNN) を使って解く． ソースコードは /handson/minist/pytorch/ にある mnist.ipynb と simple_mnist.py である． なお，このプログラムは， PyTorch の公式 Example Project 集 を参考に，多少の改変を行ったものである．

まずは，カスタムのクラスや関数が定義された simple_mnist.py をアップロードしよう (Figure 30)． 画面右上の "Upload" ボタンをクリックし，ファイルを選択することでアップロードができる． この Python プログラムの中に，CNN のモデルや，学習の各イテレーションにおけるパラメータの更新などが記述されている． 今回はこの中身を説明することはしないが，興味のある読者は自身でソースコードを読んでみるとよい．

simple_mnist.py をアップロードできたら，次に新しい notebook を作成しよう． "conda_pytorch_p36" の環境を選択することを忘れずに．

新しいノートブックが起動したら，まずは必要なライブラリをインポートしよう．

torchvision パッケージには，MNIST データセットをロードするなどの便利な関数が含まれている． また，今回のハンズオンで使うカスタムのクラス・関数 (Model, train, evaluate) のインポートを行っている．

次に，MNIST テストデータをダウンロードしよう． 同時に，画像データの輝度の正規化も行っている．

今回扱う MNIST データは 28x28 ピクセルの正方形の画像(モノクロ)と，それぞれのラベル(0 - 9 の数字)の組で構成されている． いくつかのデータを抽出して，可視化してみよう． Figure 31 のような出力が得られるはずである．

次に， CNN のモデルを定義する．

今回使う Model は simple_mnist.py の中で定義されている． このモデルは，Figure 32 に示したような，２層の畳み込み層と2層の全結合層からなるネットワークである． 出力層 (output layer) には Softmax 関数を使用し，損失関数 (Loss function) には 負の対数尤度関数 (Negative log likelyhood; NLL) を使用している．

続いて， CNN のパラメータを更新する最適化アルゴリズムを定義する． ここでは， 確率的勾配降下法 (Stochastic Gradient Descent; SGD) を使用している．

これで，準備が整った． CNN の学習ループを開始しよう!

ここでは5エポック分の学習を行っている． GPU を使えば，これくらいの計算であれば1分程度で完了するだろう．

出力として， Figure 33 のようなプロットが得られるはずである． イテレーションを重ねるにつれて，損失関数 (Loss function) の値が減少している (=精度が向上している) ことがわかる．

出力にはテキスト形式で各エポック終了後のテストデータに対する精度も表示されている． 最終的には 98% 以上の極めて高い精度を実現できていることが確認できるだろう (Figure 34)．

学習した CNN の推論結果を可視化してみよう． 次のコードを実行することで， Figure 35 のような出力が得られるだろう． この図で，下段右から二番目は，"1"に近い見た目をしているが，きちんと"9"と推論できている． なかなか賢い CNN を作り出すことができたようだ！

最後に，学習したニューラルネットワークのパラメータを mnist_cnn.pt というファイル名で保存しておこう． これで，将来いつでも今回学習したモデルを再現し，別の実験に使用することができる．

以上が， AWS クラウドの仮想サーバーを立ち上げ，最初のディープラーニングの計算を行う一連の流れである． MNIST 文字認識のタスクを行うニューラルネットを，クラウド上の GPU を使って高速に学習させ，現実的な問題を一つ解くことができたのである． 興味のある読者は，今回のハンズオンを雛形に，自分の所望の計算を走らせてみるとよいだろう．

これにて，ハンズオン第二回の内容はすべて説明した． クラウドの利用料金を最小化するため，使い終わったEC2インスタンスはすぐさま削除しよう．

ハンズオン第一回と同様に， AWS の CloudFormation コンソールか， AWS CLI により削除を実行する (詳細は Section 4.4.8 参照)．

先ほどから"計算システムの大規模化"と繰り返し唱えているが，それは具体的にはどのようなものを指しているのか？ ここでは大規模データを処理するための計算機システムを，機械学習を例にとって見てみよう．

Section 5 で紹介した GPT-3 のような，超巨大な数のパラメータを有する深層学習モデルを学習させたいとしよう． そのような計算を行いたい場合，一つのサーバーでは計算力が到底足りない． したがって，典型的には Figure 36 に示すような計算システムの設計がなされる． すなわち，大量の教師データを小さなチャンクとして複数のマシンに分散し，並列的にニューラルネットのパラメータを最適化していくという構造である．

あるいは，学習済みのモデルを大量のデータに適用し，解析を行いたいとしよう． たとえば， SNS のプラットフォームで大量の画像が与えられて，それぞれの写真に何が写っているのかをラベルづけする，などのアプリケーションを想定できる． そのような場合は， Figure 37 のようなアーキテクチャが考えられるだろう． すなわち，大量のデータを複数のマシンで分割し，それぞれのマシンで推論の計算を行うというような構造である．

このような複数の計算機を同時に走らせるようなアプリケーションをクラウド上で実現するには，どのようにすればよいのだろうか？

重要なポイントとして， Figure 36 や Figure 37 で起動している複数のマシンは，基本的に全く同一のOS・計算環境を有している点である． ここで，個人のコンピュータで行うようなインストールの操作を，各マシンで行うこともできるが，それは大変な手間であるし，メンテナンスも面倒だろう． すなわち，大規模な計算システムを構築するには，簡単に計算環境を複製できるような仕組みが必要であるということがわかる．

そのような目的を実現するために使われるのが， Docker とよばれるソフトウェアである．

Docker とは， コンテナ (Container) とよばれる仮想環境下で，ホストOSとは独立した別の計算環境を走らせるためのソフトウェアである． Docker を使うことで， OS を含めたすべてのプログラムをコンパクトにパッケージングすることが可能になる (パッケージされた一つの計算環境のことを イメージ (Image) とよぶ)． Dockerを使うことで，クラウドのサーバー上に瞬時に計算環境を複製することが可能になり， Figure 37 で見たような複数の計算機を同時に走らせるためのシステムが実現できる．

Docker は2013年に Solomon Hykes らを中心に開発され，それ以降爆発的に普及し，クラウドコンピューティングだけでなく，機械学習・科学計算の文脈などでも欠かすことのできないソフトウェアとなった． Docker はエンタープライズ向けの製品を除き無料で使用することができ，コアの部分は オープンソースプロジェクト として公開されている． Docker は Linux, Windows, Mac いずれの OS でも提供されている． 概念としては， Docker は仮想マシン (Virtual machine; VM) にとても近い． ここでは， VM との対比をしながら，Docker とはなにかを簡単に説明しよう．

仮想マシン (VM) とは，ホストとなるマシンの上に，仮想化されたOSを走らせる技術である (Figure 39)． VM には ハイパーバイザー (Hypervisor) とよばれるレイヤーが存在する． Hypervisor はまず，物理的な計算機リソース (CPU, RAM, network など) を分割し，仮想化する． たとえば， ホストマシンに物理的な CPU が4コアあるとして，ハイパーバイザーはそれを (2,2) 個の組に仮想的に分割することができる． VM 上で起動する OS には，ハイパーバイザーによって仮想化されたハードウェアが割り当てられる． VM 上で起動する OS は基本的に完全に独立であり，たとえば OS-A は OS-B に割り当てられたCPUやメモリー領域にアクセスすることはできない (これを isolation とよぶ)． VM を作成するための有名なソフトウェアとしては， VMware， VirtualBox， Xen などがある． また，これまで触ってきた EC2 も，基本的に VM 技術を使うことで所望のスペックをもった仮想マシンがユーザーに提示される．

Docker も， VM と同様に，仮想化された OS をホストのOS上に走らせるための技術である． VM に対し， Docker ではハードウェアレベルの仮想化は行われておらず，すべての仮想化はソフトウェアレベルで実現されている (Figure 39)． Docker で走る仮想 OS は，多くの部分をホストのOSに依存しており，結果として非常にコンパクトである． その結果， Docker で仮想 OS を起動するために要する時間は， VM に比べて圧倒的に早い． また， パッケージ化された環境 (=イメージ) のサイズも完全なOSに比べ圧倒的に小さくなるので，ネットワークを通じたやり取りが非常に高速化される点も重要である 加えて， VM のいくつかの実装では，メタル (仮想化マシンに対して，物理的なハードウェア上で直接起動する場合のこと) と比べ，ハイパーバイザーレイヤーでのオーバーヘッドなどにより性能が低下することが知られているが， Docker ではメタルとほぼ同様の性能を引き出すことができるとされている．

その他， VM との相違点などはたくさんあるのだが，ここではこれ以上詳細には立ち入らない． 大事なのは， Docker とはとてもコンパクトかつハイパフォーマンスな仮想計算環境を作るツールである，という点である． その手軽さゆえに，2013年の登場以降，クラウドシステムでの利用が急速に増加し，現代のクラウドでは欠くことのできない中心的な技術になっている．

Docker とはなにかを理解するためには，実際に触って動かしてみるのが一番有効な手立てである． ここでは， Docker の簡単なチュートリアルを行っていく．

Docker のインストールについては， Section 15.6 および 公式のドキュメンテーション を参照してもらいたい． Docker のインストールが完了している前提で，以下は話を進めるものとする．

ここまでに説明してきたように， Docker を使うことで仮想計算環境を簡単に複製・起動することが可能になる． 本章の最後の話題として， AWS 上で Docker を使った計算システムを構築する方法を解説しよう．

Elastic Container Service (ECS) とは， Docker を使った計算機クラスターを AWS 上に作成するためのツールである (Figure 42)． ECS を使用することで， Docker にパッケージされたアプリケーションを計算機クラスターに投入したり，計算機クラスターのインスタンスを追加・削除する操作 (=スケーリング) を行うことができる．

ECS の概要を示したのが Figure 43 である． ECS は，タスク (Task) と呼ばれる単位で管理された計算ジョブを受け付ける． システムにタスクが投入されると，ECS は最初にタスクで指定された Docker イメージを外部レジストリからダウンロードしてくる． 外部レジストリとしては， Docker Hub や AWS 独自の Docker レジストリである ECR (Elastic Container Registry) を指定することができる．

ECS の次の重要な役割はタスクの配置である． あらかじめ定義されたクラスター内で，計算負荷が小さい仮想インスタンスを選び出し，そこに Docker イメージを配置することで指定された計算タスクが開始される． "計算負荷が小さい仮想インスタンスを選び出す" と言ったが，具体的にどのような戦略・ポリシーでこの選択を行うかは，ユーザーの指定したパラメータに従う．

また，クラスターのスケーリングもECSにおける重要な概念である． スケーリングとは，クラスター内のインスタンスの計算負荷をモニタリングし，計算負荷に応じてインスタンスの起動・停止を行う操作を指す． クラスター全体の計算負荷が指定された閾値 (たとえば80%の稼働率) を超えていた場合，新たな仮想インスタンスをクラスター内に立ち上げる操作を scale-out (スケールアウト) とよび， 負荷が減った場合に不要なインスタンスを停止する操作を scale-in (スケールイン) とよぶ． クラスターのスケーリングは， ECS がほかの AWS のサービスと連携することで実現される． 具体的には， EC2 の Auto scaling group (ASG) や Fargate の２つの選択肢が多くの場合選択される． ASG については Section 9, Fargate については Section 8 でより詳細に解説する．

これら一連のタスクの管理を， ECS は自動でやってくれる． クラスターのスケーリングやタスクの配置に関してのパラメータを一度指定してしまえば，ユーザーは (ほとんどなにも考えずに) 大量のタスクを投入することができる． クラスターのスケーリングによってタスクの量にちょうど十分なだけのインスタンスが起動し，タスクが完了した後は不要なインスタンスはすべて停止される．

さて，ここまで説明的な話が続いてしまったが，次章からは早速 Docker と AWS を使って大規模な並列計算システムを構築していこう！

ハンズオンに入っていく前に， Fargate という AWS の機能を知っておく必要がある (Figure 44)．

ECS の概要を示した Figure 43 をもう一度見てみよう． この図で， ECS の管理下にあるクラスターが示されているが，このクラスターの中で計算を行う実体としては二つの選択肢がある． EC2 あるいは Fargate のいずれかである． EC2 を用いた場合は，先の章 (Section 4, Section 6) で説明したような流れでインスタンスが起動し，計算が実行される． しかし， EC2 を用いた計算機クラスターの作成・管理は技術的な難易度がやや高いので，次章 (Section 9) で説明することにする．

Fargate とは， ECS での利用に特化して設計された，コンテナを使用した計算タスクを走らせるための仕組みである． 計算を走らせるという点では EC2 と役割は似ているが， Fargate は EC2 インスタンスのような物理的実体はもたない． 物理的実体をもたないというのは，たとえば SSH でログインすることは基本的に想定されていないし，なにかのソフトウェアをインストールしたりなどの概念も存在しない． Fargate ではすべての計算は Docker コンテナを介して行われる． すなわち， Fargate を利用するには，ユーザーは最初に所望の Docker イメージを指定しておき， Fargate は docker run のコマンドを使用することで計算タスクを実行する． Fargate を用いる利点は， Fargate を ECS のクラスターに指定すると，スケーリングなどの操作が簡単な設定・プログラムで構築できる点である．

Fargate では， EC2 と同様に CPU とメモリーのサイズを必要な分だけ指定できる． 執筆時点では， CPU は 0.25 - 4 コア， RAM は 0.5 - 30 GB の間で選択することができる (詳しくは 公式ドキュメンテーション "Amazon ECS on AWS Fargate" 参照)． クラスターのスケーリングが容易な分， Fargate では EC2 ほど大きな CPU コア・ RAM 容量を単一インスタンスに付与することができず，また GPU を利用することもできない．

以上が Fargate の概要であったが，くどくど言葉で説明してもなかなかピンとこないだろう． ここからは実際に手を動かしながら， ECS と Fargate を使った並列タスクの処理の仕方を学んでいこう．

ハンズオンのソースコードは GitHub の handson/qa-bot にある．

本ハンズオンの実行には，第一回ハンズオンで説明した準備 (Section 4.1) が整っていることを前提とする． また， Docker が自身のローカルマシンにインストール済みであることも必要である．

このハンズオンで開発する，自動質問回答システムをより具体的に定義しよう． 次のような文脈 (context) と質問 (question) が与えられた状況を想定する．

今回作成する自動回答システムは，このような問題に対して， context に含まれる文字列から正解となる言葉を見つけ出すものとする． 上の問題では，次のような回答を返すべきである．

人間にとっては，このような文章を理解することは容易であるが，コンピュータにそれを解かせるのは難しいことは容易に想像ができるだろう． しかし，近年の深層学習を使った自然言語処理の進歩は著しく，上で示したような例題などは極めて高い正答率で回答できるモデルを作ることができる．

今回は， huggingface/transformers で公開されている学習済みの言語モデルを利用することで，上で定義した問題を解く Q&A ボットを作る． この Q&A ボットは Transformer とよばれるモデルを使った自然言語処理に支えられえている (Figure 45)． このプログラムを， Docker にパッケージしたものが 著者の Docker Hub リポジトリ に用意してある． クラウドの設計に入る前に，まずはこのプログラムを単体で動かしてみよう．

次のコマンドで，今回使う Docker image を ローカルにダウンロード (pull) してこよう．

pull できたら，早速この Docker に質問を投げかけてみよう． まずは context とquestion をコマンドラインの変数として定義する．

そうしたら，次のコマンドによってコンテナを実行する．

今回用意した Docker image は，第一引数に context となる文字列を，第二引数に question に相当する文字列を受けつける． 第三引数，第四引数については，クラウドに展開するときの実装上の都合なので，いまは気にしなくてよい．

このコマンドを実行すると，次のような出力が得られるはずである．

"score" は正解の自信度を表す数字で， [0,1] の範囲で与えられる． "start", "end" は， context 中の何文字目が正解に相当するかを示しており， "answer" が正解と予測された文字列である． 1921 年という，正しい答えが返ってきていることに注目してほしい．

もう少し難しい質問を投げかけてみよう．

出力：

今度は， score が 0.52 と，少し自信がないようだが，それでも正しい答えにたどりつけていることがわかる．

このように， 深層学習に支えられた言語モデルを用いることで，実用にも役に立ちそうな Q&A ボットを実現できていることがわかる． 以降では，このプログラムをクラウドに展開することで，大量の質問に自動で対応できるようなシステムを設計していく．

このハンズオンで作成するアプリケーションの概要を Figure 46 に示す．

簡単にまとめると，以下のような設計である．

それでは，プログラムのソースコードを見てみよう (handson/qa-bot/app.py)．

スタックの中身が理解できたところで，早速スタックをデプロイしてみよう．

デプロイの手順は，これまでのハンズオンとほとんど共通である． SSH によるログインの必要がないので，むしろ単純なくらいである． ここでは，コマンドのみ列挙する (# で始まる行はコメントである)． それぞれの意味を忘れてしまった場合は，ハンズオン1, 2に戻って復習していただきたい． シークレットキーの設定も忘れずに (Section 15.3)．

デプロイのコマンドが無事に実行されれば， Figure 47 のような出力が得られるはずである．

AWS コンソールにログインして，デプロイされたスタックの中身を確認してみよう． コンソールから，ECS のページに行くと Figure 48 のような画面が表示されるはずである． EcsClusterQaBot-XXXX という名前ついたクラスターを見つけよう．

Cluster というのが，先ほど説明したとおり，複数の仮想インスタンスを束ねる一つの単位である． Figure 48 で， FARGATE という文字の下に 0 Running tasks, 0 Pending tasks と表示されていることを確認しよう． この時点では一つもタスクが走っていないので，数字はすべて0になっている．

続いて，この画面の左のメニューバーから Task Definitions という項目を見つけ，クリックしよう． 移動した先のページで EcsClusterQaBotEcsClusterQaBotTaskDefXXXX という項目が見つかるので，開く． 開いた先のページをスクロールすると Figure 49 に示したような情報が見つかるだろう． 使用する CPU ・メモリーの量や， Docker container の実行に関する設定などが，この Task Definition の画面から確認することができる．

それでは，質問をデプロイしたクラウドに提出してみよう．

ECS にタスクを投入するのはやや複雑なので，タスクの投入を簡単にするプログラム (run_task.py) を用意した (handson/qa-bot/run_task.py)．

次のようなコマンドで，ECSクラスターに新しい質問を投入することができる．

"ask" の引数に続き，文脈 (context) と質問 (question) を引数として渡している．

このコマンドを実行すると， "Waiting for the task to finish…​" と出力が表示され，回答を得るまでしばらく待たされる． この間， AWS では ECS がタスクを受理し，新しい Fargate のインスタンスを起動し， Docker イメージをそのインスタンスに配置する，という一連の処理がなされている． AWS コンソールから，この一連の様子をモニタリングしてみよう．

先ほどの ECS コンソール画面にもどり，クラスターの名前をクリックすることで，クラスターの詳細画面を開く． 次に， "Tasks" という名前のタブがあるので，それを開く (Figure 50)． すると，実行中のタスクの一覧が表示されるだろう．

Figure 50 で見て取れるように， "Last status = Pending" となっていることから，この時点では，タスクを実行する準備をしている段階である，ということがわかる． Fargate のインスタンスを起動し， Docker image を配置するまでおよそ1-2分の時間がかかる．

しばらく待つうちに， Status が "RUNNING" に遷移し，計算が始まる． 計算が終わると， Status は "STOPPED" に遷移し， ECS によって Fargate インスタンスは自動的にシャットダウンされる．

Figure 50 の画面から， "Task" の列にあるタスクIDクリックすることで，タスクの詳細画面を開いてみよう (Figure 51)． "Last status", "Platform version" など，タスクの情報が表示されている． また， "Logs" のタブを開くことで，コンテナの吐き出した実行ログを閲覧することができる．

さて， run_task.py を実行したコマンドラインに戻ってきてみると， Figure 52 のような出力が得られているはずである． "Momotaro" という正しい回答が返ってきている！

さて，先ほどはたった一つの質問を投入したわけだが，今回設計したアプリケーションは， ECS と Fargate を使うことで同時にたくさんの質問を処理することができる． 実際に，たくさんの質問を一度に投入してみよう． run_task.py に ask_many というオプションを付けることで，複数の質問を一度に送信できる． 質問の内容は handson/qa-bot/problems.json に定義されている．

次のようなコマンドを実行しよう．

このコマンドを実行した後で，先ほどの ECS コンソールに行き，タスクの一覧を見てみよう (Figure 53)． 複数の Fargate インスタンスが起動され，タスクが並列に実行されているのがわかる．

すべてのタスクのステータスが "STOPPED" になったことを確認した上で，質問への回答を取得しよう． それには，次のコマンドを実行する．

結果として， Figure 54 のような出力が得られるだろう． 複雑な文章問題に対し，高い正答率で回答できていることがわかるだろう．

おめでとう！ ここまでついてこれた読者はとても初歩的ながらも，深層学習による言語モデルを使って自動で質問への回答を生成するシステムを創り上げることができた！ それも，数百の質問にも同時に対応できるような，とても高いスケーラビリティーをもったシステムである！ 今回は GUI (Graphical User Interface) を用意することはしなかったが，このシステムに簡単な GUI を追加すればなかなか立派なウェブサービスとして運用できるだろう．

これにて，今回のハンズオンは終了である． 最後にスタックを削除しよう．

スタックを削除するには，前回までと同様に， AWS コンソールにログインし CloudFormation の画面から DELETE ボタンをクリックするか，コマンドラインからコマンドを実行する． コマンドラインから行う場合は，次のコマンドを使用する．

ハンズオンに入っていく前に， Auto scaling groups (ASG) とよばれる EC2 の概念を知っておく必要がある．

ECS の概要を示した Figure 43 を振り返って見てほしい． 前章 (Section 8) でも説明したが， ECS のクラスターで計算を担う実体としては EC2 と Fargate を指定することができる． Fargate については前章で記述した． Fargate を用いると，自在にスケールする計算環境をとても簡単な設定で構築することができた． しかし， GPU を利用することができないなど，いくつかの制約があった． EC2 を使用した計算環境を指定することで，プログラミングの複雑度は増すが， GPU やその他のより高度かつ複雑な設定を伴ったクラスターを構築することができる．

EC2 クラスターには ASG と呼ばれるサービスが配置される． ASG は複数の EC2 インスタンスをロジカルな単位でグループ化することでクラスターを構成する． ASG はクラスター内に新しいインスタンスを起動する，あるいは不要になったインスタンスを停止するなどのスケーリングを担う． ASG で重要な概念として， desired capacity, minimum capacity, maximum capacity というパラメータがある． minimum capacity， maximum capacity は，それぞれクラスター内に配置できるインスタンスの数の最小値・最大値を指定するパラメータである． 前者は，クラスターに負荷がかかっていない場合でもアイドリング状態にあるインスタンスを維持することで，急に負荷が増大した時などのバッファーとして作用することができる． 後者は，負荷が急に増えたときに，過剰な数のインスタンスが起動する事態を防ぎ，経済的なコストの上限を定める役割を果たす．

desired capacity が，その時々でシステムが要求するインスタンスの数を指定する． desired capacity は，例えば24時間のリズムに合わせてインスタンスの数を増減させる (昼は多く夜は少なくなど) などの決まったスケジュールに基づいた設定を適用することができる． あるいはクラスター全体にかかっている負荷に応じて， desired capacity を動的に制御することも可能である． どのような基準でクラスターのスケーリングを行うかを定めるルールのことを，スケーリングポリシーとよぶ． たとえば，クラスター全体の稼働率 (負荷) を常に 80% に維持する，などのスケーリングポリシーが想定できる． この場合，クラスター全体の負荷が80%を下回ったときにはクラスターからインスタンスが削除され，80%を超える (あるいは超えると予測される) 場合はインスタンスを追加する，という操作が ASG によって自動的に行われる．

上記のようなパラメータを検討し，ユーザーは ASG を作成する． ASG を作成したのち， ECS との連携をプログラムしてあげることで， ECS を介して ASG による EC2 クラスターにタスクを投入することが可能になる．

先に説明したように， ECS と ASG を組み合わせることで，所望の計算クラスターを構築することが可能である． しかしながら， ECS と ASG にはかなり込み入った設定が必要であり，初心者にとっても経験者にとってもなかなか面倒なプログラミングが要求される． そこで， ECS と ASG によるクラスターの設計を自動化してくれるサービスが提供されている． それが AWS Batch である．

AWS Batch はその名のとおりバッチ (Batch) 化されたジョブ (入力データだけが異なる独立した演算が繰り返し実行されること) を想定している． 多くの科学計算や機械学習がバッチ計算に当てはまる． たとえば，初期値のパラメータを変えて複数のシミュレーションを走らせる，といったケースだ． AWS Batch を用いることの利点は，クラスターのスケーリングやジョブの割り振りはすべて自動で実行され， ユーザーはクラウドの舞台裏の詳細を気にすることなく，大量のジョブを投入できるシステムが手に入る点である． が，知識として背後では ECS/ASG/EC2 の三つ巴が協調して動作しているという点は知っておいてほしい．

AWS Batch では，ジョブの投入・管理をスムーズに行うため，次のような概念が定義されている (Figure 56)． まず， ジョブ (Job) というのが，AWS Batch によって実行される一つの計算の単位である． Job definitions とはジョブの内容を定義するものであり，これには実行されるべき Docker のイメージのアドレスや，割り当てる CPU・RAM の容量，環境変数などの設定が含まれる． Job definition に基づいて個々のジョブが実行される． ジョブが実行されると，ジョブは Job queues に入る． Job queues とは，実行待ち状態にあるジョブの列のことであり，時間的に最も先頭に投入されたジョブが最初に実行される． また，複数の queue を配置し， queue ごとに priority (優先度) を設定することが可能であり， priority の高い queue に溜まったジョブが優先的に実行される (筆者はこれをディズニーランドの"ファストパス"を連想して捉えている)． Compute environment とは，先述したクラスターとほぼ同義の概念であり，計算が実行される場所 (EC2 や Fargate からなるクラスター) を指す． Compute environment には，使用する EC2 のインスタンスタイプや同時に起動するインスタンス数の上限などの簡易なスケーリングポリシーが指定されている． Job queues は Compute environment の空き状況を監視しており， それに応じてジョブを Compute environment に投下する．

以上が AWS Batch を使用するうえで理解しておかなければならない概念であるが，くどくど言葉で説明してもなかなかピンとこないだろう． ここからは，実際に自分で手を動かしながら学んでいこう．

ハンズオンのソースコードは GitHub の handson/aws-batch にある．

本ハンズオンの実行には，第一回ハンズオンで説明した準備 (Section 4.1) が整っていることを前提とする． また， Docker が自身のローカルマシンにインストール済みであることも必要である．

今回のハンズオンでは，機械学習のハイパーパラメータ調整を取り上げると冒頭で述べた． その最もシンプルな例題として， Section 6.7 で扱った MNIST 手書き文字認識の問題を再度取り上げよう． Section 6.7 では，適当にチョイスしたハイパーパラメータを用いてモデルの訓練を行った． ここで使用したプログラムのハイパーパラメータとしては，確率的勾配降下法 (SGD) における学習率やモメンタムが含まれる． コードでいうと，次の行が該当する．

ここで使用された 学習率 (lr=0.01) やモメンタム (momentum=0.5) は恣意的に選択された値であり，これがベストな数値であるのかはわからない． たまたまこのチョイスが最適であるかもしれないし，もっと高い精度を出すハイパーパラメータの組が存在するかもしれない． この問題に答えるため，ハイパーパラメータサーチを行おう． 今回は，最もシンプルなアプローチとして，グリッドサーチによるハイパーパラメータサーチを行おう．

まずは，本ハンズオンで使用する Docker イメージをローカルで実行してみよう．

Docker イメージのソースコードは handson/aws-batch/docker にある． 基本的に Section 6.7 のハンズオンを元にし，本ハンズオン専用の軽微な変更が施してある． 興味のある読者はソースコードも含めて読んでいただきたい．

練習として，この Docker イメージを手元でビルドするところからはじめてみよう． Dockerfile が保存されているディレクトリに移動し， mymnist という名前 (Tag) をつけてビルドを実行する．

イメージの準備ができたら，次のコマンドでコンテナを起動し， MNIST の学習を実行する．．

このコマンドを実行すると，指定したハイパーパラメータ (--lr で与えられる学習率と --momentum で与えられるモメンタム) を使ってニューラルネットの最適化が始まる． 学習を行う最大のエポック数は --epochs パラメータで指定する． Section 6 のハンズオンで見たような， Loss の低下がコマンドライン上に出力されるだろう (Figure 57)．

上に示したコマンドを使うと，計算は CPU を使って実行される． もし，ローカルの計算機に GPU が備わっており， nvidia-docker の設定が済んでいるならば， 次のコマンドにより GPU を使って計算を実行できる．

このコマンドでは，--gpus all というパラメータが加わった．

CPU/GPU どちらで実行した場合でも，エポックを重ねるにつれて訓練データ (Train データ) の Loss は単調に減少していくのが見て取れるだろう． 一方，検証データ (Validation データ) の Loss および Accuracy は，ある程度まで減少した後，それ以上性能が向上しないことに気がつくだろう． これを実際にプロットしてみると Figure 58 のようになるはずである．

これはオーバーフィッティングとよばれる現象で，ニューラルネットが訓練データに過度に最適化され，訓練データの外のデータに対しての精度 (汎化性能) が向上していないことを示している． このような場合の対処法として， Early stopping とよばれるテクニックが知られている． Early stopping とは，検証データの Loss を追跡し，それが減少から増加に転じるエポックで学習をうち止め，そのエポックでのウェイトパラメータを採用する，というものである． 本ハンズオンでも， Early stopping によって訓練の終了を判断し，モデルの性能評価を行っていく．

このハンズオンで作成するアプリケーションの概要を Figure 59 に示す．

簡単にまとめると，次のような設計である．

それでは，プログラムのソースコードを見てみよう (handson/aws-batch/app.py)．

スタックの中身が理解できたところで，早速スタックをデプロイしてみよう．

デプロイの手順は，これまでのハンズオンとほとんど共通である． ここでは，コマンドのみ列挙する (# で始まる行はコメントである)． シークレットキーの設定も忘れずに (Section 15.3)．

デプロイのコマンドが無事に実行されたことが確認できたら，AWS コンソールにログインして，デプロイされたスタックを確認してみよう． コンソールの検索バーで batch と入力し， AWS Batch の管理画面を開く (Figure 61)．

まず目を向けてほしいのが，画面の一番下にある Compute environment overview の中の SimpleBatchcompute-env という名前の項目だ． Compute environment とは，先ほど述べたとおり，計算が実行される環境 (クラスターと読み替えてもよい) である． プログラムで指定したとおり， g4dn.xlarge が実際に使用されるインスタンスタイプとして表示されている． また， Minimum vCPUs が0，Maximum vCPUs が 64 と設定されていることも見て取れる． 加えて，この時点では一つもジョブが走っていないので， Desired vCPUs は0になっている． より詳細な Compute environment の情報を閲覧したい場合は，名前をクリックすることで詳細画面が開く．

次に，Job queue overview にある SimpleBatch-queue という項目に注目してほしい． ここでは実行待ちのジョブ・実行中のジョブ・実行が完了したジョブを一覧で確認することができる． PENDING, RUNNING, SUCCEEDED, FAILED などのカラムがあることが確認できる．ジョブが進行するにつれて，ジョブの状態がこのカラムにしたがって遷移していく． 後でジョブを実際にサブミットしたときに戻ってこよう．

最後に，今回作成した Job definition を確認しよう． 左側のメニューから　Job definitions を選択し，次の画面で SimpleBatchjob-definition という項目を見つけて開く． ここから Job definition の詳細を閲覧することができる (Figure 62)． 中でも重要な情報としては，　vCPUs, Memory, GPU がそれぞれ Docker に割り当てられる vCPU・メモリー・ GPU の量を規定している． また， Image と書いてあるところに，ジョブで使用される Docker イメージが指定されている． ここでは， ECR のレポジトリを参照している． 現時点ではこの ECR は空である． 次のステップとして，この ECR にイメージを配置する作業を行おう．

さて， Batch がジョブを実行するには，どこか指定された場所から Docker イメージをダウンロード (pull) してくる必要がある． 前回のハンズオン (Section 8) では，公開設定にしてある Docker Hub からイメージを pull してきた． 今回のハンズオンでは， AWS から提供されているレジストリである ECR (Elastic Container Registry) に image を配置するという設計を採用する． ECR を利用する利点は，自分だけがアクセスすることのできるプライベートなイメージの置き場所を用意できる点である． Batch は ECR からイメージを pull してくることで，タスクを実行する (Figure 59)．

スタックのソースコードでいうと，次の箇所が ECR を定義している．

さて，スタックをデプロイした時点では， ECR は空っぽである． ここに自分のアプリケーションで使う Docker イメージを push してあげる必要がある．

そのために，まずは AWS コンソールから ECR の画面を開こう (検索バーに Elastic Container Registry と入力すると出てくる)． Private というタブを選択すると， simplebatch-repositoryXXXXXX という名前のレポジトリが見つかるだろう (Figure 63)．

次に，このレポジトリの名前をクリックするとレポジトリの詳細画面に遷移する． そうしたら，画面右上にある View push commands というボタンをクリックする． すると Figure 64 のようなポップアップ画面が立ち上がる．

このポップアップ画面で表示されている四つのコマンドを順番に実行していくことで，手元の Docker イメージを ECR に push することができる． push を実行する前に， AWS の認証情報が設定されていることを確認しよう． そのうえで，ハンズオンのソースコードの中にある docker/ という名前のディレクトリに移動する． そうしたら，ポップアップ画面で表示されたコマンドを上から順に実行していく．

四つ目のコマンドは，数GBあるイメージを ECR にアップロードするので少し時間がかかるかもしれないが，これが完了するとめでたくイメージが ECR に配置されたことになる． もう一度 ECR のコンソールを見てみると，確かにイメージが配置されていることが確認できる (Figure 65)． これで，AWS Batch を使ってジョブを実行させるための最後の準備が完了した．

さて，ここからは実際に AWS Batch にジョブを投入する方法を見ていこう．

ハンズオンのディレクトリの notebook/ というディレクトリの中に， run_single.ipynb というファイルが見つかるはずである (.ipynb は Jupyter notebook のファイル形式)． これを Jupyter notebook から開こう．

今回のハンズオンでは， venv による仮想環境の中に Jupyter notebook もインストール済みである． なので，ローカルマシンから以下のコマンドで Jupyter notebook を立ち上げる．

Jupyter notebook が起動したら， run_single.ipynb を開く．

最初の [1], [2], [3] 番のセルは，ジョブをサブミットするための関数 (submit_job()) を定義している．

submit_job() 関数について簡単に説明しよう． Section 9.4 で， MNIST の Docker をローカルで実行したとき，次のようなコマンドを使用した．

ここで， --lr 0.1 --momentum 0.5 --epochs 10 の部分が，コンテナに渡されるコマンドである．

AWS Batch でジョブを実行する際も，ContainerOverrides の command というパラメータを使用することで，コンテナに渡されるコマンドを指定することができる． コードでは以下の部分が該当する．

続いて， [4] 番のセルに移ろう． ここでは，上記の submit_job() 関数を用いて， 学習率 = 0.01, モメンタム=0.1, エポック数=100 を指定したジョブを投入する．

[4] 番のセルを実行したら，ジョブが実際に投入されたかどうかを AWS コンソールから確認してみよう． AWS Batch の管理コンソールを開くと， Figure 66 のような画面が表示されるだろう．

Figure 66 で赤で囲った箇所に注目してほしい． 一つのジョブが投入されると，それは SUBMITTED という状態を経て RUNNABLE という状態に遷移する． RUNNABLE とは， ジョブを実行するためのインスタンスが Compute environment に不足しているため，新たなインスタンスが起動されるのを待っている状態に相当する． インスタンスの準備が整うと，ジョブの状態は STARTING を経て RUNNING に至る．

次に，ジョブのステータスが RUNNING のときの Compute environment の Desired vCPU を見てみよう (Figure 66 で紫で囲った箇所)． ここで 4 と表示されているのは， g4dn.xlarge インスタンス一つ分の vCPU の数である． ジョブの投入に応じて，それを実行するのに最低限必要な EC2 インスタンスが起動されたことが確認できる (興味のある人は， EC2 コンソールも同時に覗いてみるとよい)．

しばらく経つと，ジョブの状態は RUNNING から SUCCEEDED (あるいは何らかの理由でエラーが発生したときには FAILED) に遷移する． 今回のハンズオンで使っている MNIST の学習はだいたい 10 分くらいで完了するはずである． ジョブの状態が SUCCEEDED になるまで見届けよう．

ジョブが完了すると，学習の結果 (エポックごとの Loss と Accuracy を記録した CSV ファイル) は S3 に保存される． AWS コンソールからこれを確認しよう．

S3 のコンソールに行くと simplebatch-bucketXXXX (XXXX の部分はユーザーによって異なる) という名前のバケットが見つかるはずである． これをクリックして中身を見てみると， metrics_lr0.0100_m0.1000.csv という名前の CSV があることが確認できるだろう (Figure 67)． これが， 学習率 = 0.01, モメンタム = 0.1 として学習を行ったときの結果である．

さて，ここで run_single.ipynb に戻ってこよう． [5] から [7] 番のセルでは，学習結果の CSV ファイルのダウンロードを行っている．

[6] で S3 から CSV データをダウンロードし， pandas の DataFrame オブジェクトとしてロードする関数を定義している． [7] を実行する際， bucket_name という変数の値を，自分自身のバケットの名前に置き換えることに注意しよう (先ほど S3 コンソールから確認した simplebatch-bucketXXXX のことである)．

続いて， [9] 番のセルで， CSV のデータをプロットしている (Figure 68)． ローカルで実行したときと同じように， AWS Batch を用いて MNIST モデルを訓練することに成功した！

さて，ここからが最後の仕上げである． ここまでのハンズオンで構築した AWS Batch のシステムを使って，ハイパーパラメータサーチを実際に行おう．

先ほど実行した run_single.ipynb と同じディレクトリにある run_sweep.ipynb を開く．

セル [1], [2], [3] は run_single.ipynb と同一である．

セル [4] の for ループを使って，グリッド状にハイパーパラメータの組み合わせを用意し， batch にジョブを投入している． ここでは 3x3=9個のジョブを作成した．

セル [4] を実行したら， Batch のコンソールを開こう． 先ほどと同様に，ジョブのステータスは SUBMITTED > RUNNABLE > STARTING > RUNNING と移り変わっていくことがわかるだろう． 最終的に 9 個のジョブがすべて RUNNING の状態になることを確認しよう (Figure 69)． また，このとき Compute environment の Desired vCPUs は 4x9=36 となっていることを確認しよう (Figure 69)．

次に，Batch のコンソールの左側のメニューから Jobs をクリックしてみよう． ここでは，実行中のジョブの一覧が確認することができる (Figure 70)． ジョブのステータスでフィルタリングをすることも可能である． 9個のジョブがどれも RUNNING 状態にあることが確認できるだろう．

今度は EC2 コンソールを見てみよう． 左のメニューから Instances を選択すると， Figure 71 に示すような起動中のインスタンスの一覧が表示される． g4dn.xlarge が 9 台稼働しているのが確認できる． Batch がジョブの投下に合わせて必要な数のインスタンスを起動してくれたのだ！

ここまで確認できたら，それぞれの Job が終了するまでしばらく待とう (だいたい 10-15 分くらいで終わる)． すべてのジョブが終了すると，ダッシュボードの SUCCEEDED が 9 となっているはずだ． また， Compute environment の Desired vCPUs も 0 に落ちていることを確認しよう． 最後に EC2 コンソールに行って，すべての g4dn インスタンスが停止していることを確認しよう．

以上から， AWS Batch を使うことで，ジョブの投入に応じて自動的に EC2 インスタンスが起動され，ジョブの完了とともに，ただちにインスタンスの停止が行われる一連の挙動を観察することができた． 一つのジョブの完了におよそ10分の時間がかかるので，9個のハイパーパラメータの組を逐次的に計算していた場合は90分の時間を要することになる． AWS Batch を使ってこれらの計算を並列に実行することで，ジョブ一個分の計算時間 (=10分) ですべての計算を終えることができた！

さて，再び run_sweep.ipynb に戻ってこよう． [5] 以降のセルでは，グリッドサーチの結果を可視化している．

最終的に出力されるプロットが Figure 72 である．

このプロットから，差は僅かであるが，学習率が 0.1 のときに精度は最大となることがわかる． また，学習率 0.1 のときはモメンタムを変えても大きな差は生じないことが見て取れる．

以上のようにして， CNN を用いた MNIST 分類モデルのハイパーパラメータの最適化の一連の流れを体験した． AWS Batch を利用することで，比較的少ないプログラミングで，動的に EC2 クラスターを制御し，並列にジョブを処理するシステムが構築できた． ここまで EC2 を使いこなすことができれば，多くの問題を自力で解くことが可能になるだろう！

これにて，本ハンズオンは終了である．最後にスタックを削除しよう． 今回のスタックを削除するにあたり，ECR に配置された Docker のイメージは手動で削除されなければならない (これをしないと， cdk destroy を実行したときにエラーになってしまう． これは CloudFormation の仕様なので従うしかない)．

ECR の Docker image を削除するには， ECR のコンソールに行き，イメージが配置されたレポジトリを開く． そして，画面右上の DELETE ボタンを押して削除する (Figure 73)．

あるいは， AWS CLI から同様の操作を行うには，以下のコマンドを用いる (XXXX は自分の ECR レポジトリ名に置き換える)．

image の削除が完了したうえで，次のコマンドでスタックを削除する．

[sec:batch_development_and_debug] === クラウドを用いた機械学習アプリケーションの開発とデバッグ

本章で紹介したハンズオンでは， AWS Batch を使用することでニューラルネットの学習を複数並列に実行し，高速化を実現した． 本章の最後の話題として，クラウドを用いた機械学習アプリケーションの開発とデバッグの方法について述べよう．

ローカルに GPU を搭載した強力なマシンがなく，クラウドを利用する予算が確保されているのであれば， Figure 74 のような開発のスキームが理想的であると考える． 最初の段階では， Section 6 で見たような方法で， GPU 搭載型の EC2 インスタンスを作成し， Jupyter Notebook などのインタラクティブな環境で様々なモデルを試し実験を行う． Jupyter である程度アプリケーションが完成してきたタイミングで，作成したアプリケーションを Docker イメージにパッケージングする． そして， EC2 上で docker run を行い，作成したイメージがバグなく動作するか確認を行う． その次に，ハイパーパラメータの最適化などのチューニングを， Section 9 のハンズオンで学んだ AWS Batch などの計算システムを利用して行う． よい深層学習モデルが完成したら，仕上げに大規模データへの推論処理を行うシステムを Section 8 を参考に構築する．

実際，本書ではこの流れに沿って演習を進めてきた． MNIST タスクを解くモデルを，最初 Jupyter Notebook を使用して実験し，そのコードをほとんどそのまま Docker にパッケージし， AWS Batch を用いてハイパーパラメータサーチを行った． このサイクルを繰り返すことで，クラウドを最大限に活用した機械学習アプリケーションの開発を進めることができる．

ここまでが，本書第二部の内容である． 第一部に引き続き盛りだくさんの内容であったが，ついてこれたであろうか？

第二部ではまず最初に，深層学習の計算をクラウドで実行するため， GPU 搭載型の EC2 インスタンスの起動について解説した． さらに，ハンズオンでは，クラウドに起動した仮想サーバーを使って MNIST 文字認識タスクを解くニューラルネットを訓練した (Section 6)．

また，より大規模な機械学習アプリケーションを作るための手段として， Docker と ECS によるクラスターの初歩を説明した (Section 7)． その応用として，英語で与えられた文章問題への回答を自動で生成するボットをクラウドに展開した (Section 8)． タスクの投入に応じて動的に計算リソースが作成・削除される様子を実際に体験できただろう．

さらに， Section 9 では AWS Batch を用いてニューラルネットの学習を並列に実行する方法を紹介した． ここで紹介した方法は，ミニマムであるが，計算機システムを大規模化していくためのエッセンスが網羅されている． これらのハンズオン体験から，クラウド技術を応用してどのように現実世界の問題を解いていくのか，なんとなくイメージが伝わっただろうか？

本書の第三部では，さらにレベルアップし，サーバーレスアーキテクチャという最新のクラウドの設計手法について解説する． その応用として，ハンズオンでは簡単な SNS サービスをゼロから実装する． 引き続きクラウドの最先端の世界を楽しんでいこう！

あなたがパソコンやスマートフォンから Twitter, Facebook, YouTube などのウェブサービスにアクセスしたとき，実際にどのようなことが行われ，コンテンツが提示されているのだろうか？

HTTP を通じたサーバーとクライアントのデータのやり取りは，すでに知っている読者も多いだろうし，逆にすべて解説しようとすると紙面が足りないので，ここではエッセンスの説明のみにとどめる． 以降では Twitter を具体例として，背後にあるサーバーとクライアントの間の通信を概説しよう． 概念図としては Figure 75 のような通信がクライアントとサーバーの間で行われていることになる．

前提として，クライアントとサーバーの通信は HTTP (Hypertext Transfer Protocol) を使って行われる． また，最近では，暗号化された HTTP である HTTPS (HTTPS (Hypertext Transfer Protocol Secure)) を用いることがスタンダードになってきている． 第一のステップとして，クライアントは HTTP(S) 通信によってサーバーから静的なコンテンツを取得する． 静的なコンテンツとは， HTML (Hyptertext Markup Language) で記述されたウェブページの文書本体， CSS (Cascading Style Sheets) で記述されたページのデザインやレイアウトファイル，そして JavaScript (JS) で記述されたページの動的な挙動を定義したプログラム，が含まれる． Twitter を含む現代的なウェブアプリケーションの設計では，この静的なファイル群はページの”枠”を定義するだけで，中身となるコンテンツ (例: ツイートの一覧) は別途 API (Application Programming Interface) によって取得されなければならない． そこで，クライアントは先のステップで取得された JavaScript で定義されたプログラムに従って，サーバーに API を送信し，ツイートや画像データを取得する． この際，テキストデータのやり取りには JSON (JavaScript Object Notation) というフォーマットが用いられることが多い． 画像や動画などのコンテンツも同様にAPIにより取得される． このようにして取得されたテキストや画像が，HTMLの文書に埋め込まれることで，最終的にユーザーに提示されるページが完成するのである． また，新しいツイートを投稿するときにも，クライアントから API を通じてサーバーのデータベースにデータが書き込まれる．

API (Application Programming Interface) とはこれまで何度も出てきた言葉であるが，ここではよりフォーマルな定義付けを行う． API とはあるソフトウェア・アプリケーションが，外部のソフトウェアに対してコマンドやデータをやり取りするための媒介の一般的総称である． とくに，ウェブサービスの文脈では，サーバーが外界に対して提示しているコマンドの一覧のことを意味する． クライアントは，提示されている API から適切なコマンドを使うことによって，所望のデータを取得したり，あるいはサーバーにデータを送信したりする．

とくに，ウェブの文脈では REST (Representational State Transfer) とよばれる設計思想に基づいた API が現在では最も一般的に使われている． REST の設計指針に従った API のことを REST API あるいは RESTful API とよんだりする．

REST API は， Figure 76 に示したような Method と URI (Universal Resource Identifier) の組からなる．

Method (メソッド) とは，どのような操作を行いたいかを抽象的に表す，"動詞" として捉えることができる． メソッドには HTTP 規格で定義された9個の動詞 (verb) を使用することができる． この中でも， GET, POST, PUT, PATCH, DELETE の5個が最も頻繁に使用される (Table 6)． この5つのメソッドによる操作を総称して CRUD (create, read, update, and delete) とよぶ．

一方， URI は操作が行われる対象，すなわち "目的語" を表す． ウェブの文脈では操作が行われる対象のことをしばしば リソース とよぶ． URI は多くの場合 http または https から始まるウェブサーバーのアドレスから始まり， / (スラッシュ) 以降に所望のリソースのパスが指定される． Figure 76 の例で言えば， https://api.twitter.com というアドレスの /1.1/status/home_timeline というリソースを取得 (GET) せよ，という意味になる (なお，ここで 1.1 という数字は API のバージョンを示している)． この API リクエストによって，ユーザーのホームのタイムラインのツイートの一覧が取得される．

もう少し具体的にウェブサービスのAPIを体験する目的で，ここでは Twitter のAPIを見てみよう． Twitter が提供している API の一覧は Twitter の Developer Documentation で見ることができる． いくつかの代表的な API を Table 7 にまとめた．

この API リストをもとに， Twitter のアプリまたはウェブサイトを開いたときに起こるクライアントとサーバーの通信をシミュレートしてみよう．

ユーザーが Twitter を開くと，まず最初に GET statuses/home_timeline の API リクエストによって，ユーザーのホームのタイムラインのツイートのリストが取得される． 個々のツイートは JSON 形式のデータになっており， id, text, user, coordinates, entities などの属性を含む． id はツイートに固有な ID を表し， text はツイートの本文を含んでいる． user はツイートを投稿したユーザーの名前やプロフィール画像の URL などを含んだ JSON データになっている． coordinates にはツイートが発信された地理的な座標が記録されている． また， entities にはツイートに関連するメディアファイル (画像など) のリンクなどの情報が埋め込まれている． GET statuses/home_timeline からは直近のツイートのリスト (リストが長すぎる場合は途中で切られたもの) が取得される． もしツイートの ID を知っている場合は GET statuses/show/:id を呼ぶことによって， :id パラメータで指定された特定のツイートを取得することができる．

ツイートの検索を行うためには GET search API を使用する． この API には，ツイートに含まれる単語や，ハッシュタグ，ツイートの発信された日時や場所など，様々なクエリの条件を渡すことができる． API からは， GET statuses/home_timeline などと同様， JSON 形式のツイートのデータが返される．

ユーザーが新しいツイートを投稿するには POST statuses/update のエンドポイントを利用する． POST statuses/update には，ツイートの文章や，リプライの場合はリプライ先のツイートの ID などのデータを送信する． また，ツイートに画像データを添付したい場合は， POST media/upload を併せて使用する． ツイートの削除を行うには， POST statuses/destroy/:id を用いる．

そのほか，頻繁に行われる操作としては， POST statuses/retweet/:id と POST statuses/unretweet/:id がある． これらは， :id で指定されるツイートに対して，それぞれリツイートを実行あるいは取り消すための API である． また， POST favorites/create，POST favorites/destroy を使用することによって，選択されたツイートに"いいね"を追加したり，取り消したりする操作を行う．

このような一連の操作が， Twitter のアプリの背後では行われている． また，自分自身でボットを作成したい場合は，これらの API を適切に組み合わせ，カスタムのプログラムを書くことで実現される．

このように， API はあらゆるウェブサービスを作るうえで一番基礎となる要素である． 次からの章では本章で紹介した用語が何度も出てくるので，頭の片隅に置いたうえで読み進めていただきたい．

従来的なクラウドシステムのスケッチを Figure 77 に示す． クライアントから送信されたリクエストは，最初に API サーバーに送られる． API サーバーでは，リクエストの内容に応じてタスクが実行される． タスクには，APIサーバーだけで完結できるものもあるが，多くの場合，データベースの読み書きが必要である． データベースには，データベース専用の独立したサーバーマシンが用いられることが一般的である． また，画像や動画などの容量の大きいデータは，また別のストレージサーバーに保存されることが多い． これらの APIサーバー，データベースサーバー，ストレージサーバーはそれぞれ独立したサーバーマシンであり， AWS の言葉では EC2 による仮想インスタンスを想定してもらったらよい．

多くのウェブサービスでは，多数のクライアントからのリクエストを処理するため，複数のサーバーマシンがクラウド内で起動し，負荷を分散するような設計がなされている． クライアントから来たリクエストを計算容量に余裕のあるサーバーに振り分けるような操作を Load balancing とよび，そのような操作を担当するマシンのことを Load balancer という．

計算負荷を分散する目的で多数のインスタンスを起動するのはよいのだが，計算負荷が小さすぎてアイドリング状態にあるようではコストと電力の無駄遣いである． したがって，すべてのサーバーが常に目標とする計算負荷を維持するよう，計算の負荷に応じてクラスター内の仮想サーバーの数を動的に増減させるような仕組みが必要である． そのような仕組みをクラスターのスケーリングとよび，負荷の増大に応答して新しい仮想インスタンスをクラスターに追加する操作を scale-out，負荷の減少に応答してインスタンスをシャットダウンする操作を scale-in とよぶ． クラスターのスケーリングは， API サーバーではもちろんのこと，データベースサーバー・ストレージサーバーでも必要になる． ストレージサーバーでは，例えば頻繁にアクセスされるデータはキャッシュ領域に保存したり，データのコピーを複数作るなどのスケーリングが行われる． データベースサーバーも同様に，頻繁にアクセスされるデータのアクセスがパンクしてしまわないよう，分散的な処理が必要となる． このように，クラウドシステム内すべての箇所で，負荷が均一になるような調整が必要であり，開発者は多くの時間をそのチューニングに費やさなければならない． また，サービスの利用者の数などに応じてスケーリングの設定は常に見直される必要があり，継続的な開発が要求される．

さらに問題を複雑にするのは，APIサーバーで処理されるべきタスクが，非一様な点である． 非一様であるとは，たとえばタスクAは3000ミリ秒の実行時間と 512MB のメモリーを消費し，別のタスクBは1000ミリ秒の実行時間と 128MB のメモリーを消費する，というような状況を指している． 一つのサーバーマシンが計算負荷が異なる複数のタスクを処理する場合，クラスターのスケーリングはより複雑になる． この状況をシンプルにするために，１サーバーで実行するタスクは１種類に限る，という設計も可能であるが，そうするとで生まれる弊害も多い (ほとんど使われないタスクに対してもサーバー一台をまるまる割り当てなければならない = ほとんどアイドリング状態になってしまう，など)．

Section 11.1 で議論したように，クラスターのスケーリングはクラウドシステムの経済的効率とシステムの安定性を最大化するために必須の作業である． それを反映して，多くの開発者の時間が投資されてきた．

クラスターのスケーリングはすべての開発者が何度も繰り返し行ってきた作業であり，いくつかの側面をテンプレート化し，共通化することができたならば開発のコストを大幅に削減できるだろう． それを実現するには，根本的なレベルからクラウドシステムの設計を考え直す必要がある． スケーリングを前提として考えることで，もっとシンプルで見通しがよいクラウドシステムの設計の仕組みはないだろうか？ そのような動機が，サーバーレスアーキテクチャが誕生する背後にあった．

従来の serverful なシステムでの最大の問題点は，サーバーをまるまる占有してしまうという点にある． すなわち， EC2 インスタンスを起動したとき，そのインスタンスは起動したユーザーだけが使えるものであり，計算のリソース (CPUやRAM) が独占的に割り当てられた状態になる． 固定した計算資源の割り当てがされてしまっているので，インスタンスの計算負荷が0%であろうが100%であろうが，均一の使用料金が起動時間に比例して発生する．

サーバーレスアーキテクチャは，このような 独占的に割り当てられた計算リソースというものを完全に廃止することを出発点とする． サーバーレスアーキテクチャでは，計算のリソースは，クラウドプロバイダーがすべて管理する． クライアントは，仮想インスタンスを一台まるごと借りるのではなく，計算のタスクの需要が生まれる毎に，実行したいプログラム・コマンドをクラウドに提出する． クラウドプロバイダーは，自身のもつ巨大な計算リソースから空きを探し，提出されたプログラムを実行し，実行結果をクライアントに返す． 言い換えると，計算リソースのスケーリングやアロケーションなどはクラウドプロバイダーが一手に引き受け，ユーザーはジョブをサブミットすることに注力する，という枠組みである． これを図示すると， Figure 78 のようになる．

サーバーレスクラウドでは，スケーリングはすべてクラウドプロバイダーが引き受けるので，スケーラビリティーが保証されている． クライアントが同時に大量のタスクを送信した場合でも，クラウドプロバイダー側の独自の仕組みによってすべてのタスクが遅延なく実行される． また，サーバーレスクラウドを利用することで，クラウドのコストは実際に使用した計算の総量 (稼働時間) で決定されることになる． これは，計算の実行総量に関わらずインスタンスの起動時間で料金が決定されていた従来のシステムと比べて大きな違いである．

サーバーレスクラウドは，従来のクラウドとは根本から異なったアプローチなので，コードの書き方やシステムの設計が大きく異なる． サーバーレスクラウドを開発・運用するには，サーバーレス固有の概念や用語に精通している必要がある． 以降では，実際にクラウドを動かしながら，サーバーレスをより具体的に体験していこう．

サーバーレスアーキテクチャの概要がわかってきたところで，ここでは AWS においてサーバーレスクラウドを構成する様々なコンポーネントを紹介していこう． 特に， Lambda, S3, DynamoDB を取り上げ，解説する (Figure 79)． サーバーレスクラウドは，これらのコンポーネントを統合することで一つのシステムが出来上がる． ここでは， Lambda，S3，DynamoDB を利用する際に押さえておかなければならない知識を一通り説明しきる都合上，具体的なイメージがわきにくいかもしれない． が，続く Section 12 でそれぞれについてハンズオン形式で演習を行うので，そこでさらに理解を深めれば大丈夫である．