AWS Developer Associate 合格体験記/学習方法 [AWS認定4冠]

  • AWS Developer Associate 合格までの学習方法についての記録
  • 先にSAA, SOAを取得していたので、これでアソシエイト3種をコンプできました
  • SAA/SOAとDVAは試験の毛色が大分違う為相応の準備が必要でした
  • AWS認定のオンライン試験も初めてだったので、その辺りも書いておきます

試験までにやったこと

  1. AWS 公式研修: Developing on AWSの受講
    • 試験前にポイントと各モジュール末の問題を復習
  2. AWS WEB問題集
    • 2周 & 模擬試験
  3. AWS公式 模擬試験
  4. 書籍で問題集を実施
  5. AWS公式 試験対策ワークショップ
  6. AWS公式研修: DevOps Engineering on AWSの受講
  7. 公式ドキュメントを読む

0. 事前の知識レベル

AWS認定

  • 先に取得したアソシエイト試験

  • Developing on AWS研修受講前の業務経験

    • 複数のサーバレスアプリケーションのPoCを経験
    • CloudFormationやS3、CloudFront、WAF、AWS SDK等を頻繁に利用
    • Codeシリーズはあまり使っていなかった(Github Actionsなどを活用)
    • PO/SCM等のマネジメント寄りの業務や、SPA開発とそのHosting環境構築等を担当していたため、バックエンド(API Gateway, Lambda, DynamoDB等)を自ら手を動かして実装する機会に恵まれなかった

1. Developing on AWSを受講

  • 概要

    • 日程: 3days
    • テキストはGlimoreでPDFを閲覧する。受講後も閲覧可能。試験前の学習にも役立つ。
    • プログラムからSDKでAWSのサービスを動かす
    • 前提知識
      • AWSのサービスの知識
      • Java, C# /.NET, Pythonの実務的な知識
  • 所感

    • 費用を出して貰える会社であれば、確実に受講すべき
    • 各サービスの概要は基本的に別のAWSの資格取得時に理解していたが、Labで本業のPJ内で扱えていないサービスを触れたことが非常に大きかったと感じる
    • 特にCodeシリーズやLambda, API Gateway, X-Rayは必ず一度は触った方がいい
    • 本業ではNode.jsを活用しているので、研修のLabがJava, C#, Python縛りなのは残念であった
    • 研修内で講師が教えてくれる試験のポイントは本当に重要
  • 上位の研修として以下がある

    • DevOps Engineering on AWS
    • Advanced Developing on AWS
  • 試験直前に講師が話していた試験頻出ポイントを復習

    • 例:DynamoDBのRCU/WCUの計算方法(計算問題は必ず出る)
  • 各モジュール末の問題も復習した方が良い

2. AWS WEB問題集サイトを2周

  • AWS問題集サイト
    • AWS認定の学習で最も有名なサイト
    • 有料なので課金が必要
    • 過去にSAA, SAP, SOAもこのサイトで学習
    • アップデートのタイミングには注意
      • サイトのアップデートと公式試験のアップデートのタイミングがかなり離れている時は注意
      • 公式試験が改訂される直前にこのサイトでSAPやSOAの学習をして、本番が改訂版で大分違うという経験があります…
    • 少なくとも2021/9月末時点のDeveloper 認定ではドンピシャでした
      • 不安があれば、後ほど紹介する書籍も使った方がいいです
    • 模擬試験モードもある
  1. 問題集

    • 各7問 x DVA#40をコツコツ実施
      • サイト内でも他の試験と比較して問題数が少ないので楽であった
    • ミスした問題をMarkdownでノートに整理
    • 合格者は2周している方が多い
    • 回答後に表示される解説まで読んで理解しなければ、試験では太刀打ちできない
    • 解説のリンクや分からなかった問題を調べた際に登場する公式のホワイトペーパーを読むほど合格に近づく
  2. AWS認定試験モード(AWS WEB問題集でできる模擬試験)

    • AWS認定デベロッパー - アソシエイトを受験
      • 試験時間:130分
      • 65問題
      • 合格点:720点
      • 問題ストック総数: 280問
    • 1周目終了時点
      • 57/65問 855/975点 (87.69%)
      • 残り1時間程度を残して終了。だらだら進めたので、サイトの前半の問題は忘れている状態
      • サイト利用者の平均点は93.85%

AWS公式模擬試験

  • 概要
    • 本番よりもかなり難しい
    • 料金: 2200円(税込み)
    • 所要時間: 35分
    • AWS Web問題集は非公式であるため、公式の問題傾向は確認しておくべき。ここで問題の傾向が著しく異なっていたら注意

申し込み手順

  • 公式サイト/試験のスケジュールを立てる

  • サインイン

  • アカウントへ移動

  • 新しい試験の予約

  • ピアソンVUEで模擬試験をスケジュールする

  • DVA-P01: AWS Certified Developer - Associate Practice

  • 申し込みが完了するとメールが届く

  • 試験開始ボタンの押下で試験前の説明画面に遷移する

    • 申し込んだ当日に好きなタイミングで受験可能
  • 引っかかった問題は試験中にメモして後に確認した

    • Cognitoオーソライザーについてなど、WEB問題集では登場しなかった問題もあった

結果

  • 30分のうち20分程度で完了

  • 合計スコア: 65%

  • トピックレベルのスコア:

    • 1.0. Deployment 50%
    • 2.0. Security 60%
    • 3.0. Development with AWS Services 67%
    • 4.0. Refactoring 100%
    • 5.0. Monitoring and Troubleshooting 67%
  • 以降の学習では点数が低いカテゴリに重点をおいた(書籍で問題集を解いた)

試験の予約

  • AWS認定サイト
  • AWS Certified Developer - Associate
    • PSIによるスケジュール or ピアソンVUEによるスケジュールを選択
  • 試験オプションの選択
    • テストセンター
    • オンライン
      • 今回はこちらを選択
  • 試験の準備
    • PCのシステムテストは必ず実施すべき(会社のPCでは無理でした)
    • onVUEというアプリをダウンロードする
    • このアプリが頻繁に固まることがあるので注意
  • 確認ができたら次へ
  • 試験言語/試験監督の言語を選択
  • 日付を選択

4. 書籍:ポケットスタディ AWS認定デベロッパーアソシエイト

  • ポケットスタディ AWS認定デベロッパーアソシエイト

    • 最近Developer Associate対策専用の書籍が初めて出版された
    • 試験前の週末に購入
    • 試験問題集 50問を実施
      • 解説が丁寧でかなり理解が深まった
    • 「1章 公式サンプル問題と問題傾向、解説」
    • 模擬試験で点数の低かったカテゴリ(展開、セキュリティ、開発)の章末問題も実施
      • 解説が丁寧で理解が深まった
  • AWS認定3試験対策という書籍もある

    • 私はSOA受験時に購入してすでにやっていたので、今回の試験のためには使わなかったが、SAAやSOAを取っていない方には必要かも

5. AWS公式 試験対策ワークショップ

  • 概要
    • 定期開催されており、よくAWSからメールで案内が来る
    • 無料
  • 会社で業務時間内に受けてOKと言われたので受講
  • 所感
    • 暇があれば受講推奨
    • 試験のポイントを解説してくれる
    • 受けなくとも勉強すれば合格はできる
  • 試験前に章末問題と模擬試験などで引っかかったカテゴリのスライドを確認

6. AWS公式研修: DevOps Engineering on AWSの受講

  • 上位の試験の研修をDVA試験前に受講
  • この研修までに受験しようと考えていたが、結果的にDVAの対策にもなった

オンラン試験本番

  • オンライン試験について
    • 試験の30分前がチェックイン時間
      • スマホで部屋中を撮影して回るなど結構面倒
      • チャット形式で試験監督と会話する
    • モニターにつなげてはならない
      • なるべく大画面のPCを用意すべき
    • 試験中に部屋に人が入ってはならない
      • 子供が入ってしまう環境は危険
    • 余計な操作をするとonVUEが何度も固まるので注意
      • Command + で文字サイズを変更しようとしたり、試験開始後にチャットを操作したら、この事象が発生した
      • 事前のシステムチェックでは全く問題なく、試験開始後に初めて発生した
      • 一度PCを再起動する羽目にもなった
        • メールで届いたURLから復帰はできた
      • 固まったり途中離脱した際にも時間は進んだ状態で再開する。0からやり直しはできない
      • フルスペックのMacBookProで他のAPを閉じていたため、マシンのスペックの問題ではない。もしかしたら、Bluetoothで繋げていたLogicoolのマウスが問題となっていたかもしれない。何も繋げない方が良さそう
    • 正直なところストレスフルで最悪のUXだった

結果

  • 60分ほど残して試験を完了
  • 無事合格
  • 忘れないうちにDevOps Professionalも受けてみようと思います

参考

関連記事

Amazon API Gateway WebSocket APIでリアルタイム通信を行うチャットAPを開発 [SAR/SAM]

  • リアルタイムの双方向通信を可能にするAmazon API Gateway WebSocket APIについてのメモ
    • 活用例: チャットアプリ、金融取引システム
  • リアルタイムの双方向通信にはAppSyncを活用する手もあるが、条件によっては使えないことがあった(個人的にはAmplifyでAppSyncを自動生成するのが一番楽だと思います)
  • 下記はAWSブログで公開されていたリアルタイムチャットAPの開発方法とGithubに公開されているSAMテンプレートの内容の個人的理解のまとめ

Amazon API Gateway WebSocket API

WebSocketAPIとは

  • Amazon API Gatewayには以下の3種のタイプがある

    • HTTP API
    • REST API
    • WebSocket API
  • WebSocket API

    • リアルタイムでの双方向通信に用いられるAPIタイプ
    • 公式説明
      1
      2
      チャットアプリケーションやダッシュボードなど、リアルタイムのユースケース向けの永続的な接続を使用する WebSocket API を構築します。
      双方向の振る舞いにより、クライアント/サーバーとのやりとりがより豊富になります。これは、明示的なリクエストをする必要のないクライアントにデータをプッシュできるためです。 WebSocket APIは、チャットアプリケーション、コラボレーションプラットフォーム、マルチプレイヤーゲーム、金融取引プラットフォームなどのリアルタイムアプリケーションでよく使用されます。
  • 従来WebSocket APIを構築するためには、WebSocketプロトコルの基礎となる永続的な接続の管理を担当するホストの設定が必要であったが、API Gateway Web Socket APIであれば、こういった作業をショートカットできる

