2018 最新事例！ l u e AWS Lambdaを使った E サーバレスの …•...

Copyright © 2018 EXA CORPORATION

ＥｘａＶａｌｕｅＦｏｒｕ m2018

2018年 11月 7日株式会社エクサ

テクノロジーイノベーション部

萩森省吾

冨田大樹

最新事例！AWS Lambdaを使ったサーバレスのアプリケーション開発

2Copyright © 2018 EXA CORPORATION

目次1. はじめに

2. 研修実績管理システムの概要

3. AWS Lambdaを利用した開発

4. チャットボットの開発

5. Webアプリケーションの開発

6. アクセス制御と認証

7. CI/CD実現のためのポイント

8. おわりに

※本資料に記載されているロゴ、システム名称、企業名称、製品名称は各社の登録商標または商標です。









8. おわりに


１．はじめに


サーバレスコンピューティングとはThe phrase “serverless” doesn’t mean servers are no longer involved. It simply means that developers no longer have to think that much about them. Computing resources get used as services without having to manage around physical capacities or limits.

Ken Fromm 「Why The Future Of Software And Apps Is Serverless」(2012/10/15 ReadWrite)より<https://readwrite.com/2012/10/15/why-the-future-of-software-and-apps-is-serverless/>

● サーバがもはや必要となくなった、という意味ではない

● 開発者がインフラについて多くの事を考える必要がなくなった

● コンピューティングリソースがサービスとして提供され、開発者が物理的な容量や限界を管理する必要がない

サーバやインフラを気にかけず、主力製品に集中できる

１．はじめに

https://readwrite.com/2012/10/15/why-the-future-of-software-and-apps-is-serverless/


近年のクラウドサービスの動き近年、サーバレスコンピューティングはAWSに続き、主要クラウドサービスの全てがサービスを展開し、急速に注目を集めている

AWSLambda

AzureFunctions

Google Cloud PlatformCloud Functions

IBM CloudFunctions

サーバレスの知見を得る事により、新たなビジネスチャンスが生まれる！

マイクロサービスベースとなるため、構築が早く、変更も容易となるシステムが開発できる

１．はじめに


研修実績管理システムのリプレース現在の研修実績管理システムの問題点

• サーバ老朽化による故障で、昨年から臨時サーバで運用– 臨時環境であり、恒久的な運用に耐えられない

• アプリケーション本体もFWやDBが古く、サポート切れ

• UIが使いにくく社員がシステムを活用できていない

AWS上でサーバレスアプリケーションとしてリプレースする事に

１．はじめに









8. おわりに


２．研修実績管理システムの概要


研修実績管理システムについて

社員

研修受講システム

技術管理システム

研修実績管理システム

・社内研修の　受講申請をする

・自己研鑽・社外研修の　実績を登録する・年間総受講日数の確認　をする

・スキルレベルを確認する・研修受講計画を考える

育成担当

社内研修受講実績　　データ

研修実績データ

・全社の研修受講状況レポートを作成する



リプレース要件

1. 社員がいつでもどこでも、研修実績を登録することができる

2. 育成担当が効率よく作業できる

3. 他の社内システムと同じユーザIDとパスワードを使って認証できる

社員個人が頻繁に使う機能は、会社支給 iPhoneからも簡単に利用できるインターフェースとして、

チャットボットで提供

主に育成担当が使う、複数件一括登録や、対象

件数が多い参照機能はWebで提供

チャットボットはG suiteへのログインで利用可

Webは、GoogleのOpenID Connectを利用してGsuiteの認証と同じ認証機構をつかうようにした



新研修実績管理システムの全体アーキテクチャ

Google CloudPlatform

Google AppsScript

IF

ブラウザ

Hangouts Chat

社員

IAM

Dynamo DBLambda

Cognito

API Gateway

WAF

CloudFront

S3

CodeCommit

CodePipelineCodeBuild

CloudFormation

CloudWatch

開発者

JavaScript

YAML

開発者用サービス



主な使用サービス一覧種類名前説明

AWSサービス

WAF AWSのWeb Application Firewall

CloudFront CDN(Contents Delivery Network)サービス

API Gateway APIのエンドポイントを作成 (Lambdaと繋げる)

Lambda サーバの管理必要なしでコードを実行できるコンピューティングサービス

