AWS Amplifyを軸にした フルサーバーレスなアプリケーション構成 / Full serverless application on AWS Amplify

AWS Dev Day Online Japan 2021

Transcript

1. © 2021, Amazon Web Services, Inc. or its affiliates. All rights reserved.
   AWS Amplifyを軸にした
   フルサーバーレスなアプリケーション構成
   清家 史郎 (@seike460)
   Fusic Co., Ltd.
   Evangelist / TeamLeader / PrincipalEngineer
   H-1
   

   View Slide

2. • Name / ID
   • 清家 史郎 / @seike460
   • Company
   • Fusic Co., Ltd.
   • Evangelist / TeamLeader / PrincipalEngineer
   • Skill
   • AWS / PHP / Go
   • AWS Certification
   • AWS Certified Solutions Architect Associate Professional
   • Community
   • ServerlessDays Fukuoka 2019 co-chair
   • JAWS DAYS 2019-2020 speaker
   Who?
   

   View Slide

3. © 2021, Amazon Web Services, Inc. or its affiliates. All rights reserved.
   1. AWS のサービスを理解することで、課題解決できる可能性の⽰唆
   2. バックエンドエンジニアから⾒たときのAWS Amplifyの良さ、凄さ
   3. AWS AppSyncを利⽤したGraphQLとTypeScriptの相性の良さ
   本⽇のゴール
   

   View Slide

4. © 2021, Amazon Web Services, Inc. or its affiliates. All rights reserved.
   1. 構築したAWS構成と状況
   2. 当時の課題感と気付き
   3. 構成変更の流れ
   4. 最終構成
   5. まとめ
   Agenda
   

   View Slide

5. © 2021, Amazon Web Services, Inc. or its affiliates. All rights reserved.
   構築したAWS構成と状況
   

   View Slide

6. • 解析プログラムの実⾏を制御するPoC⽤のWebフロントエンドが必要
   • 解析プログラムの作成は既に進んでいる
   • ⽇毎の解析実⾏回数としては多いわけではない
   • 解析結果データに対して、相当レコード数検索する必要がある
   レコード数が多い検索を、PoCなのでスピーディーに実装する必要がある
   →肝になりうる部分、馴染みのある技術で確実な実装が必要と判断
   状況
   

   View Slide

7. • S3へ⼤容量ファイルアップロードの可能性在り
   • マルチパートアップロードへの対応が必要
   • フロントエンドにはユーザー認証が必要
   • 結果、必然的にバックエンドにも必要
   • PoC解析環境を素早く整えたい
   • 作らなくて良いものは作らず構築したい
   その他要件
   

   View Slide

8. • メンバー⼆⼈︓共通するスキルセット
   • Go
   • React
   • 役割分担
   • バックエンド
   • GoにてAmazon RDSのCRUD操作をするAWS Fargate API構築
   • フロントエンド
   • Amplify UI Componentsを利⽤してReact フロントエンド構築
   プロジェクトメンバースキルセット
   

   View Slide

9. amplify add auth
   • 最低限の設定を⾏うだけなら不安になるくらいすべてやってくれる
   • Amazon Cognitoの構築を数分で⾏える
   • Social Providerの設定も可能
   

   View Slide

10. Authentication UI Components
    

    View Slide

11. i18nの対応も可能
    • ⾃分で辞書ファイルを⽤意する必要は
    あるが簡単に対応可能
    

    View Slide

12. amplify add storage
    • コンテンツアップロード⽤のS3も楽々作成
    

    View Slide

13. Storage Libraries
    • サンプルコードにて簡単に
    アップロード機能作成も可能
    • アップロード進捗を⾒る為の
    ProgressCallbackもあり
    

    View Slide

14. OpenAPI Generator
    バックエンドとフロントエンドの齟齬を⼩さくする為
    OpenAPI定義を⾏い Code Generatorを利⽤する事で
    データのやり取りをスムーズに進めることが出来た。
    OpenAPI
    

    View Slide

15. TypeScript
    バックエンドはGo、OpenAPI Generatorを利⽤しているので
    フロントエンドも厳密に型を設定したい。
    TypeScript対応しているReactとMaterial-UIにて
    ⼿戻りを少なく構築を⾏う。
    TypeScript OpenAPI
    

    View Slide

