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認定 SysOps Administratorに合格するまでの学習方法詳細 (2021年)

  • AWS認定 SysOps Administrator(SOA)の合格体験記

  • SAA(Solution Architect)は一度もAWSを触らず黒本問題集だけで合格できたが、SysOpsは専用の教材も無く、格段に難しかったので、学習方法やレベル感について詳細をまとめておきます

  • Developer Associateについては以下を参照

AWS認定 SysOps Administrator 概要

AWS認定

  • AWS 認定 SysOps アドミニストレーター – アソシエイト

    • AWSアソシエイト資格三種の一つ
    • AWS でのデプロイ、管理、運用に関しての問題が出題される
      1
      2
      3
      4
      5
      6
      7
      認定によって検証される能力
      ・スケーラブルで、高可用性および高耐障害性を備えたシステムを AWS でデプロイ、管理、運用する
      ・AWS との間のデータフローを実装および制御する
      ・コンピューティング、データ、セキュリティ要件に基づく適切な AWS のサービスを選択する
      ・AWS 運用のベストプラクティスの適切な使用方法を識別する
      ・AWS の使用コストを予測し、運用コストコントロールメカニズムを識別する
      オンプレミスワークロードを AWS に移行する
  • SAA(Solution Architect Associate)の次にとる資格としておすすめ

  • SAAと比較してかなり実用的

    • SAAは”AWSが得意”ではなく、”最低限の知識があります”程度のレベル感だが、SysOpsを持っていれば、組織内のAWSアカウントの管理や運用中のサービスの運用監視周りの設計をリードすることができる
  • 上位資格に挑戦する前のステップになる

    • AWS DevOps Professional合取得にはDeveloperの内容よりも、SysOpsの細かい内容の方が障壁になる
    • SAP(Solution Architect Professional)はSysOpsほど細かくでないが、運用周りの細かい知識を先に固めておくと手堅く点数を稼げる
    • DeveloperとSysOpsのどちらを先に取るべきかは実務経験にもよるが、SysOpsの方が比較的簡単

難易度

  • SAA取得済みでProfessionalレベルに挑戦する前に受験すると丁度良い

  • SAA(AWS Solution Architect)と比較して遥かに難しく、出題内容が細かい

    • SAAは黒本問題集サイトを1, 2ヶ月集中して取り組んだらAWSを触ることなく余裕を持って合格できたが、SysOpsは厳しかった
  • AWSのサービス全般についての一般的な知識があっても、2択までしか絞れないことが多い

    • 実際に手を動かした経験のあるサービスのみ確実に答えることができるレベル
    • 問題集サイトの問題を覚えるのではなく、説明まで読み込んで深く理解しなければ歯が立たない
  • SysOpsは完全に机上の学習のみではハードになる

    • 少なくともCloudFormationと運用監視関係のサービスは、実務で利用する機会が無くとも、自分で触ってみた方が良い
    • 利用したことの無いサービス(KMS, Systems Manager, RDS)も沢山あったが合格できた(経験があるほど難易度が下がる程度)

合格までの道のり

0. 先にSAA(AWS Solution Architect)を取得

  • 新卒配属三ヶ月程度で、AWSを一度も触ることなく受験

    • SAA取得後に実務でAWSを触り始めた
  • 運用を専門的に極めたいという特殊な希望がなければ、SysOpsの前に必ずSAAを取得すべき

1. AWS公式の研修を受講

Systems Operations on AWS

  • Systems Operations on AWS

    • 3日間の講義
    • AWSのSolution Architectが講師を務めてくれ、質問も沢山できる
  • 会社経由で無料だったため受講

    • 会社で受けられない場合は、最低限の実務経験があれば受けなくてもOK
      • 個人では20万以上かかるので注意
    • CloudFormationも運用監視関連のサービスも利用したことない場合は、先にう毛ておくと理解し易い
  • 実務経験が豊富な人以外は、これだけでは間違いなく受からない

2. 書籍

3. 実務経験

