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
Access to multiple microservices on AWS
Search
k1nakayama
July 15, 2020
3
1.3k
Access to multiple microservices on AWS
Serverless Meetup Japan Virtual #2
#serverless #AWS #AppSync #serverlessjp
k1nakayama
July 15, 2020
Tweet
Share
More Decks by k1nakayama
See All by k1nakayama
GitLab Duo with Amazon Q の機能実装を試してみた
k1nakayama
0
28
GitLab Ultimateを用いたDevSecOps実践事例
k1nakayama
0
150
GitLabを活用したDevSecOps
k1nakayama
1
300
GitLabを活用したクラウドネイティブ アプリケーションセキュリティ
k1nakayama
0
140
サーバーレス開発を円滑に進めるための実践DevSecOps
k1nakayama
1
460
大容量データをDynamoDBで扱う際のMomento導入検討
k1nakayama
0
660
Deep Dive on DevOps for Serverless Applications
k1nakayama
0
300
Featured
See All Featured
Producing Creativity
orderedlist
PRO
342
39k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
232
17k
How STYLIGHT went responsive
nonsquared
96
5.2k
Building an army of robots
kneath
302
44k
The Pragmatic Product Professional
lauravandoore
32
6.3k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
229
52k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
33
2k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
29
900
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
330
21k
[RailsConf 2023] Rails as a piece of cake
palkan
53
5k
A Tale of Four Properties
chriscoyier
157
23k
Bash Introduction
62gerente
609
210k
Transcript
Serverless Meetup Japan Virtual #2 Access to multiple microservices on
AWS @k1nakayama
Serverless Meetup Japan Virtual #2 自己紹介 • 中山 桂一 (
@k1nakayama ) • 株式会社キャラウェブ クラウドパートナーグループ 副部長 • クラウドパートナー事業をリード • 2020 APN AWS Top Engineers
Serverless Meetup Japan Virtual #2 会社概要 会社名:株式会社キャラウェブ 所在地:東京都台東区東上野4−12−1 資本金:7,161万円 主な事業内容:
コンテンツ事業 電子書籍のライセンスおよび管理,電子書籍販売 クラウドパートナー事業 サーバーレスアプリケーション構築にフォーカスした アジャイルチーム提供サービス 他 ISO/IEC 27001:2013 & JIS Q 27001:2014 クラウドに関するコンサルティング、設計、 構築、運用、管理 における認証 当社は AWSパートナーネットワーク の コンサルティングパートナー です
Serverless Meetup Japan Virtual #2 マイクロサービスしてますか?
Serverless Meetup Japan Virtual #2 マイクロサービスの特徴 Ø 小さく分かれていて、それぞれが自立しているサービス Ø 他のサービスと連携するためのインタフェースを持つ
• 他のサービスとのコミュニケーションはAPI等のインタフェースを通して 行われる Ø デプロイが独立している • データストア等を共有していない Ø 回復性が高い(他のサービスに影響を与えにくい)
Serverless Meetup Japan Virtual #2 マイクロサービスの課題 主にフロントエンドから見た、マイクロサービスの課題 u 多くのAPI仕様を把握しなければならない u
結果を得るために、多くのAPIへのリクエストが発生する u 分散処理のため非同期的になりやすい u 認証・認可が複雑になりがち u モニタリングの複雑化
Serverless Meetup Japan Virtual #2 AWS AppSync
Serverless Meetup Japan Virtual #2 AWS AppSync Ø マネージドなGraphQLサービス Ø
リアルタイムなデータアクセス Ø 様々なデータソースを利用可能 Ø きめ細やかなアクセスコントロール
Serverless Meetup Japan Virtual #2 GraphQL Ø エンドポイントは1つだけ Ø Query、Mutation、Subscription
の3つのオペレーションが行える Ø 1回のクエリに複数のリクエストを含めることができる Ø レスポンスに必要な要素を、クライアントが指定可能 Ø フィールド毎にクエリを入れ子にできる
Serverless Meetup Japan Virtual #2 クエリの例 とあるECサイトのユーザープロフィールページに、下記の情報を表示する • ユーザーのプロフィール情報 •
直近3件の購入履歴(購入した日付と配送ステータス) このサイトはマイクロサービスで構築されていて、それぞれ下記のAPIから情 報を取得可能 • User Service: ユーザーのプロフィール情報を管理 • Order Service:ユーザーの購入情報を管理 • Delivery Service:各注文の配送を管理
Serverless Meetup Japan Virtual #2 REST APIの場合 GET https://user.api/user/12345 {
“id”: ”12345”, “username”: “hogetarou”, “name”: “ホゲ太郎”, ・・・・ } GET https://order.api/user/12345/orders?limit=3 { “orders”: [ “id”: ”xxxxxxxxxx”, “ordered_at”: 1594482902, “status”: ”delivery_requested”, “details”: [ ・・・・ }
Serverless Meetup Japan Virtual #2 REST APIの場合 GET https://delivery.api/order/xxxxxxxxxx {
“id”: ” xxxxxxxxxx”, “status”: “Preparing_for_delivery”, “provider”: “ホゲホゲ運輸”, ・・・・ } GET https://delivery.api/order/xzxzxzxzxzx { “id”: ” xzxzxzxzxzx”, “status”: “delivered”, “provider”: “エクスプレス配送”, ・・・・ } 合計5回のリクエストを行い、不要なデータも大量に受け取る
Serverless Meetup Japan Virtual #2 GraphQLの場合 POST https://graphql-server/graphql query getProfilePageData
{ getUserProfile(user_id: “12345”) { name email registration_at } getUserOrderHistory(user_id: “12345”, limit: 3) { ordered_at delivery_info { status } } } ※上記は説明のため簡略化してあります
Serverless Meetup Japan Virtual #2 GraphQLの場合 { “data”: { “getUserProfile”:
{ “name”: “ホゲ太郎”, “email”: “
[email protected]
”, “registration_at”: 1578727153 }, ”getUserOrderHistory”: { “orders”: [{ “ordered_at”: 1594482902, “delivery_info”: { “status”: “Preparing_for_delivery” } }, ・・・・・ } } } 1回のみリクエストを行い、必要なデータのみ受け取る
Serverless Meetup Japan Virtual #2 AppSyncで利用可能なデータソース Ø AWS Lambda •
この時点でほぼ全てのデータソースに対応可能 Ø Amazon DynamoDB • トランザクションにも対応 Ø Amazon Elasticsearch Service Ø Amazon Aurora Serverless Ø HTTP Endpoint • SignatureV4を使用可能なため、各種AWSサービスのAPIを使用可能
Serverless Meetup Japan Virtual #2 for Monolith
Serverless Meetup Japan Virtual #2 for Microservices
Serverless Meetup Japan Virtual #2 ここからはAppSyncを既に触った ことがある方に捧げるTIPS
Serverless Meetup Japan Virtual #2 リゾルバーのデバッグ 1. AppSyncの設定から「ログを有効化」を有効にする 2. CloudWatch
Logs Insightsで設定したAppSyncのAPI IDを持つロググループ を選択 3. クエリに下記を設定してクエリを実行 fields ispresent(graphQLAPIId) as isApi, @message | filter isApi | filter logType = "ResponseMapping" | sort @timestamp desc | limit 20 | display @message
Serverless Meetup Japan Virtual #2 リゾルバーのデバッグ
Serverless Meetup Japan Virtual #2 リゾルバーのデバッグ
Serverless Meetup Japan Virtual #2 Subscription とあるECサイトの決済サービスでは、外部の決済代行サービスに決済をリク エストし、結果は非同期処理でAPIにコールバックされる フロントエンドでは、ユーザーに決済を実行した後、決済ステータスが完了す るまで待たせておきたい
この処理に、◯秒毎に結果をポーリングするのではなく、出来る限りリアルタ イムに結果を受け取りたい
Serverless Meetup Japan Virtual #2 間違った例 QueryによってDynamoDBに入れたステータスを得られることから誤解し、 DynamoDB上のデータを更新したらそのデータをSubscribe出来ると思いがち
Serverless Meetup Japan Virtual #2 正しくは Mutationを実行した内容だけがSubscribe可能 SubscribeできるデータもMutationの内容と同じなので注意
Serverless Meetup Japan Virtual #2 AppSync + API Gatewayの認証 AppSync
API Gateway(REST) API Key認証 ◯(最大365日間有効) △ IAM認証 ◯ ◯ Cognito認証 ◯ ◯ OIDC認証 ◯ ☓(カスタム認証で対応) カスタム認証 ☓ ◯ AppSyncのバックエンド(データソース)にAPI Gatewayを置いた場合、それぞ れ使える認証方法が異なるため注意が必要
Cognito認証 1. AppSyncへのリクエスト時に、AuthorizationヘッダーにCognitoのAccessToken、id-token ヘッダーにCognitoのID Tokenをセットしてリクエスト 2. HTTPリゾルバーにてAPI Gatewayのリクエスト時のAuthorizationヘッダーにid-tokenヘ ッダーの値をセット {
"version": "2018-05-29", "method": "GET", "params": { "headers":{ "Content-Type":"application/json", "Authorization": "${context.request.headers.id-token}" }, ・・・・ AppSyncのCognitoのグループ等を使用した認証が使える上、セッション持続 時間などに制限があるアプリケーションなどのコントロールがしやすい
IAM認証 1. 両方の認証をIAM認証にし、Cognitoの認証済みRoleに“appsync:GraphQL”のポリシー を付与する 2. データソースの設定で下記のようにSigV4の設定を入れておく { "endpoint": " https://abcdefghij.execute-api.ap-northeast-1.amazonaws.com/prod",
"authorizationConfig": { "authorizationType": "AWS_IAM", "awsIamConfig": { "signingRegion": ”ap-northeast-1", "signingServiceName": ”execute-api” } } } 面倒なヘッダー付与等を行わずにリクエストが行える上、Lambdaからのリク エストなどを統一してIAM認証で制御できる
Pipeline Resolverを使用した認証 JWTトークンを使用した認証などを入れたい場合 1. AppSyncの認証をIAM認証で認証した上、JWTトークンの認証用Lambdaをデータソー スとしたファンクションを定義する 2. 実際に使いたいリゾルバーをファンクションとして定義する 3. 2で定義したそれぞれのファンクションの前に、1で定義したファンクションを入れた
Pipeline Resolverを定義する Pipeline Resolverを使用することで、API GatewayのLambdaオーソライザーと 似た形で使用したり、各リゾルバーの前処理・後処理としてノーマライズ等の 処理を入れることができる
Serverless Meetup Japan Virtual #2 X-Rayを使ったモニタリング
Serverless Meetup Japan Virtual #2 X-Rayを使ったモニタリング
Serverless Meetup Japan Virtual #2 まとめ Ø AWS AppSyncはフロントエンドの処理をシンプルにしやすい Ø
各マイクロサービスAPIの手前にAppSyncを置くことで、マイクロサービスに おけるいくつかの課題を解消しやすい Ø Cognitoとの組み合わせで、細かな認証やAPI Gatewayの認証にも使える Ø CloudWatch Logs InsightsやX-Rayなどのサービスも使ってみると捗る
Serverless Meetup Japan Virtual #2 エンジニア募集中 サーバーレスエンジニアを募集中! サーバーレス未経験OK なんならエンジニア未経験OK (一定のプログラミングスキルは必要です)
お気軽にお声がけください Twitter: @k1nakayama Mail:
[email protected]
Accelerate your business with the cloud.