目次はじめに研修実績管理システムの概要 AWS Lambdaを利用した開発チャットボットの開発 Webアプリケーションの開発アクセス制御と認証 CI/CD実現のためのポイントおわりに本資料に記載されているロゴシステム名称企業名称製品名

(1)

Ｅ

ｘａ

Ｖ

ａｌｕｅ

Ｆ

ｏｒｕ m

2018

2018年 11月 7日

株式会社エクサ

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

萩森省吾

冨田大樹

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

(2)

1. はじめに

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

3. AWS Lambdaを利用した開発

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

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

6. アクセス制御と認証

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

8. おわりに

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

(3)

1. はじめに

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

3. AWS Lambdaを利用した開発

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

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

6. アクセス制御と認証

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

8. おわりに

(4)

サーバレスコンピューティングとは

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/>

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

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

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

界を管理する必要がない

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

１．はじめに

(5)

近年のクラウドサービスの動き

近年、サーバレスコンピューティングはAWSに続き、主要クラウド

サービスの全てがサービスを展開し、急速に注目を集めている

AWS Lambda Azure Functions

Google Cloud Platform Cloud Functions IBM Cloud Functions

サーバレスの知見を得る事により、

新たなビジネスチャンスが生まれる！

マイクロサービスベースとなるため、構築が早く、

変更も容易となるシステムが開発できる

(6)

研修実績管理システムのリプレース

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

• サーバ老朽化による故障で、昨年から臨時サーバで運用

– 臨時環境であり、恒久的な運用に耐えられない

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

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

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

レースする事に

１．はじめに

(7)

1. はじめに

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

3. AWS Lambdaを利用した開発

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

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

6. アクセス制御と認証

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

8. おわりに

(8)

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

社員研修受講システム技術管理システム研修実績管理システム・社内研修の　受講申請をする・自己研鑽・社外研修の　実績を登録する・年間総受講日数の確認　をする・スキルレベルを確認する・研修受講計画を考える育成担当社内研修受講実績　　データ研修実績データ・全社の研修受講状況レポートを作成する

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

(9)

リプレース要件

1. 社員がいつでもどこでも、研修実績を

登録することができる

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

3. 他の社内システムと同じユーザIDとパ

スワードを使って認証できる

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

チャットボットで提供

主に育成担当が使う、複数件一括登録や、対象件数が多い参照機能は

_Webで提供

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

Webは、GoogleのOpenID Connectを利用して

(10)

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

Google Cloud Platform Google Apps Script IF ブラウザ Hangouts Chat 社員 IAM Dynamo DB Lambda Cognito API Gateway WAF CloudFront S3 CodeCommit CodePipeline CodeBuild CloudFormation CloudWatch 開発者 JavaScript YAML 開発者用サービス

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

(11)

主な使用サービス一覧

種類名前説明

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上でのイベントの管理

(12)

主な言語・フレームワーク・ライブラリ一覧　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 コンポーネントライブラリ

(13)

主な言語・フレームワーク・ライブラリ一覧　2/2

種類名前説明フレームワーク・ライブラリ Mocha テスト全般で使用するテストフレームワーク power-assert アサーションライブラリ Mochawesome テストレポート出力ライブラリ Enzyme React.jsコンポーネントテストのためのユーティリティライブラリ TestMyBot チャットボットAPI用テストフレームワーク

(14)

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

Google Cloud Platform Google Apps Script IF ブラウザ Hangouts Chat 社員 IAM Dynamo DB Lambda Cognito API Gateway WAF CloudFront S3

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

(15)

1. はじめに

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

3. AWS Lambdaを利用した開発

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

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

6. アクセス制御と認証

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

8. おわりに

(16)

Lambdaとは

• AWSが提供しているコンピューティングサービス

– サーバをプロビジョニングしたり管理しなくてもコードを実行できる

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

• 最大処理時間15分

– バッチ処理には向かない

• イベントにより、コンテナが処理中のみ立ち上がって関数が実行さ

れる

– APIへのリクエスト、時間、各種AWSサービスのイベント等

