AWSJに勤めるサーバーレスのスペシャリスト
西谷圭介氏：みなさんこんばんは。アマゾンウェブサービスジャパンの西谷と申します。私からはAWS Lambdaというものを紹介したいと思います。実は今日、顔を出すつもりでいたんですが、なぜか直前になって、カメラがまったく言うことを聞かなくて顔が出せない状態なので、顔なしで失礼いたします。
改めまして西谷と言います。アマゾンウェブサービスジャパンでソリューションアーキテクトをしています。もともとサーバーレスのスペシャリストをしていて、ここ1年ぐらいはどちらかというとサーバーレスに特化しないで、アプリケーション開発者そのものを支援するようなチームのマネージャーをしています。今日紹介するLambdaもサーバーレスと呼ばれるものの1つです。
ここに大きなQRコードを記載していますが、基本的に私は、ふだんのコミュニケーションはTwitterが多いです。今日さっきリモート懇親会みたいなのがあるという話もありましたけど、オフラインの懇親会とは違って、なかなか質問しにくいかなと思います。（Twittrerを）フォローしてカジュアルに質問などしてもらえれば、可能な範囲でお答えしたいなと思いますので、ぜひフォローしてもらえればと思います。
Twitter自体はサーバーレスに限らず、AWS関連とかアプリケーション開発関連の全般的な何かを呟いていることが多いです。その昔、Lambdaの本を書きました。もう今はけっこう古くなってあまり参考にはならないと思いますが、Lambdaの本を書いたりサーバーレスアプリケーションの本を書いたりもしています。
Lambdaを知ってもらいたい
ではさっそく本題に入っていきたいんですが、本題に入る前にですね……。
これ実は、今回のイベントの登録時のアンケートの結果です。今日の参加者のみなさん、AWS Lambdaについて、「使っていた」「使っている」「知ってるだけ」「知らない」と、いろいろあるんですが、要注目なのは、この使っていないというか、そもそも「知らない」の31パーセントですね。実数にして136名くらいなんですが、けっこう知らないという方が多いようなので、ぜひ今日は知っていただきたいなと思います。
AWS LambdaとPythonの話になりますが、実は先月、先々月ぐらいにTwitter上でアンケート調査をしていまして、「Lambdaファンクションをどの言語で書いているのか」というアンケート調査をした結果、総数424票の6割弱ぐらいが「Pythonで書かれている」という回答がありました。
このときJavaと.NETが5パーセントずつという、けっこうかわいそうな結果になったということもあって、もう1度改めて、今度はGoとRubyを追加してアンケートを取ってみました。
このアンケートには800票の回答をもらえて、約半数の方々がPythonで使っているのがわかりました。この結果は、いろんな状況とか僕のTwitterのクラスタなので多少の偏りはあるのかなと思うんですが、言いたいことは何かというと、このぐらいAWS LambdaでPythonが使われているというのをお伝えしたいなと思った次第です。
というわけで本日の私の個人的な目標は、先ほど少し紹介したAWS Lambdaを知らないと回答した136名の方にAWS Lambdaを知ってもらうことだけとしたいと思います。今日の資料、実はかなりのボリュームがありまして、残り25分ぐらいでは、すべて紹介はできないかなと思います。
75ページぐらいあるんですかね。全部紹介しているととても30分では終わらないので、随時割愛していきたいと思います。資料に関しては、ちょっと手直しをしたあと、できれば今日中ぐらいに公開したいと思いますので、そちらですべての資料を見てもらえればよいかなと思います［参考資料］。
Lambdaの4つの特徴
まずそもそもAWS Lambdaを知らないという方にお伝えしたいのが、AWS Lambdaの特徴。この4つですね。上からサーバーレスなコード実行、イベントドリブン、あらゆるランタイム、関数とありますが、情報が多すぎて、まずサーバーレスという言葉そのものをご存知ない方もいらっしゃると思うので、これに関して簡単に説明したいと思います。
サーバーレスとは
サーバーレスは、インフラのプロビジョニングが不要だったり、そのインフラの管理が不要と言われていたり、あとは自動でスケールすると言われています。通常はEC2とかの仮想マシンだったりオンプレのサーバーだったりする場合は、リクエストが増えたときのスケールなどを自分たちでコントロールする。もしくはオートスケーリングみたいなサービスを使ってスケールを考慮する必要があるんですが、その点、このサーバーレスと呼ばれる製品では自動でそのあたりをスケールします。
価値に対する支払いですが、これはどういうことかと言いますと、通常AWSでいうところの仮想マシンサービスのEC2の場合、処理してもしていなくても、リクエストを待ち受けている状態だけでお金が掛かってきます。
要は仮想マシンを起動しているだけでお金が掛かってくるんですが、Lambdaに代表されるサーバーレスなアプリケーションに関しては、実際に発生したリクエスト数だったり実行した処理の実行時間、そういったものに対してのみ課金がされるということになります。
高可用かつ安全というのは、通常は自分たちで冗長化したり、そういったことを自分たちで考えて設計して運用していくんですが、そのあたりが既にサービスとして組み込まれているので、考える範囲がだいぶ減るというのが特徴になっています。
3-tier Webアプリにおけるサーバーレス
ここまでが、「サーバーレスとは？」という話なんですが、今日Lambdaをご存知ないとお話していた136名の方には正直何を言っているのかよくわからないと思いますので、もうちょっとだけ詳しくサーバーレスのお話をしたいと思います。
一般的な3-tierのWebアプリを例にお話をすると、だいたいこんな感じになっているかなと思います。クライアントとしてブラウザだったりモバイルがあって、ロジック層としてWebサーバーもしくはアプリケーションサーバー。データストアとしてデータベースがあるというのが一般的な構成だと思います。
これをAWSの上で実現した場合のオーソドックスな構成は、こういった感じになります。クライアントの部分は変わらないとして、CDN、一番左のContent Delivery Networkというものなんですが、クラウドフロントのサービスを使ったりですね。
Webサーバーが真ん中にあるんですが、その手前でロードバランサとしてElastic Load Balancingというサービスを使ったり。それからWebサービスとしてEC2、仮想マシンのサービスですね。またELBのロードバランサがいてアプリケーションサーバーのEC2がいる。それで一番後ろのデータストアのデータベースとしてRDS、Relational Database Serviceを使ったRDBMSを用意するような構成が一般的だったりします。
あとはStatic Contents、静的なコンテンツに関してはS3を使って配信したり、S3上に置くというのが多いかなと思います。
この構成図で見たときに、EC2はもちろんサーバーですね。ここにもサーバーがあります。いろんなところにサーバーが存在するのがわかると思います。
これをサーバーレスに置き直した場合、どういった構成図になるかというと、こういった構成図になります。CloudFront、S3……。静的なコンテンツがS3上に置かれます。S3というのはオブジェクトストレージのサービスなんですが、S3上に置かれてCDNのサービスであるCloudFrontを経由してブラウザ、モバイルにコンテンツが届きます。
今、Webサーバーとかデータベースサーバーとかいろいろあったと思うんですが、そこの部分がAPI GatewayおよびAWS Lambda。それからDynamoDBというのはデータベースのサービスで、NoSQLデータベースのサービスです。これらに置き直っているのがわかるかと思います。
これはすべてがAWSによるフルマネージドなサービスと呼ばれていて、通常の先ほどの一般的な3-tierの構成をした場合、規模の見積もりであったり可用性の設計、データ保全の検討みたいなものは自分たちでやる必要があるんですが、このフルマネージドなサービスを活用することで、自動でスケールしたりリトライとかそういった処理が既にサービスの機能として設計済みになっています。
データ保全の検討の部分に関して言うと、そもそもそういったものが考慮された、データの信頼性が考慮されたサービスとなっています。これはシンプルにサーバーレスはだいたいこんなイメージですよと思ってもらうだけで今日はいいです。
サーバーレスは結局のところ何なの？ みたいな話があるかなと思うんですが、当然ながら本当にこの世のすべてのサーバーが存在しないわけではないんですが、サーバーレスというのは、みなさんや利用者が管理したりスケールさせたりするようなサーバーが存在しないと思ってもらうといいかなと思います。
今のがサーバーレスの簡単な説明です。超早足なのでなかなかわかりにくいところがあると思うので、ぜひTwitterで質問してもらえるといいかなと思います。
