『Amazon Web Servicesを使ったサーバーレスアプリケーション開発ガイド』という本を書きました

かなり久しぶりの更新ですが、タイトルの通り『Amazon Web Servicesを使ったサーバーレスアプリケーション開発ガイド』という書籍を執筆し3月16日より発売されましたー。

出版社はマイナビ出版さんで、もちろんAmazonで買えます! 

Amazon Web Servicesを使ったサーバーレスアプリケーション開発ガイド

Amazon Web Servicesを使ったサーバーレスアプリケーション開発ガイド

 

目次は以下のようになっています。総ページ数は297ページと前回(263ページ)をわずかに上回る分量となりました!

Chapter1 サーバーレスアプリケーションの概要
1-1 サーバーレスアプリケーションとは
1-2 ユースケースアーキテクチャパターン
1-3 サーバーレスアプリケーションのライフサイクル管理概要

Chapter2 Amazon Web ServicesAWS)利用の準備
2-1 AWSアカウントの取得
2-2 AWSにおける認証と認可について
2-3 リージョンの選択
2-4 AWS Command Line Interface(AWS CLI)の準備

Chapter3 インフラを自動化しよう
3-1 Amazon CloudWatchのアラームをトリガーに自動処理をする
3-2 Webサイトの状態を定期的にチェックする

Chapter4 Twitterのリアルタイム分析をしよう
4-1 Amazon Kinesisを使ってTwitterのデータを受け取る
4-2 AWS Lambdaを使ってストリーミングデータをAmazon DynamoDBへ保存する

Chapter5 写真投稿サイトをシングルページアプリケーションで作ろう
5-1 Webサイトの概要を確認する
5-2 バックエンドのAPIを実装する
5-3 フロントエンドを実装する
5-4 Amazon Cognitoを利用した認証処理を追加する
5-5 Amazon Rekognitionを使って自動タグづけを行う

Chapter6 サーバーレスアプリケーションのライフサイクル管理
6-1 AWS Serverless Application Model(AWS SAM)詳細
6-2 複数環境の管理
6-3 デリバリプロセスの自動化(CI/CD)

Chapter7 サーバーレスアプリケーションのトラブルシューティング
7-1 メトリクスのモニタリング
7-2 AWS X-Rayを利用したトラブルシューティング

 

 

さて、今回の書籍執筆にあたりいくつかの試みがありました。まず、昨年のAWS Summit Tokyo 2017のタイミングで『実践AWS Lambda』という本を書いて発売されたのですが、このときのポストにも書いたようにいくつかの点で心残りがありました。 

また、スクリーンショットに関しては今回は主に初心者向けということでなるべくマネージメントコンソールからの操作にしようという方針だったので、スクリーンショット多めだったんですが、次回からは全てCLIを使った手順にしようと強く思いました。CLIベースであれば画面のアップデートによる影響を受けないので。

なかでもこのスクリーンショットによる手順の問題はずっと気になっていた点です。というのもロードマップ情報を知る立場として、対外的には言えないもののAWS Lambdaのコンソールがアップデートされることを実は知っていたのです。ただし、執筆中に聞いていた範囲ではそこまで大きなものではないはずでした。しかし、実際にAWS re:Invent 2017で発表され、その大きく様変わりしたユーザーインターフェースに驚いた方も多いと思います。これだけ大幅な変更が入ることがわかったのは脱稿した後でしてどうしようもなかったというのが実情です。

実際のところ、このマネージメントコンソールのアップデートで既存資料が影響を受けるというのはあるある話なんですね。例えば、前日夜中までかけてハンズオン資料作って、翌日いざってときに画面が変わってるとか。

しかし、『実践AWS Lambda』に関しては6月に発売開始され、マネージメントコンソールのアップデートが発表されるのが11月末でした。言ってみれば賞味期限として半年程度しかないことになります。

書籍の場合、機能のアップデートが多いと追従できず陳腐化しがちという課題もあるのですが、コンソールのアップデートというのはまた違います。今回のように大幅な変更が入ってしまうと解説している手順自体が変わってしまうわけです。というわけで前回の書籍でやりたくてもスケジュール上の問題でできなかったCLIによる手順を今回の手順では全面的に採用しています。

その結果、スクリーンショットが少なく初心者の方には少し手が出しづらいものになってしまったかも知れません。その点に関しては申し訳ないと思うものの情報の賞味期限を延ばすためでありご理解いただけると嬉しいです。