３．AWS Lambdaを利用した開発

(17)

Lambda関数から別のLambda関数の呼び方　1/2

Lambda関数をモジュール単位で分割して開発したい

Lambda ウェブ用実績登録ロジック実績テーブル Dynamo DB ボット用

しかし、Lambdaは各関数が隔離されたコンテナで動作するため

言語仕様上の呼び出し方では不可能

resiter bot bot.js

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

エラー

例：

(18)

Lambda関数から別のLambda関数の呼び方　2/2

AWS SDK のLambda関数呼び出しメソッドを利用

bot.js

const AWS = require(‘aws-sdk’); const lambda = new AWS.Lambda({ ... }); ... lambda.invoke({ FunctionName: ‘register’, Payload: parameters }); SDKは require 可能 関数名(FunctionName)を 指定して呼び出し

３．AWS Lambdaを利用した開発

(19)

DynamoDBとは

• AWSで提供されているKey Value Store型のデータ

ベース

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

• トランザクションは使えない

– コミット・ロールバックなし

– 複数レコードの一貫性が保たれなくても本当に問題ないか、十分に検討

する必要がある

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

(20)

Lambda関数のユニットテスト手法

Lambda関数に依存するAPIやDBはクラウド上のサービスとなってい

るため、通常はLambda関数のユニットテストはクラウドにあげて行う

必要がある

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

– SAM Local (現 SAM CLI)

– DynamoDB ローカル

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

３．AWS Lambdaを利用した開発

(21)

SAM Local

• AWSのサーバレス環境をローカルPCのDockerコンテ

ナ上で構築できるコマンドラインツール

– CloudFormationテンプレートを利用する事で、本番と同等

の環境が構築可能

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

• ローカルで任意のタイミングで素早くテスト出来る環境

はアジャイル開発においては必須

SAM Localのセットアップ方法

(22)

DynamoDBローカル

• ダウンロード可能なDynamoDB

– Javaアプリケーション

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

• SAM LocalではDynamoDBは構築されないため、使

用する必要がある

３．AWS Lambdaを利用した開発

(23)

ローカルPC環境全体図

Node.js Docker ソースコード / テストコード仮想AWS環境 SAM Local DynamoDBローカル Lambdaから参照コンテナ立ち上げ CentOS 7.1 Virtual Box Windows 7 ローカルPC 社用PCだとセキュリティソフトとの兼ね合い (?)でWindows 7上で Dockerが動作しなかったため、 Linuxの仮想OS上で環境を構築 コンテナ立ち上げ・環境構築 JDK 8

(24)

1. はじめに

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

3. AWS Lambdaを利用した開発

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

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

6. アクセス制御と認証

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

8. おわりに

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

(25)

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

Hangouts Chat

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

こんにちはコンニチハ CloudFront

WAF API Gateway Lambda DynamoDB

Google Cloud Platform

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

Google Apps Script

Hangout Chat用IF

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

(26)

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

登録する研修名は？サーバーレス研修日は？登録実行登録しました 2018/06/12 会話の開始会話の終了

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

ユーザ _{チャットボット} _機能

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

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

(27)

会話の状態保持

Lambdaは処理が終わるとインスタンスが破棄されてしまう。

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

データ構造

{ user_id: ”abc” intent_id: ”sample” session:{ index: 2 entities:{ 　name:”サーバーレス ” } } } ユーザのID 進行中の話題何番目の会話まで進んだか会話の中で得た情報

(28)

テストの手法

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 実際にチャットクライアントを使用してテストするー _×

(29)

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

記述する

-

お客様にテストコードを直接レビューいただくことが可能

-

テストケース表を別途作成する必要がなくなる

#me 　←ユーザの入力登録 #bot 　←ボットからの応答どんな研修を受けましたか。タイトルを入れてください。 #me サーバーレスアプリケーション開発 #bot 「サーバーレスアプリケーション開発」ですね。

TestMyBotの特徴

テストコード一例

(30)

レスポンスの問題発生

実装したものを触ってみると、ユーザの入力からボットの応答があるまでの

時間が非常に遅いことがわかった。