WebSocket APIの概念

  • ルート
    • 新しいリソースタイプ
      1
      ルートは、API Gatewayが特定のタイプのクライアントリクエストを処理する方法を記述し、ルートを識別するために提供する値であるrouteKeyパラメータを含みます。
    • WebSocket APIは1つまたは複数のルートで構成される
      1
      WebSocket APIは、1つまたは複数のルートで構成されています。特定のインバウンドリクエストで使用するルートを決定するには、ルートセレクションエクスプレッション(選択式)を指定します。式は、ルートのrouteKey値の1つに対応する値を生成する着信リクエストに対して評価されます。
  • API Gatewayでルートに使用できる3つの特別なrouteKey値
    • $default
      1
      選択式がAPIルート内の他のrouteKeyに一致しない値を生成する場合に使用されます。 これは、例えば、一般的なエラー処理メカニズムを実装するために使用できます。
    • $connect
      1
      クライアントがWebSocket APIに最初に接続するときに、関連するルートが使用されます。
    • $disconnect
      1
      クライアントがAPIから切断すると、関連するルートが使用されます。 この呼び出しは、ベストエフォート方式で行われます。

構築手順

開発サンプル:リアルタイムチャットAP

WebSocket Chat App Architecture

  • WebSocket APIとAPI Gatewayを使用してサーバーレスのリアルタイムチャットAPを構築する

  • 主な機能

    • クライアントはWebSocket APIに接続するときにチャットルームに参加
    • バックエンドは、ユーザーがWebSocket APIに接続した後に提供されるコールバックURLを使用して、特定のユーザーにメッセージを送信できる
    • ユーザーはルームにメッセージを送信できる
    • 切断されたクライアントはチャットルームから削除される
  • ロジック概要

    1
    アプリケーションは、クライアントとサーバー(1)間の接続を処理するAPI GatewayのWebSocket APIで構成されています。 クライアントがAPIに接続(2)または切断(5)すると、2つのAWS Lambdaが反応します。 sendMessage関数(3)は、クライアントがサーバーにメッセージを送信するときに呼び出されます。 サーバーは、新しいAPI Gateway管理APIを使用して、接続されているすべてのクライアント(4)にメッセージを送信します。 接続された各クライアントを追跡するには、DynamoDBテーブルを使用して接続識別子を保持します。
  • 構築方法は3つあったので全て試した

    • 手動でAWS Consoleから構築
    • AWS Serverless Application Repository(SAR)のsimple websocket-chat-appを実行
      • SARであればボタン一つで自動構築できる。SAMのテンプレートがAP単位で公開されている
      • 今回のチャットAPの一式(Lambda関数、DynamoDBテーブル定義、IAMロールなど)が提供されている
    • SAM(Serverless Application Model)テンプレートをSAM CLIで実行
      • GitHubリポジトリにSARで使われているテンプレートが公開されている
      • 上記のリポジトリを手元にCloneしてSAM CLIで実行する
  • AmplifyではWebSocket APIはまだ使えないっぽい(2021/08/20時点)

SAMテンプレート

  • SAM CLIを用いると以下のテンプレートで環境を自動生成できる

    • オリジナルのWebSocket APIを開発する際もここから改変すると楽そう
    • ParameterはDynamoDBのテーブル名のみ
    • 内容の説明は以降のコンソールでの実装手順と一緒にまとめた
      1
      2
      3
      4
      5
      6
      7
      8
      9
      10
      11
      12
      13
      14
      15
      16
      17
      18
      19
      20
      21
      22
      23
      24
      25
      26
      27
      28
      29
      30
      31
      32
      33
      34
      35
      36
      37
      38
      39
      40
      41
      42
      43
      44
      45
      46
      47
      48
      49
      50
      51
      52
      53
      54
      55
      56
      57
      58
      59
      60
      61
      62
      63
      64
      65
      66
      67
      68
      69
      70
      71
      72
      73
      74
      75
      76
      77
      78
      79
      80
      81
      82
      83
      84
      85
      86
      87
      88
      89
      90
      91
      92
      93
      94
      95
      96
      97
      98
      99
      100
      101
      102
      103
      104
      105
      106
      107
      108
      109
      110
      111
      112
      113
      114
      115
      116
      117
      118
      119
      120
      121
      122
      123
      124
      125
      126
      127
      128
      129
      130
      131
      132
      133
      134
      135
      136
      137
      138
      139
      140
      141
      142
      143
      144
      145
      146
      147
      148
      149
      150
      151
      152
      153
      154
      155
      156
      157
      158
      159
      160
      161
      162
      163
      164
      165
      166
      167
      168
      169
      170
      171
      172
      173
      174
      175
      176
      177
      178
      179
      180
      181
      182
      183
      184
      185
      186
      187
      188
      189
      190
      191
      192
      193
      194
      195
      196
      197
      198
      199
      200
      201
      202
      203
      AWSTemplateFormatVersion: '2010-09-09'
      Transform: AWS::Serverless-2016-10-31
      Description: >
      simple-websockets-chat-app
      SAM Template for simple-websockets-chat-app that has the DynamoDB table and Lambda
      functions needed to demonstrate the Websocket protocol on API Gateway.
      Parameters:
      TableName:
      Type: String
      Default: 'simplechat_connections'
      Description: (Required) The name of the new DynamoDB to store connection identifiers for each connected clients. Minimum 3 characters
      MinLength: 3
      MaxLength: 50
      AllowedPattern: ^[A-Za-z_]+$
      ConstraintDescription: 'Required. Can be characters and underscore only. No numbers or special characters allowed.'

      Resources:
      SimpleChatWebSocket:
      Type: AWS::ApiGatewayV2::Api
      Properties:
      Name: SimpleChatWebSocket
      ProtocolType: WEBSOCKET
      RouteSelectionExpression: "$request.body.action"
      ConnectRoute:
      Type: AWS::ApiGatewayV2::Route
      Properties:
      ApiId: !Ref SimpleChatWebSocket
      RouteKey: $connect
      AuthorizationType: NONE
      OperationName: ConnectRoute
      Target: !Join
      - '/'
      - - 'integrations'
      - !Ref ConnectInteg
      ConnectInteg:
      Type: AWS::ApiGatewayV2::Integration
      Properties:
      ApiId: !Ref SimpleChatWebSocket
      Description: Connect Integration
      IntegrationType: AWS_PROXY
      IntegrationUri:
      Fn::Sub:
      arn:aws:apigateway:${AWS::Region}:lambda:path/2015-03-31/functions/${OnConnectFunction.Arn}/invocations
      DisconnectRoute:
      Type: AWS::ApiGatewayV2::Route
      Properties:
      ApiId: !Ref SimpleChatWebSocket
      RouteKey: $disconnect
      AuthorizationType: NONE
      OperationName: DisconnectRoute
      Target: !Join
      - '/'
      - - 'integrations'
      - !Ref DisconnectInteg
      DisconnectInteg:
      Type: AWS::ApiGatewayV2::Integration
      Properties:
      ApiId: !Ref SimpleChatWebSocket
      Description: Disconnect Integration
      IntegrationType: AWS_PROXY
      IntegrationUri:
      Fn::Sub:
      arn:aws:apigateway:${AWS::Region}:lambda:path/2015-03-31/functions/${OnDisconnectFunction.Arn}/invocations
      SendRoute:
      Type: AWS::ApiGatewayV2::Route
      Properties:
      ApiId: !Ref SimpleChatWebSocket
      RouteKey: sendmessage
      AuthorizationType: NONE
      OperationName: SendRoute
      Target: !Join
      - '/'
      - - 'integrations'
      - !Ref SendInteg
      SendInteg:
      Type: AWS::ApiGatewayV2::Integration
      Properties:
      ApiId: !Ref SimpleChatWebSocket
      Description: Send Integration
      IntegrationType: AWS_PROXY
      IntegrationUri:
      Fn::Sub:
      arn:aws:apigateway:${AWS::Region}:lambda:path/2015-03-31/functions/${SendMessageFunction.Arn}/invocations
      Deployment:
      Type: AWS::ApiGatewayV2::Deployment
      DependsOn:
      - ConnectRoute
      - SendRoute
      - DisconnectRoute
      Properties:
      ApiId: !Ref SimpleChatWebSocket
      Stage:
      Type: AWS::ApiGatewayV2::Stage
      Properties:
      StageName: Prod
      Description: Prod Stage
      DeploymentId: !Ref Deployment
      ApiId: !Ref SimpleChatWebSocket
      ConnectionsTable:
      Type: AWS::DynamoDB::Table
      Properties:
      AttributeDefinitions:
      - AttributeName: "connectionId"
      AttributeType: "S"
      KeySchema:
      - AttributeName: "connectionId"
      KeyType: "HASH"
      ProvisionedThroughput:
      ReadCapacityUnits: 5
      WriteCapacityUnits: 5
      SSESpecification:
      SSEEnabled: True
      TableName: !Ref TableName
      OnConnectFunction:
      Type: AWS::Serverless::Function
      Properties:
      CodeUri: onconnect/
      Handler: app.handler
      MemorySize: 256
      Runtime: nodejs12.x
      Environment:
      Variables:
      TABLE_NAME: !Ref TableName
      Policies:
      - DynamoDBCrudPolicy:
      TableName: !Ref TableName
      OnConnectPermission:
      Type: AWS::Lambda::Permission
      DependsOn:
      - SimpleChatWebSocket
      Properties:
      Action: lambda:InvokeFunction
      FunctionName: !Ref OnConnectFunction
      Principal: apigateway.amazonaws.com
      OnDisconnectFunction:
      Type: AWS::Serverless::Function
      Properties:
      CodeUri: ondisconnect/
      Handler: app.handler
      MemorySize: 256
      Runtime: nodejs12.x
      Environment:
      Variables:
      TABLE_NAME: !Ref TableName
      Policies:
      - DynamoDBCrudPolicy:
      TableName: !Ref TableName
      OnDisconnectPermission:
      Type: AWS::Lambda::Permission
      DependsOn:
      - SimpleChatWebSocket
      Properties:
      Action: lambda:InvokeFunction
      FunctionName: !Ref OnDisconnectFunction
      Principal: apigateway.amazonaws.com
      SendMessageFunction:
      Type: AWS::Serverless::Function
      Properties:
      CodeUri: sendmessage/
      Handler: app.handler
      MemorySize: 256
      Runtime: nodejs12.x
      Environment:
      Variables:
      TABLE_NAME: !Ref TableName
      Policies:
      - DynamoDBCrudPolicy:
      TableName: !Ref TableName
      - Statement:
      - Effect: Allow
      Action:
      - 'execute-api:ManageConnections'
      Resource:
      - !Sub 'arn:aws:execute-api:${AWS::Region}:${AWS::AccountId}:${SimpleChatWebSocket}/*'
      SendMessagePermission:
      Type: AWS::Lambda::Permission
      DependsOn:
      - SimpleChatWebSocket
      Properties:
      Action: lambda:InvokeFunction
      FunctionName: !Ref SendMessageFunction
      Principal: apigateway.amazonaws.com

      Outputs:
      ConnectionsTableArn:
      Description: "Connections table ARN"
      Value: !GetAtt ConnectionsTable.Arn

      OnConnectFunctionArn:
      Description: "OnConnect function ARN"
      Value: !GetAtt OnConnectFunction.Arn

      OnDisconnectFunctionArn:
      Description: "OnDisconnect function ARN"
      Value: !GetAtt OnDisconnectFunction.Arn

      SendMessageFunctionArn:
      Description: "SendMessage function ARN"
      Value: !GetAtt SendMessageFunction.Arn

      WebSocketURI:
      Description: "The WSS Protocol URI to connect to"
      Value: !Join [ '', [ 'wss://', !Ref SimpleChatWebSocket, '.execute-api.',!Ref 'AWS::Region','.amazonaws.com/',!Ref 'Stage'] ]
  • Resourceのまとめ

    • AWS::ApiGatewayV2::Api x 1
    • RouteとIntegration x 3セット
      • AWS::ApiGatewayV2::Route x 3
      • AWS::ApiGatewayV2::Integration x 3
    • デプロイ関係
      • AWS::ApiGatewayV2::Deployment x 1
      • AWS::ApiGatewayV2::Stage
    • AWS::DynamoDB::Table x 1
    • Lambda関数と権限 x 3セット
      • AWS::Serverless::Function x3
      • AWS::Lambda::Permission x 3