また、ほとんどの手順をCLIで解説したことで発生した課題もあります。それは1つのコマンドが非常に長いものが多く紙面サイズ上一行で掲載できないのはもちろん複数行にわけるにしてもキリの良いところで改行できないというなかなか悩ましい問題がありました。なるだけ対応したつもりではありますが、わかりにくい箇所があるかもしれません。

 

さて、それ以外では前回は主にAWS Lambdaの機能や設定項目について解説した内容となっていたのですが、実際のところAWS Lambdaを中心とする「サーバーレス」なサービスを活用して構築する「サーバーレスアプリケーション」では各サービスの設定方法だけでなく、実際にアプリケーションからどう呼び出すかがイメージし辛いという声をよく聞いていました。そこで、今回は企画段階からユースケース別に実際のアプリケーションをサンプルとしてコードベースで解説するというものにしようという話になりました。そのかわり各サービスの機能や設定方法の詳細に関してはそこまで言及せず、あくまで組み合わせや選択時における考え方を示すだけにしようというのが本書のコンセプトでした。そこで実際のよくあるワークロード、ユースケースをもとにサンプルとなるアプリケーションを用意していきました。

とはいえ、ページ数やスケジュールの都合で盛り込めなかったものが多いのも事実でした。本当はテストに関しても深掘りしたかったところです。考え方はコンテキストの違いによってもいろいろあるものの1つの考え方を示したいという思いがあったのですがこちらに関しては残念ながら見送りました。また、シングルページアプリケーションの章において実画像の削除処理をAmazon DynamoDBのストリームをもちいて非同期で行うというものを盛り込みたかったのですがこちらに関してはページ数の都合で割愛となってしまったことは残念です。とはいえ、触れるべき内容ではあるのでこちらの処理に関してはサポートサイトにて別途配信を予定しています。

それ以外にも、例えばAWS LambdaでDead Letter Queueを用いてより信頼性・堅牢性の高いアプリケーションをしていく話やAWS Step FunctionsとAWS Lambdaを用いた分散バッチ処理実装やLambdaファンクションのオーケストレーションといった部分も色んな事情が重なって含めることができませんでした。まあ色んな事情の多くはスケジュール的なものだったりするのですが。

 

なお、今回ももちろんサポートサイトが用意されています。

book.mynavi.jp

 

こちらのサイトでは本文に含まれているソースコードが全てダウンロードできるようになっています。正直なところ、本文に記載されているコードを全て手で写して実行するのはかなり大変な作業になると思いますのでダウンロードして活用いただければと思います。

また、今後発見されたミスや誤字などの修正に関しても随時こちらのサイトに記載されていきます。
※既にいくつかご指摘いただいています…m(_ _)m

 

あと、発売を記念して購入者限定のセミナーをマイナビさん主催で開催することになっています。購入した方であれば無料で参加できますのでぜひお越しいただければと思います。当日は私のほうからはサーバーレス関連サービスのアップデートならびに最新事例のご紹介を行います。また、別のものがサーバーレスアプリケーションのライブコーディングをお見せすることも予定されています。

もちろん、私がいるので本の内容に関する不明点などを直接ご質問いただいても構いませんし、感想などをいただけると非常に励みになります。

また、当日は来場の方向けに特製AWS Lambda Tシャツを御用意していますのでお時間がありましたらぜひお越しいただければと思います。

お申込みは以下のサイトよりどうぞ。

2018年3月発売予定『Amazon Web Servicesを使ったサーバーレスアプリケーション開発ガイド』で、ご予約・ご購入者限定イベントを開催します! | マイナビブックス

 

なお、『実践AWS Lambda』に関しては現在改訂版を準備中でして、発売以降のアップデートを盛り込むだけでなく手順をすべてCLI化します。こちらは順調にいけば今年のAWS Summit Tokyoあたりでお届けできるのではないかと思っております。

 