DynamoDB KVS型のNoSQLデータベース

S3 オブジェクトストレージ

Cognito AWSの認証・認可用サービス

IAM AWSでのユーザ管理

CodeCommit Gitリポジトリホスティングサービス

CodeBuild コンテナ上で任意のシェルスクリプトを実行可能

CloudFormation AWSサービスのオーケストレーション

CodePipeline CI/CD(継続的インテグレーション / デリバリー)サービス

CloudWatch ログ・AWS上でのイベントの管理



主な言語・フレームワーク・ライブラリ一覧　1/2種類名前説明

言語

JavaScript Lambda関数・Webアプリクライアントで使用

YAML CloudFormationのテンプレートファイルの記述で使用

Google Apps Script チャットボットの IFに使用

フレームワーク・ライブラリ

Node.js JavaScript実行環境

AWS SDK Node.jsで使用するAWSのSDK

React.js フロントエンドのUI作成ライブラリ

AWS SAM CloudFormation用サーバレスアプリケーションモデル

SAM Local AWS SAMをローカルで構築できるCLIツール

webpack フロントエンドのモジュールバンドラ

babel JavaScript コンパイラ

Material UI コンポーネントライブラリ



主な言語・フレームワーク・ライブラリ一覧　2/2種類名前説明

フレームワーク・ライブラリ

Mocha テスト全般で使用するテストフレームワーク

power-assert アサーションライブラリ

Mochawesome テストレポート出力ライブラリ

Enzyme React.jsコンポーネントテストのためのユーティリティライブラリ

TestMyBot チャットボットAPI用テストフレームワーク

Puppeteer Google Chromeオートメーションライブラリ



アプリケーションアーキテクチャ

Google CloudPlatform

Google AppsScript

IF

ブラウザ

Hangouts Chat

社員

IAM

Dynamo DB

Lambda

Cognito

API Gateway

WAF

CloudFront

S3










8. おわりに


３．AWS Lambdaを利用した開発


Lambdaとは

• AWSが提供しているコンピューティングサービス– サーバをプロビジョニングしたり管理しなくてもコードを実行できる

• JavaScript, Java, C#, Go, Python が対応

• 最大処理時間15分– バッチ処理には向かない

• イベントにより、コンテナが処理中のみ立ち上がって関数が実行される– APIへのリクエスト、時間、各種AWSサービスのイベント等



Lambda関数から別のLambda関数の呼び方　1/2Lambda関数をモジュール単位で分割して開発したい

Lambda

ウェブ用

実績登録ロジック

実績テーブル

Dynamo DBボット用

しかし、Lambdaは各関数が隔離されたコンテナで動作するため言語仕様上の呼び出し方では不可能

resiter

bot

web

bot.js

const register = require(‘./register’);...

エラー

※ イメージ図

例：

実行サーバ



Lambda関数から別のLambda関数の呼び方　2/2AWS SDK のLambda関数呼び出しメソッドを利用

bot.js

const AWS = require(‘aws-sdk’);const lambda = new AWS.Lambda({ ...});

...

lambda.invoke({ FunctionName: ‘register’, Payload: parameters});

SDKは require 可能

関数名(FunctionName)を指定して呼び出し



DynamoDBとは• AWSで提供されているKey Value Store型のデータベース

• 読み込み・書き込みが早い

• トランザクションは使えない– コミット・ロールバックなし– 複数レコードの一貫性が保たれなくても本当に問題ないか、十分に検討

する必要がある– 代替手段として、Amazon RDS (フルマネージドのRDBサービス)



Lambda関数のユニットテスト手法Lambda関数に依存するAPIやDBはクラウド上のサービスとなっているため、通常はLambda関数のユニットテストはクラウドにあげて行う必要がある

AWS公式ツールを用いてローカル環境でテストが可能

– SAM Local (現 SAM CLI)– DynamoDB ローカル

ローカルPC上でLambda関数の開発が可能



SAM Local• AWSのサーバレス環境をローカルPCのDockerコンテナ上で構築できるコマンドラインツール– CloudFormationテンプレートを利用する事で、本番と同等

の環境が構築可能

• 構築できるのは API Gateway と Lambda のみ

• ローカルで任意のタイミングで素早くテスト出来る環境はアジャイル開発においては必須