WebSocket APIの作成(コンソールからの構築手順)

コンソールでポチポチする場合は先にLambda関数を作ったほうが手間が少ない
コンソールでの構築手順とテンプレートの該当箇所を以下に示す

  • AWS Console/API Gateway/APIを作成

  • APIタイプを選択

    • WebSocketAPIの”構築”を押下
  • Step1 APIの詳細を指定する

    • API名
      • ex. My Chat API
    • ルート選択式
      • ex. $ request.body.action
      • ルート選択式の値で記述された属性は、クライアントがAPIに送信するすべてのメッセージに存在する必要がある。リクエストメッセージの例↓
        1
        2
        3
        4
        {
        "action": "sendmessage",
        “data”: "Hello, I am using WebSocket APIs in API Gateway.”
        }
      • WebSocket APIは、メッセージの内容に基づいてメッセージをルーティングするために、ルーティングキーとして機能するJSON形式のメッセージを必要とする
    • 次へ
  • Step1の設定内容はSAMテンプレートの以下に該当する

    1
    2
    3
    4
    5
    6
    SimpleChatWebSocket:
    Type: AWS::ApiGatewayV2::Api
    Properties:
    Name: SimpleChatWebSocket
    ProtocolType: WEBSOCKET
    RouteSelectionExpression: "$request.body.action"
  • Step2 ルートを追加

    • $connectや$disconnectなどは事前定義されている
    • カスタムルート
      • “カスタムルートを追加”
        • こちらから独自のルートを作成する
      • ルートキーを入力
        • ex: sendmessage
    • 次へ
  • Step3 統合をアタッチする

    • 公式説明
      1
      この API をデプロイするには、少なくとも 1 つのルートを設定する必要があります。設定するすべてのルートに統合がアタッチされている必要があります。後で統合をセットアップするには、ルートの統合タイプとして [Mock] を選択します。
    • 統合タイプ
      • 以下がある
        • Mock, Lambda, HTTP, AWSのサービス VPCリンク
      • 今回はLambda
        • 既存のLambdaを選択
        • 先に作成しておく必要がある
      • Mock
        • 後で統合する場合はMockを選択
    • 次へ
  • Step2,3の設定事項(Route/Integration)はSAMの以下に該当する

    • RouteとIntegarationはセット(今回は3セット)
    • IntegrationでLambdaとの紐づけを行っている
      1
      2
      3
      4
      5
      6
      7
      8
      9
      10
      11
      12
      13
      14
      15
      16
      17
      18
      19
      20
      21
      22
      23
      24
      25
      26
      27
      28
      29
      30
      31
      32
      33
      34
      35
      36
      37
      38
      39
      40
      41
      42
      43
      44
      45
      46
      47
      48
      49
      50
      51
      52
      53
      54
      55
      56
      57
      58
      59
      60
      ConnectRoute:
      Type: AWS::ApiGatewayV2::Route
      Properties:
      ApiId: !Ref SimpleChatWebSocket
      RouteKey: $connect
      AuthorizationType: NONE
      OperationName: ConnectRoute
      Target: !Join
      - '/'
      - - 'integrations'
      - !Ref ConnectInteg
      ConnectInteg:
      Type: AWS::ApiGatewayV2::Integration
      Properties:
      ApiId: !Ref SimpleChatWebSocket
      Description: Connect Integration
      IntegrationType: AWS_PROXY
      IntegrationUri:
      Fn::Sub:
      arn:aws:apigateway:${AWS::Region}:lambda:path/2015-03-31/functions/${OnConnectFunction.Arn}/invocations
      DisconnectRoute:
      Type: AWS::ApiGatewayV2::Route
      Properties:
      ApiId: !Ref SimpleChatWebSocket
      RouteKey: $disconnect
      AuthorizationType: NONE
      OperationName: DisconnectRoute
      Target: !Join
      - '/'
      - - 'integrations'
      - !Ref DisconnectInteg
      DisconnectInteg:
      Type: AWS::ApiGatewayV2::Integration
      Properties:
      ApiId: !Ref SimpleChatWebSocket
      Description: Disconnect Integration
      IntegrationType: AWS_PROXY
      IntegrationUri:
      Fn::Sub:
      arn:aws:apigateway:${AWS::Region}:lambda:path/2015-03-31/functions/${OnDisconnectFunction.Arn}/invocations
      SendRoute:
      Type: AWS::ApiGatewayV2::Route
      Properties:
      ApiId: !Ref SimpleChatWebSocket
      RouteKey: sendmessage
      AuthorizationType: NONE
      OperationName: SendRoute
      Target: !Join
      - '/'
      - - 'integrations'
      - !Ref SendInteg
      SendInteg:
      Type: AWS::ApiGatewayV2::Integration
      Properties:
      ApiId: !Ref SimpleChatWebSocket
      Description: Send Integration
      IntegrationType: AWS_PROXY
      IntegrationUri:
      Fn::Sub:
      arn:aws:apigateway:${AWS::Region}:lambda:path/2015-03-31/functions/${SendMessageFunction.Arn}/invocations
  • Step4 ステージを追加

    1
    ステージは、API をデプロイできる個別に設定可能な環境です。API 設定の変更を有効にするには、ステージにデプロイする必要があります。開発や本稼働などの環境を表すステージを追加できます。
    • ステージ名
      • 任意のステージ名を定義
      • ex: Prod, dev
    • 次へ
  • SAMテンプレートでは以下のResourceが該当する

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    Deployment:
    Type: AWS::ApiGatewayV2::Deployment
    DependsOn:
    - ConnectRoute
    - SendRoute
    - DisconnectRoute
    Properties:
    ApiId: !Ref SimpleChatWebSocket
    Stage:
    Type: AWS::ApiGatewayV2::Stage
    Properties:
    StageName: Prod
    Description: Prod Stage
    DeploymentId: !Ref Deployment
    ApiId: !Ref SimpleChatWebSocket
  • Step5 作成してデプロイ

    • 内容を確認して”作成してデプロイ”を押下
    • ルートやステージが生成される
  • SAMテンプレートでは、ここまでの設定の他にLambda関数や実行環境、DynamoDBテーブルなどが定義されていた

  • 残りのResourceの詳細

    • AWS::DynamoDB::Table x 1
    • Lambda関数と権限 x 3セット
      • AWS::Serverless::Function x3
      • AWS::Lambda::Permission x 3

Lambda関数の構築(コンソールから)

  • コンソールから作る場合

    • Console/Lambda/関数の作成
    • sendMessage, onConnect, onDisconnectで関数を生成。コードスニペットを貼り付けてdeploy
  • コードスニペットはGitを参照

    • sendMessage関数
      • この関数は、クライアントの1つが送信したデータを受け取り、現在接続されているすべてのクライアントを検索し、それぞれに提供されたデータを送信する
    • onConnect関数
      • requestContextからのconnectionId値をDynamoDBテーブルに挿入する
    • onDisconnect関数
      • 指定されたconnectionId値に対応するレコードを削除
  • 手動の場合はAPI Gatewayとの統合と権限設定も必要

    • API GW.MychatAPI/ルート/各ルート/統合
      • 統合タイプ: Lambda関数として作成した関数を選択
  • SAMテンプレートでは以下のように表現される

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
ConnectionsTable:
Type: AWS::DynamoDB::Table
Properties:
AttributeDefinitions:
- AttributeName: "connectionId"
AttributeType: "S"
KeySchema:
- AttributeName: "connectionId"
KeyType: "HASH"
ProvisionedThroughput:
ReadCapacityUnits: 5
WriteCapacityUnits: 5
SSESpecification:
SSEEnabled: True
TableName: !Ref TableName
OnConnectFunction:
Type: AWS::Serverless::Function
Properties:
CodeUri: onconnect/
Handler: app.handler
MemorySize: 256
Runtime: nodejs12.x
Environment:
Variables:
TABLE_NAME: !Ref TableName
Policies:
- DynamoDBCrudPolicy:
TableName: !Ref TableName
OnConnectPermission:
Type: AWS::Lambda::Permission
DependsOn:
- SimpleChatWebSocket
Properties:
Action: lambda:InvokeFunction
FunctionName: !Ref OnConnectFunction
Principal: apigateway.amazonaws.com
OnDisconnectFunction:
Type: AWS::Serverless::Function
Properties:
CodeUri: ondisconnect/
Handler: app.handler
MemorySize: 256
Runtime: nodejs12.x
Environment:
Variables:
TABLE_NAME: !Ref TableName
Policies:
- DynamoDBCrudPolicy:
TableName: !Ref TableName
OnDisconnectPermission:
Type: AWS::Lambda::Permission
DependsOn:
- SimpleChatWebSocket
Properties:
Action: lambda:InvokeFunction
FunctionName: !Ref OnDisconnectFunction
Principal: apigateway.amazonaws.com
SendMessageFunction:
Type: AWS::Serverless::Function
Properties:
CodeUri: sendmessage/
Handler: app.handler
MemorySize: 256
Runtime: nodejs12.x
Environment:
Variables:
TABLE_NAME: !Ref TableName
Policies:
- DynamoDBCrudPolicy:
TableName: !Ref TableName
- Statement:
- Effect: Allow
Action:
- 'execute-api:ManageConnections'
Resource:
- !Sub 'arn:aws:execute-api:${AWS::Region}:${AWS::AccountId}:${SimpleChatWebSocket}/*'
SendMessagePermission:
Type: AWS::Lambda::Permission
DependsOn:
- SimpleChatWebSocket
Properties:
Action: lambda:InvokeFunction
FunctionName: !Ref SendMessageFunction
Principal: apigateway.amazonaws.com