最後に、技術書に関する今後の在り方について個人的に思うところをつらつらと書いて終わりにします。今回の書籍は執筆時間がなかなか取れずダラダラと期間をかけてしまったのですが、そこに年に一度のグローバルカンファレンスであるAWS re:Inventが重なっていたこともあり紹介しているサービス群にもいくつかアップデートが入っていたりします。今回は各サービスの深掘りではなく組み合わせとアプリ実装に重きを置いていたのでAWS Lambdaのマネージメントコンソールの問題以外は大きな影響はなかったものの、やはりクラウドのような進化の速いサービス・プロダクトに関する解説書というのは難しいなと強く感じたのも事実です。電子版はアップデートしやすいのでまだしも紙の書籍に関しては特にそう思います。

一方で技術書の類はどういうわけか事実として紙媒体のほうが好まれます。また、公式のドキュメントではわかりにくいところがあるのも事実だと思います。特に英語のドキュメントを翻訳しているものなどは日本語表現としてわかりにくいことも往々にしてあります。

そういったこともあり、日本語執筆者による解説書の有用性は認めるものの、先述したとおり機能のアップデートが早く、多いとそれに対して紙媒体では追従が難しく陳腐化しがちというのは作者としてはそれなりの苦労をもって書いている以上悲しい気分にもなったりするわけです。

もちろんすべての技術書が同様とは思いません。長期に渡って手に取られる優れた技術書というのも数多く存在します。特定のサービスやプロダクトについて解説するものだからそういうことに陥りがちというのもわかります。

と、まあこんな感じでモヤモヤした気持ちを抱えたまま答えも出ずに過ごしていますw

 

というわけで、とりとめもなく書いてしまいましたが、各種勉強会での登壇依頼もお待ちしていますので、こんな私でよければTwitterあたりで雑に絡んでいただけますと幸いです。

 

ブログ分けました

 

というわけでブログをわけました。

テックぽいこと、お仕事絡みのことはこれまで通りのブログでそれ以外は新しく立ち上げたブログで更新していきます。

 

理由はいろいろあるけどまあ仕方ない。

というわけであんまり更新ないですが今後ともよろしくお願いします。

 

広告を非表示にする

なぜAWS LambdaとRDBMSの相性が悪いかを簡単に説明する

f:id:Keisuke69:20170621131534j:plain

表題の通りです。
AWS LambdaとRDBMS全般(Amazon RDSに限らず)はその特性的に相性が悪いのでデータストアはなるべくAmazon DynamoDBを使いましょうという話しをよくします。
今回はなぜそうなのかをもう少しだけ説明しようと思います。

大前提

まず、大前提としてAWS Lambdaは水平方向へのスケーラビリティを特徴とするサービスです。リクエストが来たらそれを処理するLambdaファンクションのコンテナを作成し、処理を実行します。

このLambdaファンクションのコンテナは1つあたり同時に1リクエスト(1イベント)しか処理しません。従って同時に100リクエスト来た場合は同じLambdaファンクションのコンテナ100個で処理されます。ただし、必ずしも毎回100コンテナが1から作成されて起動されるわけではありません。

Lambdaファンクションのコンテナは起動コストの効率化のために再利用も行います。いわゆるウォームスタートというものですね。ウォームスタート可能なコンテナがあれば新しくコンテナを作ることはせずにそれを利用します。しかし、ウォームスタートできるコンテナがない場合やあってもその数以上のリクエストを同時に処理する必要が発生した場合は新しくコンテナが作成・起動されます。これがデフォルトの同時実行1000だと1,000コンテナが同時に実行される可能性があるわけです。もちろん10,000であれば10,000個です。とはいえ、AWS Lambdaを中心とするサーバレスのプラットフォームはNever Pay for Idleなのでリクエストがなければ一切費用は発生しません。

最大同時接続数の問題

ご存知の通り各種RDBMSには最大同時接続数的なパラメータがあるわけですが、設定可能な値と実際に使い物になる値は別物です。DBエンジンごとの多少の違いはもちろんあるものの、使い物になる数値というのはCPU数やメモリ数と大きく関係してきます。

当然ながら同時に接続される数が多ければ多いほど必要なCPU数、メモリ数が増えていきます。つまり、アクティブな接続が同時に数千から数万になるDBを動かすにはそれなりのスペックが必要というわけです。そもそもプロセスやスレッドが数千とか数万になってくると1サーバのOSだとコンテキストスイッチやら何やら厳しくなってくるので、DB分割なんかも検討するかと思います。

また、RDBMSというと、現状ではほとんどが処理量が増えた場合にスケールアウトで対応するのではなくスケールアップが必要になります。要はサーバに積むCPU、メモリなどを増やす方向です。参照系はスケールアウトできても更新系はスケールアップで対応するしかないことが多いです。

