[レポート] めざせ！サーバレスプロフェッショナル #AWSSummit

AWS Summit Tokyo 2019 Day3 で開催された「めざせ！サーバレスプロフェッショナル」についてレポートします。

目次

セッション情報

スピーカー：清水 崇之氏 （アマゾン ウェブ サービス ジャパン株式会社）

セッション名：めざせ！サーバレスプロフェッショナル

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

自己紹介

AWS芸人

https://www.slideshare.net/shimy_net

アジェンダ

• おさらい
• 開発テスト、フレームワーク
• 複数環境、CI/CD
• 監視、モニタリング
• デザインパターン

サーバーレスとは（おさらい）

• サーバ管理が不要
  • ソフトウェアのインストール不要
  • パッチの適用不要
• 柔軟なスケーリング
  • 必要なときに自動で拡張
  • ストレージ、ネットワーク帯域のキャパシティ考慮が不要
• アイドル時のリソース確保が不要
  • アイドル時には課金がされない
• 組み込まれた高可用性
  • 今まではAZを跨いで冗長構成にしていたが、もともと組み込まれている

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

• Lambda（サーバレスの核となる機能）
• それ以外にも堅牢なサービスが揃っている
• アプリはコードだけでは動かないので、ストレージ、DB、API Gatewayなどを組み合わせてアプリを構築していく

従来なら

• EC2、ELB、RDSが必要だった
• キャッシング、認証の仕組みを開発する必要があった

サーバレスなら

• API Gateway
  • 認証、スロットリング、キャッシング機能が最初から含まれている
• WAF
• Lambda
• Cognito（認証）
• DynanoDB
• CloudWatch（監視）
• X-Ray（モニタリング）
• 従来は稼働時間での課金だったが、サーバレスだと課金のポイントが非常に小さくなる
• スモールスタートして本番までそのままのアーキテクチャでスケールできる

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

使い慣れた開発環境

• AWS Cloud9
  • AWSサービスとの連携が密になっている
• 以下IDEではプラグインを提供
  • PyCharm
  • IntelliJ
  • Eclipse
  • Visual Studio
  • VS Code（Preview）

サーバレスの例

• マイクロサービスに向かうにつれてサービスが増えていく
• 疎結合になるほど、APIやファンクションが増えていく
• モノリシックと同じ様な課題に直面していく。どこに何があるのかわからないなど

AWS SAM（Serverless Application Model）

• AWSサーバレスアプリケーションを表現するスタンダードモデル
• 関数、API、イベントソースとデータストアを簡単に記述できる
• サーバレスアプリケーションのデプロイと管理を簡素化
  • アプリケーションの全てのライフサイクルのステップをコントロールできる
• SAMでPackage & Deploy
  • SAMとはCFnの拡張として提供している
  • CFnにSAMに対応するpackage、deployコマンドが追加されている
  • SAMはJSON、YAMLで記述する
  • 開発の流れ
    • SAMテンプレート、ソースコードを記述
    • packageコマンドでSAMテンプレートをCloudFormationテンプレートに変換
    • デプロイするパッケージをS3にアップロード
    • deployコマンドCloudFormationが実行され環境が作成される

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メソッドを指定
  

  • Eventsとして定義すると暗黙的にAPI Gatewayが作成される
• DynamoDB

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

• awslabsで各種サンプルが提供されているので活用する
  • https:github.com/awslabs
• Express.jsのサンプルを動かす
  • Githubからサンプルをcloneする
  • アカウントIDやリージョンを設定する
    • $ npm run config --account-id="<accountId>" -—bucket-name="<bucketName>" [--region="<region>" --function-name="<functionName>"]
  • AWSへデプロイする
    • $ npm run setup

AWS SAM CLI (旧 SAM Local)

