Serverless Meetup Japan Virtual #2 #serverless #AWS #AppSync #serverlessjp
Serverless Meetup Japan Virtual #2Access to multiple microservices on AWS@k1nakayama
View Slide
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 #2AWS AppSync
Serverless Meetup Japan Virtual #2AWS AppSyncØ マネージドなGraphQLサービスØ リアルタイムなデータアクセスØ 様々なデータソースを利用可能Ø きめ細やかなアクセスコントロール
Serverless Meetup Japan Virtual #2GraphQLØ エンドポイントは1つだけØ Query、Mutation、Subscription の3つのオペレーションが行えるØ 1回のクエリに複数のリクエストを含めることができるØ レスポンスに必要な要素を、クライアントが指定可能Ø フィールド毎にクエリを入れ子にできる
Serverless Meetup Japan Virtual #2クエリの例とあるECサイトのユーザープロフィールページに、下記の情報を表示する• ユーザーのプロフィール情報• 直近3件の購入履歴(購入した日付と配送ステータス)このサイトはマイクロサービスで構築されていて、それぞれ下記のAPIから情報を取得可能• User Service: ユーザーのプロフィール情報を管理• Order Service:ユーザーの購入情報を管理• Delivery Service:各注文の配送を管理
Serverless Meetup Japan Virtual #2REST 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 #2REST 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 #2GraphQLの場合POST https://graphql-server/graphqlquery getProfilePageData {getUserProfile(user_id: “12345”) {nameemailregistration_at}getUserOrderHistory(user_id: “12345”, limit: 3) {ordered_atdelivery_info {status}}}※上記は説明のため簡略化してあります
Serverless Meetup Japan Virtual #2GraphQLの場合{“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 #2AppSyncで利用可能なデータソースØ AWS Lambda• この時点でほぼ全てのデータソースに対応可能Ø Amazon DynamoDB• トランザクションにも対応Ø Amazon Elasticsearch ServiceØ Amazon Aurora ServerlessØ HTTP Endpoint• SignatureV4を使用可能なため、各種AWSサービスのAPIを使用可能
Serverless Meetup Japan Virtual #2for Monolith
Serverless Meetup Japan Virtual #2for 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 #2SubscriptionとあるECサイトの決済サービスでは、外部の決済代行サービスに決済をリクエストし、結果は非同期処理でAPIにコールバックされるフロントエンドでは、ユーザーに決済を実行した後、決済ステータスが完了するまで待たせておきたいこの処理に、◯秒毎に結果をポーリングするのではなく、出来る限りリアルタイムに結果を受け取りたい
Serverless Meetup Japan Virtual #2間違った例QueryによってDynamoDBに入れたステータスを得られることから誤解し、DynamoDB上のデータを更新したらそのデータをSubscribe出来ると思いがち
Serverless Meetup Japan Virtual #2正しくはMutationを実行した内容だけがSubscribe可能SubscribeできるデータもMutationの内容と同じなので注意
Serverless Meetup Japan Virtual #2AppSync + 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 #2X-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: @k1nakayamaMail:[email protected]
Accelerate your business with the cloud.