ⅰ 1.5秒 _ⅱ 0.4秒 ⅲ 0.8秒 ⅳ 0.4秒

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

(31)

Botの応答速度改善

Hangouts Chat Hangout Chat用IF Google 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 DynamoDB Google Apps Script

TOTAL

4秒 → 3.5秒

(32)

1. はじめに

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

3. AWS Lambdaを利用した開発

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

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

6. アクセス制御と認証

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

8. おわりに

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

(33)

• アプリケーションの形態は Single Page Application とした

–

フロントエンドのライブラリとして React.js を採用

• Single Page Application とは？

–

単一ページで構成されるWebアプリケーション

–

サーバサイドではデータのみを返すREST APIを実装

–

クライアントサイドでJavaScriptを用いてDOMを操作してページを切り替える

Webアプリケーション概要

CloudFront

WAF API Gateway Lambda Dynamo DB

REST APIを実装

ブラウザ React.js

(34)

Single Page Application の特徴

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

サーバサイド処理の違い ● データのみをクライアントへ返し、クライアントサイドで描画する ● 必要箇所のみ再描画するため、レスポンスも速い ● サーバサイドで HTMLを描画してクライアントへ返すセッションの有無 ● 無し ● DBで保持する、もしくはクライアントサイドで保持する必要がある (Cookie等) ● 有りブラウザとの依存性 ● ブラウザがJavaScriptをサポートしている必要がある ● 特に無し

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

(35)

Single Page Application の特徴

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

サーバサイド処理の違い ● データのみをクライアントへ返し、クライアントサイドで描画する ● 必要箇所のみ再描画するため、レスポンスも速い ● サーバサイドで HTMLを描画してクライアントへ返すセッションの有無 ● 無し ● DBで保持する、もしくはクライアントサイドで保持する必要がある (Cookie等) ● 有りブラウザとの依存性 ● ブラウザがJavaScriptをサポートしている必要がある ● 特に無し次スライドで詳しく説明

(36)

処理フロー図

例：研修実績登録時 API Gateway Lambda I/F 実績登録_ロジック実績テーブル DynamoDB ユーザブラウザ・入力値のバリデーション・システムプロパティ作成 ① 実績を入力し、　登録ボタンをクリック

② APIに対してリクエスト ③ 対応するLambda関数_{が実行される} ④ DynamoDBに_{実績データを挿入}

⑤ レスポンスを　 API Gatewayに渡す ⑥ レスポンスを　クライアントに返す ⑦ APIのレスポンスを受け取り　画面を再描画

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

(37)

処理フロー図

例：研修実績登録時 Lambda I/F 実績登録_ロジック実績テーブル DynamoDB ユーザブラウザ・入力値のバリデーション・システムプロパティ作成 ① 実績を入力し、　登録ボタンをクリック

⑤ レスポンスを　 API Gatewayに渡す ⑥ レスポンスを　クライアントに返す ⑦ APIのレスポンスから　非同期で画面を再描画シンプルなREST APIを実装 { statusCode: 200, data: { … } } データをJSONを返す API Gateway

(38)

処理フロー図

例：研修実績登録時 API Gateway Lambda I/F 実績登録_ロジック実績テーブル Dynamo DB ユーザブラウザ・入力値のバリデーション・システムプロパティ作成 ① 実績を入力し、　登録ボタンをクリック

⑤ レスポンスを　 API Gatewayに渡す ⑥ レスポンスを　クライアントに返す ⑦ APIのレスポンスを受け取り　画面を再描画登録ボタンクリック前登録ボタンクリック後

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

(39)

React.jsについて

• A JavaScript library for building user interfaces

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

• コンポーネント

単位で実装

• コンポーネントとは、UI部品の見た目と振る舞いをセッ

トにしたもの

– 例：ボタンとクリック時のイベントハンドラ

• コンポーネントとDOMは1：1対応

– DOMの粒度は実装者が決定

(40)

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

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

資料を作る追加部屋の掃除をする本を買う

✔

メールを返す

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

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

最初は大きい粒度で実装した方がやりやすい