• サーバレスアプリのためのローカルテストツール
• ローカルマシンでレスポンスやログの確認ができる
• Lambdaの実行環境をシミュレートしたDockerイメージ
• SAM CLIの使い方
  • サンプルアプリの作成
    • $ sam init --runtime nodejs8.10
    • テストコード、アプリコード、SAMのテンプレートの雛形が作成される
  • 関数ペイロード（S3イベントなど）を生成する
    • $ sam local generate-event s3 --bucket hogeBucket --key hogeKey > s3event.json
  • 上記作成した関数ペイロードを用いてLambda関数をローカルで実行する
    • $ sam local invoke hogeFunction -e s3event.json
  • APIをローカルで実行する
    • $ sam local start-api

複数環境 CI/CD

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

• なぜ？
  • リソースの重複使用を避けたい
  • ユーザに影響を与えずに安全に新しいコードをテストしたい
  • インフラストラクチャの変更を安全にテストしたい
• 方法は？
  • アカウント戦略：AWSアカウントを分ける
  • 環境変数：それぞれの環境に固有の変数を利用する
  • SAM：インフラストラクチャをコードとして利用する
  • CI/CD：アプリケーションのテストとデプロイを自動化する

アカウント戦略

• 同じアカウントでスタックを分ける：小規模チームや個人に向いている
  • リソース管理が簡単
  • 管理や監視ツールを見やすい
  • 許可やアクセスの分離が難しい
• アカウンを分ける：大規模チームや企業に向いている
  • 許可やアクセスを確実に分離できる
  • アカウントごとのリソース制限を管理しやすい
  • 複数アカウントとそれらの間のコントロールを管理するのが難しい

Lambda

• 環境変数
  • 関数に動的に渡すことができるキーと値のペア
  • Node.jsのprocess.env、Pythonのos.environのような標準的な環境変数をAPIで利用できる
  • オプションでKMS経由で暗号化できる
    • IAMによって、どのロールが復号化キーにアクセスできるかを指定できる
  • ステージごとに環境を作成するために利用すると便利
    • 開発、テスト、本番など

• バージョニング・エイリアス
  • エイリアスはLambda関数の特定のバージョンに対するポインタ
  • バージョンごとにエイリアスを作成できる
  • 開発、テスト、本番といった開発ワークフローにおいて異なるバリエーションのLambda関数で作業できる

API Gateway

• ステージ
  • 環境変数のように利用できる
  • $contextオブジェクトで利用できる
  • API Gatewayのほとんどのフィールドからアクセスできる
    • ラムダ関数ARN
    • HTTPエンドポイント
    • カスタム認証機能名
    • パラメータマッピング

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

• バージョン管理システムを使ってテンプレートへの変更を保存・追跡
• 同じテンプレートを使って、開発、テスト、本番、さらにはDR、複数のアカウントにまたがるなど、複数の環境を構築

LambdaとAPIGatewayの変数 ＋ SAMの例

• パラメータ部分
  • MyEnvironmentで環境を定義
  • SpecialFeature1で機能のオンオフを定義
• Lambda部分
  • !Ref: Myenvironmentでパラメータを参照
  • !Ref: SpecialFeature1で機能のオンオフを参照
• API Gateway部分
  • !Ref: Myenvironmentでパラメータを参照
  • !Ref: SpecialFeature1で機能のオンオフを参照

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

• CI/CDパイプラインの例
  1. 開発者がコードをCodeCommitにプッシュ
  2. CodePipelineがリソースの変更を検知
  3. CodeBuildが起動し、ビルド、テストを行い、デプロイ用の成果物を作成
  4. CodeDeployでデプロイする
• CodePipelineの動きを見てみたい場合は、CodeStarがまるっと上記を提供するので、最初に試してみるにはおすすめ
• AWS CodeStarからテンプレート（Node.js、Web service、AWS Lambda）を選択すると作成できる

段階的なデプロイメント

• CodeDeployで実現できる
• Deployment Preference Typeを指定することで可能
  • Canary10Percent30Minutes
    • 10%のトラフィックを30分間新しいLambdaに流し、その後100%新しいLambdaに流す
  • Linear10PercentEvery10Minutes
    • 10分ごとに10%ずつ新しいLambdaに流す
  • AllAtOnce
    • 即時にすべてのトラフィックを新しいLambdaに流す

アラーム、フック