SAR(Serverless Application Repository)で自動構築

  • SARにも今回の環境のテンプレートが公開されており、自動構築できる

  • 以下にアクセス

  • “Deploy”

  • 自分のAWSアカウントの確認画面で”デプロイ”

  • 以下のメッセージが表示された

    1
    承認が必要です。デプロイするには、[アプリケーション設定] セクションのチェックボックスをオンにしてください。
  • 該当箇所をチェック

    1
    このアプリがカスタム IAM ロールとリソースポリシーを作成することを承認します
  • デプロイを押下

  • Lambda/アプリケーションで生成されたAPスタックを確認することができる

  • 生成されていたリソース

    • DynamoDBテーブル: simplechat_connectionsはconnectionIdのみを保持する
    • API GW: SimpleChatWebSocket
      • $connect, $disconnect, sendMessageの3ルート
      • ダッシュボードからWebSocket URLを確認することができる
    • Lambda関数

      SAMテンプレートで自動構築

  • SAM CLIを使えば、SAMテンプレートで今回の構成を構築することもできる

    • SARでは裏側でSAMテンプレートを使っている
  • 今回のチャットAPのSAM Template手元にクローンしてCLIから実行する

### WebSocketAPIの検証/検証ツール wscat

  • WebSocket APIのテストには、OSSのコマンドラインツール wscatが役立つ
  1. NPMをインストールします。
  2. wscatをインストール
    1
    $ npm install -g wscat
  3. コンソールで、次のコマンドを実行して公開APIエンドポイントに接続します。
    • AWS Cnsole/API Gateway/My Chat APIのダッシュボードでWeb Socket URLとして下記のURLを確認出来る
      1
      2
      $ wscat -c wss://{YOUR-API-ID}.execute-api.{YOUR-REGION}.amazonaws.com/{STAGE}
      Bash
  4. sendMessage関数をテストするには、次の例のようなJSONメッセージを送信する。 Lambda関数はコールバックURLを使用してそれを返す:
    1
    2
    3
    4
    $ wscat -c wss://{YOUR-API-ID}.execute-api.{YOUR-REGION}.amazonaws.com/dev
    connected (press CTRL+C to quit)
    > {"action":"sendmessage", "data":"hello world"}
    < hello world
  • wscatを複数のコンソールで実行すると、それぞれが “hello world”を受信する。これで、WebSocket APIからメッセージを送信したり、応答を返すことができるようになったと言える
  • この検証方法は今回のサンプル以外でも使えそう

参考

関連記事

その他

[Angular x AWS CI/CD] CodePipelineの構築 (Github main更新→build→test→deploy to S3)

  • SPA(Angular)をAWSのS3でホスティングする際のCI/CDについてのメモ
    • 今回はGithubのbranchの変更をトリガーとしてCodePipelineを動かす
  • Amplifyであればコマンド一発で自動構築できるが、Github Enterprise Serverのリポジトリをソースプロバイダーとして選択できないという弱点があるので、会社では結局使えないケースもある

Angular x AWS Codepipeline

実装の流れ

AngularPJやHosting環境(S3 bucket)を構築済みであることを前提として、Githubのmain branchの更新時に自動でng buildとS3へのデプロイが実行されるようにする

  1. 事前準備
    • Githubにリポジトリを作成
    • Angular PJを作成
    • Hosting環境の設定
      • S3 bucketやCloudFront Distribution
  2. buildspec.ymlの生成
  3. CodePipelineの構築

1. buildspec.ymlの生成

  • Angular Projectに直下にbuildspec.ymlという名称で設定ファイルを生成する

  • buildspec.yml

    • CodeBuildの設定ファイル
    • ここでbuildやtestなどのコマンドを実行させる
  • my-angular-pj/buildspec.yml

    • 以下では、build以外のtest等の工程は一旦コメントアウトしている
      1
      2
      3
      4
      5
      6
      7
      8
      9
      10
      11
      12
      13
      14
      15
      16
      17
      18
      19
      20
      21
      22
      23
      24
      25
      26
      27
      28
      29
      30
      31
      32
      version: 0.2 # Codebuildの設定ファイル Angular PJの直下に必要

      phases:
      install:
      commands:
      - if [ -e /tmp/node_modules.tar ]; then tar xf /tmp/node_modules.tar; fi
      - npm install -g @angular/cli # Angular CLIをinstall
      - cd ./my-angular-pj # AngularPJ直下へ移動
      - npm install # AngularPJ配下にnode_moduleをinstallする必要がある
      #- npm ci
      # test時にchromeを利用可能にする場合には以下が必要
      #- curl https://intoli.com/install-google-chrome.sh | bash

      build:
      commands:
      #- npm run lint
      - npm run build --prod # buildを実行
      #- npm run test:ci
      #- npm run e2e:ci
      #- npm run e2e -- --protractor-config=e2e/protractor-ci.conf.js
      #- npm audit

      post_build:
      commands:
      - tar cf /tmp/node_modules.tar node_modules
      artifacts:
      files:
      - '**/*'
      base-directory: ./my-angular-pj/dist/my-angular-pj # build時に生成されるアーティファクトのパス
      cache:
      paths:
      - /tmp/node_modules.tar
  • npm ciについて

    • npm ciを用いるとpackage-lock.json を使用してパッケージをインストールできる
  • chromeについて

    • testまで実行する場合は、Chromeをinstallする必要がある

CodePipelineの構築

  • AWS Console/CodePipeline/パイプラインの作成

  • パイプラインを作成する

    • 任意のpipeline名を入力
      1
      例: pjname-web-pipeline
    • サービスロールはデフォルトの設定で自動生成される
    • next
  • ソースステージを追加する

    • ソースプロバイダ
      • 今回はGithubを選択
        • バージョン1,2があり、2が推奨されている
      • Amplifyで構築する場合はここでGithub Enterprise Serverを選択できない
    • 接続
      • “Githubに接続する”から、任意のOrganizationとの接続を作成することができる
      • 一度作成した接続は、同様のOrganizarion配下の別リポジトリにも活用可能
    • リポジトリ名
      • 任意のリポジトリを選択
    • ブランチ名
      • mainを選択
    • 検出オプションを変更する
      • “ソースコードの変更時にパイプラインを開始する”でOK
    • 出力アーティファクト形式
      • 特別な要件が無ければ、CodePipelineのデフォルトでOK
    • next
  • ビルドステージを追加する

    • プロバイダー
      • AWS CodeBuildを選択
    • リージョン
    • プロジェクト名
      • “プロジェクトを作成する”で新たなプロジェクトを作成
  • ビルドプロジェクトを作成する

    • プロジェクトの設定
      • Project名、Descriptionを任意で設定
        • ex: my-angular-app-build-pj
      • 追加設定
        • PJ名や所有者程度はタグ付けしておく
    • 環境
      • 環境イメージ
        • マネージド型かカスタムイメージを選択
      • OS: Ubuntu
      • ランタイム: Standard
      • イメージ
        • ここは常に最新のものを指定する: aws/codebuild/standard:5.0
      • イメージのバージョン: 最新のものを指定
      • 環境タイプ: Linux
      • 特権付与
        • Dockerイメージを構築するか、ビルドで昇格されたアクセス権限を取得する場合は、有効化
      • サービスロール/ロール名
        • 自動生成されたロールがデフォで指定されている
    • Buildspec
      • Githubリポジトリ直下にbuildspecファイルがある場合は以下でOK
        • ビルド仕様: buildspecファイルを使用する
      • 今回はGitリポジトリ配下にAngularPJがあり、その直下にbuildspec.ymlを配置するため、以下のようにパスを指定する
        • ./my-angular-pj/buildspec.yml
    • バッチ設定
      • 今回は設定不要
    • ログ
      • CloudWatch Logs - オプショナル
      • グループ名,ストリーム名を定義
        • ex: xxxx-build-log-group
        • ex: xxxx-build-log-stream
      • S3
        • S3ログオプショナル: 今回は不要
    • CodePipelineに進む
  • 特に追加する環境変数が無ければ、next

  • デプロイステージを追加する

    • デプロイプロバイダ
      • Amazon S3を選択
    • リージョン/バケットから作成済みのホスティング用バケットを選択
    • デプロイする前にファイルを抽出する
      • こちらにチェック
    • next
  • 以上でパイプラインが生成される

    • パイプラインの画面に飛び、最初のビルド・デプロイ処理が開始される(buildspec.ymlファイルをgitにpushする前の場合は失敗する)

参考

関連記事

その他


AWS Amplifyによるバックエンド(認証認可,API,CI/CD,AI/ML)の高速開発とCloudFormationとの使い分けについて

AWS Amplify 概要