16. 初期アーキテクチャ
    • フロントエンド
    • React + AWS Amplify
    • TypeScript
    • バックエンド
    • Go
    • データベース
    • Amazon RDS
    • API仕様
    • OpenAPI
    • 解析実⾏
    • Step Functions +AWS Batch
    • 中間データ -> S3
    • 検索データ -> RDS
    

    View Slide

17. © 2021, Amazon Web Services, Inc. or its affiliates. All rights reserved.
    課題感と気付き
    

    View Slide

18. 課題感
    • 解析実⾏回数としては多いわけではない
    • 特に利⽤されてない時のリソース待機コストが気になっていました
    • ALB、AWS FargateやAmazon RDSを無くしてリソース待機コストを低減したい
    • バックエンドでやってることは⾮常に単純でこのコード管理・改修をしたくない
    • Goとコンテナ管理を無くしたい
    • 解析データの検索さえなければフルサーバーレス構成を取れるのに…
    ⚡
    

    View Slide

19. JAWS DAYS 2020にて気付き
    サーバレスの新しいデータストアの選択肢
    S3 Select の魅⼒
    Fusic / Principal Engineer
    内⽥が⽰した
    当時の⾃分にはなかった
    新しい選択肢 S3 Select
    対応しているSQLは
    解析結果データの検索に対して
    ⼗分に要件を満たしていた
    

    View Slide

20. 技術の引出しの狭さが仇になる
    • GA後に試している、確実に認識していたはずのS3 Select
    • 実際に対象にS3 Selectを実⾏してみると
    取得したかったデータが返ってくる
    • レスポンスも前述スライドの通り、Webレスポンスに耐えうる⼗分な速度
    • 計測が挟まる要件上、確実に結果整合性で良い
    • ⼊⼒または結果のレコードの最⼤⻑は 1 MBを超えることはない
    • 今後の結果が爆発的に増えることもない
    • これを利⽤したAPIを作成するというアイディア、応⽤⼒のなさが仇に
    

    View Slide

21. 課題の顕在化
    • PoC環境を完成した後、リソースコストが話題に
    • 今こそあの後悔を解消する時
    • インフラコストとコンテナ管理部分を排除出来る可能性
    • Application Load Balancer、AWS Fargate、Amazon RDS
    • ECR管理のGoアプリケーション
    S3 Select
    

    View Slide

22. © 2021, Amazon Web Services, Inc. or its affiliates. All rights reserved.
    構成変更の流れ
    

    View Slide

23. 前提にすべき要件
    • 表⾯的、機能的にはアップデートがない
    • 最⼩の⼯数かつ爆速で構築する必要がある
    • デグレードの可能性も最⼩にする必要がある
    • ⼈の⼿での変更を最⼩にする構成変更
    今こそ認証とS3アップロードで使ってたAmplifyを全⾯的に活⽤
    

    View Slide

24. S3 Select API 作成
    • 解析プログラム側はS3に中間データを配置していた
    • 結果CSVを配置するのみで対応完了
    • 元々AWS Fargate に Amazon RDSからSelectするSQLがある
    • S3 Select SQLに応⽤しLambda APIを作成
    • Amplify CLIを使って 、REST APIを設置
    • Step FunctionsをKickするAPIも合わせて設置
    

    View Slide

25. amplify add api(REST)
    

    View Slide

26. AWS AppSync
    • OpenAPI Generatorを利⽤しコードを⾃動⽣成していた
    • AWS AppSyncもスキーマーからコード⾃動⽣成してくれる
    • TypeScriptを利⽤した型付け
    • スキーマーベースAPIの為、型が決まる
    • コードの変更箇所は明確
    • OpenAPI Generatorのコードを、AppSync⽣成のコードに変更
    • データを取得する箇所、登録する箇所をひたすら置き換え
    

    View Slide

27. AWS AppSync
    exampleの例だとAPI.graphqlを素直に
    呼び出していて戻り値の型が表現出来ない
    出⼒されたAPI.tsの中に型情報がある
    

    View Slide

28. AWS AppSync
    GraphQLResultに各QueryやMutationを
    ⾷わせることで戻り値の型も表現できる
    useStateにてState管理を⾏っていた
    箇所に対して、AppSync対応を⾏う
    元々OpenAPIにて型管理されていた為、
    同じ型にはめ込み、その後の動作も保証
    

    View Slide