• デプロイメントで何かしらのエラー（アラーム）が発生すると自動でロールバック
• フック
  • 新しいトラフィックの開始前後でLambdaをフックできる
  • LambdaはCodeDeployに成功、失敗をコールバックする
  • PreTraffic トラフィックが流れる前にLambdaが起動
  • PostTraffic トラフィック流れ出した後に起動

APIGateway：Canaryリリース

• 新しいステージのデプロイに進むトラフィックの割合を設定し、ステージの設定や変数をテストできる
• Canaryリクエストは、それ自身のAmazon CloudWatch Logsグループとメトリクスを別途で持つ
• ロールバックするには、デプロイを削除するか、トラフィックの割合を0に設定する
• 問題がなければCanaryリリースを本稼働に昇格させCanaryをデプロイから無効にする

再利用

• SAMやCloudFormationとして利用する
• Serverless Application Repository経由で再利用する
  • AWS CodePipeline SAR Auto-Publishで自動化

監視・モニタリング

メトリクスとログ

• CloudWatchメトリクス
  • デフォルトメトリクス
    • Invocations
    • Duration
    • Throttles
    • Errors, Availability
    • IteratorAge
    • DeadLetterErrors
  • カスタムメトリクス
    • 独自の特性をチェック
• CloudWatchログ
  • すべてのInvocationにおいてSTART、END、REPORTエントリが作成される
  • 自身独自のログエントリを送信
  • 集約化と可視化のためにサードパーティのツールを利用、Kibana、QuickSight、loggiy、DATADOG、splunk、sumologic

AWS X-Ray

• リクエスト実行状況の確認
• 問題の検出
• パフォーマンスの改善
• さまざまなアプリに最適
• トレースビュー
  • Trace
    • 単一のリクエスト。サービスをまたいだもの
  • Segment
    • Traceの構成要素
  • SubSegment
    • サービスなどの処理単位

サービスマップ

• どのコンポーネントが通信して、どのように依存しているか視覚的に確認できる機能
• 各ノードの呼び出し結果を色で分類し、割合を円グラフに
  • グリーン：成功した呼び出し
  • レッド：5xx errors
  • イエロー：4xx errors
  • パープル：429 Too Many Reuests（スロットリングエラー）
• 平均レイテンシ（ms）
• トレース数（trace/min）
• サービス名
• サービスの分類

デザインパターン

• API、モバイル関連
  • インタラクティブモバイル モバイルオフライン処理
    • リアルタイム通信要件や非接続状態（オフライン）要件のモバイル向け
      • AppSync → Lambda → DynamoDB
• データ加工、連携処理
  • 画像処理 シンプルなデータ加工
    • データ投入をきっかけにファイル情報を引き渡して処理を起動
      • S3イベント → Lambda → S3
  • アプリケーション フロー処理
    • 一覧の処理フローを可視化
    • エラー処理のフロー管理としても利用可
      • Step Funcitonsを利用
• データイベント処理
  • 流入データの連続処理
    • Kinesisに流入するデータを定期的に受信してデータ加工を施して格納
      • Kinesis → Lambda → S3
  • データ変更トリガー（変更に起因する処理の実行）
    • DynamoDBに実行されたデータ変更処理に反応したイベント処理
      • DynamoDB Stream → Lambda → RDSや外部コールなど
• バックエンドデータ処理
  • 機械学習/ETL データパイプライン
    • 一連のデータ加工や集計処理、学習処理、後処理をフローで管理
      • Step Functionsを利用
  • データレイクからのデータ加工
    • データレイクのデータの加工処理やDBへのデータローディング
      • Glueを利用

まとめ

• 開発環境IDE、SAM、テンプレート書き方、サンプル
• SAM CLI、ひな形アプリ、ローカルテスト
• 複数環境におけるアカウント戦略 / 環境変数 / ステージ
• CodeサービスとCI/CDパイプライン
• 段階的なデプロイメント、Canaryリリース
• 再利用、SAM、Serverless Application Repository
• 監視、モニタリング、CloudWatch、X-Ray
• デザインパターン