試験合格には以下の経験が大きく活きた

  • CloudFormationテンプレートの開発

    • CFnを触った経験があると合格に大きく近づく
    • 業務内でAWSを使っていて、IaCを実践できていなければ、指示されていなくともCFnテンプレート化してみると、仕事での評価も知識も獲得できるのでおすすめ
    • 業務内で使う機会が無ければ、個人でWEBに落ちているテンプレートを改造して試してみると良い経験になる
  • 実際のサービスの運用

    • CloudFront, S3, WAF, その他運用監視関係
    • 運用監視周りのサービスは実際に手を動かしてみなければ暗記だけでは厳しい
      • 自分のアカウントを作って簡単に通知設定などを設定してみると良い

4. 問題集サイト

AWS WEB問題集サイト

  • 有名なAWS 問題集サイトを2週(SAAもここで学習)
    • 試験対策の勉強はこれがメイン
    • Udemyなどで学習した人もいるようだが、英語らしい。Linked in LearningのSysOpsの研修は情報が古かった
    • 1ヶ月ちょっと学習。余裕を持つなら二ヶ月必要
      • #88まであり、平日は一日5つ程度(各7問)のペースで取り組んだが、結構大変
    • 他の人の体験記を見ていても実務経験が浅い人は1周では危険
    • サイトの問題は定期的に更新されているが、毎年の公式の更新直後は問題がかなり異なっていた
      • 筆者は試験問題更新直後に一度受験し、問題集サイトと全く範囲が違い落ちてしまった…
      • 2度目の受験時はかなりの精度で出題範囲が似通っていた
        • 各問題の説明まで全て読み込むことで合格レベルに達した
        • SAAほど問題が似ていないので、深い理解が必要

5. 模擬試験

  • 模擬試験で高得点を取れていても本番の試験の方が難しいので注意

模擬試験概要

WEBから公式の模擬試験を受験することができる。時期によっては問題集サイトとAWS認定試験の範囲が異なることもあるため、必ず受験して感触を掴んだ方が良い

  • SOA-P01: AWS 認定 SysOps アドミニストレーター – アソシエイト模擬
    • 費用: 2000円(税込み 2200)
    • 時間: 35分
      • 試験開始前に「受験者行動規範」を読んで確認するため時間が 5 分含まれている
    • 難易度
      • 問題集サイト #88まで一周解説の読み込みまでやっていればほぼ全て解ける

申し込み手順

  • AWS認定の認定サイトから以下を申し込む

    • SOA-P01 AWS Certified SysOps Administrator - Associate Practice
  • 試験の申し込みタブ

    • ピアソンVUE(or PSI)で模擬試験をスケジュールする
    • 画面下部の受験資格がある試験欄には模擬試験がないので注意
  • 受けたい試験を選択

    • SOA-P01: AWS 認定 SysOps アドミニストレーター – アソシエイト模擬
  • 試験言語を選択

  • 試験の詳細が表示され、問題なければ次へ

  • 支払情報と請求情報を入力

    • バウチャーコードがあれば入力
      • 本試験のバウチャーは会社から支給されていたが、模擬試験は自腹で払う必要があった…
    • バウチャがなければクレジット情報を入力
    • 住所は英語表記でなければ弾かれるので注意
  • 申込事項に問題がなければ予約内容を確定

    • 予約されましたと表示される
  • この画面の試験開始ボタンを押すと模擬試験が始まる

    • はじめに説明があるので、身構えなくてOK
  • 試験終了後にE メールでスコアのリンクが送られてくる

    • 5分程度待つことになる
    • 認定サイトのピアソンVUE試験の管理からみれる
    • スコアレポートの表示

問題集サイト#88まで一周した後のスコア

  • 合計スコア: 90% = (18/20)
    • ミスっていたのは以下のトピックのみなので復習をした
      • Monitoring and Reporting
        • モニタリングレポート 試験比重 22%
      • Security and Compliance
        • セキュリティとコンプライアンス 試験比重18%
1
2
3
4
5
6
7
8
トピックレベルのスコア:
1.0. Monitoring and Reporting 80%
2.0. High Availability 100%
3.0. Deployment and Provisioning 100%
4.0. Storage and Data Management 100%
5.0. Security and Compliance 75%
6.0. Networking 100%
7.0. Automation and Optimization 100%
  • 一度目の受験では模擬試験スコア 85%で余裕だと思ったが、本番で不合格となった
    • 合格最低点720,スコア700であった
    • 本番の方が圧倒的に難しいので注意