AWS Amplify

  • AWSを用いたWEB/Mobileアプリを高速にリリースするための開発プラットフォーム

    • 競合はGCPのFirebase
    • どちらも利用経験があるが、Amplifyの方ができることが多く、連携部分も自動構築できるのが強みだと感じている
      1
      2
      3
      Amplify を使用するお客様は、数分の内にバックエンドを構成しアプリケーションと接続でき、
      また、静的なウェブアプリケーションのデプロイは数クリックだけで実行できます。
      さらに、AWS コンソールの外部でも、簡単にアプリケーションコンテンツの管理が行えます。
  • 目的:差別化につながらない重労働の排除

    • 認証周りのようなバックエンド構築やアプリへの組み込みをショートカットできる
      • 特にサーバレス構成に適している
    • バックエンドをCLIから対話形式で手軽に自動構築
      • AWSのベストプラクティスが反映された、フルマネージドなサービスを数分で即活用できる
  • Amplifyで提供されるもの
    Amplify Console

  1. Amplify CLI

    1
    2
    Web/Mobile APのバックエンドをインタラクティブに
    作成・管理するためのOSSツールチェーン
    • やりたいことから宣言的にバックエンドを構築できる
      • 自動構築言えばCFnもあるが、Amplifyは対話形式細かい設定を決めずにべスプラに沿った構成を瞬時に構築できる
  2. Amplify ライブラリ

    1
    Web/Mobile APとAWSを統合するためのOSSライブラリ
    • AWSのバックエンドとの連携に利用。SDKと比較して短く直感的にかける
  3. Amplify Console

    1
    2
    フルスタックサーバレスWebアプリをビルド、テスト、デプロイ、
    ホスティングするためのOSSライブラリ
  4. Amplify Admin UI

    1
    2
    Web/Mobile APのバックエンドとコンテンツを管理するための
    GUIツール
    • ユーザーとコンテンツの管理
    • GUIを用いたデータモデリング
      • GraphQLスキーマを自動生成できる
      • シンプルなデータモデルで完結するAPのバックエンドを手軽に開発できる
      • Admin UI (GUI)で作成されたデータをpullすることも可能

ユースケース

Amplify Usecase

AmplifyはCloudFormationと競合するか?

  • Amplifyを活用する前に分かっていなかったポイント

    • CloudFormationでPFを管理する場合、Amplifyが邪魔になってしまう?
  • 競合しなかった

    • Amplifyの構成もCFnテンプレートに取り込める
    • PF構成がパラメータレベルで定まっていれば最初からCFnを、試行錯誤しながら進めていくのであればまずはAmplifyが適している
    • 個人的には以下の開発フローが望ましいと感じた
      • 初期はAmplifyで高速開発&検証 → PF構成が確定 → Former2などを活用してCFnテンプレート化 → Gitで差分管理 → 他環境やPJに同一構成を展開
  • 新規開発(Serverless or PF構成未確定)

    • Amplifyによる自動構築が適する
    • 認証周りやCI/CD, モニタリング、DB, Serverlessサービスなどをコマンドで俊敏に構築していく
  • 新規開発(PF構成が確定済、サーバレスや認証周りを使わない)

    • こういったシンプルなケースは、はじめからCloudFormationで構築してOK
    • 無理にAmplifyを使う必要はない
  • 開発が進み、PF構成が確定

    • ここでCFnテンプレート化を図れば良い
    • Former2を活用して実環境をCFnテンプレートに落とし込む
    • 固定値のテンプレートを汎用化(変数化など)する
    • GitでPF構成の差分管理を実施
  • CloudFormtionとは用途が異なる

    • CFnはPFの管理、再現性の確保を重点においている
    • Amplifyはどちらかというと、俊敏性/高速開発に重点が置かれている
      • 差別化を図れない重労働の削減が目的
      • CFnと異なり、細かい設定を規定しなくともAWSのベストプラクティスに即したPFを作れる
        • 使ったことがないサービスをいきなりCFnテンプレに起こすのはしんどい
      • 個人的にはスタートダッシュを図る為のものというイメージ

利用手順

Amplifyによる自動構築の流れ

基本的に以下の順序でバックエンドを数分で自動構築できる

  1. Amplify CLIのインストール&設定
  2. PJの作成、Amplify初期化コマンドを実行
  3. API追加コマンドを実行
  4. デプロイコマンドの実行

Amplify CLI インストール/設定

  • インストール

    1
    npm install -g @aws-amplify/cli
  • 設定

    • 以下のコマンドを実行するとブラウザにAWS Consoleのログイン画面ができる
      1
      2
      3
      4
      5
      6
      > amplify configure
      Follow these steps to set up access to your AWS account:

      Sign in to your AWS administrator account:
      https://console.aws.amazon.com/
      Press Enter to continue
  • 立ち上がったブラウザでログインを実施

  • CLI上でEnter

  • 次にデフォルトリージョンを選択する

    • 東京であれば ap-north-east-1にカーソルを合わせてEnter
      1
      2
      3
      4
      5
      6
      7
      8
      9
      10
      Specify the AWS Region
      ? region: (Use arrow keys)
      ❯ us-east-1
      us-east-2
      us-west-2
      eu-west-1
      eu-west-2
      eu-central-1
      ap-northeast-1
      (Move up and down to reveal more choices)
  • Amplifyが使うIAM Userを設定

    • これは新規に作成するユーザー
      1
      2
      Specify the username of the new IAM user:
      ? user name:
  • ブラウザでAWS Consoleのユーザーを追加画面が立ち上がる

    • ここでIAM Userを作成する
    • 別のIAMがあれば、プログラムによるアクセスのみでOK
    • 権限はデフォでAdmin, AdministoratorAccess-Amplifyがおすすめ
  • ユーザーが生成されたら、アクセスキー/シークレットキーを控えておく

  • CLIに戻りEnter

  • accessKeyId/secretAccessKeyを入力

    1
    2
    3
    Enter the access key of the newly created user:
    ? accessKeyId: ********************
    ? secretAccessKey: ****************************************
  • profile名はデフォルトでOK

    1
    2
    This would update/create the AWS Profile in your local machine
    ? Profile Name: (default)
  • 以下が表示されれば完了

    1
    Successfully set up the new user.

アプリケーションのプロジェクトにAmplifyを導入する

  • アプリのProjectのトップディレクトリに移動
  • コマンドで初期化処理を実行
    • いくつか質問される。基本defaultでOK
      1
      amplify init
  • amplifyフォルダが生成される
    • この中にバックエンドに関する設定ファイルが入る
    • つまり、テキストベースで設定変更が可能。Gitで差分管理もできる

Amplify CLIによるバックエンドの構築

  • 基本的に以下のコマンドの後ろにカテゴリ名を入れて構築する
    1
    amplify add XXXX

認証周りの自動構築

Amazon Cognito

  • Amazon Cognito

    • 標準的な認証基板に求められる機能とAPIを提供。認証トークンの発行もできる
  • AmplifyではUIの構築済みコンポーネントも用意されている

    • 構築をコマンドだけで済ませ、認証のフォームも数行書くだけ済む
      • 数分で認証周りの実装が完了する
    • クロスプラットフォームにも対応
  • Cognitoの自動構築

    • 以下のコマンドを実行して、Defaultの設定でEnterを押していくだけで、Cognitoのバックエンドの設定が完了する
      1
      amplify add auth
  • Amplify UI Componentsを使ってSign-Up画面を追加

    • 以下の要素を使って数行で実装できる
      1
      <AmplifyAuthenticator>...

Amplify UI Component Auth


API(GraphQL/REST)の自動構築

AppSync DynamoDB

  • AmplifyではGraphQLとRESTに対応しており、バックエンドとクエリや設定ファイルを含めて自動構築できる
    • GraphQL API
      • AppSync, Dynamo DB
    • REST API
      • API Gateway, Lambda

AppSyncとは

AWS AppSync

  • AWS AppSync API基盤(GraphQL)

    • フルマネージドGraphQLサービス
    • DynamoDBを初めとする様々なAWSデータリソースにアクセスするためのマネージドなGraphQL基盤を提供
      1
      2
      アプリケーション開発が加速できるという理由から、各組織では API の構築に GraphQL を選択しています。この API により、フロントエンドのデベロッパーは、複数のデータベースやマイクロサービス、そして API に対し、単一の GraphQL エンドポイントから迅速にクエリができるようになります。
      AWS AppSync は、GraphQL API の開発を容易にする、完全マネージド型サービスです。このサービスは、AWS DynamoDB や Lambda、その他のデータソースとの安全な接続に必要な、面倒な作業を自動的に処理します。パフォーマンスを向上させるためのキャッシュや、リアルタイムの更新を可能にするためのサブスクリプション、そして、オフラインのクライアントを簡単に同期できるようにするクライアント側のデータストアなどが、簡単に利用できるようになります。デプロイが完了すると、API リクエストのボリュームに合わせた GraphQL API 実行エンジンの自動的なスケールアップとダウンが、AWS AppSync により行われます。
  • マイクロサービスへの統合されたアクセス
    マイクロサービスへの統合されたアクセス

    1
    単一的なインターフェースを使用して、(REST API や GraphQL API のエンドポイントなどが置かれている) VPC 内のコンテナで実行中の複数のマイクロサービスからのデータにアクセスし、それらを組み合わせて使用できます。
  • Subscriptionを用いる事で、データの更新(Mutation)をリアルタイムにクライアントAPに通知可能
    AppSyncリアルタイム同期

    1
    データは、バックエンドと接続されたすべてのクライアントの間 (1 から多)、もしくは、クライアント間 (多から多) でブロードキャストされます。同じデータを 1 秒以内にすべてのクライアントにブロードキャストし、それらのクライアントから応答を得るシナリオが実現できます。
  • シンプルかつ安全なデータアクセス

    • 短くコードを記述できる。セキュリティについてはWAFをアタッチできる

GraphQLとは

  • API用のクエリ言語およびサーバーサイドランタイム
  • 機能
    • 3種類のデータ処理形態
    1. 取得(Query)
    2. 変更(Mutation)
    3. 購読(Subscription): リアルタイムにデータを受け取るための存続期間の長い接続
  • 特徴
    • 型指定されたスキーマ
    • サブスクリプションを利用したリアルタイム処理