(コンポーネント分割は後からでも可能)

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

(41)

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を設計しておくと、

仕様変更に強いコードになる

(42)

テスト手法

テスト種類テスト内容使用lib 自動化 UT (クライアント側₎ ● 実装したコンポーネントの動きをテスト ● コンポーネントが問題なく作られるかどうか、コンポーネント中の要素がクリックされた時の動きを仮想的にシミュレートする Enzyme

○

ITa ● APIにリクエストして期待のレスポンスが返ってくるか、 AWSの結合テスト ● AjaxでAPIにリクエストを送るコードを書き、テストする -

○

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

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

○

ST

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

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

(43)

Enzyme

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

• React.jsコンポーネントの処理を画面に描画せずとも

仮想的にシミュレートできる

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

– コンポーネント中の要素がクリックされた時に正しくイベント

ハンドラが動作するか

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

(44)

Puppeteer

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

• Headless Chromeも制御可能

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

• DOMが生成される / 削除されるまで処理を待機させる

事が可能のため Single Page Application と相性が良

い

(45)

1. はじめに

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

3. AWS Lambdaを利用した開発

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

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

6. アクセス制御と認証

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

8. おわりに

(46)

セキュリティに関する考え方

本システムは、秘匿性の高いデータを持っていない。また、社員が通常業務を行う上で

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

1. 正当な権利を持った人だけが使用できる

a. ユーザ認証を行う b. チャットボットへのアクセス制御を行う c. Webアプリへのアクセス制御を行う

2. 正当な権利を持たない人に変更されない

a. WAFを使用し、CSRF、XSSなど基本的な対策を実施する

3. 個人情報を漏洩させない

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

６．アクセス制御と認証

(47)

Webアプリでのユーザ認証

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

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

項番内容 ① 利用するWebページを取得 ② 社内の共通認証基盤でログインし、IDトークンを取得する ③ IDトークンからユーザの認証情報を生成し返却する ④ ③で取得した認証情報を付与してAPIへリクエストを送信する ⑤ 認証情報を検証し、認可されていればLambdaを実行する認証フロー

(48)

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

Hangouts Chat

Google Apps Script

Google Cloud Platforms CloudFront WAF IFキーの送信 ①IFキーの存在チェック APIキーの付与 ②APIキーの存在チェックブロック項目手法 ①作成したプログラム以外からのアクセス WAFを使用してリクエストにIFキーが存在するかをチェックする ②API Gateway への直接アクセス Cloud Frontを使用してリクエストにAPIキーを付与し、

API Gatewayで存在をチェックする

API Gateway Lambda DynamoDB

研修実績管理システムのプログラム以外から

ボットAPIを利用できないようにする

(49)

Webアプリのアクセス制御

CloudFront

API Gateway Lambda

WAF DynamoDB ブラウザ S3 ②Cloud Front経由チェック ①IPアドレスチェック ③認証チェックブロック項目手法 ①社外IPからのアクセス WAFを使用して、IPアドレスのチェックする ②S3への直接アクセス CloudFront経由のアクセスかをS3でチェックする ③未認証ユーザのAPI Gatewayへのアクセス API Gatewayでユーザの認証をチェックする

(50)

個人情報の保護

IF チャットボットでの ID生成箇所 WebアプリでのID生成箇所インターフェースのイベントが発火した際に渡される情報には、実行したユーザの情報が含まれている。その情報の一つにメールアドレスがあるためそれを利用する。 Google によって発行された IDトークンを検証する際にユーザ情報を取得することが出来る。その情報の一つにメールアドレスがあるためそれを利用する。

• 社員の個人情報をAWSで保持しない設計とした

• 社員を特定するキーとなるようなプログラム上必要な情報はユーザのメールアド

レスをハッシュ化した物を利用した

• なりすましを防ぐためにユーザのメールアドレスはユーザが入力したものではな

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

６．アクセス制御と認証

(51)

1. はじめに

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

3. AWS Lambdaを利用した開発

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

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

6. アクセス制御と認証

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

8. おわりに

(52)

CI/CD環境が何故必要か

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

スプリント毎にフィードバックをもらうため、早く

リリースできる環境を整える必要がある

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

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

(53)

• ソースコードをコミットするだけでパイプラインが走る様にする

–

CLIからアップロードする事も可能だが、開発者のローカルPCの

環境構築が煩雑

• クラウド上のサービスのみを使ってCI/CD環境を作る

–

自前でCIサーバは立てない

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

サーバを直接参照できない

　warを作ってscpでアプリサーバにコピーして...は不可能

(54)

CI/CDプロセスの概略図

(55)

Build

• AWSリソース

– CloudFormationテンプレートをデプロイ可能

形式に変換

• Webアプリクライアント

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

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

(56)

Deploy

• AWSリソース

– テンプレートを基に各種サービスを

デプロイ

• Lambda関数

• DynamoDBのテーブル

• API

• Webアプリクライアント

– 特になし

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

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

(57)

Test

• 各種テストを実行

• テスト実行後、各種テストレ

ポートとWebアプリのITbの

実行中に撮られたスクリーン

ショットをS3のバケットに保

存

(58)

複数環境へのデプロイ

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

たい

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

• 本番環境とStaging環境で構成が異なってしまう事を避けるため

CloudFormationテンプレートファイルは1つにしたい

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

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

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

(59)

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

bugfix master release develop feature branches

ソースコードの構成管理として

Git-flow というブランチモデルを使用する事を策定した

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

(60)

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

Regiser: # 登録ロジックLambdaの定義

FunctionName: !Sub ‘tr_${EnvName}_register’ ...

Environment:

RESULT_TABLE: !Sub ‘tr_${EnvName}_result’ ...

CloudFormation Template Staging環境用 CodePipeline 設定画面 _{(CloudFormationの設定)}

Lambda関数名

環境変数

(61)

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 というビルダーを活用

(62)

1. はじめに

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

3. AWS Lambdaを利用した開発

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

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

6. アクセス制御と認証

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

8. おわりに

８．おわりに

(63)

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

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

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

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

化できる

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

スの再利用が可能

(64)

まとめ

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

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

　・Webからの実績登録

８．おわりに

(65)

ｅ

ａ

ご清聴いただき

(66)

ボット

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

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

• ユーザがチャットを操作したときのイベントを受け取る

• ボットへのリクエストをボットが期待する形に整形する

• ボットの応答をHangoutsChatが期待する形に整形する

• APIがユーザ個人を識別できる情報を付加する

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

• 会話の進行を制御する(戻ることもある)

• 今の話題や会話の進行度を管理する

• 機能の実行に必要な情報を収集・管理する

• 情報が揃ったときに適切な機能を実行する

• ユーザに適切なメッセージで応答する

付録

ボット本体インターフェース

(67)

会話の設計（用語）

• インテント

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

• エンティティ

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

• フルフィルメント

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

　

(68)

インテント

• システムが提供する機能単位でインテントを定義した

– 「登録」「削除」「照会」

• ユーザとの会話はインテントを基準に進行する

– 目的が達成されるまで(エンティティが揃うまで)繰り返される

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

付録

(69)

エンティティ

• 目的(インテント)を達成するために収集される情報

– インテントごとに内容は様々

– ユーザから聞き出す必要のあるものと無いものがある

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

(70)

フルフィルメント

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

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

付録

(71)

ボット本体の設計

IF ボットインテントコントローラーインテントA インテントB インテントC ・・・フルフィルメントA フルフィルメントB インテントD ・・・機能(インテント)の増加や修正等のインパクトをなるべく抑えるために上記のように切り分けを行った。また、インテントも共通部の処理は切り出し、会話の実装方法も固定化した。 API Gateway Lambda Lambda

(72)

ボット本体の設計

ボットインテントコントローラーインテントフルフィルメント Bot API へのリクエスト処理のエントリーポイントになる。 DBに格納されている「会話の状態」や、「ユーザの発言」を元に実行するインテントを決定する。「ボット」から渡された「会話の状態」と「インテント」を使って、会話の進行を制御する。進行した「会話の状態」を DBへ保存する。一つのインテントで行われる会話の内容を定義する。ユーザの発言から必要なエンティティを抽出しバリデーションも行う。フルフィルメントを実行するための処理も定義するシステムの核となる機能を持つ。インテントによって実行される。インテントとフルフィルメントは 1対1になるとは限らない。

付録

(73)

ボットインテントコントローラーインテントフルフィルメントインテントの決定・生成コントローラーの生成 run(input)を実行 run(input)を実行バリデーションとエンティティの抽出応答メッセージと成否 executeFullfilment(entity)を実行 invoke(entity)を実行成否成否会話状況の更新応答メッセージと成否インテント終了時

(74)

DynamoDB バックアップ方法検討　1/3

※ 2018年11月現在バックアップ種類メリットデメリットオンデマンドバックアップ ● Webインタフェース上で手軽にバックアップが取れる ● バックアップ対象の読み込みキャパシティを消費しない ● バックアップ処理は早い ● 自動化のための敷居が高い ○ Webインタフェース上では 1度きりのバックアップしか取れないため、 AWS CLIや各種SDK経由で行うスクリプトを書いて実行させる必要がある Data Pipeline によるバックアップ ● 定期実行が可能 ● バックアップは S3上にファイルとして作られるので取り回しが良い ● バックアップ処理が遅い ● 読み込みキャパシティを消費する ● Data Pipeline上で処理を定義する必要があるため導入の敷居が少し高い Point In Time Recovery (PITR) ● 1秒単位でデータをバックアップして 35日間分保存 ● 有効化するだけなので簡単 ● 35日分しか保存されない ● テーブルが削除されるとバックアップデータもなくなる

付録

(75)

DynamoDB バックアップ方法検討　2/3

PITR が手軽かつ強力

• 追加料金が発生するが、本プロジェクト程度の規模の場合であ

れば計算上は年間1ドルかからない

しかし...

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

しまう事を懸念

AWSサポートに連絡する事で、削除したテーブルのバックアップを復元する事も可能ではある https://forums.aws.amazon.com/thread.jspa?messageID=840798

Ｅ

ｘ ａ

Ｖ

ａ ｌ ｕ ｅ

Ｆ

ｏ ｒ ｕ m

2018

2018年 11月 7日

株式会社エクサ

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

萩森 省吾

冨田 大樹

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

目次

1. はじめに

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

3. AWS Lambdaを利用した開発

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

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

6. アクセス制御と認証

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

8. おわりに

目次

1. はじめに

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

3. AWS Lambdaを利用した開発

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

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

6. アクセス制御と認証

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

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.

●

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

●

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

●

コンピューティングリソースがサービスとして提供され、開発者が物理的な容量や限

界を管理する必要がない

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

１．はじめに

近年のクラウドサービスの動き

近年、サーバレスコンピューティングはAWSに続き、主要クラウド

サービスの全てがサービスを展開し、急速に注目を集めている

サーバレスの知見を得る事により、

新たなビジネスチャンスが生まれる！

マイクロサービスベースとなるため、構築が早く、

変更も容易となるシステムが開発できる

研修実績管理システムのリプレース

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

• サーバ老朽化による故障で、昨年から臨時サーバで運用

– 臨時環境であり、恒久的な運用に耐えられない

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

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

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

レースする事に

１．はじめに

目次

1. はじめに

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

3. AWS Lambdaを利用した開発

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

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

6. アクセス制御と認証

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

8. おわりに

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

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

リプレース要件

1. 社員がいつでもどこでも、研修実績を

登録することができる

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

3. 他の社内システムと同じユーザIDとパ

スワードを使って認証できる

チャットボットで提供

Webで提供

ｘａ

ａｌｕｅ

ｏｒｕ m

萩森省吾

冨田大樹

_Webで提供

主な言語・フレームワーク・ライブラリ一覧　1/2

主な言語・フレームワーク・ライブラリ一覧　2/2

Lambda関数から別のLambda関数の呼び方　1/2

Lambda関数から別のLambda関数の呼び方　2/2