6. 試験

  • オンラインか、全国の試験センターで受験可能

    • コロナの影響で、2020からオンライン受験が可能になった
    • オンラインの方が先に埋まってしまうので早めに予約した方が良い
  • 一度目の受験

    • AWS利用経験ほぼなしでWEB問題集に取組み(説明は読み込まず)、模擬試験を受けたら85%だったので甘くみて即受験
    • 合格点720に対して20点足らず不合格
      • 試験問題更新直後で学習範囲がずれており、理解度も足らないため2択までしか絞れない問題が多かった
  • 二度目の受験

    • この間に運用監視サービスやCloudFormationを実務で経験
    • 書籍の該当範囲を読み込み、問題集サイトを二週実施(説明まで読み込んだ)、間違えた問題は全てノートにまとめて復習も実施
      • 間違えた問題はAWSの公式ページを読んで理解するよう努めた
    • 本番の試験はかなり余裕を持って取り組めた
    • 900/1000点で合格。合格点は720なのでかなり余裕があった
  • 合格すると認定サイトでスコアレポートとPDFの証明書を確認でき、デジタルバッジも発行可能になる

    • PDFに書かれているValidation Numberは、本人確認のためによく使う機会があるので、控えておくと良い
  • 追記:SysOpsの次にはDeveloperを取得した

関連記事

