AWSで始めるサーバレスな RESTful API システム

2017/03/11 ハンズラボ株式会社
JAWS DAYS 2017 AWSワークショップ
AWSで始める
サーバレスな
RESTful API システム
Copyright © 2017. All rights reserved.

Copyright © 2017 All rights reserved.1
ハンズオンで使用するファイル
・以下から圧縮ファイルをダウンロードして下さい
https://s3-ap-northeast-1.amazonaws.com
/hands-lab-handson/jawsdays_handson.zip
・解凍すると以下の４フォルダがあります
/API Gateway
（API Gatewayの設定用テキスト）
/Demo
（動作確認用のフロントの静的ファイル）
/DynamoDB
（DynamoDBのテーブル構築用テキスト）
/Lambda
（Lambda関数の作成用テキスト）

ハンズラボ株式会社
• 情シス部門
 東急ハンズの各種システムの内製開発と運用保守
• 外販
 自社開発の経験を活かした受託開発、内製支援
東急ハンズのシステム子会社

自己紹介
• 名前：加藤雅之
• 所属：ハンズラボ株式会社
• 担当：東急ハンズ
- AWSインフラ、IT
統制
ハンズラボ外販
- AWS構築運用支援
等

AWS Samurai 2015 / 2016を連続受賞
2015 長谷川 2016 青木

今日の内容
サーバレス（Serverless）とは
RESTful APIについて
４つのRESTの原則
設計でのポイント
BaaSとFaaS
AWSのサーバレス
SPA(Single Page Application)のすゝめ
サーバレスとの相性
フロントエンドとの完全分離

今日の内容
hands - on
１．DynamoDBのテーブル作成
２．Lambda実行用ロールの作成
３．Lambda実装
４．API Gateway の作成とデプロイ
５．動作確認
６．S3へ静的ファイルの設置
７．Cloudfrontでキャシュ作成

サーバレス（Serverless）とは
冗長性と可用性が担保される様なインフラの構築運用や、OSやミド
ルウェアを気にする必要が無い、開発に集中出来るアーキテクチャー
BaaS（バックエンドサービス）
データベースや認証、メッセージング等のサービス
FaaS（Function as a Service）
必要な物はコードのみで処理を実行させる
注意：サーバは存在します

主に使用されるAWSのサーバレス
Amazon S3（ファイルストレージ）
Amazon Cloudfront（コンテンツデリバリーネットワーク）
Amazon DynamoDB（NoSQLデータベース）
Amazon API Gateway（アプリケーションインターフェース）
AWS Lambda（コード実行サービス）
Amazon Cognito（認証認可サービス）
Amazon SQS（メッセージキューイング）等々。。。
特に定義は無いですが、
EC2インスタンスが影に見えない事

RESTful APIとは
REST（ Representational State Transfer ）の原則に沿った形で設計され
たAPI（Application Programming Interface）
その１ステートレス性
他のリクエスト情報から完全に分離している
その２統一インターフェース
HTTP定義通りのメソッドを使用する
その３アドレス可能性
URIで表されるユニークなアドレスを持つ
その４接続性
別のリンクを含めて辿る事が出来る

その１ステートレス性
セッション情報等のクライアント側の状態を持たず、他のリクエスト情報か
らも完全に分離されている。
ステートフルとステートレスの違いは、オライリーでRESTfulの本を監訳し
ている方の有名なブログが分かりやすい。
http://yohei-y.blogspot.jp/2007/10/blog-post.html
客：Aセットください。
店員：サイドメニューは？
客：ポテトで
店員：ドリンクは？
客：コーラで
店員：以上で良いですか？
客：はい
客：Aセットください。
店員：サイドメニューは？
客：Aセットをポテトで
店員：ドリンクは？
客：Aセットをポテトとコーラで
店員：以上で良いですか？
客：Aセットをポテトとコーラで。以上
ステートレスステートフル

その２統一インターフェース
処理 HTTPメソッド SQL CRUD操作
取得 GET SELECT READ
登録 POST INSERT CREATE
更新 PUT UPDATE UPDATE
削除 DELETE DELETE DELETE
PUTしたIDがない場合はCreateとなる
POSTはID指定が出来ないCREATE
CRUDとSQLとの比較
操作は定義通りのHTTPメソッドで

