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

2019.06.14

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

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に対応するpackagedeployコマンドが追加されている
    • 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
  • デザインパターン