[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の予算を更新する流れになる

参考

関連記事

その他

[Amazon Honeycode] NoCodeで出社管理アプリを開発してみた

Amazonが最近発表したAmazon Honeycodeベータ版の使い方の解説記事。
Excelやスプレッドシートによる業務運用をNoCodeでパッとアプリ化してみました。AWSの開発者ブログの記事を参考にしています。

概要

Amazon Honeycodeとは?

  • AmazonのNoCodeサービス
    • コーディング無しでビジネスアプリケーションを実現するツール
    • 非エンジニアでも簡単に使えます
    • エンジニアも開発前のプロトタイピングに利用して、仕様を精査してから本格的な開発に入ることができます
  • モバイル対応のWeb アプリケーションを構築可能
    • Webブラウザ/iOS/Android 用のネイティブアプリから利用

機能

主な機能は3つ

  • Table: データの定義
  • Builder: アプリのUIを定義
  • Automations: 自動アクションの規定

Table

  • 行列を持つデータを格納する機能
    • スプレッドシートと大体同じ

Amazon Honeycode Table

  • できること
    • データのフィルタリング
    • データの書式設定
    • 他のTableのデータ参照

Builder

  • アプリのUIをカスタマイズする機能
    • ボタンクリック時の処理や画面遷移などを定義

Amazon Honeycode Table

Automations

  • 自動的にアクションを実行させる機能
    • Trigger
      • スケジュールされた日時やデータが追加・変更されたタイミング
    • Actions
      • 通知の送信やデータ操作

Amazon Honeycode Automations

開発手順

  • 今回作るアプリ
    • シンプルな承認アプリ
      • Excel, スプレッドシートの台帳管理で失う無駄な工数を削減します
    • 従業員が出社や社外訪問をする際に、マネージャーへ申請するケースを想定します

開発の流れ

  1. サンプルデータ(csvファイル)を準備
  2. Honeycodeへサンプルデータをインポート
  3. サンプルデータを元にデータモデルを作成
  4. アプリケーションを作る (ウィザード編)
  5. アプリケーションを作る (Builder編)
  6. 承認フローを定義

1. サンプルデータ(csvファイル)を準備

まずは出社申請業務に必要なデータをCSV形式で用意。データ件数は少量でも構わないが、選択式で入力を行うマスタデータ項目を網羅しておくと、後のデータモデル作成が楽になる。

  1. 以下の様なサンプルデータを作成
    • 作り方はスプレッドシートでもExcelでもメモ帳でもOK
sampledata_googleスプレッドシート
  • サンプルデータの形式は以下のように設定
列名 論理名
application date 申請日
applicant 申請者
work day 出社日
destination 行き先
reason 理由
manager 承認者
result 承認結果
  1. CSVを出力
  • スプレッドシートの例
スプレッドシートcsv形式でダウンロード

ここで用意した.csv形式のファイルを、後でHoneycodeに読み込ませます

2. Honeycodeへサンプルデータをインポート

ログイン/アカウント作成

Amazon Honeycode login
  • 未登録であればCreate Oneから作成
    • 確認メールが送信されます

Amazon Honeycode Create Account

  • メールのConfirm Nowより承認

    • 続けてログインを実施Amazon Honeycode 承認画面
  • 初めてログインするとこんな感じ

Amazon Honeycode 初ログイン

サンプルデータのインポート

  • 右上のCreate workbook, IMportCSV fileからインポートを押下
    • 先ほど用意したcsvファイルを選択してImportを実施

Amazon Honeycode サンプルデータのインポート

  • import後にTableの画面になります
Amazon Honeycodeファイルimport後

3. サンプルデータを元にデータモデルを作成

  • Table機能を使ってデータモデルを作ります

WorkbookとTable名を変更

  • ・・・アイコンから変更

WorkbookとTable名の変更

  • 今回は以下の様に設定
    • Workbook
      • attendance management
    • Table名
      • attendance

列の書式設定

  • 日付であればDateなどのデータの型を定義することで、不正な入力を防ぐことができる

  • データ型の変更方法

    • 列を選択
    • 画面上部の Formatsを押下
    • COLUMN FORMAT を指定
    • Applyで適用

Amazon Honeycode 列の書式設定

  • 今回は以下の様に設定
    • 例えば、Date型にすると”年/月/日”の形式のデータ以外は入力できなくなります
列名 COLUMNFORMAT
application date Date
applicant Contact
work day Date
Manager Contact
  • 日付を入力する列にDate、人名を入力する列にContactを設定しました

選択式の入力にする(マスターテーブルの作成)

  • 残ったdestination列と result列を選択式の入力にするために、マスターテーブルを作成します。

  • 画面上部の Wizardsを押下

    • 表示されたペインで Create Picklistsを選択

Amazon Honeycode Wizards

  • Create picklists for:
    • Tableを選択(今回はattendance)
  • For unique values in:
    • 列を選択
    • 今回はdestination
  • Apply

image

  • +Add Newからresult列についても同様に設定
  • GOを押下

Amazon Honeycode Create Picklists

  • 設定後は以下の様になります
Amazon Honeycode マスターテーブル作成後
  • サンプルデータでマスタデータが網羅されていない場合は、この段階でマスターテーブルに対してデータを追加
    • つまり他の選択肢もある場合は追加が必要
  • データの追加はスプレッドシート左下の「+」から実施

データモデルの作成は以上でOK

4. アプリ(UI)の開発 App Wizardによる自動生成

次はアプリのUI(画面)を作ります

UIの作り方

  • Amazon HoneycodeにおけるUIの作り方
    • Builder
      • 真っ白な画面にデータ項目やボタンを1つずつ配置しながら画面を構成
    • App Wizard
      • 自分で一から作らず、テンプレを利用

今回はウィザードで基礎を作り、詳細をBuilderで改修する流れで構築

ウィザードの利用

  • ウィザードを起動
    • 画面上部の Build appを押下
    • Use app wizardを選択

Amazon Honeycode use wizard

  • App Wizardを開くと表示される説明ムービー

About App Movie

  • App Wizaradを利用する場合の開発手順
    1. データモデルを読み込み、そこからAP画面を自動生成
    2. 一覧画面
    3. 詳細画面
    4. フォームを編集

Step1: Tableの選択

事前に作成したデータモデルを一覧表示する画面を自動生成します

Amazon Honeycode App Wizard Step1
  1. 右のサイドナビのSourceを選択

    • 今回はattendance(事前に作成したデータTable名)

    • 以下の様にアプリの画面(データの一覧画面)が自動生成されます

      Amazon Honeycode App Wizard自動生成したUI

Step3: 画面やデータ設定を編集

Amazon Honeycode App Wizard Step3
  1. 一覧画面のデザイン
    • 必要のないデータ項目を消します
    • データ項目の削除
      • Xボタンで削除
    • データ項目の追加
      • +Add column
    • データ順序の入れかえ
      • データ項目左側のドットをドラッグ
    • 設定が終わったらNext

Amazon Honeycode 一覧画面のデザイン

  1. 単票画面(詳細画面)のデザイン
    • 先ほどの行単位の話
      • 今回は単一の申請の詳細をみる画面
      • 一覧画面で表示されないデータ項目もすべて表示したい
    • データ項目を変更可能にする
      • 鉛筆アイコンをクリック
      • 今回はマネージャーによる承認行為を行うので result を変更可能に
    • 設定が終了後にNext

Amazon Honeycode App Wizard make detail

  1. フォーム画面のデザイン
    • 申請データを登録する際の画面
    • 今回は申請者がresultを決定する必要がないため、Xで削除
    • 完了したらApply

Amazon Honeycode App Wzard designe form

ここまでで基礎となるアプリケーションが完成した状態。画面右上の X からウィザードを終了。終了すると、残りはBuilderでの編集しかできないので注意(App Wizardは使えない)


5. アプリの開発 Builderによるカスタマイズ

App Wizardで作ったアプリの詳細をBuilderで編集する

  • Builder の起動
    • 画面左上の Builder アイコンを押下
    • アプリを選択
      • 今回作ったアプリ(Attendance)を選択

Amazon Honeycode Start Builder

  • Builderの立ち上げ画面

Amazon Honeycode Builder

Builderの概要

  • Screen(アプリの画面)に各Object(部品)を配置していく
    • Ex.) データを表示する部品, 処理の起点となるボタン