その３アドレス可能性
URI（URL / URN）にて簡単に指し示す事が出来る
ユニークなアドレスを持つ
URI (Uniform Resource Identifier）識別子
名前とアドレスを識別する書き方
URL (Uniform Resource Locator) 住所
場所を示す書き方のルールでWebアドレスで用いられる
URN (Uniform Resource Name) 名前
名前を永続的に識別する書き方のルールでISBN等がある
言語や実装依存の拡張子やパスを含めない
→ 環境が変わっても同じURIで動作

その４接続性
リソースの中に関連性を持つURIのハイパーメディアリンクを含む
事が出来る。
もちろん無理にリンクを設ける必要はない
例えば、商品購入リストのリソースの中に、個別商品のハイ
パーメディアリンク（URI）が記載されていれば接続性を保持して
いる事になる。

API設計で最初にすること
まずは、とにかくシンプルに何をどうするを考える
何＝リソース（情報）の洗い出し
どうする＝ CRUD(httpメソッド)
シンプル＝リソースの関連性を単純化する

API設計でのポイント
・リソース名をなるべく具体的な複数形の名詞にする
・バージョニングをどうするかを考える
おすすめはURIのパスに含める。他にはQueryパラメータやヘッダ等もある。
・メッセージフォーマットを決める
おすすめはJSON。他にはXML等も
・ドメインはAPIと分かりやすい物が良い
・URIを見ただけでリソースの関係性が分かるようにする
・リソースの階層は２階層くらいまで
https://api.hands-lab.com/v2/users
ユーザー一覧
https://api.hands-lab.com/v1/users/15/
ID15 ユーザーの指定
https://api.hands-lab.com/v2/articles/321/comments
ID 321記事のコメント一覧

SPA(Single Page Application)のすゝめ
単一ページで構成されるWebアプリケーション
主にHTMLとJavascriptで構成されており、DOM操作でページ切り替
えやAjax非同期更新を行う
AngularやReactやVue.js等々のフレームワークやライブラリがある
細かく非同期で更新をかけたいSPAと、疎結合でマイクロサービス化
されているRESTful APIは相性が良い
UI/UXをフロントエンドに任せることで、うまく分離して作業を進める
事が出来る。
またAPIとのやり取りをリソース情報のみに徹底する事は、アプリ対
応等に派生した場合も別対処する必要は無い。

ハンズオン
Let’s hands - on
１．DynamoDBのテーブル作成
２．Lambda実行用ロールの作成
３．Lambda実装
４．API Gateway の作成とデプロイ
５．動作確認
〜以下、補足説明〜
６．S3へ静的ファイルの設置
７．Cloudfrontでキャシュ作成

DynamoDB サービスを開く
マネイジメントコンソールにログインしたら、左上の
「サービス」メニューをクリック
データベースグループにある「DynamoDB」をクリック

DynamoDB テーブル作成
「テーブルの作成」ボタンをク
リック
テーブル名
→ handson_db
プライマリーキー
→ id
プライマリーキー属性
→ 文字列
テーブル設定
→ デフォルト設定の仕様
保存ボタンでテーブル作成

DynamoDB テーブル情報の確認
概要タブが選択されている事を確認
右の様な画面で
テーブル名
プライマリーパーティションキー
テーブルの状態
を作成した通りか確認

DynamoDB アラームの確認
アラームタブを選択
handson_dbの
ReadCapacity
WriteCapacity
のアラームが作成されている事を確認

DynamoDB キャパシティの確認
容量タブを選択
読み込み容量ユニット及び、書き込み容量ユニットがそれぞれ 5 となっている事を確認

DynamoDB 初期データ挿入1
項目タブを選択
項目の作成ボタンをクリック
項目の作成画面が開いたら左上の、選択項目から
Text を選択
※ 1参考画像
テキスト入力形式画面が開いたら、
DynamoDB JSON
のチェックボックスをチェック
※ 2参考画像
2 参考画像
1 参考画像

DynamoDB 初期データ挿入2
ハンズオンファイルから
DynamoDBフォルダ内にある
DynamoDB_sampleData_xxx.txt
をテキストエディタで開く
※xxx はmac / win の環境です
テキストの内容を、DynamoDB JSONの
画面に全て貼り付け
左側の行数箇所にエラーが出ていない事を
確認したら、保存

DynamoDB 初期データ確認
正しく反映されているか内容を確認
修正したいデータにチェックをつけて、アクションから編集も可能です

Lambda実行ロール IAMサービスを開く
左上のサービスをクリック
セキュリティ、アイデンティティグループにあるIAMをクリック

Lambda実行ロール新しいロールの作成1
IAMサービス画面に入ったら、左側のロールをクリック
「新しいロールの作成」ボタンをクリック
※IAMの権限作成は強力な権限です。
うまく開かない等がありましたらチュー
ターをお呼び下さい

ロール名の設定で
lambda_exec
と入力し、次へをクリック
ロールタイプの選択で
AWS Lambdaの右にある
選択をクリック

AmazonDynamoDB
FullAccess
と
AWSLambda
BasicExecutionRole
の２つのみをチェックして、
次のステップをクリック
設定した通りの内容になってい
るかを確認して、
ロールの作成ボタンをクリック

Lambda実装サービスを開く
コンピューティンググループにあるLambdaをクリック

Lambda実装作成画面を開く
まだ作成した事がない場合は、
「今すぐ始める」
ボタンをクリック
既に作成した事がある場合は、
「Lambda関数の作成」

Lambda実装関数の作成1
設計図の選択画面から画面中央にある
ブランク関数
をクリック
トリガーの設定では、そのまま次へ

関数の設定フェーズにて
名前
→ api_get_handson
説明
→ データ個別取得
ランタイム
→ Node.js 4.3

Lambda 関数のコードフェーズにて
コードエントリタイプ
→ コードをインラインで編集
ハンズオンファイルから
Lambdaフォルダ内にある
Lambda_sampleCode_xxx.txt
をテキストエディタで開く
※xxx はmac / win の環境です
テキストの内容を、
コードの箇所に全て貼り付け
左側の行数箇所にエラーが出ていない
事を確認

Lambda実装関数の作成４
環境変数の入力箇所のそれぞれに
→ TABLE_NAME → handson_db
ハンドラ
index.handler → index.get
ロール
→ 既存のロールを選択
既存のロール
→ lambda_exec

詳細設定をクリックしタイムアウトを10秒へ
次へをクリックして、内容が設定した通りか確認をしたら「関数の作成」
以下のように「あめでとうございます」となっているか確認

Lambda実装関数の作成６
左側のダッシュボードをクリックし、
同様の作業（「作成画面を開く」から「関数の作成５」）を
以下を変更しながら繰り返す
関数の作成２にて
名前
→ api_getall_handson
説明
→ データ一括取得
関数の作成４にて
ハンドラ
index.handler → index.getall

名前
→ api_put_handson
説明
→ データ登録
ハンドラ
index.handler → index.put

名前
→ api_delete_handson
説明
→ データ削除
ハンドラ
index.handler → index.delete

Lambda実装関数の作成９
左側の関数をクリックし、４つのlambda関数が登録されている事を確認

API Gateway の作成サービスを開く
アプリケーションサービスグループにあるAPI Gatewayをクリック

API Gateway の作成作成画面を開く
まだ作成した事がない場合は、
「今すぐ始める」
既に作成した事がある場合は、
「APIの作成」

API Gateway の作成 APIのインポート
Swagger からインポートをチェックして、右のSwaggerファイルの選択から
ハンズオンファイルのAPI Gatewayフォルダ内にある
apiGateway_sample.yml
を選択し、インポート

API Gateway の作成 Lambdaの紐付け1
リソースメニューの /resouce のGETをクリックし、
統合タイプ Lambda関数
Lambdaプロキシ統合の仕様にチェック
Lambda関数 api_getall_handson
で保存する。権限追加のダイアログはそのままOKを行う

リソースメニューの /resouce /{resourceId} のDELETEをクリックし、
Lambda関数 api_delete_handson

リソースメニューの /resouce /{resourceId} のGETをクリックし、
Lambda関数 api_get_handson

リソースメニューの /resouce /{resourceId} のPUTをクリックし、
Lambda関数 api_put_handson

API Gateway の作成 Mockの紐付け1
リソースメニューの /resouce のOPTIONSをクリックし、
統合タイプ Mock
で保存する。

API Gateway の作成 Mockの紐付け2
リソースメニューのの /resouce /{resourceId} のOPTIONSをクリックし、
統合タイプ Mock
で保存する。

API Gateway の作成 CORSの設定1
リソースメニューの /resouce 配下のOPTIONSをクリックし、
右下の統合レスポンスをクリック

表内の左端にある三角（▶）をクリックし、更にヘッダーのマッピングの三角をクリック

レスポンスヘッダー３種の右端にある鉛筆クリックし、マッピングの値を、
ハンズオンファイルのAPI Gatewayフォルダ内にある
apiGateway_options.txt
の通りに入力。入力後は右端のチェックマークをクリックで確定。
※前後のシングルクオーテーションも必要です。
同様の作業をリソースメニューの /resouce / {responceID }のOPTIONS
に対しても行って下さい。

API Gateway の作成デプロイ
アクションのAPIのデプロイをクリック新しいステージを選択し
ステージ名
→ handson
でデプロイをクリック

API Gateway の作成エンドポイントを確認
エンドポイント（URL）をメモ

動作確認エンドポイントの登録
ハンズオンファイルのDEMOフォルダ内にある
Index.htmlをテキストエディタで開く
139行目の API_endpoint を先程メモしたエンドポイントに書き換えて保存

動作確認
ハンズオンファイルのDEMOフォルダ内にある
Index.htmlをブラウザで開いて色々と動作を確認

動作詳細
Index.htmlの初回読み込み時及び、各タブ選択時
→ https://APIGatewayエンドポイント/resource/ GETメソッド
（api_getall_handson Lambda）
GETタブ内のGETボタン
→ https://APIGatewayエンドポイント/resource/{指定ID}/ GETメソッド
（api_get_handson Lambda）
PUTタブ内のPUTボタン
→ https://APIGatewayエンドポイント/resource/{指定ID}/ PUTメソッド
（api_put_handson Lambda）
DELETEタブ内のDELETEボタン
→ https://APIGatewayエンドポイント/resource/{指定ID}/ DELETEメソッド
（api_delete_handson Lambda）

時間の関係上、本日は省略しますが
クライアントでの動作にて問題が無いことを確認しましたら、
以下を実行する事で完全なサーバレスでの動作になります。
・動作検証済みのDEMOフォルダ内容をS3のバケットにアップロード
・対象のバケットに対してのキャッシュ配信をCloudFrontにて設定
※S3はCloudFrontからのみのアクセス許可を行うと良い
更に、Route53にてドメインを取得しCloudFrontへDNSを向け、
Certificate Managerにて証明書を取得しCloudFrontへ紐付ければ、
AWSのみで完結するサーバレスの基本形が完成します。
そこからはCognitoと連携させてログイン機能（認証認可）を行ったり、WAFやKMSと連携させてセキュアにし
てみたり、アイデア次第で様々な機能を持ったシステムを構築してく事が可能です。

最後に
サーバレスでもシステム運用は必要です。
もちろんステートレスな構成が故の、デプロイの難しさやログの追尾
性等の問題があります。
魔法の様な銀の弾丸では無いが、特性にマッチした部分で活用出来
るようになると非常に有効なシステムとなります。
多少無理でも大丈夫そうなら是非サーバレスで！
大事なことは「やっていく気持ち」

そんなエンジニアを募集中！
求むエンジニア！
ハンズラボは積極的に技術者採用中です。

AWSで始めるサーバレスな RESTful API システム

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à AWSで始めるサーバレスな RESTful API システム

Similaire à AWSで始めるサーバレスな RESTful API システム (20)

AWSで始めるサーバレスな RESTful API システム

Notes de l'éditeur