さて、ポイントは先のLambdaファンクションの振る舞いとの兼ね合いです。まず、説明のとおり、リクエストがあるとコンテナが作られて起動されるのでこのタイミングでDBへのコネクションが張るわけですが、リクエストのたびに接続するのはコストがかかるので、その接続オーバーヘッドを減らすための方法として、グローバルスコープを利用することでコンテナがアクティブな間、つまりウォームスタートの場合はそれを利用するという方法があります。

一方で先ほどの説明の通り、Lambdaは同時に処理すべきリクエストは必要なリクエスト数分のコンテナで処理します。つまり、各コンテナからDBへとそれぞれコネクションが張られることになります。ということは仮にデフォルト状態であっても1000コネクションが張られる可能性があるということです。これがプロダクション環境でもう少し大きいシステムであれば数千同時実行 = 数千コネクションとかにになってきます。こうなってくると一般的にはコネクションプールを使うことが多いと思います。DBへ都度接続するコストを減らした上で、コネクションを使いまわすことで負荷を減らすわけです。

ところが、Lambdaではこのコネクションプールを実現することが難しいのです。Lambdaファンクションのコンテナ間では何も共有しませんし、外部のデータストアへと永続化しない限りはできないからです。つまり、コンテナをまたいで利用するようなコネクションプールの実装は難しいと言えます。それを管理する中間層のようなものを用意して各コンテナはそれ経由でDBにアクセスするような何かを作るとかして頑張ればなんとかなるかも知れませんが、ちゃんと検討したことないのでわかりません。

話しを戻すと、このようなLambdaファンクションのプラットフォーム特性を考えるとダウンストリームとなるシステムも同様にスケールアウトするようなものでないと耐えきれないです。同時実行数が少ないうちはいいですが増えてくると耐えられなくなってきます。実はこれはRDBMSに限らない話しなんですけどね。スケールアウトできないシステムの場合、ある程度まではピークにあわせたスペックのサーバを用意しておくことで対応できるとは思いますが、限界は来るかと思います。また、せっかくNever pay for idleを特徴とするプラットフォームを利用するにも関わらず、ピークのために通常よりも巨大なスペックのDBサーバを維持するのももったいない話しですしね。

というわけでLambdaと組み合わせて利用するデータストアとしてはDynamoDBを推奨しているわけです。DynamoDBの場合は分散型データベースであり同時接続数の増加そのものは気にする必要がなくなります。また、一貫して高速で安定したパフォーマンスを得られます。もちろんスループット増に伴ってコストは発生しますが、そもそも対応できないという状況はなくなります。

VPCアクセスのレイテンシコスト問題

これはRDBMSに限らない話しなのですがLambdaファンクションがVPC内のリソースにアクセスしようとしたとき、かつコールドスタートが発生したときはその仕組み上10秒〜30秒ほどのレイテンシが上乗せされます。いくらコールドスタートの発生頻度が低いとはいえ、ゼロにすることはできないです。

一方で、RDBMSVPCの中に置くことが多いと思います。そうするとこのレイテンシの考慮が必要になってきます。ここはシステムの要件次第なので一概には言えないですが、DBアクセスを伴う処理がたまにとは言え10秒を超えてくることを許容できるかどうかです。

まとめ

LambdaとRDBMSの組み合わせをあまり推奨しない理由を2つ挙げました。
もちろんそれほど同時実行されることがないのであれば最初の問題はほとんど関係ないかも知れません。また、たまに発生する10秒を超える実行時間が問題ない場合もあるでしょう。

逆に言うとそうでない限り、LambdaとRDBMSを組み合わせて利用するのは止めたほうがいいです。すべてのLambdaファンクションがRDBMSに接続する必要がないのであればDynamoDBも併用してRDBMSの利用は必要最低限にするのもありですし、処理によってはLambdaファンクションのアクセス先はあくまでもDynamoDBにしてストリームを使って非同期にRDBMSに反映するという方法が取れるかも知れません。

このあたりはケースバイケースなので必要であればご相談ください。

 

最後にしつこいくらいに自分の本を宣伝しておきますね。

実践AWS Lambda ~「サーバレス」を実現する新しいアプリケーションのプラットフォーム~