Amazon Honeycode Builder Add object

チュートリアル1: Screen

  • ここでデータの追加やアプリ画面のスタイル、レイアウトのアレンジなどを行う
Amazon Honeycode About Screen

チュートリアル2: Properties

  • ソース、表示、アクションなどのデータプロパティを設定する
Amazon Honeycode Configure & edit

チュートリアル3: The data view

  • ソースデータを視覚的に参照
Amazon Honeycode data view

不要な機能の除去

詳細画面

  • 今回単票画面(詳細画面)に含まれる不要な機能を除去する
  1. 編集したいアプリの画面を移動

    • 今回弄るのは詳細画面(attendance detail)
      • 画面左側のペイン Screens で単票画面である attendance detail を選択
  2. 画面中央のペインで Jump to item 機能を含む Block を選択

  3. 画面右側のペイン BLOCK PROPERTIES で DISPLAY タブを選択

  4. Set visibility に =FALSE と入力

attendance detailの編集

データフォームの修正

申請者が申請日を編集する必要が無い(自動で決定する為)ため、機能を削除します

  1. 画面左側のペイン Screens で単票画面である attendance form を選択

  2. 画面中央のペインで application date のデータ値を入力する Data Cell を選択

  1. 画面右側のペイン DATA CELL PROPERTIES で Editable チェックを Off にする

  2. 画面右側のペインで DATA タブ、Set type で Variable を選択する

  3. Set initial value に =NOW()+9/24 と入力する

    • Amazon Honeycode では現在時刻を示す NOW() や今日を示す TODAY() などの関数と数式を利用可能です。NOW() 関数、TODAY() 関数のいずれも UTC を基準としているため、JST への変換を行っている

  • 申請者を記録するapplicantも修正
  • 代理申請を除くと申請者は操作を行ったユーザーと判断できるため、以下の手順に沿って申請者の初期値にログインユーザーを設定するとともに、利用者に入力をさせない仕様とする
  1. 画面中央のペインで applicant のデータ値を入力する Data Cell を選択

  2. 画面右側のペイン DATA CELL PROPERTIES で Editable チェックを Off に変更

    • 自動入力させる為、編集不能にする
  3. 画面右側のペインで DATA タブ、Set type で Variable を選択

  4. Set initial value に =$[SYS_USER] と入力

    • 自動的にユーザ名を入れる

手直しは以上で完了

6. 承認フローを定義(Automationsで機能を開発)

  • Automationsでメール送信機能を開発する

    • 本アプリの利用者
      1. 申請者(出社する社員)
      2. 承認者(マネージャー)
    • 上記の間をつなぐフローに必要な以下機能を作る
  • 今回作る機能

    1. 申請者が出社申請を登時、マネージャーへ承認依頼メールを送信
    2. マネージャーの承認実施時、申請者へ結果通知メールを送信