SAM Localのセットアップ方法( http://exa-knowledge.exa-corp.co.jp/open.knowledge/view/5 )


http://exa-knowledge.exa-corp.co.jp/open.knowledge/view/5


DynamoDBローカル

• ダウンロード可能なDynamoDB– Javaアプリケーション

• コマンドラインから起動・停止が可能

• SAM LocalではDynamoDBは構築されないため、使用する必要がある



ローカルPC環境全体図

Node.jsDocker

ソースコード /テストコード

仮想AWS環境

SAM Local

DynamoDBローカルLambdaから参照

コンテナ立ち上げCentOS 7.1

Virtual Box

Windows 7

ローカルPC

社用PCだとセキュリティソフトとの兼ね合い (?)でWindows 7上でDockerが動作しなかったため、Linuxの仮想OS上で環境を構築

コンテナ立ち上げ・環境構築

JDK 8










8. おわりに


４．チャットボットの開発


チャットボットのアーキテクチャ図

Hangouts Chat

会話1往復で左端から右端まですべて実行される

こんにちは

コンニチハ

CloudFrontWAF API Gateway Lambda DynamoDBGoogle CloudPlatform

インターフェースチャットボット

Google Apps Script

Hangout Chat用IF

ボット本体の機能を提供Hangouts Chatとボットの架け橋



チャットボットの会話の流れ

登録する

研修名は？

サーバーレス

研修日は？

登録実行登録しました

2018/06/12

会話の開始

会話の終了

会話の進行に合わせてその状態は保持する必要がある

ユーザチャットボット機能


一つの機能を提供するために1回以上のやり取りが必要

DB

状態保持

状態保持


会話の状態保持Lambdaは処理が終わるとインスタンスが破棄されてしまう。

そのためユーザとの会話の状態はDBなどを利用して保存した。

データ構造

{ user_id: ”abc” intent_id: ”sample” session:{ index: 2 entities:{

　name:”サーバーレス”}

}}


ユーザのID進行中の話題

何番目の会話まで進んだか会話の中で得た情報


テストの手法ITとSTフェーズでテストをする範囲は以下の様に定めた

テスト種類テスト内容使用フレームワーク自動化

UT LambdaとGoogle Apps Scriptそれぞれのテスト QUnit for Google Apps Script ○ITa Bot API が正常に動作するかをテストする TestMyBot ○ITb インターフェースとBot APIの連携をテストする QUnit for Google Apps Script ○ST 実際にチャットクライアントを使用してテストするー ×



技術者でなくても理解できる形式でテストコードを記述する

- お客様にテストコードを直接レビューいただくことが可能- テストケース表を別途作成する必要がなくなる

#me 　←ユーザの入力

登録

#bot 　←ボットからの応答

どんな研修を受けましたか。タイトルを入れてください。

#meサーバーレスアプリケーション開発

#bot「サーバーレスアプリケーション開発」ですね。

TestMyBotの特徴

テストコード一例



レスポンスの問題発生実装したものを触ってみると、ユーザの入力からボットの応答があるまでの時間が非常に遅いことがわかった。

ⅰ1.5秒 ⅱ

0.4秒 ⅲ0.8秒

ⅳ0.4秒



Botの応答速度改善

Hangouts Chat

Hangout Chat用IFGoogle Cloud

Platform

スプレッドシート

ⅲ Lambdaの起動にかかる時間 (0.8秒)ⅰ イベントが発火する時間 (1.5秒)

ⅱ Spread Sheetの操作時間(0.4秒) ⅳ Lambdaの処理にかかる時間 (0.4秒)

試した内容成果

ⅰ Googleが完全に隠蔽している領域なので断念したー

ⅱ スプレッドシートの操作にキャッシュを適用した読込：0.13秒に短縮書込：変化なし

ⅲ 15分に1度Lambdaを実行する(コンテナを常時ホットスタンバイにする ) 効果なし

ⅳ Lambda実行時に使用するメモリサイズを 128MBから512MBに増やす 0.4秒が0.1秒に短縮

API Gateway Lambda DynamoDBGoogle Apps Script

TOTAL4秒 → 3.5秒










8. おわりに


５．Webアプリケーションの開発


• アプリケーションの形態は Single Page Application とした– フロントエンドのライブラリとして React.js を採用

• Single Page Application とは？– 単一ページで構成されるWebアプリケーション– サーバサイドではデータのみを返すREST APIを実装– クライアントサイドでJavaScriptを用いてDOMを操作してページを切り替える

Webアプリケーション概要

CloudFrontWAF API Gateway Lambda Dynamo DB

REST APIを実装

ブラウザ React.js

単純な関数であるLambdaとは相性が良い



Single Page Application の特徴Single Page Application 従来のWebアプリケーション

サーバサイド処理の違い

● データのみをクライアントへ返し、クライアントサイドで描画する

● 必要箇所のみ再描画するため、レスポンスも速い

● サーバサイドでHTMLを描画してクライアントへ返す

セッションの有無● 無し● DBで保持する、もしくはクライアントサ

イドで保持する必要がある (Cookie等)● 有り

ブラウザとの依存性● ブラウザがJavaScriptをサポートしてい

る必要がある● 特に無し



Single Page Application の特徴


Single Page Application 従来のWebアプリケーション

サーバサイド処理の違い

● データのみをクライアントへ返し、クライアントサイドで描画する

● 必要箇所のみ再描画するため、レスポンスも速い

● サーバサイドでHTMLを描画してクライアントへ返す

セッションの有無● 無し● DBで保持する、もしくはクライアントサ

イドで保持する必要がある (Cookie等)● 有り

ブラウザとの依存性● ブラウザがJavaScriptをサポートしてい

る必要がある● 特に無し

次スライドで詳しく説明


処理フロー図例：研修実績登録時

API Gateway

Lambda

I/F 実績登録ロジック実績

テーブル

DynamoDB

ユーザブラウザ

・入力値のバリデーション・システムプロパティ作成

① 実績を入力し、　登録ボタンをクリック

② APIに対してリクエスト③ 対応するLambda関数　が実行される

④ DynamoDBに　実績データを挿入

⑤ レスポンスを　 API Gatewayに渡す

⑥ レスポンスを　クライアントに返す

⑦ APIのレスポンスを受け取り　画面を再描画




Lambda


テーブル

DynamoDB








⑦ APIのレスポンスから　非同期で画面を再描画

シンプルなREST APIを実装

{ statusCode: 200, data: { … }}

データをJSONを返す


API Gateway



API Gateway

Lambda


テーブル

Dynamo DB








⑦ APIのレスポンスを受け取り　画面を再描画

登録ボタンクリック前

登録ボタンクリック後



React.jsについて• A JavaScript library for building user interfaces

– 引用：https://facebook.github.io/react/

• コンポーネント単位で実装

• コンポーネントとは、UI部品の見た目と振る舞いをセットにしたもの– 例：ボタンとクリック時のイベントハンドラ

• コンポーネントとDOMは1：1対応– DOMの粒度は実装者が決定


https://facebook.github.io/react/


どの粒度でコンポーネントを分割すべき？

React.jsで実装してみての気づき ①

資料を作る追加

部屋の掃除をする

本を買う

✔

メールを返す

UI部品(DOM)は全て「コンポーネント」

粒度を小さくすれば再利用性の高いコンポーネントを作れるが、コンポーネント間の包含関係が複雑になる

最初は大きい粒度で実装した方がやりやすい(コンポーネント分割は後からでも可能)



React.jsで実装してみての気づき ②

値の状態を管理(React.jsアプリのモデル )

...this.state = { name: ‘Tomita’}...

render( return(<p>Hello,{this.state.name}</p>););

画面上で「Hello,Tomita」と表示される

stateの値に変更があると必要最低限のDOMのみ再描画される

React.js は「stateと画面表示を同期してくれるライブラリ」と言える

state設計が大切

今後の機能追加・修正も見据えてstateを設計しておくと、仕様変更に強いコードになる



テスト手法テスト種類テスト内容使用lib 自動化

UT (クライアント側)

● 実装したコンポーネントの動きをテスト

● コンポーネントが問題なく作られるかどうか、コンポーネント中の要素がクリックされた時の動きを仮想的にシミュレートする

Enzyme ○

ITa● APIにリクエストして期待のレスポンスが返ってくるか、 AWSの結合テ

スト

● AjaxでAPIにリクエストを送るコードを書き、テストする

- ○

ITb● ブラウザ上からのE2Eテスト

● Headless Chromeを自動操作してテストするPuppeteer ○

ST● ブラウザ上から手動でテスト

● システムエラーを起こしてみてちゃんとハンドリングできているか確認- -



Enzyme• React.js用テストユーティリティライブラリ

• React.jsコンポーネントの処理を画面に描画せずとも仮想的にシミュレートできる

– 対象のコンポーネントが生成されたかどうか

– コンポーネント中の要素がクリックされた時に正しくイベントハンドラが動作するか

– 子コンポーネントが生成されたかどうか等



Puppeteer• Google Chromeを制御するライブラリ

• Headless Chromeも制御可能

• Seleniumとは違いGoogle Chrome以外は動かせない

• DOMが生成される / 削除されるまで処理を待機させる事が可能のため Single Page Application と相性が良い










8. おわりに


６．アクセス制御と認証


セキュリティに関する考え方本システムは、秘匿性の高いデータを持っていない。また、社員が通常業務を行う上で

ミッションクリティカルなものではないため、以下の観点で基本的な対策をとることとした。

1. 正当な権利を持った人だけが使用できるa. ユーザ認証を行うb. チャットボットへのアクセス制御を行うc. Webアプリへのアクセス制御を行う

2. 正当な権利を持たない人に変更されないa. WAFを使用し、CSRF、XSSなど基本的な対策を実施する

3. 個人情報を漏洩させないa. AWS上に社員の個人情報を保持しないb. プログラム処理上必要な個人特定のためのキー情報は、ハッシュ化する



Webアプリでのユーザ認証ユーザが社内の共通認証基盤でログイン出来るように

Google の OpenID Connect を利用してユーザを認証する

項番内容

① 利用するWebページを取得

② 社内の共通認証基盤でログインし、IDトークンを取得する

③ IDトークンからユーザの認証情報を生成し返却する

④ ③で取得した認証情報を付与してAPIへリクエストを送信する

⑤ 認証情報を検証し、認可されていればLambdaを実行する

認証フロー



チャットボットのアクセス制御

Hangouts Chat

Google Apps Script

Google CloudPlatforms

CloudFront

WAF

IFキーの送信

①IFキーの存在チェック

APIキーの付与

②APIキーの存在チェック

ブロック項目手法

①作成したプログラム以外からのアクセス WAFを使用してリクエストにIFキーが存在するかをチェックする

②API Gateway への直接アクセスCloud Frontを使用してリクエストにAPIキーを付与し、API Gatewayで存在をチェックする

API Gateway Lambda DynamoDB

研修実績管理システムのプログラム以外からボットAPIを利用できないようにする



Webアプリのアクセス制御

CloudFront

API Gateway Lambda

WAF

DynamoDB

ブラウザ

S3

②Cloud Front経由チェック

①IPアドレスチェック

③認証チェック

ブロック項目手法

①社外IPからのアクセス WAFを使用して、IPアドレスのチェックする

②S3への直接アクセス CloudFront経由のアクセスかをS3でチェックする

③未認証ユーザのAPI Gatewayへのアクセス API Gatewayでユーザの認証をチェックする

社員以外の人がWebアプリにアクセス出来ないようにする



個人情報の保護

IF

チャットボットでの ID生成箇所

WebアプリでのID生成箇所

インターフェースのイベントが発火した際に渡される情報には、実行したユーザの情報が含まれている。その情報の一つにメールアドレスがあるためそれを利用する。

Google によって発行された IDトークンを検証する際にユーザ情報を取得することが出来る。その情報の一つにメールアドレスがあるためそれを利用する。

• 社員の個人情報をAWSで保持しない設計とした• 社員を特定するキーとなるようなプログラム上必要な情報はユーザのメールアド

レスをハッシュ化した物を利用した• なりすましを防ぐためにユーザのメールアドレスはユーザが入力したものではな

く、サーバー側でGoogle から取得して生成した










8. おわりに


７．CI/CD実現のためのポイント


CI/CD環境が何故必要か

開発手法としてアジャイル開発を取る事に決定

スプリント毎にフィードバックをもらうため、早くリリースできる環境を整える必要がある

CI/CD環境の構築が必要不可欠！



• ソースコードをコミットするだけでパイプラインが走る様にする– CLIからアップロードする事も可能だが、開発者のローカルPCの

環境構築が煩雑

• クラウド上のサービスのみを使ってCI/CD環境を作る– 自前でCIサーバは立てない

CI/CD環境構築時の考慮点


サーバを直接参照できない　warを作ってscpでアプリサーバにコピーして...は不可能


CI/CDプロセスの概略図



Build• AWSリソース

– CloudFormationテンプレートをデプロイ可能形式に変換

• Webアプリクライアント– S3のWebアプリ配信用バケットにクライアント

リソース(HTML + js)をアップロード



Deploy• AWSリソース

– テンプレートを基に各種サービスをデプロイ• Lambda関数• DynamoDBのテーブル• API

• Webアプリクライアント– 特になし

※ デプロイで使用しているサービスの都合上、 Webアプリク　ライアントはBuildプロセスにてデプロイ



Test• 各種テストを実行

• テスト実行後、各種テストレポートとWebアプリのITbの実行中に撮られたスクリーンショットをS3のバケットに保存



複数環境へのデプロイ

• 本番環境へ影響を与えずにStaging環境を自動構築できる様にしたい

→ 実開発前にブランチモデルの策定

• 本番環境とStaging環境で構成が異なってしまう事を避けるためCloudFormationテンプレートファイルは1つにしたい

→ CloudFormationパラメータ・Lambda環境変数を活用


本番機とは別に検証用にStaging環境が必要


実開発前にブランチモデルの策定

bugfix

master

release

develop

featurebranches

ソースコードの構成管理としてGit-flow というブランチモデルを使用する事を策定した masterのソースコードに

変更があると本番環境用Pipelineが実行

developのソースコードに変更があるとStaging環境用Pipelineが実行



CloudFormationパラメータ・Lambda環境変数を活用

Regiser: # 登録ロジックLambdaの定義FunctionName: !Sub ‘tr_${EnvName}_register’...Environment: RESULT_TABLE: !Sub ‘tr_${EnvName}_result’...

CloudFormation TemplateStaging環境用 CodePipeline 設定画面 (CloudFormationの設定)

Lambda関数名

環境変数



Webアプリクライアントの複数環境対応

同じソースコードでPipeline上のBuildプロセス時に特定の箇所を置換できる様にしたい

Staging用 Pipeline

本番用 Pipeline

...let url = API_ENDPOINT;...

org

stg...let url =[Staging用URL];...

Build Deploy Test

prod...let url =[本番用URL];...

Build Deploy

webpack というビルダーを活用

• ソースコード中の特定の文字列をビルド時に置換するプラグインを使用










8. おわりに


８．おわりに


サーバレスアプリケーションを開発しての気付き

• ミドルウェアを意識しなくて良いのは楽

• ビルドとデプロイの自動化は必須

• ローカルPCでユニットテストが行える環境があると開発を効率化できる

• マイクロサービスアーキテクチャとなるので、他システムとリソースの再利用が可能

８．おわりに


まとめ

デモンストレーションを見ていただきます。

　・チャットボットからの実績登録と照会

　・Webからの実績登録

８．おわりに


ｅ

ａ

ｘ

信頼という底力。

ご清聴いただきありがとうございました。


Hangout Chat用IF

ボットとインターフェースの役割詳細

ユーザとボットの架け橋を行う

• ユーザがチャットを操作したときのイベントを受け取る• ボットへのリクエストをボットが期待する形に整形する• ボットの応答をHangoutsChatが期待する形に整形する• APIがユーザ個人を識別できる情報を付加する

ユーザ個人の会話の状態や流れを管理・制御する

• 会話の進行を制御する(戻ることもある)• 今の話題や会話の進行度を管理する• 機能の実行に必要な情報を収集・管理する• 情報が揃ったときに適切な機能を実行する• ユーザに適切なメッセージで応答する

付録

ボット本体

インターフェース


会話の設計（用語）

• インテント

– 会話の「意図・目的」を表す

• エンティティ

– 会話の目的を達成するために必要な「情報」のこと

• フルフィルメント

– 目的の達成に必要な物が揃ったときに実行される

　

付録


インテント

• システムが提供する機能単位でインテントを定義した– 「登録」「削除」「照会」

• ユーザとの会話はインテントを基準に進行する– 目的が達成されるまで(エンティティが揃うまで)繰り返される

• １つのインテントに1往復以上の会話が存在する

付録


エンティティ

• 目的(インテント)を達成するために収集される情報– インテントごとに内容は様々– ユーザから聞き出す必要のあるものと無いものがある

• 収集されたエンティティを使ってフルフィルメントが実行される

付録


フルフィルメント

• 必要なエンティティがすべて揃ったときに最後に呼び出される

• 「DBに実績を格納する」等のWeb・ボット共通の処理を行う

付録


ボット本体の設計

IF

ボットインテント

コントローラー

インテントA

インテントB

インテントC

・・・

フルフィルメントA

フルフィルメントB

インテントD ・・・

機能(インテント)の増加や修正等のインパクトをなるべく抑えるために上記のように切り分けを行った。また、インテントも共通部の処理は切り出し、会話の実装方法も固定化した。

API Gateway

Lambda Lambda

付録


ボット本体の設計

ボット

インテントコントローラー

インテント

フルフィルメント

Bot API へのリクエスト処理のエントリーポイントになる。DBに格納されている「会話の状態」や、「ユーザの発言」を元に実行するインテントを決定する。

「ボット」から渡された「会話の状態」と「インテント」を使って、会話の進行を制御する。進行した「会話の状態」をDBへ保存する。

一つのインテントで行われる会話の内容を定義する。ユーザの発言から必要なエンティティを抽出しバリデーションも行う。フルフィルメントを実行するための処理も定義する

システムの核となる機能を持つ。インテントによって実行される。インテントとフルフィルメントは 1対1になるとは限らない。

付録


ボット本体の簡易シーケンス図

ボットインテント

コントローラーインテントフルフィルメント

インテントの決定・生成コントローラーの生成

run(input)を実行run(input)を実行

バリデーションとエンティティの抽出

応答メッセージと成否

executeFullfilment(entity)を実行invoke(entity)を実行

成否成否

会話状況の更新

応答メッセージと成否

インテント終了時

付録


DynamoDB バックアップ方法検討　1/3 ※ 2018年11月現在

バックアップ種類

メリットデメリット

オンデマンドバックアップ

● Webインタフェース上で手軽にバックアップが取れる

● バックアップ対象の読み込みキャパシティを消費しない

● バックアップ処理は早い

● 自動化のための敷居が高い

○ Webインタフェース上では1度きりのバックアップしか取れないため、 AWS CLIや各種SDK経由で行うスクリプトを書いて実行させる必要がある

Data Pipelineによるバックアップ

● 定期実行が可能

● バックアップはS3上にファイルとして作られるので取り回しが良い

● バックアップ処理が遅い

● 読み込みキャパシティを消費する

● Data Pipeline上で処理を定義する必要があるため導入の敷居が少し高い

Point In Time Recovery(PITR)

● 1秒単位でデータをバックアップして 35日間分保存

● 有効化するだけなので簡単

● 35日分しか保存されない

● テーブルが削除されるとバックアップデータもなくなる

付録


DynamoDB バックアップ方法検討　2/3PITR が手軽かつ強力

• 追加料金が発生するが、本プロジェクト程度の規模の場合であれば計算上は年間1ドルかからない

しかし...

テーブルが削除されるとバックアップデータがなくなってしまう事を懸念AWSサポートに連絡する事で、削除したテーブルのバックアップを復元する事も可能ではあるhttps://forums.aws.amazon.com/thread.jspa?messageID=840798

付録

https://forums.aws.amazon.com/thread.jspa?messageID=840798


DynamoDB バックアップ方法検討　3/3• 本プロジェクトでは以下を併用する事とした

a. PITRb. Data Pipelineにとるバックアップ

• 「1秒単位で復元ができ、万が一テーブル自体が削除されても1日前には戻せる」事が可能に

• b. はバックアップ処理が遅いが毎日深夜に処理を実行させる事で処理の遅さを許容

付録


PITR 設定方法

ここを有効化するだけ

付録


Data Pipeline 作成方法

テンプレートがあるため、基本的な事は自動で設定される

● バックアップ対象のテーブル● バックアップ出力先のS3バケッ

ト● バックアップスケジュール

は自分で設定する必要がある

付録

2018 最新事例！ l u e AWS Lambdaを使った E サーバレスの …•...

Documents

Transcript of 2018 最新事例！ l u e AWS Lambdaを使った E サーバレスの …•...