実践AWS Lambda ~「サーバレス」を実現する新しいアプリケーションのプラットフォーム~

 

  

Amazon Web Servicesを使ったサーバーレスアプリケーション開発ガイド

Amazon Web Servicesを使ったサーバーレスアプリケーション開発ガイド

 

 

AWS Summit Tokyo 2017でのサーバレス関連セッションまとめ

(06/21アップデート:Game Tech Sessionのスライドを追加しました)

2017年5月30日〜6月2日までの4日間で開催されたAWS Summit Tokyo 2017ではとても多くのセッションが提供されたわけだけど、その中からサーバレス関連のセッションだけをピックアップして資料のダウンロード先をまとめます。ちなみに今年のAWS SummitではDevDayという開発者向けのイベントも併催されていて、その最終日はさらにServerless Evolution Dayというタイトルでサーバレス関連セッションばかりを集めていたけど、それに対して普通の方(ひとまず本編と呼ぶ)でもいくつかサーバレス関連セッションがあったのでそちらも拾ってます。

なお、SlideshareやSpeakedeckで公開されていればそちらを埋め込み、本家サイトでの公開のみの場合は資料リンクを貼っておきます。 

【Day 2】2017 年 5 月 31 日(水)

Going Serverless with AWS

AWSのサーバレス関連のプリンシパルプロダクトマネージャであるAjay Nairのセッション。プリンシパルってのはプリンシパル>シニア>無印な感じです。なお、途中でCanonの八木田さんも事例として登壇頂いてます。

資料なんですが、このちょっとした手違いでまだ公開されていないので公開され次第掲載します。今は表紙スライドのスクショだけでご容赦を。資料が公開されたのでリンクを追加しました!

 

f:id:Keisuke69:20170616180500p:plain

 資料リンク

教えて!中堅企業の事例に学ぶ AWS 活用サクセスストーリー

これはサーバレスが中心のセッションではないんですが、最初のお客様の事例でAmazon RekognitionとAWS Lambda、Amazon API Gatewayなどを組み合わせた顔検索機能の話しが出てきます。

 

f:id:Keisuke69:20170616184746p:plain

資料リンク

 

流通業界におけるデジタルトランスフォーメーションの実践

Amazonの事例でサーバレスの話しが出てきます。サーバレスで実装したことによる実際の効果についても語られています。

 

f:id:Keisuke69:20170616185522p:plain

資料リンク

 

【Day 3】2017 年 6 月 1 日(木)

Day 3 基調講演(キーノート)

Day3のキーノートではAmazonのCTOであるWarnerからテックな話しをいくつかあったんだけど、その中でAWS Lambdaを中心としたサーバレスに関する話しもあります。

 

f:id:Keisuke69:20170616172403p:plain

資料リンク

 

最新 IoT デザインパターン 〜AWS IoT と AWS Greengrass を用いた構築パターン〜

AWS IoTを中心とした話しなんですが、AWS IoTということは当然サーバレスなわけです。Lambdaも出てきますがそれ以外のサーバレスなサービスを組み合わせたIoT向けデザインパターンです。

 

f:id:Keisuke69:20170616190120p:plain

資料リンク

 [朝日放送] サーバレスアーキテクチャで実現した M-1 グランプリ敗者復活戦投票システム

残念ながら資料はまだ公開されていないみたいです。なのでこのセッションのレポート記事のリンクを貼っておきますね。

news.mynavi.jp

資料が公開されたのでこちらもリンクを追加しておきます!

f:id:Keisuke69:20170620140013p:plain

 資料リンク

Speed matters - Amazon Kinesis が実現するストリーミングデータのリアルタイム分析

Kinesisを中心としたストリーミングデータの扱いに関する内容となってます。

 

f:id:Keisuke69:20170616190458p:plain

資料リンク

セイコーエプソンのデータプラットフォームビジネスにおけるサーバレスアーキテクチャへのマイグレーション 

f:id:Keisuke69:20170616173323p:plain

資料リンク

【Day 4】2017 年 6 月 2 日(金)

[ソニーモバイルコミュニケーションズ] スマートホームシステムの開発 〜AWS を活用した新規サービスの立ち上げ〜

Amazon CognitoのUser PoolやAWS IoTならびにAWS Lambdaあたりの話しが出てきます。

 

f:id:Keisuke69:20170616173809p:plain