Automations

  • Automationsを起動
    • 左のAutomationsアイコン → +
      Amazon Honeycode Automations 起動

まずは承認依頼メールを発信する機能を作る

  • Automationsの名称を変更
    • 上部のスリードット
    • 今回はapproval requestと命名
      Amazon Honeycode Change Automation Name
  • 処理が発生するタイミングを指定(Row Added)

    • Row Added or Deleted

    • In table

      • 申請データを格納するattendance を選択
    • Starts when

      • row is added to を選択
    • 今回のタイミング

      • 申請者による出社申請を起点

      Amazon Honeycode Row Added

テーブルの行が追加されるとき=承認依頼を実施した時

  • 処理内容を定義(Add Actions)

    • Add actions
    • Notify(通知機能)を選択
      Amazon Honeycode Add Actions
    • 送信先、件名、メッセージを入力
      • データ項目名も指定可能
      • データ項目名を指定した箇所は処理対象のデータ値に置換された上でメールが送信されるため、宛先や文面を動的に構成可能
      • 今回は”=manager”を指定
  • 承認依頼メールを定義

    • 線が引かれている箇所は =manager との形式でデータ項目名を指定している

    • 表記のデータ値はあくまで一例であり、送信されるメールの文面は Automations で処理されるデータの値を用いて構成される

      Amazon Honeycode 承認依頼メール

=データ名でデータモデルから参照してくれる
緑のラインが入っている箇所

  • 変更を確定
    • 画面右上のPublishを押下
    • Publish されていない、つまりは変更が加えられている状態では画面右上に Draft と表示される

Publish Automation

  • Notifyで以下のような警告が表示される場合がある

Amazon Honeycode notification alert

申請者への結果通知メール送信機能を作成

  • Automationを追加
    • 画面左側の + をクリックして画面を起動

add automation

  • automation Trigger
    • 処理が発生するタイミングは承認者による承認結果登録を起点とする
    • Column Changes を選択
    • In table
      • 申請データを格納する attendance を選択
    • Starts when this column changes
      • 承認結果データである =[result] を選択
    • Run automation if this formula is TRUE
      • 承認結果の入力を示す式 =[result]<>"" を入力

Set Automation Trigger

  • 結果通知メールを定義
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
=applicant 様

以下の出社申請への承認結果をご連絡致します。

申請日:=
申請者:
出社希望日:
出社先:
出社理由:

承認者:
承認結果:

本メールは、配信専用のアドレスで配信されています。
本メールに返信されても、返信内容の確認およびご返信ができません。
あらかじめご了承ください。

Amazon Honeycode 申請メール例

  • Publishで編集を完了

ここまででアプリの開発は完了
次に関係者にアプリを公開する

アプリを公開

Teamにユーザを招待

Honeycodeで開発したアプリを使ってもらうには、事前に以下が必要

  • 利用者にAmazon Honeycodeのアカウントを作成してもらう

  • 同じTeamに入ってもらう

  • 招待の手順

    • 画面左下の Teams アイコンをクリック
    • チーム名をクリック
    • 画面右上の Add team member をクリック

Amazon Honeycode Teamへの招待

  • Connect AWS account
    • 有料プランにすればAWSのアカウントとも連携可能なよう
      1
      To upgrade your team plan, connect to your AWS account.

Amazon Honeycode add member

  • Invite to join
    • 表示された画面でメンバーのメールアドレスを入力
    • 役割を Admin と Member のいずれかから選択
    • Invite ボタンをクリック
    • 役割の違い
      • Admin : Workbook、アプリケーション、Automations の作成。Plan とチームメンバーの管理
      • Member : Workbook、アプリケーション、Automations の作成

Invite to join

  • 招待を受けたユーザーには以下のようなメールが送信される
    • Join ボタンをクリックしてもらう

Amazon Honeycode invite mail

事前の登録作業は以上で完了。
一度Honeycodeのアカウントを登録すれば他のアプリを作っても使いまわせるが少し手間ではある印象

share