Amplify CLIによるAPIの作成

  1. API追加コマンドを実行
    • デフォルトではシンプルなTodoデータのスキーマを作成
    • 任意のGraphQLスキーマによるAPIを作成することも可能
  2. デプロイコマンドを実行
  • GraphQL APIを追加する手順
    • Step1 Amplify CLIでAPIカテゴリを追加
    • Step2 schema.grapfqlにスキーマを定義
    • AppSync経由でDynamoやLambdaと連携できる
      • @model @keyディレクティブ
        • DynamoDBのスキーマを意識しなくても必要なデータモデルの定義が可能
      • @connectionディレクティブ
        • DynamoDB間のリレーションを定義する

GraphQLのスキーマを定義

定義方法は二つある

  • PJ/amplify/backend/apiにGraphQLの設定が入っている

    • schema.grapfql が定義ファイル
    • デフォルトのスキーマが定義されているため、APに即した形式に変更する
    • property名に対して型を決めて、スキーマを定義していく
      • 型の右に!をつけると必須(required)のpropertyになる
    • @model
      • このスキーマに即したテーブルをDynamoDBに作成する
    • このスキーマを定義することで、それに即したAppSyncとDynamoDBのテーブルが生成される
  • Amplify Consoleでのスキーマの定義

    • クライアント側のコードの自動生成
    • 一からGraphQLをクエリするコードを書く必要がなくなる
    • Queryの深さには注意

GraphQL APIのローカルテスト

  • Step1 Amplify GrapfQL Explorerの立ち上げ
    1
    amplify mock api
  • Step2 deploy
    1
    amplify push api

Hosting環境の自動構築

  • add hostingコマンドでホスティング環境を構築できる

    • ここで amplify console コマンドを叩くと、このアプリの管理コンソールがブラウザで立ち上がります。
      1
      2
      3
      4
      5
      6
      7
      8
      $ amplify add hosting
      ? Select the plugin module to execute (Use arrow keys)
      ? Hosting with Amplify Console (Managed hosting with custom domains, Continuous deployment)
      ? Choose a type Manual deployment

      You can now publish your app using the following command:

      Command: amplify publish
  • amplify publish でアプリをアップロード

    1
    amplify publish
  • 参考

AIサービス(Recognition)との連携

  • AI/ML系のサービスを利用する際のコマンドは以下

    1
    amplify add predictions
  • Recognitionによる物体検知は以下

    1
    2
    Identify
    Identity Labels
  • 他の設定はDefaultを利用

  • Recognitionの機能を使えるのは、認証されたユーザーのみかゲストユーザーか?

    1
    2
    ? Who should have access
    > Auth users only
  • 以上でRecognitionに関するバックエンドの設定は完了

Storageの追加

  • 以下のコマンドでstorageカテゴリを追加狩野
    1
    amplify add storage

開発端末上でのAmplifyの設定をAWSに反映

  • amplify addを実行した時点で設定は作成されているが、AWSの実環境にはまだ構築されない
  • 以下のコマンドで実環境に反映できる
    1
    amplify push
  • push前にどのような設定がされるか確認画面が出る
  • ContinueでYes
  • GraphQLのスキーマにアクセスするためのクエリを自動生成してくれる
    • 言語をTypescriptに指定
    • AppSyncのスキーマに投げるためのクエリ&設定ファイルがローカルに生成される
  • クラウドに設定が反映されると同時にローカルにAWSの設定ファイルが吐き出される
  • graphqlフォルダも作成される
    • AppSyncのスキーマに投げるためのクエリのソースコードが自動生成されている

運用周りについて

CI/CD

  • amplify envコマンド

    • 複数バックエンド環境を管理可能
  • Amplify Console: PR Preview

    • プルリク時の一時的なバックエンド環境
      • Step1. Amplify CLIでHostingカテゴリを追加
        1
        amplify add hosting
      • Step2. Gitリポジトリと紐付け
        • 関連付けるリポジトリやbranchを選択
      • Step3. Pull Request Preview
      • Step4. Merge PR & Deploy
  • Amplify Console E2E Test

    • cypressを使用したE2Eテストとの統合によるフルスタックCI/CDパイプラインの作成
    • Step1 cypressのインストール
      1
      yran add -D cypress
    • Step2 amplify.ymlにtestフェーズを追加

モニタリング

  • Amplify Console Monitoring Metrics

    • CloudWatchアラーム・SNSトピックの作成、アクセスログの閲覧をAmplifyから一元管理
    • Amplify HostingがAmazon CloudWatchの統合でモニタリング機能をサポート
    • リクエスト数やデータ転送長、エラー数、TTFB(レスポンスまでの時間の平均)
  • AWS X-Ray

    • Step1 AppSyncコンソールからXーRayを有効化
    • Step2 LambdaのコンソールからXーRayを有効か

セキュリティ

  • AWS WAF with AppSync
    • Web ACLを作成
    • AppSyncコンソールからWAFを有効化

その他

Amplifyのラーニングパス

  • AWS Summit 2021 セッション

    • AmplifとAWS App Syncを使ったフルスタックアプリケーションの開発
    • ChimeSDKを使ったオンラインミーティングのサンプルAP
  • AWS Amplify Social Network App Workshop

    • CI/CDやE2Eテストにも触れられている
  • AWS Samplesの活用

    • GitでそれぞれのAWSサービスを利用したシステムのリファレンスアーキテクチャとソースが公開されている
  • AWS Amplifyに関連するコミュニティ

    • Amplify Japan User Group
    • AWS Front-end Community

参考

関連記事

その他

[AWS] PJ毎のコスト管理まとめ(Cost Explorer/Cost Anomaly Detection/Budgets/タグ付けルール)

単一アカウント内で複数のPJやサービスが運用されているケースのコスト管理についてのメモ
マルチアカウント運用の際にもこれらのサービスの設定が必要になる


PJ開始時にすべきコスト関連の作業

以下は基本的に無料枠で実施できるため、PJ開始時に対処しておく
(SNS通知に微量だが料金がかかる)

1. 運用ルールの定義・周知

  • AWSの利用開始時に、タグ付けルールを定めてメンバに周知する
  • CFnテンプレートにはタグの入力欄を設けておく

2. PJで利用中のリソースに限った総コストの確認/予測

Cost Explorer

  • Cost Explorerのフィルタリング機能を活用する
  • 単一のAWSアカウント内で複数のサービスを運用する場合、タグを付与することで費用を区分できる

3. 異常検出

  • Cost Anomaly Detectionを活用する
  • タグやリソースベースでPJのコストを追跡し、料金の異常発生時に通知させる
    • 例えば、DDoS攻撃による料金の急騰などが挙げられる

4. Budgetsで予算を設定、超過時の通知を設定

AWS Budgets

  • AWS Budgetsを活用して、承認を得た予算に対する状況管理を可能にする

設定手順

運用ルール(タグ付けルール)の定義

単一のAWSアカウント内で複数のサービスを運用する場合、タグを付与することで費用を区分することが可能になる。PJでリソースを作り始める前に、ルールを定めて周知しておく必要がある。

  • タグ付けルール例
    • Project
      • Project毎のコスト管理に活用
    • Owner
      • リソースの作成者を後で判別するために必要。誰がこれ作って放置してるの?を防ぐ
    • Environment
      • 本番、テスト環境などの判別/コスト管理のために活用

CFnテンプレートを利用する場合は、上記のタグを入力値として用意しておくと、つけ忘れを防止できる

コスト配分タグのアクティブ化

Cost Explorer内で、タグによるフィルタリングをするには、リソースに付与したタグを Billing and Cost Management コンソールでアクティブ化する必要がある。会社でOrganizationsを利用している場合、部門のアカウントでは設定権限が無いこともあるので注意。

  • AWS Console/Billing and Cost Management/コスト配分タグ
    • アクティブ化するタグを選択
    • ここでアクティブ化したタグのみ、Cost Explorerでフィルタリングに活用できる
      • リソースにタグを付与しただけでは活用できない

PJのコスト確認/予測方法

  • AWS Management Console/Cost Explorer

    • 過去6か月間のコスト($)がサービス毎に表示される
  • 任意の期間に変更

    • 期間が表示されているタブから選択
  • PJのリソースのフィルタリング

    • 右側のフィルター欄/タグを押下
    • Project名のタグを選択

Cost Explorerタグによるフィルタリング

  • 予測
    • 期間を変更することで、最大12ヵ月先までの予想費用をグラフに表示できる

Cost Anomaly Detectionでコストの異常検出を設定

  • AWS Cost Anomaly Detectionにより、コスト異常検出と原因の分析を自動化できる

    • 無料だが、SNSアラート通知を有効化すると微量の料金がかかる
  • AWSConsole/Cost Explorer/コスト異常検出

    • コストモニターを作成
    • モニタータイプを選択
      • コスト配分タグ
        • PJ毎の総費用を追跡する場合はこちらでPJで運用ルールとして付与したタグを選択する
      • 連結アカウント
        • マルチアカウント形式で運用している場合はこちらにアカウントIDを入力
    • アラートサブスクリプションを設定
      • アラート受信者に、開発チームのteamsのチャンネルやメーリスを登録しておくと管理が楽になる
        1
        コストモニターが異常を検出したときに通知します。アラートの頻度に応じて、E メールまたは Amazon SNS によって指定されたユーザーに通知できます。たとえば、組織の Finance team のサブスクリプションを作成できます。
    • モニターを作成

Budgetsによる予算管理

  • AWS Management Console/Cost Explorer/Budgetsタブ
    • 予算を作成
    • 事前に承認されたPJのコストを上限値として設定する
    • 設定した予算に対する状況は%で確認できる
      • 引き上げが必要になったら、Cost Explorerの予測を元に算出した値で予算管理者から承認を得て、Budgetsの予算を更新する流れになる

参考

関連記事

その他

[CloudFormation] WAFv2(SCOPE: CLOUDFRONT)をIaC化する際に発生するリージョン問題について

AWSでCloudFront Distributionに関連付けるWAFv2リソースをCFnテンプレート化する際の注意点についてのメモ

