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 Ultimateを用いたDevSecOps実践事例
k1nakayama
0
140
GitLabを活用したDevSecOps
k1nakayama
1
280
GitLabを活用したクラウドネイティブ アプリケーションセキュリティ
k1nakayama
0
130
サーバーレス開発を円滑に進めるための実践DevSecOps
k1nakayama
1
460
大容量データをDynamoDBで扱う際のMomento導入検討
k1nakayama
0
630
Deep Dive on DevOps for Serverless Applications
k1nakayama
0
290
Featured
See All Featured
Unsuck your backbone
ammeep
668
57k
Making Projects Easy
brettharned
115
5.9k
Large-scale JavaScript Application Architecture
addyosmani
510
110k
Why Our Code Smells
bkeepers
PRO
334
57k
Building Your Own Lightsaber
phodgson
103
6.1k
The Pragmatic Product Professional
lauravandoore
31
6.3k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
126
18k
VelocityConf: Rendering Performance Case Studies
addyosmani
325
24k
The Language of Interfaces
destraynor
154
24k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
31
2.7k
Documentation Writing (for coders)
carmenintech
65
4.4k
Code Reviewing Like a Champion
maltzj
520
39k
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.