作成したアプリケーションの公開は関係者に Shareする

  • 画面左上の Amazon Honeycode アイコンをクリック
  • Workbook とアプリケーションの一覧を表示
  • 公開したいアプリケーション右端のスリードットの左側をカーソルでポイント
    • Share ボタンが表示されるのでクリック

Amazon Honeycode 作成したアプリを公開

  • 公開先のユーザアカウントを選択する
    • ユーザー名やメールアドレスで検索
    • リストに追加
    • Update ボタンをクリック

Amazon Honeycode Share App

  • 利用可能になった旨がメールで通知される

Amazon Honeycode 利用通知メール


アプリを利用してみる

スマホで利用

  • まずはアプリケーションの公開通知を受け取ったユーザーがスマートフォンから出社申請をする

  • Amazon honeycode アプリをインストール

  • ログイン

    • アカウントを持っていなければここで作成
  • アカウント作成時に入力したメールアドレスとパスワードでログイン

    • 自分に公開されているアプリケーションの一覧が表示される
    • 今回作成したアプリケーションの Attendance をタップして起動

Ammazon Honeycode login画面

  • アプリケーションが起動すると、ホーム画面の申請一覧が表示される
    • データモデルを作成する際にインポートしたサンプルデータを削除していない場合はリストに表示される

ホーム画面の申請一覧

  • 画面右上の + Add をタップして出社申請を行う
    +Add

  • 出社申請のエントリー画面で入力可能な項目を埋めていく

  • データモデルの作成をする際に各データ項目の formats を定めた。アプリケーションでもその結果が踏襲され、データに合わせた入力が可能

  • データ入力が完了したら Done ボタンをクリックし、入力を確定

  • 申請一覧画面に遷移し、直前の操作で作成した申請が一覧に表示される

  • 申請データの登録に合わせて Automations が実行され、マネージャーにはこのようなメールが送信される

Web ブラウザで申請を承認

  • 続いては承認依頼通知を受け取ったマネージャーが出社申請を承認する

  • Amazon Honeycode は Webブラウザからも利用可能なため、マネージャーはブラウザから承認を行ってみる

  • Chrome、Edge、Firefox、Safari などの Web ブラウザで Amazon Honeycode にアクセス

  • 今回作成したアプリケーションの Attendance をクリックして起動

  • アプリが起動すると、ホーム画面の申請一覧が表示される
    • 承認結果が空白のデータをクリックし、出社申請の承認を実施

  • 出社申請の詳細画面が表示される
    • 内容を確認して承認結果を選択

  • 選択すると自動的にデータが保存され、申請者にはこのようなメールが送信された

無事に出社申請業務を実施できたので、これで動作確認は完了

所感

  • iOS や Android のアプリストアから Amazon Honeycode アプリをダウンロードしてログインするだけで、利用者に必要なアプリケーションが表示され、配布の手間が少ない点はメリット
    • honeycodeへのアカウント登録とTeamへの加入は必要だが、以降はアプリを追加してもすぐにShareできる
  • AWSアカウントとの連携も利用すれば、より配布の手間を削減できそう

参考

その他

その他

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

参考

関連記事

その他

[AWS Budgets x SNS]でPJ毎の運用コストを管理/閾値超過で通知

AWSにおけるコストの管理方法についてです。総コストはCloud Watchでも見れますが、PJ単位でコスト管理するにはAWS Budgetsでタグを使ってフィルタリングする方式が適しています。

AWS Budgestとは?

  • AWS Budgets
    • カスタム予算を設定して、コストまたは使用量が予算額や予算量を超えたとき (あるいは、超えると予測されたとき) にアラートを発信できるサービス

AWS Budgets

  • コストレポートで出力して、報告にそのまま使える
    Report

PJのリソースの総コストをタグでフィルタリング

  • まずは各リソースにタグを付ける

    • PJタグを付与するルールをチーム内で設定
  • Console/ AWS Budgets

  • Cost Explorer

    • ここでコストの詳細を視覚的に確認できる
      Cost Explorer
  • データのグループ化やフィルタリングでPJ毎のリソースのコストを抽出する

    • グループ化の条件/詳細/タグから絞る
      AWS Budgets グループ化

    • データのフィルタ機能で全体から絞る
      AWS Budgets データのフィルタ