29. schema.graphql
    ドキュメント内にExampleが提供されている
    書き⽅がわからなければこちらから
    編集するのが良い
    hasoneやhasmanyの様な
    リレーショナルデータベース的なモデリング
    

    View Slide

30. amplify-cli Developer Preview Update
    ※先⽇amplify-cliのDeveloper Previewが公開されてました。
    @connection と @key がdeprecatedになるとのこと
    

    View Slide

31. @connection -> @hasOne, @hasMany, and @belongsTo
    ORMの様な使⽤感のディレクティブ
    @hasOne(fields: [String!])
    @hasMany
    (indexName: String, fields: [String!], limit: Int = 100)
    @belongsTo(fields: [String!])
    

    View Slide

32. @key -> @primaryKey, @Index
    詳しくはGithubへ
    https://github.com/aws-amplify/amplify-cli/issues/6217#issuecomment-929677992
    

    View Slide

33. AWS AppSyncに対する懸念
    • 検索項⽬が増加していく事に対する懸念
    • @searchableにてAmazon OpenSearch Serviceにて対応可能と判断
    • インスタンス管理はサービス成⻑によるコスト増加と割り切る
    • Amazon DynamoDBで処理するのが難しいデータ量に対する懸念
    • Aurora Serverlessにて対応可能と判断(⾃⼒構築の必要あり)
    • 最終⼿段はLambda︖
    • VTLと格闘することになるのは避けたいなぁ…
    Amazon OpenSearch
    Service Amazon DynamoDB
    Amazon Aurora Serverless
    

    View Slide

34. amplify add api,auth,storage そしてhosting
    • Amplify APIを導⼊
    • 構成変更によりHosting S3とCloudFront以外はAmplify管理
    • Amplify Consoleにて管理
    • デプロイ、ドメイン管理も
    

    View Slide

35. ただし注意が必要
    • CloudFrontの細かい設定が出来ない
    • Consoleを⾒る限り、CloudFrontが設定されているが、実際は⾒えない
    • AWS Amplify Performance mode設定はあるが、CloudFrontほどの細かい設定はない
    • IP制限が現状設定出来ない
    • CloudFront の設定が⾒えないため、AWS WAFを設定することが出来ない。
    • Basic認証も設定できるが、開発以外の環境かつ、制限をしたいという動機で
    Basic認証を利⽤するのは⾮現実的な印象
    

    View Slide

36. © 2021, Amazon Web Services, Inc. or its affiliates. All rights reserved.
    最終構成
    

    View Slide

37. 最終構成
    • フロントエンド
    • React + AWS Amplify
    • TypeScript
    • バックエンド
    • AWS AppSync
    • Lambda(Go)
    • データベース(ストレージ)
    • Amazon DynamoDB
    • S3 Select
    • API仕様
    • GraphQL
    • 解析実⾏
    • Step Function
    AWS Batch
    • 中間データ -> S3
    • 検索データ -> S3
    

    View Slide

38. © 2021, Amazon Web Services, Inc. or its affiliates. All rights reserved.
    まとめと謝辞
    

    View Slide

39. フルサーバーレス、フルマネージド環境
    • AWS管理をAWS Amplifyを軸にしてフルサーバーレス環境に
    • 初期構成の課題感を解消出来た
    • ⾃ら積極的に管理するものがないフルサーバーレス環境
    • OpenAPI Generator + Typescript構築前提でのAWS AppSyncの親和性を感じた
    • AWS Amplifyを⼒を感じた、引き続き知⾒を貯め、アウトプットに繋げたい
    

    View Slide

40. 謝辞
    • 今回知識の幅が広がる事で、構成がガラリと変更することが出来た
    • 「無知は罪なり」とは⾔うが、⼈は万能ではない
    • コミュニティイベントでのアウトプットが決定打になった
    • 私の気付きのきっかけを与えてくれた「JAWS DAYS」の皆様
    • この場の与えてくれた「AWS Dev Day Online Japan」の皆様
    • この発表を聞いてくれた「聴講者」の皆様
    

    View Slide

41. Thank you!
    © 2021, Amazon Web Services, Inc. or its affiliates. All rights reserved.
    清家 史郎(@seike460)
    Fusic Co., Ltd.
    Evangelist / TeamLeader / PrincipalEngineer
    We Are Hiring︕
    https://recruit.fusic.co.jp
    

    View Slide