Application Lifecycle Management in a Serverless World
11 likes4,823 views
2017/04/25にDevOps Days Tokyo 2017で登壇した際の資料です。 サーバレスアプリケーションのライフサイクル管理について。
Application Lifecycle Management in a Serverless World
- 1. Application Lifecycle Management in a Serverless World Keisuke Nishitani (@Keisuke69) Amazon Web Services Japan K.K. Apr 25, 2017
- 2. Who am I Keisuke Nishitani Specialist Solutions Architect, Serverless Amazon Web Service Japan K.K @Keisuke69 Keisuke69 ✤ スタートアップ担当 => Web系担当 =>サーバレスのスペシャリストSA ✤ RESTおじさん ✤ 餃⼦の王将エヴァンジェリスト（⾃称） ✤ ⾳楽が好きです、フジロッカーです、今年も⾏きます ✤ ブログ: http://keisuke69.hatenablog.jp/ Keisuke69 Keisuke69Keisuke69x
- 4. Serverless = No servers to manage and scale
- 7. Amazon S3 Amazon DynamoDB Amazon Kinesis AWS CloudFormation AWS CloudTrail Amazon CloudWatch Amazon SNSAmazon SES Amazon API Gateway Amazon Cognito AWS IoT Amazon Alexa Cron events DATA STORES ENDPOINTS REPOSITORIES EVENT/MESSAGE SERVICES AWS Lambdaと連携するイベントソース Amazon Config Amazon Aurora 続々と追加中！
- 8. AWSのサーバレスオファリング AWS LambdaAmazon API Gateway Amazon DynamoDB Amazon Kinesis Amazon Mobile Analytics Amazon SNS Amazon Cognito AWS IoT Amazon S3 Amazon Elastic Transcoder AWS CloudWatch AWS CloudTrail Amazon SES Amazon Machine Learning Amazon Route53Amazon SQS AWS Step Functions Amazon SWF Amazon Pinpoint* Amazon Athena
- 9. ユースケース Web Applications Data Processing ChatbotsBackends </></> Amazon Alexa Autonomous IT • Static websites • Complex web apps • Packages for Flask and Express • Real time • MapReduce • Batch • Powering chatbot logic • Apps & services • Mobile • IoT • Powering voice- enabled apps • Alexa Skills Kit • Policy engines • Extending AWS services • Infrastructure management
- 10. So, why are we here today?
- 12. サーバレスアプリケーション開発における ライフサイクルマネジメント ✤ 対象 ⎻ サーバレスアプリケーションのコード ⎻ サーバレスアプリケーションを構成するリソース ✤ やること ⎻ コードをどのようにビルド、テストしてデプロイするか ⎻ リソースをどのように構成管理してプロビジョニングするか
- 13. サーバレスアプリケーション開発における ライフサイクルマネジメント ✤ 対象 ⎻ サーバレスアプリケーションのコード => Lambdaファンクション ⎻ サーバレスアプリケーションを構成するリソース => AWSリソース ✤ やること ⎻ コードをどのようにビルド、テストしてデプロイするか ⎻ リソースをどのように構成管理してプロビジョニングするか
- 14. サーバレスアプリケーション開発における ライフサイクルマネジメント ✤ 対象 ⎻ サーバレスアプリケーションのコード => Lambdaファンクション ⎻ サーバレスアプリケーションを構成するリソース => AWSリソース ✤ やること ⎻ Lambdaファンクションをどのようにビルド、テストしてデプロイするか ⎻ AWSリソースをどのように構成管理してプロビジョニングするか
- 15. サーバレスアプリケーション開発における ライフサイクルマネジメント ✤ 対象 ⎻ サーバレスアプリケーションのコード => Lambdaファンクション ⎻ サーバレスアプリケーションを構成するリソース => AWSリソース ✤ やること ⎻ Lambdaファンクションをどのようにビルド、テストしてデプロイするか ⎻ AWSリソースをどのように構成管理してプロビジョニングするか サーバレスといっても特別なことはなく、通常のシステムと同じ
- 16. 開発ワークフロー構築における考慮点 ✤ 独⽴した複数の環境をどのように構築・維持するか ✤ どのように⾃動化を進めるか ✤ プロビジョニングやコンフィギュレーションが必要なAWSリソースは どれか、そしてそれをどうやるか ✤ 特に開発途中において、アプリケーションやアーキテクチャのテスト と検証をどのように⾏っていくか
- 17. テスト/検証 ✤ やりたいことは⾃分のコードが正しいことの確認 ⎻ シンタックスの問題がないか ⎻ 企業のフォーマット標準にあっているか ⎻ コンパイルが通るか ⎻ ユニットテストを通じて⼗分にテストされているか ✤ サーバレスで確認したいこと ⎻ 他のコンポーネントと関連するものとしてファンクションが動くか ⎻ アップストリーム、ダウンストリームのエラーを適切にハンドルできるか ✤ アプリケーション/インフラストラクチャ全体で確認したいこと ⎻ エンドツーエンドのテスト ⎻ セキュリティのベストプラクティスに従っているか ⎻ スケーラビリティのハンドリング
- 18. チェックリスト ✤ アプリケーションやインフラリソースのモデル化 ✤ 複数環境のコンフィグと管理 ✤ ⼿動によるデプロイメント ✤ デリバリプロセスの⾃動化（CI/CD） ✤ デバッグとモニタリング
- 19. チェックリスト ✤ アプリケーションやインフラリソースのモデル化 ✤ 複数環境のコンフィグと管理 ✤ ⼿動によるデプロイメント ✤ デリバリプロセスの⾃動化（CI/CD） ✤ デバッグとモニタリング
- 20. Author Package Test Deploy サーバレスアプリのライフサイクルマネジメント
- 21. Author Package Test Deploy AWS Lambda console サーバレスアプリのライフサイクルマネジメント
- 22. Author Package Test Deploy AWS Lambda console IDE plugins サーバレスアプリのライフサイクルマネジメント
- 23. Author Package Test Deploy AWS Lambda console IDE plugins 3rd party toolsText editor サーバレスアプリのライフサイクルマネジメント
- 24. Author Package Test Deploy AWS Lambda console IDE plugins 3rd party toolsText editor サーバレスアプリのライフサイクルマネジメント
- 25. サーバレスアプリのライフサイクルマネジメント ✤ 数⼗、数百のAWSリソースから構成される場合はどうするか？ ⎻ Lambdaファンクションだけでなく、関連するAWSリソースも ✤ 開発チームが巨⼤な場合はどうするか？ ⎻ マネジメントコンソールを使⽤したプロセスはありえない Author Package Test Deploy
- 26. AWS Serverless Application Model (powered by CloudFormation)
- 27. AWS CloudFormation ✤ 関連するAWSリソースのコレクションの プロビジョンと管理 ✤ JSON / YAMLで環境を記述 ⎻ テキストファイルなのでバージョン管理システ ムにも登録可能 ⎻ このテンプレートを使って何個でも同じ環境を つくれる ✤ アプリケーション＝CloudFormation stack ✤ テンプレートファイルがインプットであ り、プロビジョニングされたAWSリソー スがアウトプット
- 28. AWS Serverless Application Model (SAM) ✤ サーバレスアプリに最適化したAWS CloudFomationの拡張 ✤ サーバレスアプリ⽤の新たなリソースタイプ ⎻ 関数 ⎻ API ⎻ テーブル ✤ CloudFormationがサポートしているすべてのものをサポート ✤ 既存のファンクションをSAMテンプレートとしてエクスポート可能 ✤ オープンな仕様（Apache 2.0）
- 29. SAMテンプレート AWSTemplateFormatVersion: '2010-09-09’ Transform: AWS::Serverless-2016-10-31 Resources: GetHtmlFunction: Type: AWS::Serverless::Function Properties: CodeUri: s3://flourish-demo-bucket/todo_list.zip Handler: index.gethtml Runtime: nodejs4.3 Policies: AmazonDynamoDBReadOnlyAccess Events: GetHtml: Type: Api Properties: Path: /{proxy+} Method: ANY ListTable: Type: AWS::Serverless::SimpleTable
- 30. SAMテンプレート AWSTemplateFormatVersion: '2010-09-09’ Transform: AWS::Serverless-2016-10-31 Resources: GetHtmlFunction: Type: AWS::Serverless::Function Properties: CodeUri: s3://flourish-demo-bucket/todo_list.zip Handler: index.gethtml Runtime: nodejs4.3 Policies: AmazonDynamoDBReadOnlyAccess Events: GetHtml: Type: Api Properties: Path: /{proxy+} Method: ANY ListTable: Type: AWS::Serverless::SimpleTable AWS SAMのテンプレートであり、 変換が必要であると宣⾔
- 31. SAMテンプレート AWSTemplateFormatVersion: '2010-09-09’ Transform: AWS::Serverless-2016-10-31 Resources: GetHtmlFunction: Type: AWS::Serverless::Function Properties: CodeUri: s3://flourish-demo-bucket/todo_list.zip Handler: index.gethtml Runtime: nodejs4.3 Policies: AmazonDynamoDBReadOnlyAccess Events: GetHtml: Type: Api Properties: Path: /{proxy+} Method: ANY ListTable: Type: AWS::Serverless::SimpleTable 必要なアクセス権やランタイム、コ ードの場所などを指定してLambda ファンクションを定義
- 32. SAMテンプレート AWSTemplateFormatVersion: '2010-09-09’ Transform: AWS::Serverless-2016-10-31 Resources: GetHtmlFunction: Type: AWS::Serverless::Function Properties: CodeUri: s3://flourish-demo-bucket/todo_list.zip Handler: index.gethtml Runtime: nodejs4.3 Policies: AmazonDynamoDBReadOnlyAccess Events: GetHtml: Type: Api Properties: Path: /{proxy+} Method: ANY ListTable: Type: AWS::Serverless::SimpleTable イベントの定義 この例ではAPIとして⽤意するURIや 、HTTPメソッドを定義
- 33. SAMテンプレート AWSTemplateFormatVersion: '2010-09-09’ Transform: AWS::Serverless-2016-10-31 Resources: GetHtmlFunction: Type: AWS::Serverless::Function Properties: CodeUri: s3://flourish-demo-bucket/todo_list.zip Handler: index.gethtml Runtime: nodejs4.3 Policies: AmazonDynamoDBReadOnlyAccess Events: GetHtml: Type: Api Properties: Path: /{proxy+} Method: ANY ListTable: Type: AWS::Serverless::SimpleTable DynamoDBのテーブルを作成
- 34. 変換後のテンプレートAWSTemplateFormatVersion: '2010-09-09' Resources: GetHtmlFunctionGetHtmlPermissionProd: Type: AWS::Lambda::Permission Properties: Action: lambda:invokeFunction Principal: apigateway.amazonaws.com FunctionName: Ref: GetHtmlFunction SourceArn: Fn::Sub: arn:aws:execute-api:${AWS::Region}:${AWS::AccountId}:${ServerlessRestApi}/Prod/ANY/* ServerlessRestApiProdStage: Type: AWS::ApiGateway::Stage Properties: DeploymentId: Ref: ServerlessRestApiDeployment RestApiId: Ref: ServerlessRestApi StageName: Prod ListTable: Type: AWS::DynamoDB::Table Properties: ProvisionedThroughput: WriteCapacityUnits: 5 ReadCapacityUnits: 5 AttributeDefinitions: - AttributeName: id AttributeType: S KeySchema: - KeyType: HASH AttributeName: id GetHtmlFunction: Type: AWS::Lambda::Function Properties: Handler: index.gethtml Code: S3Bucket: flourish-demo-bucket S3Key: todo_list.zip Role: Fn::GetAtt: - GetHtmlFunctionRole - Arn Runtime: nodejs4.3 GetHtmlFunctionRole: Type: AWS::IAM::Role Properties: ManagedPolicyArns: - arn:aws:iam::aws:policy/AmazonDynamoDBReadOnlyAccess - arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole AssumeRolePolicyDocument: Version: '2012-10-17' Statement: - Action: - sts:AssumeRole Effect: Allow Principal: Service: - lambda.amazonaws.com ServerlessRestApiDeployment: Type: AWS::ApiGateway::Deployment Properties: RestApiId: Ref: ServerlessRestApi Description: 'RestApi deployment id: 127e3fb91142ab1ddc5f5446adb094442581a90d' StageName: Stage GetHtmlFunctionGetHtmlPermissionTest: Type: AWS::Lambda::Permission Properties: Action: lambda:invokeFunction Principal: apigateway.amazonaws.com FunctionName: Ref: GetHtmlFunction SourceArn: Fn::Sub: arn:aws:execute-api:${AWS::Region}:${AWS::AccountId}:${ServerlessRestApi}/*/ANY/* ServerlessRestApi: Type: AWS::ApiGateway::RestApi Properties: Body: info: version: '1.0' title: Ref: AWS::StackName paths: "/{proxy+}": x-amazon-apigateway-any-method: x-amazon-apigateway-integration: httpMethod: ANY type: aws_proxy uri: Fn::Sub: arn:aws:apigateway:${AWS::Region}:lambda:path/2015-03-31/functions/${GetHtmlFunction.Arn}/invocations responses: {} swagger: '2.0'
- 35. SAMで利⽤可能なリソースタイプ ✤ AWS::Serverless::Function ⎻ Lambdaファンクション ⎻ コードだけでなくメモリなどファンクション⾃体の設定 ⎻ イベントソースの設定
- 36. SAMで利⽤可能なリソースタイプ ✤ AWS::Serverless::Function ⎻ Lambdaファンクション ⎻ コードだけでなくメモリなどファンクション⾃体の設定 ⎻ イベントソースの設定 ✤ AWS::Serverless::Api ⎻ Amazon API Gatewayを利⽤したAPIの作成 ⎻ HTTPSのエンドポイントを通じて呼び出されるリソースとメソッドを定義 ⎻ AWS::Serverless::FunctionでAPI Gatewayをイベントソースとする定義をしていると⾃動で作成される ⎻ Swaggerを利⽤してより細かく管理する場合はこの定義が必須
- 37. SAMで利⽤可能なリソースタイプ ✤ AWS::Serverless::Function ⎻ Lambdaファンクション ⎻ コードだけでなくメモリなどファンクション⾃体の設定 ⎻ イベントソースの設定 ✤ AWS::Serverless::Api ⎻ Amazon API Gatewayを利⽤したAPIの作成 ⎻ HTTPSのエンドポイントを通じて呼び出されるリソースとメソッドを定義 ⎻ AWS::Serverless::FunctionでAPI Gatewayをイベントソースとする定義をしていると⾃動で作成される ⎻ Swaggerを利⽤してより細かく管理する場合はこの定義が必須 ✤ AWS::Serverless::SimpleTable ⎻ DynamoDBのシンプルなテーブルを作成 ⎻ 細かい設定が必要な場合は通常の AWS::DynamoDB::Tableを使⽤して定義する
- 38. チェックリスト ✤ アプリケーションやインフラリソースのモデル化 ✤ 複数環境のコンフィグと管理 ✤ ⼿動によるデプロイメント ✤ デリバリプロセスの⾃動化（CI/CD） ✤ デバッグとモニタリング
- 39. 複数環境の構成 ✤ アプリケーションを構築、テスト、実⾏するにはリソースごと分けた異な る環境を⽤意するのがよい ✤ Why？ ⎻ リソースの利⽤が被らないようにするため ⎻ ユーザ影響なく新規コードを「安全」にテストするため ⎻ インフラ構成の変更を「安全」にテストするため ✤ How？ ⎻ AWSアカウントをわける ⎻ Infrastracture as a Codeのツールを活⽤する ⎻ アプリケーションのデリバリとテストを⾃動化する
- 40. 複数環境を構成する2種類の⽅法 ✤同⼀アカウント、別スタック ⎻ メリット ⎻ リソースの管理が簡単 ⎻ 管理/モニタリングツールを通じた容易 な可視化 ⎻ デメリット ⎻ パーミッションやアクセス権の分離が 難しい ⎻ 数が増えると⾒通しが悪くなる ✤複数アカウント ⎻ メリット ⎻ パーミッションとアクセス権の分離が 保証される ⎻ 利⽤量をコントロールするためのアカ ウントごとのリソース制限 ⎻ デメリット ⎻ 複数アカウントの管理とコントロール のオーバーヘッド
- 41. 複数環境を構成する2種類の⽅法 ✤同⼀アカウント、別スタック ⎻ メリット ⎻ リソースの管理が簡単 ⎻ 管理/モニタリングツールを通じた容易 な可視化 ⎻ デメリット ⎻ パーミッションやアクセス権の分離が 難しい ⎻ 数が増えると⾒通しが悪くなる ✤複数アカウント ⎻ メリット ⎻ パーミッションとアクセス権の分離が 保証される ⎻ 利⽤量をコントロールするためのアカ ウントごとのリソース制限 ⎻ デメリット ⎻ 複数アカウントの管理とコントロール のオーバーヘッド ⼩規模なチーム/個⼈におすすめ ⼤規模なチーム/企業におすすめ
- 42. 複数環境を構成する2種類の⽅法 ✤同⼀アカウント、別スタック ⎻ メリット ⎻ リソースの管理が簡単 ⎻ 管理/モニタリングツールを通じた容易 な可視化 ⎻ デメリット ⎻ パーミッションやアクセス権の分離が 難しい ⎻ 数が増えると⾒通しが悪くなる ✤複数アカウント ⎻ メリット ⎻ パーミッションとアクセス権の分離が 保証される ⎻ 利⽤量をコントロールするためのアカ ウントごとのリソース制限 ⎻ デメリット ⎻ 複数アカウントの管理とコントロール のオーバーヘッド ⼩規模なチーム/個⼈におすすめ ⼤規模なチーム/企業におすすめ AWS Organizationsの利⽤検討を
- 43. AWS Organizations ✤ 複数のAWSアカウントを運⽤するためのサービス ✤ APIを使⽤してAWSアカウントを作成可能 ✤ 追加コストなし。
- 45. チェックリスト ✤ アプリケーションやインフラリソースのモデル化 ✤ 複数環境のコンフィグと管理 ✤ ⼿動によるデプロイメント ✤ デリバリプロセスの⾃動化（CI/CD） ✤ デバッグとモニタリング
- 46. パッケージとデプロイに関するAWSコマンド ✤ AWS SAMのリリースにともない以下のコマンドが追加 ✤ aws cloudformation package ⎻ デプロイパッケージの作成(.zip file) ⎻ Amazon S3バケットへのデプロイパッケージのアップロード ⎻ S3 URIによるCodeUriプロパティの追加 ✤ aws cloudformation deploy ⎻ CloudFormationの‘CreateChangeSet’ APIをコール ⎻ CloudFormationの‘ExecuteChangeSet’ APIをコール
- 47. チェックリスト ✤ アプリケーションやインフラリソースのモデル化 ✤ 複数環境のコンフィグと管理 ✤ ⼿動によるデプロイメント ✤ デリバリプロセスの⾃動化（CI/CD） ✤ デバッグとモニタリング
- 48. AWS CodePipeline ✤ ⾼速かつ信頼性の⾼いアプリケーション更新のためのサービス ✤ 独⾃のワークフローを定義 ⎻ ソースコードチェック ⎻ ビルド ⎻ テスト ⎻ デプロイ ✤ ソフトウェアのリリースプロセスをモデル化し可視化 ✤ Git pushごとにビルド、テスト、デプロイ ✤ AWSサービスやサードパーティツールとのインテグレーション
- 50. Source Source GitHub Build JenkinsOnEC2 Jenkins Deploy JavaApp Elastic Beanstalk Stage CodePipeline
- 51. Source Source GitHub Build JenkinsOnEC2 Jenkins Deploy JavaApp Elastic Beanstalk Action CodePipeline
- 56. デプロイパッケージのビルド Node.js & Python • コードとすべての依存関係を含 むZIPファイル • npm/pipを使ってライブラリを インストール Java • コードとすべての依存関係を含 むZIPファイルもしくはスタン ドアロンJar • MavenやEclipseのプラグイン を使ってライブラリをインスト ール • コンパイルされたクラスとリソ ースファイル、/libにあるライ ブラリ C#（.NET Core） • コードとすべての依存関係を含 むZIPファイルもしくはスタン ドアロン.dll • NuGetやプラグインを使ってラ イブラリのインストール
- 57. AWS CodeBuild ✤ クラウド上でのビルドとテスト ⎻ ボリュームに合わせて⾃動でスケール ⎻ 分単位の時間課⾦ ✤ ソースレポジトリとして、AWS CodeCommit、 GitHub、 S3を利⽤できる ✤ ビルド環境としてPython、Java、Node.jsをサポート ⎻ テストツールを含めたカスタムビルド環境も構築可能 ✤ CodePipelineと連携しCI/CD環境を実現
- 58. サーバレスアプリのパイプライン Source Build Beta Test Prod
- 59. サーバレスアプリのパイプライン GitHub CodeBuild Ghost inspector Source Build Beta Test Prod CloudFormation (AWS SAM) CloudFormation (AWS SAM)
- 60. サーバレスアプリのパイプライン GitHub CodeBuild Ghost inspector Source Build Beta Test Prod CloudFormation (AWS SAM) CloudFormation (AWS SAM) ✤ CodePipelineを⽤いてGithubもしくはCodeCommitからソースを直接Pull
- 61. サーバレスアプリのパイプライン GitHub CodeBuild Ghost inspector Source Build Beta Test Prod CloudFormation (AWS SAM) CloudFormation (AWS SAM) ✤ CodePipelineを⽤いてGithubもしくはCodeCommitからソースを直接Pull ✤ AWS CodeBuildでサーバレスアプリのビルドとパッケージング ⎻ npm、pip、Javaコンパイル
- 62. サーバレスアプリのパイプライン GitHub CodeBuild Ghost inspector Source Build Beta Test Prod CloudFormation (AWS SAM) CloudFormation (AWS SAM) ✤ CodePipelineを⽤いてGithubもしくはCodeCommitからソースを直接Pull ✤ AWS CodeBuildでサーバレスアプリのビルドとパッケージング ⎻ npm、pip、Javaコンパイル ✤ AWS CloudFormationで完成したアプリをデプロイ
- 63. サーバレスアプリのパイプライン GitHub CodeBuild Ghost inspector Source Build Beta Test Prod CloudFormation (AWS SAM) CloudFormation (AWS SAM) ✤ CodePipelineを⽤いてGithubもしくはCodeCommitからソースを直接Pull ✤ AWS CodeBuildでサーバレスアプリのビルドとパッケージング ⎻ npm、pip、Javaコンパイル ✤ AWS CloudFormationで完成したアプリをデプロイ ✤ サードパーティツールによるテスト
- 64. サーバレスアプリのパイプライン GitHub CodeBuild Ghost inspector Source Build Beta Test Prod CloudFormation (AWS SAM) CloudFormation (AWS SAM) ✤ CodePipelineを⽤いてGithubもしくはCodeCommitからソースを直接Pull ✤ AWS CodeBuildでサーバレスアプリのビルドとパッケージング ⎻ npm、pip、Javaコンパイル ✤ AWS CloudFormationで完成したアプリをデプロイ ✤ サードパーティツールによるテスト ✤ 本番環境へのデプロイ
- 65. チェックリスト ✤ アプリケーションやインフラリソースのモデル化 ✤ 複数環境のコンフィグと管理 ✤ ⼿動によるデプロイメント ✤ デリバリプロセスの⾃動化（CI/CD） ✤ デバッグとモニタリング
- 66. メトリクスとログ ✤CloudWatchメトリクス ⎻ 標準 ⎻ Invocations ⎻ Duration ⎻ Throttles ⎻ Errors ⎻ カスタムメトリクスの作成 ✤CloudWatch Logs ⎻ 呼び出しごとに「START」、「 END」、「REPORT」エントリが CloudWatch Logsに出⼒される ⎻ 独⾃のログエントリを出⼒ ⎻ 可視化のためにサードパーティツー ルを利⽤
- 67. メトリクスとログ ✤CloudWatchメトリクス ⎻ 標準 ⎻ Invocations ⎻ Duration ⎻ Throttles ⎻ Errors ⎻ カスタムメトリクスの作成 ✤CloudWatch Logs ⎻ 呼び出しごとに「START」、「 END」、「REPORT」エントリが CloudWatch Logsに出⼒される ⎻ 独⾃のログエントリを出⼒ ⎻ 可視化のためにサードパーティツー ルを利⽤
- 68. AWS X-Rayを使ったトラブルシューティング ✤ AWS X-Rayを⽤いることでサービス間のイベントの 遷移を可視化 ✤ Lambdaファンクションから他のサービスに対する 呼び出しと時間をトレース ✤ ファンクションとサービスの依存関係、関連性を実 際に⽬視 ✤ 消えたイベントやスロットルといった状態を確認し たり診断したりが簡単に ✤ 簡単なセットアップ 簡単セットアップ AWS Lambda Amazon S3 Amazon DynamoDB
- 69. AWS X-Rayを使ったトラブルシューティング ✤ ⾮同期呼び出しの滞留時間とリトライを確認 ✤ AWSサービスに対する呼び出しパフォーマンスをプロファイリング ⎻ イベント処理の失敗を検知 ⎻ パフォーマンス問題の特定と修正が簡単に dwell times service call times retries
- 70. Service map
- 71. チェックリスト ✤ アプリケーションやインフラリソースのモデル化 ✤ 複数環境のコンフィグと管理 ✤ ⼿動によるデプロイメント ✤ デリバリプロセスの⾃動化（CI/CD） ✤ デバッグとモニタリング
- 72. まとめ ✤ サーバレスアプリにおけるライフサイクルマネージメント ⎻ サーバレスアプリケーションのコード ⎻ サーバレスアプリケーションのリソース ⎻ ⼀般的なシステムと⼤きな違いはない ✤ サーバレスアプリのモデル化とデプロイを実現するAWS SAM ⎻ ユニットテストはこれまで通り ✤ サーバレスアプリのビルドとデリバリパイプライン ⎻ CodeBuild ⎻ CodePipeline ✤ サーバレスアプリのデバッグ ⎻ CloudWatch ⎻ CloudWatch Logs ⎻ X-Ray
- 73. 最後に、
- 74. ローカル実⾏について
- 75. テストドライバ例 import json import lambda_function f = open(“event.json”) event = json.load(f) f.close() context = "” lambda_function.lambda_handler(event,context)
- 76. テストドライバ例 import json import lambda_function f = open(“event.json”) event = json.load(f) f.close() context = "” lambda_function.lambda_handler(event,context) イベントを静的ファイルとして⽤意しておき、ロード <= 必要に応じて設定する（今回は空） <= ファンクションの実⾏
- 77. テストドライバ例 def lambda_handler(event, context): #Do something if __name__ == "__main__": f = open("event.json") event = json.load(f) f.close() context = "" lambda_handler(event,context) • Pythonの場合、以下のようにすることでも可能。Javaも同様にPublicなmainメ ソッドを定義して内部で呼び出すことも可能
- 78. AWS Dev Day Tokyo 2017 • 2017/5/31（⽔）〜 6/2（⾦） • 受付開始 9:00〜 • セッション 13:20〜 • 品川プリンスホテル アネックスタワー 5F プリンスホール • 来場無料（要事前申し込み） http://www.awssummit.tokyo/devday/index.html 5/31（⽔） 6/1（⽊） 6/2（⾦） • Serverless Evolution Day• Microservices、DevOps、IoT、Deep Learning など最先端技術にフォーカスした実践的なセッション • Amazon.com CTO Werner Vogelsも登壇