予算作成 & アラートを設定

  • AWS Budgets/予算を作成
  • 予算を作成する
    • 予算タイプ
      • コスト予算
    • 予算の設定
      • タグでPJで利用しているリソース群に絞る
        予算設定
    • アラートの設定
      • しきい値
        • 80%にしておく
      • SNS Topicを経由するか、直でメール送信か選べる
        • 今回は連絡電子メールにTeamsの開発チームのチャンネルのアドレスを設定
          AWS Budgets alart
    • 予算の確認
      • 問題なければ”作成”

以上で、コストの閾値超過時点でTeamsに通知が飛ぶように設定できた。

参考

関連記事

[AWS CloudTrail] 証跡/内部監査用のログを貯める

監査対策としてCloudTrailでログを取得する方式を解説します。

CloudTrailとは?

CloudTrail

  • 単一のAWS アカウントにおける、全APIリクエストを記録するサービス

    • 公式説明
      1
      CloudTrail を使用すると、AWS アカウントのイベントを表示できます。これらのイベントの記録を保持するには、証跡を作成します。証跡により、イベントメトリクスを作成し、アラートをトリガーして、イベントワークフローを作成することもできます。 また、AWS Organizations のマスターアカウントでログインすると、組織の証跡を作成することができます。
    • 一つのAPではなく、アカウント全体の話
    • 外向きよりも、内向きの監視が目的
      • AWSアカウントを共有する内部のIAMユーザの悪意を持った行動を抑えることができる
      • 外部からのリクエストも記録できる
  • デフォルト

    • 90日間の記録は初めから有効
    • 無料
    • 永続的に保持する際には有料となる
  • ”証跡情報の作成”

    • S3
    • 本番稼働でなければ、ひとまず対処しなくてもOK?
  • CloudTrail Insights

    • 異常検知機能
      • 公式説明
        1
        CloudTrailが異常なアクティビティを検出した場合、Insightsイベントはトレイルの送信先のS3バケットに配信されます。また、CloudTrailコンソールでInsightsイベントを表示すると、インサイトの種類やインシデント期間を確認することができます。CloudTrailのトレイルでキャプチャされる他のタイプのイベントとは異なり、インサイトイベントは、アカウントの通常の使用パターンとは大きく異なるアカウントのAPI使用状況の変化をCloudTrailが検出した場合にのみログに記録されます。
    • 有料
  • Organizationのマスターアカウントを使えば、マルチアカウント運用でも組織の証跡を作成可能

    • 監査チームとの連携に活用

CloudTrailで内部監査用のログを貯める

デフォルトでは90日間の情報しか確認出来ないため、証跡を作成してS3 bucketに貯める必要がある。

  • AWS Console/CloudTrail
  • ダッシュボード/”証跡の作成”を押下
    CloudTrail

証跡の作成

  • 使い方は2種類ありそう
    • アカウント統一の証跡を作成
    • サービス毎に証跡を分ける
      • 複数の認跡の作成では、追加コストが発生

リージョン毎に一つまでの証跡を作成しても無料であり、S3のみの課金となる。
CloudWatch側でサービス毎のログは取るので、CloudTrailはアカウント統一の証跡を作成することにする

CloudTrail 証跡の作成

  • 証跡情報の作成
    • 証跡名
      • アカウント名-logsで設定してみる
    • 証跡情報を全てのリージョンに適応
      • はい
    • 管理イベント
      • そのまま
    • Insightsイベント
      • いいえ
        • 追加料金を避けるため
        • CloudWatchからのAlartで充分だと考える
    • データイベント
      • S3, Lambda共に全てでOK
    • ストレージの場所
      • 新しいS3バケットを作成しますか?
        • はい
      • S3バケット
        • 適当に命名
          • bucket-for-cloudtrail-logs
    • 詳細
      • ログファイルの検証
        • CloudTrailからログファイルを送信後に、編集/削除/変更がないか確認できる
        • Cloud Configが必要だと考えていたが、利用せずとも改ざん対策できた
    • タグ
      • Own
        • 証跡の作成者だけ登録
    • 作成

以上で証跡とS3 Bucketが生成される。内部監査対策は基本的にこれだけでOK。

参考

関連記事

@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

×