資料リンク


全部教えます!サーバレスアプリのアンチパターンとチューニング

これは自分のセッションですね。ここではやってしまいがちなパターンとどうすればいいのか、あとはコールドスタート関連について説明しています。

 

speakerdeck.com

[JINS] バイタルデータの意味付けという荒波を乗り越える!適切な処理分担のためのサーバーレスアーキテクチャ

f:id:Keisuke69:20170616183147p:plain

 

資料リンク


サーバレスで王道 Web フレームワークを使う方法

このセッション面白いよ?今まであんまり語られることがなかった内容で、Express.jsとかSpringといった従来からある一般的なフレームワークをサーバレスでも使いたいって人たち向けの解説。既存の移行とかこういったフレームワーク使いたいとかの人たちには必読です。

 

speakerdeck.com


[ワイヤ・アンド・ワイヤレス] AWS Lambda を使ったモバイルバックエンドのサーバレス開発事例

こちらのセッションは残念ながら資料・動画ともに非公開だそうです。


[タワーズ・クエスト]Serverless 時代のテスト戦略

テストの伝道師こと @t-wada さんがサーバレスアプリのテストについて語ってます。みなさんもサーバレスアプリ、特に「Lambdaのテストってどうしたらいいの?」って悩んでる人も多いのでは?そんな方は必読です。

 

speakerdeck.com


[ワークスアプリケーションズ] AWS Lambda で変わるバッチの世界 ~ CPU 時間トータル 100 時間の処理を 10 分で終わらせるには~

このセッションはLambdaの考え方をよく理解して効果的に実装されている例についてお話されてます。とても参考になるノウハウも多いかと。

 

f:id:Keisuke69:20170616183502p:plain

資料リンク


もう悩まない!AWS SAM で始めるサーバーレスアプリケーション開発

みなさん、AWS Serverless Application Model (AWS SAM)って知ってます?サーバレスアプリケーションをパッケージングしたりデプロイするためのAWSの推奨ツールです。推奨も何もAWSオープンソースで作ってるんですけど。そのAWS SAMについて、日本のサーバレスコミュニティの立役者、吉田真吾さんが説明してくれてます。

 

www.slideshare.net


[Sansan] AWS が支える Eight のリコメンデーションエンジンの裏側

Lambdaだけでなく、Step Functionsも活用した興味深い事例です!

 

speakerdeck.com


サーバーレスアプリケーションのための CI/CD パイプライン構築

f:id:Keisuke69:20170616183826p:plain

資料リンク


[日本経済新聞社] 紙面ビューアーとサーバーレスアーキテクチャ

こちらも残念ながらまだ資料が公開されていないようなので公開され次第、リンクを貼りますー。レポート記事なんかも見つからなかったです。

セッション内容とは関係ないんですが、日経さんと言えばAWS Summit期間中に日経IDでAWS Lambdaを採用っていいうリリースを出されていたりしました。

www.itmedia.co.jp

(追加)Game Tech Session

カプコンにおけるインフラへの取り組み

インフラ面における過去の振り返りからサーバレスへと話が進んでいきます。31ページからスライドの雰囲気が激変します。こういう特徴あるスライド作れるのうらやましい。

f:id:Keisuke69:20170622212122p:plain

資料リンク

DAU 100 万人突破! 急成長を支える Shadowverse のインフラ技術

ログ収集まわりでECSによるコンテナと組み合わせて利用している事例です。

speakerdeck.com

さいごに

というわけでまとめてみましたが、結構な数ですね。コミュニティとかウェブとかではあまり外に出ていない事例もあったかと思います。さらにここでは取り上げなかったセッションでもシステム全体の隅っこに少しだけ動くLambdaファンクションがいたりするようなものも多かったです。

最後に自分の本もまた宣伝しておきますかね。AWS Lambdaを解説した本です。AWS Summitの会場で先行販売して、6月9日から一般販売開始されました。よろしければどうぞmm

 

実践AWS Lambda ~「サーバレス」を実現する新しいアプリケーションのプラットフォーム~

実践AWS Lambda ~「サーバレス」を実現する新しいアプリケーションのプラットフォーム~

 

  

Amazon Web Servicesを使ったサーバーレスアプリケーション開発ガイド

Amazon Web Servicesを使ったサーバーレスアプリケーション開発ガイド