発生する事象

  • CFnテンプレートの書式が正しくても、CFnを実行するリージョンによって以下のエラーが発生する
    1
    2
    3
    Error reason: The scope is not valid., 
    field: SCOPE_VALUE, parameter:
    CLOUDFRONT (Service: Wafv2, Status Code: 400, Request ID: ...

原因: WAFv2のSCOPE: CLOUDFLONT

  • WAFv2はSCOPEによって、us-east-1にしか生成できないことがある

    • CloudFormation Distributionに関連づけるWAFはコンソールであれば、Globalとするが、実体はus-east-1に生成される
    • CFnでは”SCOPE”というプロパティで、WAFv2がCloudFront向けか、各リージョンに生成するか定義する
      • 以下のように定義した場合、cloudFront Distributionにアタッチ可能なWAFv2リソースとなるが、
        1
        Scope: "CLOUDFRONT"
  • SCOPEについてのルールは公式ドキュメントに以下のように書かれていた

    1
    CLOUDFRONT の場合、米国東部 (バージニア北部) リージョン (us-east-1) で WAFv2 リソースを作成する必要があります。
  • CloudFormtationは選択中のリージョンで実行される

    • SCOPE: CLOUDFRONTのWAFv2リソースがあれば、us-east-1で実行する必要がある
    • 同じテンプレートで定義した他のリソース群も、us-east-1に生成されてしまう
      • 払い出せるリージョンが実質ロックされるので、汎用性が欠けたテンプレートになってしまう…

回避策

以下が考えられる

  • テンプレートの分割
    • WAFv2リソースのみ別にする
      • CloudFront Distributionとの関連付けが面倒ではある
  • us-east-1専用テンプレートとしてルール付けする

同様の問題を経験した人も多いはずなので、そのうちAWS側で解消されるかもしれない

参考

関連記事

[AWS/IaC] Former2によるCloudFormation/Terraformテンプレートの自動出力方法

AWSアカウント内の既存のリソースから、IaCテンプレート(CloudFormation/Terraform)を自動で作成するツールの活用方法と手動で改修すべき範囲についてのメモ

1. Former2の概要

Former2

  • Former2
    • ブラウザで動くWebアプリ
    • サードパーティ製のツール
      1
      Former2では、AWSアカウント内の既存のリソースからInfrastructure-as-Codeの出力を生成することができます。AWS JavaScript SDKを使用して関連するコールを行うことで、Former2はインフラストラクチャをスキャンし、出力を生成するリソースのリストを表示します。
    • CFnテンプレートだけでなく、Terraform等も出力可能
      • CloudFormation
      • Terraform
      • Troposphere
      • CDK (Cfn Primitives) - TypeScript, Python, Java, C#
      • CDK for Terraform - TypeScript
      • Pulumi - TypeScript
      • Diagram - embedded version of draw.io
    • CloudFormerと比較して高機能で2021年現在主流になっている
    • 価格はOSSのため無料
      1
      Former2はローカルでのアクセスや利用は無料ですが、一部のAWSサービスではAPIコールに関連して少額の料金が発生するため、AWSの利用料金に数セント余分に加算される可能性があります。
    • 出力したCFn Templateを汎用的にするには少し手直しが必要であった
      • ex. 固定値のパラメータを入力値を参照するように変更、formerでテンプレートに取り込めない細かいリソースの追記
    • 使用方法は二つ
      • Webアプリとして使用
      • セキュリティの関係でローカルホスティングしたい場合は、自分で動作環境を準備してそこで動かば良い

2. (Former2動作環境の起動)

3. Former2 Setup

3.1. Introduction

Former2 Introduction

  • ブラウザにプラグインを導入

    • Install Former2 Helper for Google Chrome
      Former2 Google Chrome Plugin
  • Continue to Credentialsを押下

3.2. Credentials

Former2 Credential

事前にReadOnlyAccessを付与したIAM UserとAccess Key/Secret Access Keyの用意が必要

  • IAM UserのCredentialを入力

    • Access Key ID
    • Secret Access Key
  • Credentialを正しく認識できたら、以下が表示される

    1
    Logged in as: <IAM User Name>@<AWS Account>
  • 公式説明

    1
    2
    リクエストを認証するには、IAM キーのペアが必要です。リソースを直接インポートすることを計画していない場合は、これらの資格情報で読み取りアクセスのみを提供し、
    ReadOnlyAccessポリシーを割り当てることをお勧めします。インポート機能を使用する予定がある場合は、スタックを作成するために適切な権限を付与する必要があります。
  • Continue to Parametersを押下

3.3. Parameter

Former2 Parameter

  • 独自のCloudFormation Parameterを設定する事ができる
    • 特になければスルー
1
オプションとして、以下にCloudFormationスタックのパラメータを追加することで、独自のCloudFormationスタックパラメータを含めることができます。デフォルト値が設定されている場合、値が一致していれば、出力でこれらのパラメータを参照するために !Ref または !Sub を使用することができます。
  • Continue to Settingsを押下

3.4. Settings

  • CFnテンプレートを出力するだけであればデフォルトでもOK

    • 設定後にGo to Dashboardを押下
  • CloudFormation Spacing

    • 出力のスペース数を変更
  • Logical ID Strategy

    • 論理ID名の付け方を設定
  • Default Output

    • 出力言語の設定
    • デフォルトではCloudFormation
    • ここで、TerraformやCDK, Draw.ioのDiagram等に変更可能
  • Irrelevant Resources

    1
    有効にすると、この設定は無関係とみなされるリソースをスキップします(現在はCloudWatchログストリームのみ)
  • Enable Related Resources

    • 関連リソースを有効化
  • Add All Resources

    1
    以下のボタンを使用して、スキャンしたすべてのリソースを出力に追加します(非推奨)
  • Save / Load Settings

    1
    すべての設定されたパラメータと設定(資格情報を除く)を含むファイルを保存またはロードします。
  • Programming Language

    1
    CDKやPulumiの出力プログラミング言語の好みを変更してください。
  • Default Resources

    1
    この設定を有効にすると、デフォルトのVPCやそのサブネットなどのデフォルトのリソースが含まれます。

以上でセットアップは完了

4. Former2によるテンプレートの出力

テンプレートに含めたいリソースを選択していく

  • Former2のDashboardからサービスを選択

Former2 Dashboard

  • 表示されたオブジェクトから、テンプレート化したいリソースを選択

  • +Add Selected

  • 関連するリソースがタブでまとまっており、直感的に操作できる
    Former2 Select Objects

  • Generate Template

    • オブジェクトの追加完了後に、Generate
    • CFnテンプレートが出力される
    • オブジェクト追加時に確認出来なかった項目も反映されていた
      • ex. tag

generate template

5. Former2で出力されるテンプレートについて

  • Former2では、一部CFnテンプレートに含まれない情報を見受けられた
  • また、各Propertyが固定された状態で出力されてしまうため、汎用的なテンプレートにするには入力値(Properties)の設定が必要になる

例とするPF構成

  • 以下のPF構成をformer2でテンプレート化したケースを考える
    • S3 Bucket
      • アプリをホスティング
    • CloudFront Distribution
      • S3 Bucketをソースとしてアプリを配信
    • AWS WAF
      • CloudFrontにアタッチ
      • アクセスを制限

出力したCFn Temlateに含まれない情報/注意点

  • s3 bucket

    • LifecycleConfiguration
      • Rules
        • Id指定のみで、ルール自体はCFn Templateに取り込めていなかった
        • 別アカウントでテンプレートを実行する場合は同名のルールが無いためエラーになってしまうと思われる
        • ライフサイクル未指定であれば無関係
  • WAFに関する注意点

    • CloudFront用に設定したWAFのリソースはGlobal(CloudFront)として扱われる
    • former2では画面右上のボタンでリージョンを選択するが、Globalが無い
    • 調査したところ、リージョンをUS East(N. Virginia)に設定することで確認可能であった
      • US East(N. Virginia)で生成される仕様になっていため、former2の画面右上のボタンでリージョンを変更するだけで良い

汎用的なテンプレートにするには

  • Parametersで各固定値を自由に設定可能な入力値に変更する

    • CFn Template実行時の入力値としてユーザが設定可能なパラメータを規定できる
      • テンプレートが汎用的に利用可能になり、別Projectやアカウントでも使い回し可能になる
    • 各パラメータには以下を定めることで利便性を高めることができる
      • Description
        • 説明を定義
      • 初期値とバリデーションも定義できる
        • 参考となるような名称を予め定めておくことで、Templateの利便性が高まる
    • 記載例
      1
      2
      3
      4
      5
      6
      7
      8
      9
      10
      Parameters: # 入力値を定義 
      BucketName:
      # CFn実行時に入力欄に表示されるユーザ向けの説明
      Description: Please write bucket name
      # デフォルト値
      Default: sample-bucket #
      # 入力値のタイプ
      Type: String
      XXXXName:
      ...
  • 各リソースのPropertiesの各項目から入力値(Parameters)を参照する

    • !RefでParametesで定めた入力値を参照できる
    • 入力値の規定/参照例
      1
      2
      3
      4
      5
      6
      7
      8
      9
      10
      11
      12
      13
      14
      Parameters: # 入力値を定義 
      BucketName:
      # CFn実行時に入力欄に表示されるユーザ向けの説明
      Description: Please write bucket name
      # デフォルト値
      Default: sample-bucket #
      # 入力値のタイプ
      Type: String
      ...
      Resources: # 生成するResourceを定義
      S3Bucket:
      Type: "AWS::S3::Bucket"
      Properties:
      BucketName: !Ref BucketName # 入力値を参照
  • 入力値の参照にはRefを用いる

    • 指定した論理IDのパラメータやリソースを参照する
      1
      !Ref <PropertyName>
      CloudFormationRef
  • Subを使うと変数と文字列を組み合わせられる?

  • !Subを活用すると、入力値と固定値を組み合わせることができる

    • 名称の一貫性や、入力の手間の省力化を見込める
    • 書式
      1
      2
      3
      !Sub "${PJName}-Bucket"
      !Sub "${PJName}-Policy"
      ...

所感

  • Former2で出力したテンプレートの活用方法

    • そのまま固定値で使用しても構わないが、他のPJでも使いまわせる汎用的なテンプレートにするには、paramaterで変数化する必要がある。CFnの記法については最低限知識が必要
  • CFnに精通したメンバがいない場合は、以下の流れでIaC化を図ると良さそう

    1. 0から無理にCFnテンプレを作らず、コンソールやCLIで検証しながらPFを構築
      • 初級者が0からCFnテンプレを書くと細かい内容でハマってしまう(実体験)
    2. ある程度定まってからFormer2で固定値のテンプレートを出力
    3. 固定値を変数化
    4. 以降はCFnテンプレートとGitでPFを管理していく
  • テンプレートの分割について

    • 大規模なPFの場合はテンプレートを分割して、他のテンプレートと入れ子構造にした方が良い
      • Former2でホスティング環境/IAM関連/運用監視関係と分割してテンプレートを出力することで、管理が円滑になる
    • 分割テンプレートを連携させるには、パラメータの受け渡しなどの手間が増えるため、CFnの知識がある程度必要

参考

関連記事

その他

AWS SDK for JavaScriptでRegionリストを取得

やりたいこと

describeRegionsメソッド

  • 使用可能なリージョンに関する情報を取得するには、describeRegions メソッドを呼び出せばよい
    • 戻り値
      • Aws::EC2::Types::DescribeRegionsResult オブジェクト
        • DescribeRegionsResult.Regionsに配列が格納されている
        • AWS.EC2.RegionList
          1
          2
          3
          4
          console.log(data.Regions); // dataに戻り値が格納される
          [object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]
          console.log(data.Regions[0]);
          [object Object]
        • EC2.Region.RegionName
          1
          2
          console.log(data.Regions[0].RegionName);
          eu-north-1

実装例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
// aws-sdkを変数AWSとしてimport
import * as AWS from 'aws-sdk';

// RegionListを取得するメソッド
getRegions() {
// AWS SDKのEC2オブジェクトを宣言
let ec2 = new AWS.EC2({region: ap-northeast-1}); // Default Regionの指定が必須
// 問合せ(describeRegions)を実行
ec2.describeRegions({}, (err, data ) => {
if (err) {
let errorMessage = String(err);
alert(errorMessage);
}
else { // データ取得時
// Aws::EC2::Types::DescribeRegionsResult オブジェクトが戻り値としてdataに格納される
let regions = data.Regions.map((d) => d.RegionName); // ループでリージョン名を抽出した配列を生成
return(regions);
}
});
}

参考

関連記事

その他

[AWS SDK for JavaScript] WEBアプリ→AWSへのリクエスト認証時のエラーハンドリング

  • WEBアプリ(Angular)からAWS SDK経由でAWSにアクセスする際に、Credential(AccessKey/SecretAccessKey)の認証が必須。そこでの認証エラーを検知する仕組みを作る手法についてのメモ

認証エラーを検知 → アラート発信 & 処理の中止

AWS SDK経由のリクエストのイメージ

WEBアプリからAWSへの通信時のエラーハンドリングについて、AWS SDK開発者ガイドを基に以下を検討した

  • 実現したい仕様

    • AWS SDK経由のリクエスト実行時にクレデンシャルエラーを検知したい
      • クレデンシャルの認証エラーであることをユーザにエラーメッセージで教えたい
        • Credentialの問題なのか、リクエストの問題(例えば指定したリソースが存在しない)なのか知りたい
        • ユーザは原因を判断できないと、次のアクションが分からない
    • クレデンシャルエラーを検知した場合に処理をストップ
      • クレデンシャルに誤りがある場合、AWSへの複数ののリクエストを実行しても全て失敗する
      • 一つエラーが出た時点で止めることでUXを向上させたい
  • AWS SDKとは

    • WEBアプリからAWSにリクエストする際に利用するもの
    • AWS Credential(accessKeyId, secretAccessKey)が必要
      • 今回は↑が間違っていた場合に検知したい
    • サービスオブジェクトメソッドは呼び出されると、AWS.Response オブジェクトをコールバック関数に渡すことで返す
    • AWS.Response オブジェクトのプロパティを通じて、レスポンスの内容にアクセス可能
  • AWS.Response オブジェクトのプロパティ x 2

    1. data プロパティ
    2. error プロパティ
      • ここの内容でエラーの種類を見分けられそう

        エラーメッセージの検証

  • Credentialの認証エラー時のメッセージを確認してみる

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    // aws-sdkを変数AWSとしてimport
    import * as AWS from 'aws-sdk';

    region = XXXX;

    // AWS SDK各サービスのオブジェクトをまとめて宣言
    let ec2 = new AWS.EC2({region: region});

    // Ex. VPCの情報をリクエスト(describeVpcs)
    // AWSにリクエストを発信し、返り値(dataプロパティ & errorプロパティ)に応じた処理を実行
    ec2.describeVpcs({}, (err, data ) => {
    if (err) { // Error発生時の処理
    // 以下でエラーメッセージを見てみる
    alert(err); // AuthFailure: AWS was not able to validate the provided access credentials
    }
    else { // データを取得した際の処理
    resolve(data); // 問題無くresolveしたら()の値を返す
    }
    });

  • Credentialのエラーメッセージは以下が出た

    • alert(err)の結果
      1
      AuthFailure: AWS was not able to validate the provided access credentials

alertで確認したエラーメッセージ

その他

CloudWatchまとめ モニタリング~異常検知/通知の自動化(SNS連携)/コスト管理

AWSの一般的なサーバレス構成における、以下の手法を解説します

  • 運用状況をCloudWatch Dashboardで可視化
  • CloudWatch Alarm メトリクスの異常値を自動検知
  • Amazon SNS連携による自動通知
  • コスト超過でSNS通知

必要な情報をCloudWatchに集める

  • 今回のターゲット
    • ユーザがコンテンツを利用する際に接する、以下のリソースの利用状況
      • CloudFront
      • WAF

Dashboardを作成

  • Console/CloudWatch/Dashboard

  • ダッシュボードの作成

    • 名称を設定(今回PJ名)
  • ウィジェットの作成

    • タイプを選択
    • CloudFront
      • 欲しい項目を選択
        image
      • ウィジェットの作成
  • 次にWAFのエラー=ソースIP外から試みたアクセスを可視化する

    • ウィジェットの追加
    • タイプを選択
    • AWS/WAFV2/Rule, WebAClから必要な項目を選択
      CloudWatchメトリクスの追加
    • ウィジェットの作成
  • 以下のようにウィジェットが表示される
    CloudFront Dashboard

  • 分かり辛いので名称を変更
    CloudFront Dashboard

  • ダッシュボードの保存

各サービスのコンソールから設定する場合

  • 例:CloudFrontのメトリクスをダッシュボードに追加
    • aws console/CloudFront
    • 左のメニューバー/Monitoringを選択
    • 作成済みのディストリビューションのラジオボタンを選択
    • View distribution metricsを押下
    • ダッシュボードに追加を押下

その他

アラームを設定

  • WAFで弾かれるリクエストが異常発生した際にSNSで通知が来るように設定
    • アラーム/アラームの作成
    • メトリクスの選択
      • AWS/WAFV2/Rule, WebACL
      • BlockedRequestを選択
    • メトリクスと条件の指定
      • 5分間に50以上弾かれていれば攻撃を受けている可能性があるのでアラートを出す
        CloudWatchアラームの作成
      • 次へ
    • アクションの設定
      • 新しいトピックの作成
        • 通知を受け取るEメールエンドポイントに、開発チームのTeamsチャンネルのメールアドレスを指定
        • トピックの追加を押下
          • この時点でテストメールが発信されます
          • ”Confirm Subscription”と書かれたリンクを押すと有効化される
      • 次へ
    • 名前と説明を追加
      名前と説明を追加
    • 次へ
    • 問題なければアラームの作成

設定したいアラーム毎に以上の作業を行えばOK


コスト追跡

  • CloudWatchの請求アラーム
    • これはアカウント全体に対する請求のアラームであり、PJ毎にコスト監視することはできない
    • PJ毎にTagでフィルタリングして監視するにBudgetsで監視する

おまけ:CloudWatch Logs

  • CloudWatch Logs
    • EC2等からエージェント経由でログを集めるサービスなので今回は不要だが、ログをExportする手法を以下にメモとして残しておきます
    • 有料にはなるが、CloudTrailの証跡へのアクセスをLogsで取り込んで、改竄発生時にアラートを出すことも可能

ログの取得まで

  • CloudWatch Logs エージェントをEC2にインストール
  • ロググループを作成~サブスクライブ設定

S3にログをエキスポート

  • 事前にログ格納用のS3バケットを作成

Export設定

  • 任意のロググループ/アクション/データをAmazon S3にエクスポート
    CloudWatch Export

  • データを Amazon S3 にエクスポート

    • 開始と終了を選択
    • S3バケットを選択
      • 事前に作成が必須
    • エクスポート

CloudWatch Export

参考

関連記事

その他

@EventEmitter @Input @Output @ViewChild ACM AMP API Gateway AR AR.js AR.js Studio AWS AWS Amplify AWS Budgets AWS Cost Explorer AWS SDK for JavaScript AddThis Adobe XD Alexa Amazon CloudWatch Amazon Honycode Amazon SNS Android Angular Angular Material AngularFire AppSync Augury C CDN CI/CD Cloud Craft Cloud9 CloudFormation CloudFront CloudTrail Cognito Cost Anomaly Detection Cubase ai Cubasis LE DTM Disqus DynamoDB Elgato HD 60S Firebase Firebase Hosting Former2 Github Github Actions Github.com GithubEnterprise GithubPages Google Chrome Google Cloud Shell GraphQL Hexo Hosting IAM Ionic JSON JavaScript LadioCast Logging LowCode MFA MS Authentication MacBook Pro 16 Mind Node NETDUETTO Netflix Party Netlify Network NoCode Observable PO PdM Promise RPA ReactiveForm Recognition Route53 S3 SAM(Serverless Application Model) SAR SSL SYNCROOM Schematics ScrumInc Serverless Service Siri Sitemap Spark AR Steinberg UR44C Teams Touch Cast Studio Treetable TypeScript UI UI Bakery WAF WAFv2 WEB Page Dev WEB会議 WebAR WebSocketAPI Webhook Windows Power Automate Wireshark aot async/await aws config cloud9 display.land draw.io e2e test filter() forkJoin() google search console hexo-generator-amp iOS iPad Pro iPhone icarus map() mat input mat tree mat-checkbox mat-input mat-selection-list mmhmm ngFor plantUML popIn Aladdin2 then() vscode ”global is not defined” らくがきAR アジャイル アジャイル開発 クロスプラットフォーム ショートカット スクラム スクラム開発 テレワーク ファイル操作 ブラウザ型IDE プロダクトオーナー プロダクトマネージャー プロトタイピング リモートセッション 共同開発 双方向データバインディング 待ち合わせ処理 認定スクラムマスター 静的WEB Hosting 静的WEBサイトHosting
Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×