【AWS Summit Osaka 2019 セッションレポート】めざせ！サーバレスプロフェッショナル #AWSSummit

AWS Summit Osaka 2019

#レポート

#Amazon API Gateway

#セッションレポート

#サーバーレス

#AWS X-Ray

かずえ

2019.06.27

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

AWS Summit Osaka 2019 のセッション、「めざせ！サーバレスプロフェッショナル」をレポートします。

セッション概要

サーバレスアプリケーションを本格的に活用したいデベロッパー向けのセッションです。巷では既に多くのサーバーレスアプリケーションが開発されプロダクション環境で稼働しています。本セッションでは、サーバレスアプリケーションを本格的に活用するうえで知っておきたい、フレームワーク、CI／CDパイプライン、チューニング、運用と監視について解説します。また、最新アップデートについてもお話します。

スピーカー

アマゾンウェブサービスジャパン株式会社技術統括本部ソリューションアーキテクト

清水崇之さん

セッションレポート

おさらい

サーバレスとは

サーバ管理不要
柔軟なスケーリング
アイドル時のリソース確保不要
組み込まれた高可用性

サーバレスのためのビルディングブロック

Lambdaが代表的サービス
だがそれ以外にも堅牢な一連のサービスが揃っているのがAWSの特徴
- DB
- ストレージ
- REST API
- などなど

REST APIの例

API Gatewayをフロントに
Lambda で各種処理
DynamoDBをデータストアに
AWS WAFでWAF機能を追加
CloudWatchで監視、ロギング
Cognito で認証機能追加
X-rayで分析とデバッグ

サーバレスアーキテクチャのメリット

各サービスの課金体系はリクエスト数やAPIコール数など→より効率的なコストになる
スモールスタートから大規模本番環境まで同じアーキテクチャでシームレスにスケールできる

開発テスト、フレームワーク

開発環境

Cloud9
- AWSサービス
- 他のAWSサービスとの密な連携が可能
以下にはプラグインを提供
- PyCharm
- IntelliJ
- Eclipse
- VisualStudio
- VS Code(Preview)

サーバレスアーキテクチャを拡大していくと直面する問題点

各機能ごとに複数のサービスを利用
機能数が増えていくと、モノリシックアーキテクチャと同様にどこに何があるかわからなくなるような問題に直面する
解決策として以下SAMを紹介

AWS SAM(Serverless Application Model)

AWSでサーバーレスアプリケーションを表現するスタンダードモデル
関数、API、イベントソースとデータストア
サーバレスアプリケーションのデプロイと管理を簡素化

SAMの動作

CFnの拡張として提供されている
Package & Deplopyが追加されている
YAMLもしくはjsonテンプレートを記述する
流れ
- ローカルにSAMテンプレートとソースコードがある
- SAMテンプレートをCloudFormationテンプレートに変換
- S3にコードをアップロード
- LambdaやAPI Gatewayなどがデプロイされる

SAM表記法

Lambda Function

AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31       # SAMのバージョンを指定

Resource:
  hogeFunction:                             # 関数名
    Type: AWS::Serverless::Function         # Lambdaということを指定
    Properties:
        Handler: index.handler                # 実行される関数
        Runtime: nodejs8,10                   # 実行ランタイムの指定
        CodeUri: s3://hogeBucket/code.zip     # 実装コードの場所を指定

API Gateway

Resources:
    hogeFunction:
        Type: AWS::Serverless::Function
        Properties:
        Handler: index.handler
        Runtime: nodejs8,10
        CodeUri: s3://hogeBucket/code.zip
        Events:
            GetResource:
                Type: Api                         # API Gatewayが暗黙的に追加される
                Properties:
                    Path: /resource/{resourceId}    # 鍵カッコはパスパラメータ
                    Method: get                     # HTTPメソッドを指定

DynamoDB

Resources:
    hogeTable:                             # テーブル名を指定
        Type: AWS::Serverless::SimpleTable   # 単一キーのテーブルを作成
        Properties:
            PrimaryKey:
                Name: id                         # 主キー名を指定
                Type: string                     # 型を指定
            ProvisionedThroughput:
                ReadCapacityUnits: 5             # 読み込みキャパシティを指定
                WriteCapacityUnits: 7            # 書き込みキャパシティを指定

