Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
AWS Amplifyを軸にした フルサーバーレスなアプリケーション構成 / Full s...
Search
shiro seike
PRO
September 30, 2021
Technology
6
2.7k
AWS Amplifyを軸にした フルサーバーレスなアプリケーション構成 / Full serverless application on AWS Amplify
AWS Dev Day Online Japan 2021
shiro seike
PRO
September 30, 2021
Tweet
Share
More Decks by shiro seike
See All by shiro seike
PHPで作るWebSocketサーバー ~リアクティブなアプリケーションを知るために~ / WebSocket Server in PHP - To know reactive applications
seike460
PRO
2
390
CQRS+ES の力を使って効果を感じる / Feel the effects of using the power of CQRS+ES
seike460
PRO
0
130
AWS Lambdaから始まった Serverlessの「熱」とキャリアパス / It started with AWS Lambda Serverless “fever” and career path
seike460
PRO
1
520
とにかくAWS GameDay!AWSは世界の共通言語! / Anyway, AWS GameDay! AWS is the world's lingua franca!
seike460
PRO
1
1.1k
実践サーバーレスパフォーマンスチューニング ~その実力に迫る~ / Practical Serverless Performance Tuning ~A Close Look at its Power~
seike460
PRO
2
350
PHPを書く理由、PHPを書いていて良い理由 / Reasons to write PHP and why it is good to write PHP
seike460
PRO
5
600
AWS CDKを用いたセキュアなCI/CDパイプラインの構築 / Build a secure CI/CD pipeline using AWS CDK
seike460
PRO
3
760
いまあるチームにフィットさせる Serverless そして Platform Engineeringへの挑戦 / Serverless Fits the Team You Have and Platform Engineering
seike460
PRO
2
2.1k
いまあるチームにフィットさせる Serverless / Serverless fits in with the team you have now.
seike460
PRO
2
180
Other Decks in Technology
See All in Technology
UI State設計とテスト方針
rmakiyama
2
590
ずっと昔に Star をつけたはずの思い出せない GitHub リポジトリを見つけたい!
rokuosan
0
150
ブラックフライデーで購入したPixel9で、Gemini Nanoを動かしてみた
marchin1989
1
540
私なりのAIのご紹介 [2024年版]
qt_luigi
1
120
組織に自動テストを書く文化を根付かせる戦略(2024冬版) / Building Automated Test Culture 2024 Winter Edition
twada
PRO
16
4.1k
成果を出しながら成長する、アウトプット駆動のキャッチアップ術 / Output-driven catch-up techniques to grow while producing results
aiandrox
0
330
Fanstaの1年を大解剖! 一人SREはどこまでできるのか!?
syossan27
2
170
Amazon Kendra GenAI Index 登場でどう変わる? 評価から学ぶ最適なRAG構成
naoki_0531
0
110
NilAway による静的解析で「10 億ドル」を節約する #kyotogo / Kyoto Go 56th
ytaka23
3
380
re:Invent 2024 Innovation Talks(NET201)で語られた大切なこと
shotashiratori
0
310
KubeCon NA 2024 Recap / Running WebAssembly (Wasm) Workloads Side-by-Side with Container Workloads
z63d
1
250
Snowflake女子会#3 Snowpipeの良さを5分で語るよ
lana2548
0
230
Featured
See All Featured
Statistics for Hackers
jakevdp
796
220k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
95
17k
Imperfection Machines: The Place of Print at Facebook
scottboms
266
13k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
29
2.3k
How to Think Like a Performance Engineer
csswizardry
22
1.2k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
10
810
Keith and Marios Guide to Fast Websites
keithpitt
410
22k
Adopting Sorbet at Scale
ufuk
73
9.1k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
44
9.3k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
169
50k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
17
2.3k
Thoughts on Productivity
jonyablonski
67
4.4k
Transcript
© 2021, Amazon Web Services, Inc. or its affiliates. All
rights reserved. AWS Amplifyを軸にした フルサーバーレスなアプリケーション構成 清家 史郎 (@seike460) Fusic Co., Ltd. Evangelist / TeamLeader / PrincipalEngineer H-1
• 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?
© 2021, Amazon Web Services, Inc. or its affiliates. All
rights reserved. 1. AWS のサービスを理解することで、課題解決できる可能性の⽰唆 2. バックエンドエンジニアから⾒たときのAWS Amplifyの良さ、凄さ 3. AWS AppSyncを利⽤したGraphQLとTypeScriptの相性の良さ 本⽇のゴール
© 2021, Amazon Web Services, Inc. or its affiliates. All
rights reserved. 1. 構築したAWS構成と状況 2. 当時の課題感と気付き 3. 構成変更の流れ 4. 最終構成 5. まとめ Agenda
© 2021, Amazon Web Services, Inc. or its affiliates. All
rights reserved. 構築したAWS構成と状況
• 解析プログラムの実⾏を制御するPoC⽤のWebフロントエンドが必要 • 解析プログラムの作成は既に進んでいる • ⽇毎の解析実⾏回数としては多いわけではない • 解析結果データに対して、相当レコード数検索する必要がある レコード数が多い検索を、PoCなのでスピーディーに実装する必要がある →肝になりうる部分、馴染みのある技術で確実な実装が必要と判断
状況
• S3へ⼤容量ファイルアップロードの可能性在り • マルチパートアップロードへの対応が必要 • フロントエンドにはユーザー認証が必要 • 結果、必然的にバックエンドにも必要 • PoC解析環境を素早く整えたい
• 作らなくて良いものは作らず構築したい その他要件
• メンバー⼆⼈︓共通するスキルセット • Go • React • 役割分担 • バックエンド
• GoにてAmazon RDSのCRUD操作をするAWS Fargate API構築 • フロントエンド • Amplify UI Componentsを利⽤してReact フロントエンド構築 プロジェクトメンバースキルセット
amplify add auth • 最低限の設定を⾏うだけなら不安になるくらいすべてやってくれる • Amazon Cognitoの構築を数分で⾏える • Social
Providerの設定も可能
Authentication UI Components
i18nの対応も可能 • ⾃分で辞書ファイルを⽤意する必要は あるが簡単に対応可能
amplify add storage • コンテンツアップロード⽤のS3も楽々作成
Storage Libraries • サンプルコードにて簡単に アップロード機能作成も可能 • アップロード進捗を⾒る為の ProgressCallbackもあり
OpenAPI Generator バックエンドとフロントエンドの齟齬を⼩さくする為 OpenAPI定義を⾏い Code Generatorを利⽤する事で データのやり取りをスムーズに進めることが出来た。 OpenAPI
TypeScript バックエンドはGo、OpenAPI Generatorを利⽤しているので フロントエンドも厳密に型を設定したい。 TypeScript対応しているReactとMaterial-UIにて ⼿戻りを少なく構築を⾏う。 TypeScript OpenAPI
初期アーキテクチャ • フロントエンド • React + AWS Amplify • TypeScript
• バックエンド • Go • データベース • Amazon RDS • API仕様 • OpenAPI • 解析実⾏ • Step Functions +AWS Batch • 中間データ -> S3 • 検索データ -> RDS
© 2021, Amazon Web Services, Inc. or its affiliates. All
rights reserved. 課題感と気付き
課題感 • 解析実⾏回数としては多いわけではない • 特に利⽤されてない時のリソース待機コストが気になっていました • ALB、AWS FargateやAmazon RDSを無くしてリソース待機コストを低減したい •
バックエンドでやってることは⾮常に単純でこのコード管理・改修をしたくない • Goとコンテナ管理を無くしたい • 解析データの検索さえなければフルサーバーレス構成を取れるのに… ⚡
JAWS DAYS 2020にて気付き サーバレスの新しいデータストアの選択肢 S3 Select の魅⼒ Fusic / Principal
Engineer 内⽥が⽰した 当時の⾃分にはなかった 新しい選択肢 S3 Select 対応しているSQLは 解析結果データの検索に対して ⼗分に要件を満たしていた
技術の引出しの狭さが仇になる • GA後に試している、確実に認識していたはずのS3 Select • 実際に対象にS3 Selectを実⾏してみると 取得したかったデータが返ってくる • レスポンスも前述スライドの通り、Webレスポンスに耐えうる⼗分な速度
• 計測が挟まる要件上、確実に結果整合性で良い • ⼊⼒または結果のレコードの最⼤⻑は 1 MBを超えることはない • 今後の結果が爆発的に増えることもない • これを利⽤したAPIを作成するというアイディア、応⽤⼒のなさが仇に
課題の顕在化 • PoC環境を完成した後、リソースコストが話題に • 今こそあの後悔を解消する時 • インフラコストとコンテナ管理部分を排除出来る可能性 • Application Load
Balancer、AWS Fargate、Amazon RDS • ECR管理のGoアプリケーション S3 Select
© 2021, Amazon Web Services, Inc. or its affiliates. All
rights reserved. 構成変更の流れ
前提にすべき要件 • 表⾯的、機能的にはアップデートがない • 最⼩の⼯数かつ爆速で構築する必要がある • デグレードの可能性も最⼩にする必要がある • ⼈の⼿での変更を最⼩にする構成変更 今こそ認証とS3アップロードで使ってたAmplifyを全⾯的に活⽤
S3 Select API 作成 • 解析プログラム側はS3に中間データを配置していた • 結果CSVを配置するのみで対応完了 • 元々AWS
Fargate に Amazon RDSからSelectするSQLがある • S3 Select SQLに応⽤しLambda APIを作成 • Amplify CLIを使って 、REST APIを設置 • Step FunctionsをKickするAPIも合わせて設置
amplify add api(REST)
AWS AppSync • OpenAPI Generatorを利⽤しコードを⾃動⽣成していた • AWS AppSyncもスキーマーからコード⾃動⽣成してくれる • TypeScriptを利⽤した型付け
• スキーマーベースAPIの為、型が決まる • コードの変更箇所は明確 • OpenAPI Generatorのコードを、AppSync⽣成のコードに変更 • データを取得する箇所、登録する箇所をひたすら置き換え
AWS AppSync exampleの例だとAPI.graphqlを素直に 呼び出していて戻り値の型が表現出来ない 出⼒されたAPI.tsの中に型情報がある
AWS AppSync GraphQLResultに各QueryやMutationを ⾷わせることで戻り値の型も表現できる useStateにてState管理を⾏っていた 箇所に対して、AppSync対応を⾏う 元々OpenAPIにて型管理されていた為、 同じ型にはめ込み、その後の動作も保証
schema.graphql ドキュメント内にExampleが提供されている 書き⽅がわからなければこちらから 編集するのが良い hasoneやhasmanyの様な リレーショナルデータベース的なモデリング
amplify-cli Developer Preview Update ※先⽇amplify-cliのDeveloper Previewが公開されてました。 @connection と @key がdeprecatedになるとのこと
@connection -> @hasOne, @hasMany, and @belongsTo ORMの様な使⽤感のディレクティブ @hasOne(fields: [String!]) @hasMany
(indexName: String, fields: [String!], limit: Int = 100) @belongsTo(fields: [String!])
@key -> @primaryKey, @Index 詳しくはGithubへ https://github.com/aws-amplify/amplify-cli/issues/6217#issuecomment-929677992
AWS AppSyncに対する懸念 • 検索項⽬が増加していく事に対する懸念 • @searchableにてAmazon OpenSearch Serviceにて対応可能と判断 • インスタンス管理はサービス成⻑によるコスト増加と割り切る
• Amazon DynamoDBで処理するのが難しいデータ量に対する懸念 • Aurora Serverlessにて対応可能と判断(⾃⼒構築の必要あり) • 最終⼿段はLambda︖ • VTLと格闘することになるのは避けたいなぁ… Amazon OpenSearch Service Amazon DynamoDB Amazon Aurora Serverless
amplify add api,auth,storage そしてhosting • Amplify APIを導⼊ • 構成変更によりHosting S3とCloudFront以外はAmplify管理
• Amplify Consoleにて管理 • デプロイ、ドメイン管理も
ただし注意が必要 • CloudFrontの細かい設定が出来ない • Consoleを⾒る限り、CloudFrontが設定されているが、実際は⾒えない • AWS Amplify Performance mode設定はあるが、CloudFrontほどの細かい設定はない
• IP制限が現状設定出来ない • CloudFront の設定が⾒えないため、AWS WAFを設定することが出来ない。 • Basic認証も設定できるが、開発以外の環境かつ、制限をしたいという動機で Basic認証を利⽤するのは⾮現実的な印象
© 2021, Amazon Web Services, Inc. or its affiliates. All
rights reserved. 最終構成
最終構成 • フロントエンド • React + AWS Amplify • TypeScript
• バックエンド • AWS AppSync • Lambda(Go) • データベース(ストレージ) • Amazon DynamoDB • S3 Select • API仕様 • GraphQL • 解析実⾏ • Step Function AWS Batch • 中間データ -> S3 • 検索データ -> S3
© 2021, Amazon Web Services, Inc. or its affiliates. All
rights reserved. まとめと謝辞
フルサーバーレス、フルマネージド環境 • AWS管理をAWS Amplifyを軸にしてフルサーバーレス環境に • 初期構成の課題感を解消出来た • ⾃ら積極的に管理するものがないフルサーバーレス環境 • OpenAPI
Generator + Typescript構築前提でのAWS AppSyncの親和性を感じた • AWS Amplifyを⼒を感じた、引き続き知⾒を貯め、アウトプットに繋げたい
謝辞 • 今回知識の幅が広がる事で、構成がガラリと変更することが出来た • 「無知は罪なり」とは⾔うが、⼈は万能ではない • コミュニティイベントでのアウトプットが決定打になった • 私の気付きのきっかけを与えてくれた「JAWS DAYS」の皆様
• この場の与えてくれた「AWS Dev Day Online Japan」の皆様 • この発表を聞いてくれた「聴講者」の皆様
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