Download as PDF, PPTX
Uploaded byAmazon Web Services Japan
AWS Black Belt Online Seminar 2016 AWS上でのサーバーレスアーキテクチャ入門
AWS Black Belt Online Seminar 2016 AWS上でのサーバーレスアーキテクチャ入門
More Related Content
Similar to AWS Black Belt Online Seminar 2016 AWS上でのサーバーレスアーキテクチャ入門
![[20171116 三木会] AWSを利用したサーバーレス開発の実践 by アイレット株式会社 cloudpack事業部 高橋 直樹 氏](https://cdn.slidesharecdn.com/ss_thumbnails/2aws-171130004633-thumbnail.jpg?width=640&height=640&fit=bounds)
![[最新版は別にございます! Descriptionをご確認ください] AWS Black Belt Online Seminar AWS re:Inven...](https://cdn.slidesharecdn.com/ss_thumbnails/awsblackbelt2018reinvent2018digest-181130052158-thumbnail.jpg?width=640&height=640&fit=bounds)
![[最新版(12/5 最新版) が別にございます! Descriptionをご確認ください] AWS Black Belt Online Seminar A...](https://cdn.slidesharecdn.com/ss_thumbnails/awsblackbelt2018reinvent2018digestupdated-181201055918-thumbnail.jpg?width=640&height=640&fit=bounds)
![[20220126] JAWS-UG 2022初頭までに葬ったAWSアンチパターン大紹介](https://cdn.slidesharecdn.com/ss_thumbnails/20220126-anti-220126190603-thumbnail.jpg?width=640&height=640&fit=bounds)
AWS Black Belt Online Seminar 2016 AWS上でのサーバーレスアーキテクチャ入門
- 1. © 2016, Amazon Web Services, Inc. or its Affiliates. All rights reserved. アマゾン ウェブ サービス ジャパン株式会社 ソリューションアーキテクト 清⽔水 崇之 2016.8.9 AWS 上でのサーバーレスアーキテクチャ⼊入⾨門 AWS Black Belt Online Seminar 2016
- 2. 本資料料では2016年年8⽉月9⽇日時点のサービス内容および価格についてご説明しています。最 新の情報はAWS公式ウェブサイト(http://aws.amazon.com)にてご確認ください。 資料料作成には⼗十分注意しておりますが、資料料内の価格とAWS公式ウェブサイト記載の価 格に相違があった場合、AWS公式ウェブサイトの価格を優先とさせていただきます。 内容についての注意点 AWS does not offer binding price quotes. AWS pricing is publicly available and is subject to change in accordance with the AWS Customer Agreement available at http://aws.amazon.com/agreement/. Any pricing information included in this document is provided only as an estimate of usage charges for AWS services based on certain information that you have provided. Monthly charges will be based on your actual use of AWS services, and may vary from the estimates provided. 価格は税抜表記となっています。⽇日本居住者のお客様が東京リージョンを使⽤用する場合、 別途消費税をご請求させていただきます。
- 3. 本⽇日のセミナーは US 版 AWS Webinar を元に しています Getting Started with Serverless Architectures • 資料料 ü http://www.slideshare.net/AmazonWebServices/aws-‐‑‒ march-‐‑‒2016-‐‑‒webinar-‐‑‒series-‐‑‒getting-‐‑‒started-‐‑‒with-‐‑‒serverless-‐‑‒ architectures • 動画 ü https://www.youtube.com/watch?v=O2GQRC0sVA8
- 4. Agenda • 背景 • AWSLambda • Amazon API Gateway • デモ • サーバーレスアーキテクチャパターン • サーバーレスのベストプラクティス
- 5.
- 6.
- 7. The Service OrientedArchitecture サービス指向アーキテクチャ プレゼンテーション層 ロジック層 データ層
- 8.
- 9. このパターンの⽀支援ツールは多数 • ウェブサーバー • コードライブラリ • ウェブサービス/アプリケーションフ レームワーク • 設定管理理ツール • API 管理理プラットフォーム • デプロイパターン • CI/CD パターン • コンテナ • など多数
- 10. AWS からの⽀支援ツールも多数 • AmazonEC2 • EC2 Auto-Scaling • AWS Elastic Load Balancer • EC2 Auto-Recovery • AWS Trusted Advisor • AWS Elastic Beanstalk • AWS OpsWorks • AWS EC2 Container Service • など多数
- 11.
- 12. サーバーベースアーキテクチャ どの規模のサーバーが予算に ⾒見見合うか? 何⼈人のユーザーがサーバーに 過負荷をかけているか? どれくらいの容量量がサーバーに残って いるか? サーバーが脅威にさらされているかど うかをどのように検出できるか? 何台のサーバーを予算に 組み込むか? どの OS を サーバーで実⾏行行するか? どのユーザーにサーバーへの アクセスを許可するか? どのようにサーバーからの アクセスを制御できるか? どのようにサーバーの OS に最新の パッチが適⽤用されているようにするか? どのように新しいコードは サーバーにデプロイされるか? どのようにサーバーの 使⽤用率率率を増やせるか? いつサーバーの スケールアウトを決断するか? どの規模のサーバーが⽬目的の パフォーマンスに適しているか? OS の設定をチューニングしてアプリ ケーションを最適化する必要があるか? どのパッケージをサーバーイメージに 焼くか? いつサーバーのスケールアップを 決断するか? どのようにサーバー設定の変更更を 処理理するか? どのようにアプリケーションはサーバー ハードウェアの障害を処理理するか?
- 13. サーバーレスアーキテクチャであれば • 完全マネージド型 ü プロビジョニングなし ü 管理理不不要 ü ⾼高可⽤用性 • 開発者の⽣生産性 ü 重要なコードに注⼒力力 ü すばやいイノベーション ü 市場投⼊入までの時間を短縮 • 継続的なスケーリング ü ⾃自動化 ü スケールアップと スケールダウン
- 14.
- 15. サーバーレス、イベント駆動型のコンピューティングサービス Lambda = サーバーなしの Microservice
- 16. Lambda のコンポーネント • LambdaFunction（お客様が記述） • Event Source • AWS Lambda Service • Function Networking Environment
- 17. Lambda Function • コード （Java、NodeJS、Python） • コードが実⾏行行中に引き受ける IAM ロール • コードに割り当てられた メモリの量量（CPU とネット ワークにも影響） 有効、完全な Lambda 関数
- 18. Event Source • いつ関数を実⾏行行するか? • 多くの AWS サービスを現在、 イベントソースにすることが 可能: ü S3 ü Kinesis ü SNS ü DynamoDB ü CloudWatch ü 設定ルール ü Amazon Echo ü など ü ...さらに Amazon API Gateway（詳細は後ほど）
- 19. AWS Lambda Service • サーバーを管理理またはスケーリングすることなく関数 コードを実⾏行行 • 関数の実⾏行行を開始するための API を提供 • 開始された関数を規模にかかわらず並列列に実⾏行行 • 関数の追加の機能（ログ、モニタリング）を提供
- 20. Function Networking Environment Default— VPC 内のデフォルト ネットワーク環境を提供 - インターネットへのアクセスは関数 に対して常に許可 - VPC にデプロイされたアセットへの アクセスは不不可 Customer VPC — 関数はお客様の VPC の コンテキスト内で実⾏行行 - お客様の VPC 内で他のリソースと プライベートにやり取り - 使い慣れた設定と動作: § Subnet § Elastic Network Interfaces (ENI) § EC2 セキュリティグループ § VPC ルートテーブル § NAT ゲートウェイ
- 21.
- 22. サーバーの抽象化⽅方法はすでに多数存在 • SaaS • PaaS • MBaaS • *aaS • アプリケーションエンジン/プラットフォーム
- 23. Lambda のユニークなところは？ • コード/関数レベルでの抽象化（任意の柔軟な使い慣れたも のを使⽤用） • セキュリティモデル（IAM、VPC） • 価格モデル • コミュニティー • AWS Service エコシステムとの統合 ü スケーリング ü トリガー
- 24. AWS では多くのサーバーレスオプションが⽤用意 ストレージ データベースネットワーク コンピューティングコンテンツ配信メッセージングとキューセキュリティ ゲートウェイ ユーザー管理理 モニタリングとログ記録 IoT 機械学習 ストリーミング分析
- 25.
- 26. PlayOn! Sports —ビデオストリームの処理理 ラップトップエ ンコーダー HLS S3 再⽣生 VOD ストリー ムモバイルクラ イアント CloudFront ストリーミング ライブストリー ムモバイルクラ イアント CloudFront S3 取り込み 480p トラ ンスコード HQ コピー 360p トラ ンスコード ⾳音声のみの トランス コード サムネイル QOS 分析 Lambda 関数をカスケード http://www.slideshare.net/AmazonWebServices/arc308-the-serverless-company-using-aws-lambda
- 27.
- 28.
- 29. API の完全マネージド型サービス 作成 設定公開 メンテナンス モニタリング セキュリティ保護
- 30. デモ AWS Lambda 関数 ウェブブラウザ Amazon S3 動的コンテンツ サーバーレスウェブサイト AmazonAPI Gateway 静的コンテンツ Amazon DynamoDB
- 31.
- 32.
- 33.
- 34.
- 35.
- 36. AWS Lambda のベストプラクティス 1. 関数のサイズを制限 ̶— 特に Java の場合（JVM の起動に 時間がかかる） 2. Node — 実⾏行行は⾮非同期 3. 関数コンテナの再利利⽤用を前提 としない ̶— 再利利⽤用された場 合は再利利⽤用も可能だが… 4. ディスクに注意（500 MB の / tmp ディレクトリを各関数に提 供） 5. リリースには関数エイリアスを 使⽤用 6. 付属のロガーを使⽤用（サービス 提供のコンテキストからの詳細 を含む） 7. カスタムメトリックスを作成 (operations-‐‑‒centric, and business-‐‑‒centric)
- 37. Amazon API Gatewayのベストプラクティス 4. バススルーではなくリクエス ト/レスポンスマッピングテン プレートを合理理的な場所で 使⽤用 5. HTTP レスポンスコードの所 在をAPIGWにしておく 6. クロスアカウント共有には Swagger インポート/エクス ポートを使⽤用 1. Mock Integration を利利⽤用 2. マネージド型のエンドユー ザーベースのアクセス制御に は Cognito と組み合わせて 使⽤用 3. ステージ変数を使⽤用（API設 定値をログ記録⽤用の Lambda 関数に挿⼊入）
- 38. その他のベストプラクティス 1. 使い回しできないような戦略略 的な命名規則（Lambda 関数 名、IAMロール、API 名、 API ステージ名など）を使⽤用 2. 命名規則とバージョニングを 使⽤用して⾃自動化を作成 3. できれば IAM ロールでの権限 付与で外部化 4. 権限を最⼩小化し、IAM ロール を分離離 5. 設定を外部化 ̶— これには DynamoDB が最適 6. ⼤大規模なスケーリングイベン ト が わ か り 次 第 、 事 前 に AWS サポートに連絡 7. サービスの調整が必要であれ ば、AWS サポートを⼿手配
- 39. A Call toAction
- 40. サーバーレスで構築を始めましょう Amazon API Gateway AWS LambdaAmazon DynamoDB
- 41. Webinar資料料の配置場所 • AWS クラウドサービス活⽤用資料料集 ü http://aws.amazon.com/jp/aws-‐‑‒jp-‐‑‒introduction/ • AWS Solutions Architect ブログ ü 最新の情報、セミナー中のQ&A等が掲載されています ü http://aws.typepad.com/sajp/
- 42.
Editor's Notes
- #6 本日のセミナーはUS版のAWSウェビナーをもとに作成しています。 あえて日本人的な味付けはせずにUS版の内容そのもので構成しています。 ですので、少し大味なところがあるかもしれませんが、話の内容はUS版の内容をそのまま翻訳して日本語で話しています。 というのも、サーバーレスという用語自体があたらしいものですし、USのほうがリードしているという側面もあります。今回は輸入して学ぼうという考えですね。 そもそも、サーバーレスって、インフラ構築や運用の作業負担を減らして、本来のビジネスにフォーカスしましょうっていう考えだと思うんです。 特に、日本人は働きすぎだと思います。ここはあえて懇切丁寧な資料で時間を潰すのではなく、本質以外を削ぎ落としたUSスタイルでやってみたいと思います。 決して手抜きしたわけではないです。YouTubeの動画みながら原稿起こすほうが大変でした。
- #7 まず、サーバーレスの背景の紹介、 そして、サーバーレスのコンピューティングのコアとなるAWS Lambda の紹介 また、レストフルなAPIを作成できる Amazon API Gateway の紹介 そして、実際にこれらのサービスを使って簡単なサービスを作成するデモをお見せします。 最後に、まとめとしていくつかのベストプラクティスをご紹介します。
- #8 背景 AWS Lambda を使えば如何に革新的であるか、 実際、今後のアプリケーションデザインパターンにおける次世代のステージであると考えられる。
- #9 まず、モノリシックアーキテクチャについてお話します。 これは、旧来のアーキテクチャであり、全部のアプリケションがひとつのユニットにまとまっています。 このなかには多くの機能を有しているため、多くの開発者もしくはチームがこのひとつのユニットを開発・管理することになります。 そうすると、なにかしら問題がおこると全てをロールバックする必要があり非常にリスクが高まります。 システムの変更、機能の追加など、難しくなるわけです。 現在多くの組織がこの問題点に気づいており、開発チームごとにスピーディに新しい機能を提供できるように方針転換してきています。
- #10 つづいてモノリシックなアーキテクチャから代わりまして、 今日まで数年にわたってポピュラーなものとしては、サービス指向アーキテクチャ(SOA)があります。 いくつかのコンポーネントがウェブサービスAPIを提供しており相互に連携しています。 この図はよくあるサービス指向アーキテクチャでアプローチしたマルチティアのアーキテクチャです。 この中においては、ユーザーエクスペリエンスはすべてフロントエンドにあるプレゼンテーション層(ティア)のアプリケーションで提供されます。ウェブサイトやモバイルアプリなどが考えられます。 また、いわゆるビジネスロジックはロジック層(ティア)で提供しております。 そして、データの永続化はデータ層(ティア)にあるデータベースで提供されます。 サービス指向アーキテクチャのパターンにおいて非常に重要なことは、まずインフラストラクチャが分離していることです。 スケーリング、スケジューリング、リソース消費は独立して管理されます。 次に、開発チームは非常に高くスペシャライズできるところがメリットです。 チームが担当するアプリケーションにマッチしたある特定分野にスペシャライズしたスキルセットをもったデベロッパーで、チームを構成することができます。 開発ステップの初段では、より小さくして、より安定して、の繰り返しです。
- #11 そして、ここ数年ポピュラーになってきたマイクロサービスアーキテクチャのパターンです。 サービス指向アーキテクチャのモジュールをブレークダウンして、より小さくして 単一の機能を有したモジュールへと分割しています。 中央集権的なシステムを開発するのであれば、現在でもモノリシックアーキテクチャを採用したほうが幸せになれるでしょう。 これは、組織のあり方やフェーズによっても変わってくるので一概にどれが良い悪いの話ではありません。 もしかすると、このマイクロサービスアーキテクチャは一見すると複雑に見えるかもしれませんが、 組織のプロセスと合わせて考えると、先の２つのアプリケーションパターンより利点がみえてくると思います。 つまり、全体のアプリケーションアーキテクチャの中のちっさなサブセットをサポートすることだけに責任をおえばよいので、 少人数の開発チームでよりディープに単一の機能にフォーカスすることができる。
- #12 これらのパターンを支援するツールは多岐にわたっている。 たとえばウェブサーバーは必要だろうし、もしくは、コンテナを活用するかもしれません。 これらのツールは、SOAでもマイクロサービスでも活用できる。
- #13 そして、AWSはこれらに相当するサービスを提供しています。 アマゾンEC2を利用すれば、オートスケールや可用性を高めたような、いわゆるウェブサーバーベースのアプリケーションを簡単に構築できます。 このウェブサーバーベースのアプリケーションは多くのユーザーにとって非常に重要なパターンであります。
- #14 しかし、これらのツールとイノベーションの多くは、まだまだ共有して依存しあっている
- #15 もちろん、サーバーに依存することも考えなくてはならない。 サーバーに関連する、すべての複雑性、すべての責任は、いまだ皆さんの責任である。 スクリーンに表示されたこれらの質問にたいして、一個一個こたえていかなくてはならない。 AWS のサービスを活用すれば簡単にできるようにはなっている。 しかし、そもそもなぜこのようなことを考慮する必要はあるのか？
- #16 もしサーバーレスアーキテクチャになるように設計できるなら、 いままで学んだようなサーバーベースアーキテクチャで必要となったインフラの管理などが不要になります。 いわゆる完全マネージド型である。といえます。 Noプロビジョニングのインフラストラクチャ、ビルトインのハイアベイラビリティ、Noパッチング、Noモニタリング。 また、サーバーを冗長化するために書いていたコードや取り巻く責任が必要なくなりますので、開発者の生産性が向上します。 開発者はアプリに関連するコアとなるビジネスロジックにだけフォーカスできる。 そして最後に、継続的なスケーリングが可能になります。 すべて自動化されており、スケールアップ／ダウンを意識する必要がありません。
- #17 ここからはサーバーレスのコアサービスとなるAWS Lambda とその利点についてお話します。
- #18 AWS Lambda は サーバーレスのイベント駆動型のコンピューティングサービスとして考えることができます、もしくは、 サーバーなしの マイクロサービスとしての AWS Lambda と考えることができます。 作成した個々のLambdaファンクションは、マイクロサービスの個々のモジュールに相当します。
- #19 Lambda ベースのアーキテクチャを考えるときに、いくつかのコンポーネントについて説明する必要があります。
- #20 ひとつめのコンポーネントはLambda Functionです。 Lambdaではユーザーがカスタムコードをアップロードできるようになっており、このカスタムコードをLambda 関数と呼びます。 Lambda 関数は、ユーザーがアップしたコード、関連する依存関係、および設定で構成されます。 現在は、Lambda Function として利用できるコードは、JavaScript、Python、そして、JVMベースの言語、Java,Scala,Jruby といった言語で書かれたものです。 指定した設定情報には、割り当てるコンピューティングリソース (たとえば、メモリー)、タイムアウト、IAM ロールが含まれます。 まずセキュリティに関しては、 IAM ロールを使用して、Lambda 関数（あなたのカスタムコード）がどのAWSサービスやリソースにアクセスを許可するかを制限できます。 EC2インスタンスのIAMロールとおなじコンセプトです。 つづいて、設定の一部として、AWS Lambda がコードの実行を開始するハンドラー (コード内のメソッド/関数) を指定します。 AWS Lambda はイベントデータを入力としてこのハンドラーに提供し、イベントを処理します。 Lambdaのためのコードは、文字通りのシングルファンクションである必要はありません。 ハンドラーファンクションは他のファンクションや、バイナリ、コードライブラリ、外部ウェブサーバーとの通信などに依存できます。 注意が必要とすれば、実行時間が最大５分に制限されていることです。 そして、Lambda Function に割り当てるメモリ量についてです。 これは、CPU と ネットワーク帯域にも影響をあたえます。たとえば、CPUはメモリ量にほぼ正比例するような特性があります。 128 MB を割り当てた場合よりも 、256 MB を 割り当てた場合のほうが、2 倍の CPU リソースを利用することができます、 最大 1536 MB まで、64 MB 単位で追加できます。 細く（メモリは128-1.5GBまで64MBずつ） =====原文====== Lambda Function はあなたが書いたコードであり、AWSのセキュリティがそのコードを保護しており、 そのコードを実行するのに必要なリソースを設定する。 現在は、Lambda Function として利用できるコードは、JavaScript、Python、そして、JVMベースの言語、Java,Scala,Jruby といった言語で書かれたものである。 Lambdaのためのコードは、文字通りのシングルファンクションである必要はない。 はじめに実行するように定義したメソッドはHandler function と呼ばれており、 このファンクションは他のファンクションや、バイナリ、コードライブラリ、外部ウェブサーバーに依存できる。 注意が必要とすれば、実行時間が５分に制限されていることです。 つぎはセキュリティについてですが、 これはを Lambda Function にアサインされたIAM ロールによるアクセスマネージメントで実現されています。 これにより、あなたのコードがどのAWSサービスやリソースにアクセスを許可するかを制限できます。 EC2インスタンスのIAMロールとおなじコンセプトである。 この後予定しているデモでもうすこし詳しく見ましょう。 最後は、Lambda Function に割り当てるメモリ量についてです。 これは、CPU と ネットワーク帯域にも影響をあたえます。基本的にはCPUはメモリ量にほぼ正比例する。メモリは128-1.5GBまで64MBずつ
- #21 ２つ目のコンポーネントは「イベントソース」です。 イベントソースは Lambda 関数の呼び出しを発生させるイベントを発行します。トリガーとなります。 呼び出し時、イベントを Lambda 関数コードのハンドラーに渡すことでコードを実行します。 イベントソースマッピングを使用して、イベントソースを Lambda 関数と関連付けます。 現在、S3やDynamoDBなど様々なイベントソースをサポートしており、サポートするイベントソースもどんどん増えてきています。 例えばS3をイベントソースに選択した場合には、ファイルをアップロードなどしてバケットにオブジェクトが作成されたときにLambdaファンクションが実行されます。そしてコードにそって何か処理をすることができます。たとえば画像をリサイズします。 もしくは、APIGWをイベントソースとして選択した場合には、APIにてHTTPリクエストが呼ばれたときにLambda ファンクションが実行されます。なにかしらDBに問い合わせてレスポンスするなど。 ＝＝＝＝＝＝原文＝＝＝＝＝＝ あなたが書いたコードはイベントソースに紐付いてイベントドリブンに実行されます。 これら様々なイベントソースに対応しており、サポートするイベントソースもどんどん増えてきています。 それぞれのイベントソース データとメタデータ 例えばS3をイベントソースに選択した場合には、ファイルをアップロードなどしてバケットにオブジェクトが作成されたときにLambdaファンクションが実行されます。 APIGWをイベントソースとして選択した場合には、APIにてHTTPリクエストが呼ばれたときにLambda ファンクションが実行されます。
- #22 つづいて、AWS Lambda Service そのものについてお話します。 AWS Lambda はインフラやスケーリング、コードの管理をユーザーがすることなく、AWSが代わりにまるっと管理します。 ほかのAWSサービスと同様に、関数を実行したり設定したりするための、フル機能のAPI も提供している。 マネージメントコンソールだけではなく、CLIやSDKを活用して操作を自動化することができます。 また、それぞれに設定したイベントソースのイベントをトリガーに皆さんのカスタムコード（Lambdaファンクション）を並列に実行できる。 週に１回S3に作成されるレポートをトリガーにされることもあれば、 いつでもAmazonEchoアレクサ（いわゆるインテリジェントスピーカー）にだれかが喋ったタイミングをトリガーにすることもあれば、 もしくは、公開APIに秒間1,000件のリクエストを受けたタイミングをトリガーにするかもしれません。 最後に、ログ、モニタリングを CloudWatch で提供しており、ユーザーは必要なときにログを確認することができます。
- #23 最後は、ファンクションネットワーキング環境です。 ここでは２つのオプションが選択できます。 ひとつめはデフォルトのネットワーキングエンバイロメントです。 実行されるコードファンクションはインターネットアクセスは常に許可されていますが、VPC内にデプロイしたプライベートのアセットへのアクセスはできないようになっています。たとえば、S3やDynamoDB にはアクセスできるが、RDSには接続できない。 ふたつめが、カスタマーが作成したVPC内に Lambda Function をプロビジョニングするというオプションです。 Lambda 関数から VPC 内のリソースにアクセスできるようにするには、VPC サブネット ID やセキュリティグループ ID など、追加の VPC 固有設定情報を指定する必要があります。この情報を使用して AWS Lambda によって Elastic Network Interface (ENI) のセットアップが行われ、Lambda 関数から VPC リソースへのアクセスが可能になります。 注意点としては、Lambda は、指定された VPC 情報を使用して、Lambda 関数から VPC リソースにアクセスするための ENI をセットアップします。ここで作成される ENI では、パブリックインターネットにアクセスできません。このため、VPC にインターネットゲートウェイがアタッチされていても、インターネットにアクセスすることはできません。もし、インターネットアクセスが必要である場合 (たとえば、Amazon Kinesis のように VPC エンドポイントのない AWS サービスにアクセスする場合など) は、VPC 内で NAT インスタンスを作成したり、NAT ゲートウェイを使用することで対応します。
- #24 ここで、疑問が、ということで。 サーバーレスはある種あたらしい用語ですし、ここまでサーバーレスの話をしてきました。 しかし、サーバーを気にせずアプリケーションをデプロイできる方法は既に他にもあるのではないか？という疑問があります。
- #25 実際、サーバーベースアーキテクチャでいうところのサーバーやインフラを気にせずアプリケーションをデプロイできる方法は既に他にもあります。 SaaS、PaaS、MBaaS、ちょめちょめaaS、なにかしらアプリエンジンやプラットフォームなどです。
- #26 では、Lambdaのなにがユニークなのか. Lambda を利用すると抽象化とコントロールのバランスが非常に良いモデルで動作させることができるという点です。 サーバーベースのインフラストラクチャにあるような煩わしさを抽象化することができる一方で、 アプリケーションを実行するためのコードなどに関してすべてコントロールできるということです。 ふたつ目はセキュリティです。AWSのIAMやVPCとネイティブにインテグレーションできるので、いままでどおり非常に簡単にセキュリティのベストプラクティスを実現できます。 Lambda はAWSカスタマーが今日構築しているミッションクリティカルなアプリケーションの一部として利用できます。 つぎは価格モデルです。 Lambdaは実行された回数によって課金されます。初期費用などは必要なくプロビジョニングしたキャパシティにのみ依存します。 そして無料枠もあります。1ヶ月に100万回の実行と、40万GB秒のコンピューティング時間が無料となります。 他のAWS無料枠と同様に始めの12ヶ月に適用されます。 また、ドキュメントも豊富ですし、コミュニティやネットなどでも利用例がたくさんでてきています。 最後に、ほかのAWSサービスのエコシステムと統合できるという点です。 先ほどのイベントソースによる連携もそうですが、APIを通して非常に簡単にすべてのAWSのサービスと連携することができます。
- #27 また、なにかシステムを構築する場合において、全体から見るとコンピューティングとは一部にすぎません。 AWS にはさまざまなサーバーレスのオプションがあります、システム全体を構築する際のメリットとなります。 たとえば、ストレージ、データベース、マシンラーニング、もしくは、モバイルサービスなど、これらを活用することで非常におおきなアドバンテージを受けることができます。この点もAWSそしてLambdaの特徴であるといえます。
- #28 次は、ユーザーが構築するサーバーレスアーキテクチャの簡単な例をご紹介したいと思います。
- #29 こちらは実際に本番利用されている PlayOn Sports のサーバーレスアーキテクチャになります。 この事例自体は、昨年の re:Invent にて発表されたものになります。詳しくはリンクURLからご参照ください。 これは、ライブストリーミングのシステムをLambdaを活用したサーバーレスアーキテクチャにリプレースしたものになります。 カメラにて撮影された動画をラップトップのエンコーダーからS3にHLSのチャンクファイルでランダムにアップロードされてきます。 これを、Lambdaで定義した分離した関数それぞれに五月雨にインプットされ、トランスコードなどの処理をしてS3に保存します。 これをそのまま、準リアルタイムにCloudFront経由でクライアントのプラットフォームに合わせてストリーミング配信するというものです。 いままでは、ポーリングメカニズムやメッセージキューなどを活用してEC2ベースでプロセッシングをしていたということですが、 Lambda以降は、ご紹介したように、完全なサーバーレスアーキテクチャとしてイベントドリブンに稼働させています。 これによって、開発者は、インフラの管理にパワーを割くのではなく、ビデオのクオリティにフォーカスできるようになった。
- #32 そこで、紹介するのが Amazon API Gateway です。
- #33 Amazon API Gateway は完全マネージド型サービスで、開発者はこれを利用することにより、どのようなスケールであっても、簡単に API の作成、配布、運用、監視、保護が行えます。 AWS マネジメントコンソールで数回クリックするだけで、EC2仮想サーバーで稼働中のワークロードや、AWS Lambda で稼働中のコード、または任意のウェブアプリケーションといったものを、バックエンドとして、アプリケーションの 玄関として振る舞う API を作成できます。 Amazon API Gateway では、最大で数十万の同時 API 呼び出しを受け付け、処理することが可能です。 また、Amazon CloudWatch によってサービスの呼び出しを視覚的にモニタリングできるダッシュボードが表示され、パフォーマンスのメトリックスと API 呼び出しについての情報、データのレイテンシー、エラー率を確認できます。 そして、API Gateway には、API へのアクセス認証や、操作アクセスを管理するツールが準備されています。 IAM、や、Cognito といった AWS の管理ツールやセキュリティツールを使用して、API に対するアクセス認証を実施できます。 OAuth トークンや他の認証メカニズムをすでに使用している場合、AWS Lambda のカスタムオーソライザーを使用して、受信するリクエストを検証できます。 料金についても、最低利用料や初期費用はかかりません。受信した API 呼び出しと、送出したデータ量に対してのみ料金が発生します。
- #34 このデモは、HTMLやJSといった静的コンテンツをS3でホスティングしており、 これを読み込んだブラウザがJSでAPI gateway が提供するAPIと通信します。 API gateway のバックエンドには AWS Lambda が動作しており、NoSQLであるDynamoDBにデータを投入したり取得したりします。 そして、ブラウザ画面に情報を表示します。
- #35 こちらがデモ画面になります。 これは、ショッピングリストにアイテムを登録、取得できるサービスです。 HTMLとJSで作られており、S3でホスティングしています。 まず、HTMLとJSのソースコードを見てみましょう。 HTMLには画面上に表示されていた、テキストボックスやボタンが設置されています。 下の方にJSのコードがあり、これがAPIGatewayで作成したAPIと通信します。 ２つの関数があり、addItem でアイテムの追加、getShoppingList でアイテムの取得をしています。 また、選択した部分が、APIGatewayで作成したAPIのエンドポイントになります。 それでは、DynamoDBのテーブルを見てみましょう。 ここには、ShoppingListという名前のテーブルを、Listid を primary key つまり hash key として既にに作成しています。 デモですので、Capacity unit は 5 になっています。本番で大規模に利用されるときは、このスループットを大きくしていただくことになります。 では、テーブルの中身をみてみましょう。 ここには、listid = test というレコードが登録されており、アイテムとして apple と orange が登録されています。 では、ブラウザ画面にもどって、DynamoDBに格納されていたデータを取得してみましょう。 Listid に test と入力して、get shopping list ボタンをクリックします。 すると、さきほど格納されていた apple と orange が取得され画面に表示されました。 次に、処理をしている AWS Lambda のコードを見てみましょう。 すでに、データ取得するための Lambda Function は作成されております。 今回のデモでは、これに加えて新たにアイテムを登録するFunction を作成してみたいと思います。 Create a new function ボタンをクリックします。 この画面では blue print つまり、いくつかよくあるパターンのコードをテンプレートとして提供しています。 今回は、Java のプログラムを独自にアップロードして Function を作成しますので、ここでは Skip します。 では、アップロードする Java のプログラムをみてみましょう。 まずは ShoppingList.java です。 これは、いわゆるデータオブジェクトであり、さきほどのDynamoDBのテーブルの構造と対応します。 このクラスは、String 型の listid、そして String のList 型の items をプロパティとして持っています。 次に、ShoppingListTableClient.javaです。 このクラスでは、AWSSDKのAmazonDynamoDBClientクラスを利用して、ShoppingListテーブルの情報を操作します。 addItem というメソッドにおいて、DynamoDBClient.putItem() を利用して、あらたなアイテムを追加しています。 最後が、AddItemHandler.java です。 こちらは、API gateway へのリクエストを介して最初に動作するハンドラーのためのクラスです。 addItem というメソッドが定義されており、こちらがリクエストから取得されたデータをもとに発火します。 内部では、先ほど説明した client.addItem が実行されるという実装になっています。 これで、実際にDynamoDBに対してリクエストに添えられたアイテム情報が登録されるわけです。 では、AWS Lambda の MC画面にもどります。 この画面では、まずはNameを設定します。 分かりやすいNameをつけましょう。この場合は、ServerlessShoppingList-AddItem というNameを付けています。 つづいて、説明文です。 Runtime は Java 8を選択します。 今回作成したプログラムはZipファイルでアップロードできますが、オプションとしてS3に保存したファイルも選択できます。 すでにS3にアップロードしていますので、このURLを入力してみましょう。 つづいてHandler です。 これはさきほどのコードのaddItemというメソッドが相当します。 Javaの場合はパッケージ名・クラス名・メソッド名で指定します。 つぎはRoleです。 このプログラムはAmazon DynamoDBにアクセスしますのでそれを許可するような権限を与える必要があります。 コード自体にアクセスキーやシークレットキーを書いておくということもできなくはないですが、 セキュリティ上よくありませんので、IAMロールを使いましょう。 そして、メモリ512MB、タイムアウト15秒と設定しています。 最後は、VPCの設定です。 今回はDynamoDBにアクセスのみであり、VPCリソースへのアクセスはありません。 ですので、デフォルトのNo VPCを選択します。 あとは、確認して作成するのです。 では、実際に動作するかテストしてみましょう。画面からテストできます。 このテストでは、ShoppingList に新たに Banana というアイテムを追加してみます。 入力するJson をこのように貼り付けて、テストを実行してみます。 そうするとLambda が処理を実行します。 今回はデモですのでレスポンスは適当にNullが返ってきていますが、問題なく処理が完了したようです。 では、DynamoDBのテーブルにちゃんとアイテムが追加されたか確認してみましょう。 先程は、apple, orange でしたが、あらたに banana が追加されていることが分かります。 では、このLambda function をAPI gateway に紐付けてみましょう。 API gateway には ShoppingList というAPI を既に作成しており、さきほどお見せしたようにアイテム一覧を取得するAPIは作成ずみです。 /lists というリソースの下に 実際の listid を URI path として指定してGETするとアイテム一覧が取得できるわけです。 GETの中身をみてみますと、左側にクライアント、右側にバックエンドのAWS Lambda 、それらをAPI gateway がひも付けています。 ここでは、新たにアイテムと追加するAPIを作成しますので、まずは、 /lists/ の後ろに items というリソースを定義します。 この items に対してアイテムを登録するメソッドとしてPOSTを定義します。 インテグレーションタイプとして幾つか選択できますが、今回はさきほど作成したLambda Functionを指定します。 これでAPI gateway に作成したLambdafucntion がひも付きました。 左側のクライアントからきたリクエストは、API gateway を経由して Lambda で処理がされます。 今回JsonをボディとしてPOSTリクエストしますので、マッピングテンプレートを利用します。 まず content type は application/json と指定します。 次に、マッピングをするわけですが、このJSONにあるように、フロント側とバックエンド側のパラメータのマッピングを設定します。 マッピングテンプレートを利用すると、フロント側とバックエンド側を分離できるので、いろいろいい感じです。 では、テストしてみましょう。 Path として test、JSONで grapes を登録してみます。 問題なく処理できたようです。 DynamoDB を確認してみると、あらたに grapes が追加されたことがわかります。 では、このAPI を公開してみましょう。 API gateway には stage という概念があり、開発フェーズごとに複数のstage を用意できます。 今回はすでに dev というステージがあるので、ここにデブロイします。 これで完了です。 Invoke URL というのがエンドポイントになります。 カスタムのドメインを設定することもできます。 また、セッティングタブでは、キャッシュやスロットリングの設定ができます。 Android IOS, JS のプラットフォームごとにSDKを作成できるので、これを使えば簡単に作成したAPIを利用することができます。 また、Swaggerのエクスポートもできますし、デプロイヒストリーも確認できます。 では、ブラウザに戻って、動作を確認してみましょう。 まずは、Listid = test と入力して、現在のShoppingListを取得してみます。 次に、アイテムを登録してみましょう。Bread と入力して登録ボタンをクリックすると、、、エラーがおこりました。 これはCORSの問題があるからです。 クロスオリジンリソースシェアリング、つまり、ことなるドメイン間でAPIを利用しようとしたためブラウザによってブロックされたわけです。 これを回避するには、いくつかのHeaderを応答する必要があるのですが、API gateway であれば非常に簡単に設定ができるようになっています。 プルダウンから Enable CORS をクリックしていただくと、このように簡単にheader を付けてくれます。 では、修正したので再びAPIをデプロイして確認してみましょう。 Listid = test と入力してShoppingListを取得します。 そして、アイテムに bread を入力して登録ボタンをクリック。再度ShoppingListを取得すると、アイテムが追加されているのが分かります。 Chocolate と milk は誰か他のひとが登録しちゃったんでしょうね・・・ 他にも、新たにリスト自体も作成できます。 デモは以上です。
- #36 ここからは、サーバーレスアーキテクチャのいくつかのパターンをご紹介したいと思います。
- #37 さきほどご説明したマイクロサービスアーキテクチャは、ここで我々がやろうとしていることにとてもマッチします。 マイクロサービスアーキテクチャは単純に Lambda 関数とAPI Gateway で構成できます。
- #38 次は、モバイルバックエンドです。 基本的には API gateway と Lambda の構成で実現できますし、 Amazon SNS Mobile Push などいわゆるAWSのモバイルサービスとインテグレーションできるので大きなアドバンテージがあります。
- #39 つぎは、リアルタイムのアナリティクスエンジンです。 リアルタイムデータの入力口としてKinesis を利用することができます。 Kinesis であれば高負荷のかかるようなインプットでも捌くことができます。 また、Lambda の event source として利用できるので Lambda で並列処理しながら 例えばデータを加工したりDynamoDBに保存したりできます。 そして最終的にビジュアリゼーションするというようなパターンです。
- #40 ここからはサーバーレスのベストプラクティスをご紹介します。
- #41 AWS Lambda のベストプラクティスです。 まずは、ファンクションサイズを抑えることです。 初回インボケーションのときに時間を要するということを考慮しましょう。 特に、JVMベースのJavaなどは影響が大きいです。 ファンクションサイズを小さくするということも良いですが、 初回インボケーションのペナルティを避けるために、スケジュールラムダファンクションを利用して数分に１回実行して ワーミングしておくのも良いです。 つぎは、コンテナの再利用を前提としないことです。ファンクションはステートレスに実装すべきです。 再利用されていれば再利用のアドバンテージを利用するのも良いです。 場合によっては恩恵にあずかれることもあるかもしれません。 コンフィグをロードしたり、コネクションを継続させたり インメモリーキャッシュさせたり こういう便利な機能が Lambda ファンクションコンテナをリユースさせることでアドバンテージとなる場合もあります。 あとはディスクサイズについてですが、ファンクションあたり 512 MB のテンポラリーディレクトリを持っていて処理のさいに利用できます。
- #42 ひとつめは、モックインテグレーションです。 この機能により、開発者はバックエンドを結合することなく、API Gateway から直接 API 応答を生成できます。 これにより、開発は、開発が完了する前に、API を使用する必要のある他チームの進捗を阻害せずにすみます。 たとえば、フロントエンド開発チームには事前にモックインテグレーションで仮のAPIを提供しておくことができます。 そして、エンドユーザーのアクセス制御にはマネージド型のユーザー認証サービスであるCognitoと組み合わせるのが良いです。 特定のIAMポリシーとひも付けてアクセス制御を実現できます。 モバイルのユースケースだけではなく、一般的なサーバーレスのユースケースでもご利用いただけます。 つぎに、分離することはサーバーレスアーキテクチャの鍵のひとつです。 これは何処でもいえることで、API Gateway のリクエスト／レスポンスはマッピングテンプレートを利用して フロント側とバックエンド側のLambda の処理を分離しておくことが良いです。 そうしておけば、バックエンド側のLambdaコードを変更したとしてもフロント側に影響をあたえずマッピングテンプレートを修正するだけで対応できます。 また、もしクロスアカウントでAPI gateway を共有するような場合には、Swagger インポート／エクスポートを利用するのが良いです。
- #43 最後に一般的なサーバーレスでのベストプラクティスについてです。 まずはネーミングルールですが、他の用途に使い回せない戦略的な命名規則にすることです。 これはLambdaファンクションやIAMロール、API名やステージ名に言えます。 そうしておけば、自動化するのも簡単になります。継続的インテグレーション、継続的デリバリーを実現できます。 つぎは、権限を外部管理することです。ソースコードにアクセスキーやシークレットキーを埋め込むのではなくIAMロールを利用して各AWSサービスやリソースにアクセスできるようにします。 そして、権限を最小化して、IAMロールを分離することです。 それぞれのLambda ファンクションが同一のIAMロールを共有していると、はじめは良いのですが、なにか変更が必要となり他AWSサービスにアクセスする権限をどんどん追加していくと、そのIAMロールを共有している他のLambdaファンクションにも影響がでてしまいます。 複数のLambda ファンクションに特権的なIAMロールを共有して設定するのではなく、Lambda ファンクションごとにそれぞれ 1:1 の関係になるように IAM ロールを設定することをお勧めします。 AWS サービスには初期リミットが設定されているものがあります。 これは間違った使い方をして、ユーザーの想定よりも大規模にスケールしてしまったり、課金が膨大になるようなことを防ぐためです。 もし大規模にアクセスが予想されるような場合などは、AWSサポートに事前にご連絡いただくようにお願いします。
- #44 最後に Call to Action ということで、「行動よびかけ」 本日は、サーバーレスの概要、いくつかのベストプラクティスをご紹介しました。 そしてAWS LambdaとAPI Gateway を使ったクイックデモも実施して、如何に簡単にサーバーレスアプリケーションを実現できるかお見せしました。
- #45 なにか、みなさんで作ってください。 まずは手を汚して、動かして、AWSのサービス、Lambda や API Gateway や DynamoDB などで遊んでみてください。