この記事は公開されてから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
監視,モニタリング
CloudWatch メトリックスとログ
- CloudWatch メトリクス
- CloudWatch logs
- 3rd partyツール利用するのもあり
X-ray サービスマップ
- 各ノードの呼び出しの結果を色で分類し、割合を円グラフにする
- グリーン 成功
- レッド 5xx error
- イエロー 4xx errors
- パープル 429 too many requestsスロットリングエラー
- 平均レイテンシ
- トレース数
- サービス名
- サービスの分類
デザインパターン
- 動的Webアプリモバイルバックエンド
- API Gateway
- Lambda
- DynamoDB
- インタラクティブデータ配信API
- API GatewayがWebSocketに対応
- 画像処理 シンプルなデータ加工
- S3データ投入をきっかけにLambda関数起動
- 画像圧縮、リサイズなど
- アプリケーションフロー処理
- Step Functionsでフロー化、可視化
- 流入データの連続処理
- Kinesisでバッファ
- Lambdaでポーリング
- S3に格納
- データ変更トリガー
- DynamoDB Streamでデータ変更をトリガーにLambda関数起動して各種処理（決済処理などの外部コールなど）につなげる
- 機械学習データパイプライン
- Step Functions
- データレイクからのデータ加工
- s3のデータをGlueでAthenaやRedshiftに加工しつつ格納
まとめ
- AWS SAM を使った開発、テスト
- 複数環境の使い分け
- CI/CDパイプラインで開発デプロイを自動化
- 段階的デプロイメントとカナリアリリース
- モニタリング安定運用
- デザインパターンの活用
感想
サーバーレス開発の現状の効率的な進め方手法を色々学ぶことができました。やはり色々なサービスを組み合わせてこそAWSの価値を最大限享受できるなと感じました。これからどんどん活用していきます。
補足
Summit Tokyoでも同様のセッションがありました。そちらのレポートもアップしておりますので、あわせてご覧下さい。
18