awslabsで各種サンプルが提供されているので活用する

オープンソースのGitHubリポジトリ
https:github.com/awslabs/serverless-application-model/tree/master/examples

SAM CLI(旧SAM Local)

サーバレスアプリのためのローカルテストツール
ローカルマシンでレスポンスやログの確認ができる
Lambdaの実行環境をシミュレートしたDockerイメージ

使い方

sum init --runtime (runtime name)
関数ペイロード
- sam local generate-event-s3
関数ペイロードを用いてLambda関数をローカル実行
- sam local invoke hogeFunction -e s3event.json
APIをローカル実行
- sam local start-api

複数環境、CI/CD

開発テスト、実行には複数環境が必要

なぜ
- リソース重複利用避けたい
- ユーザーに影響なしで安全に新しいコードをテストしたい
- インフラ変更を安全にテストしたい
方法
- AWSアカウントを分ける
- 環境変数を使う
- SAM インフラをコードとして利用
- CI/CD アプリのテストとデプロイを自動化する

アカウント戦略

同じアカウント内でスタックを分ける

Good
- リソース管理簡単
- 管理や監視ツールを見やすい
Bad
- 許可やアクセス分離が難しい
オススメ
- 小規模チームや個人

アカウントを分ける

Good
- 許可やアクセスを確実に分離
- アカウントごとのリソース制限を管理しやすい
Bad
- 複数アカウントとそれらの間のコントロールの管理が難しい
オススメ
- 大規模チームや企業

Lambda

環境変数
- Lambdaの環境変数動的に渡せるキーと値のペア
- node.jsのprocess.env pythonのos.environのような標準的なAPIで利用可能
バージョニング、エイリアス
- エイリアスはLambdaの特定バージョンに対するポインタ
- バージョンごとにエイリアスを作れる

API Gatway

ステージ
- 環境変数のように利用できる
- $contextオブジェクトで利用できる
- API Gatewayのほとんどのフィールドからアクセス可能

一つのテンプレートから複数の環境を構築可能

バージョン管理システムでSAMテンプレートの変更を記録
テンプレート内に環境変数等を組み込むことで、一つのテンプレートから複数の環境を構築可能

例

SAMパラメーター
- 変数定義
  - MyEnvironment 環境名が入る
  - SpecialFeature1 特定機能が利用できるかの真偽値が入る
Lambda
- 上記変数を参照する
APIGateway
- 上記変数を参照する

Code系サービスと組み合わせてCI/CD

CodeCommit
CodeBuild
CodeDeploy
CodePipeline
X-Ray

パイプライン構成例

CodeCommitにコード変更をプッシュ
Pipelineが検知
S3におく
Codebuildが起動、ビルド＆テスト実施
SAMテンプレートができる
SAMテンプレート実行
LambdaやAPI Gatewayなど各リソースがデプロイされる

Codestar

まるっと上記のようなパイプラインを作ってくれる
テンプレートを検索して選択するだけ

CodeDeploy

段階的なデプロイメントを実現可能

DeploymentPreferenceのTypeプロパティにて設定する/大別して3種類
- canary x percent y minutes
- linear x percent every y minutes
- all at once
- ※詳細情報

Alarm

何かしらのエラーで発生するCloudWatchのアラーム

Hooks

トラフィックシフトの前と後でLambdaの関数をフックする
関数失敗したらトラフィックシフト中止

APIGateway カナリアリリース

新しいステージのデプロイに進むトラフィックの割合を設定し、ステージの設定や変数をテストできる
カナリアリクエスト自体がCloudWatchLogsグループとメトリックスを別途持つ
ロールバックするにはでデプロイ削除かトラフィックの割合を0に設定
問題なければカナリアリリースを本番に昇格させる

環境の再利用方法

SAMやCloudFormationとして再利用
Serverless Application Repository経由で再利用する
- AWS CodePipeline SAR Auto-Publishで自動化
- awslabにある https://github.com/awslabs/aws-serverless-codepipeline-serverlessrepo-publish