AWS fsx for windows （自己所有AD）の事前のAD設定メモ
FSXを自己所有のADで作成する際、AD側で何をすれば良いのかが AWSのドキュメントを見ても、いまいち分かりにくかったです。 docs.aws.amazon.com aws.amazon.com 上記を見ながら作業をしてみたところ正常動作でき、 作業をより分かりやすく残しておきたいと思い、 備忘メモとしてブログ化します。
ADの事前設定
ADでOU、グループ、ユーザを作成
まず、AD側の手順として、下記を作成します。
| 設定項目 | 設定値 |
|---|---|
| OU | FileSystems |
| UserName | fsxservice |
| FileSystemAdministratorsGroup | FSXAdmins |
| Password | 適当 |
「dsa.msc」を開く
OUを「FileSystems」で作成します。
FileSystemsの中にユーザ、グループを作成します
その後、上記で作成したOUに権限を移譲します。
作成したOUで右クリックDelegate Controlを選択
「FSXAdmins」を指定
「Create a custom task to delegate」を選択します。
「Only the following objects in the folder」を選択し
「Computer objects」を選択します。
下記2つを選択します。
「Create selected objects in this folder」
「Delete selected objects in this folder」
さらに次の画面で下記を選択します。
- Reset Password
- Read and write Account Restriction
- Validated write to DNS host name
- Validated write to service principal name
以上でAD側の作業は完了です。
fsxを作成する
上記が作成できましたら、fsxを作成します。 cloudformationを作りました。
AWSTemplateFormatVersion: "2010-09-09"
Description: A templete for fsx for windows
Parameters:
EnvPrefix:
Type: String
Default: "test"
# KmsKeyId:
# Type: String
StorageCapacity:
Type: Number
Default : 32
VPCId:
Type: AWS::EC2::VPC::Id
Default: vpc-xxxxxxxxxxx
SubnetIds:
Type: List<AWS::EC2::Subnet::Id>
Default: subnet-xxxxxxxxxxx
DailyAutomaticBackupStartTime:
Type: String
Default: "16:00"
DeploymentType:
Type: String
Default: SINGLE_AZ_2
# Default: MULTI_AZ_1
ThroughputCapacity:
Type: Number
Default : 8
WeeklyMaintenanceStartTime:
Type: String
Default: "6:17:00"
OnpreDNS:
Type: CommaDelimitedList
Default: xxx.xxx.xxx.xxx
OnpreDomainName:
Type: String
Default: fsx-test.local
FileSystemAdministratorsGroup:
Type: String
Default: FSXAdmins
UserName:
Type: String
Default: fsxservice
#本当はパラメータストア等を参照するのが良いです
Password:
Type: String
Default: xxxxxxxxxxxxxx
NoEcho: True
OrganizationalUnitDistinguishedName:
Type: String
Default: "OU=FileSystems,DC=fsx-test,DC=local"
FSXAllowedRange:
Type: String
Default: xx.xx.xx.xx/xx
Resources :
fsx:
Type: AWS::FSx::FileSystem
Properties:
# BackupId: String
# KmsKeyId: kms
# LustreConfiguration:
# LustreConfiguration
FileSystemType: WINDOWS
SecurityGroupIds:
- !Ref sg
StorageCapacity: !Ref StorageCapacity
StorageType: SSD
# StorageType: HDD
# The StorageCapacity specified is not supported. Storage capacity for HDD must be no less than 2000
SubnetIds: !Ref SubnetIds
WindowsConfiguration:
# ActiveDirectoryId: !Ref ActiveDirectoryId
AutomaticBackupRetentionDays: 7
CopyTagsToBackups: true
DailyAutomaticBackupStartTime: !Ref DailyAutomaticBackupStartTime
DeploymentType: !Ref DeploymentType
# PreferredSubnetId: String
SelfManagedActiveDirectoryConfiguration:
DnsIps: !Ref OnpreDNS
DomainName: !Ref OnpreDomainName
FileSystemAdministratorsGroup: !Ref FileSystemAdministratorsGroup
OrganizationalUnitDistinguishedName: !Ref OrganizationalUnitDistinguishedName
Password: !Ref Password
UserName: !Ref UserName
ThroughputCapacity: !Ref ThroughputCapacity
WeeklyMaintenanceStartTime: !Ref WeeklyMaintenanceStartTime
sg:
Type: AWS::EC2::SecurityGroup
Properties:
GroupDescription: !Sub ${EnvPrefix}-sg
GroupName: !Sub ${EnvPrefix}-sg
VpcId: !Ref VPCId
SecurityGroupIngress:
-
CidrIp: !Ref FSXAllowedRange
FromPort: 445
ToPort: 445
IpProtocol: tcp
-
CidrIp: !Ref FSXAllowedRange
FromPort: 5985
ToPort: 5985
IpProtocol: tcp
Tags:
-
Key: Name
Value: FSX
AWS StepFunctions Lambdaを利用する時のTips
Japan APN Ambassador Advent Calendarqiita.com
2020 8 日目のエントリです。
先日、会社でStepFunctionsの利用方法や、
Tipsを説明することがありました。
良い機会なので記事に書いてみようと思いました。
Stepfunctions概要
docs.aws.amazon.com
サーバレスのサービスを組合せて利用する際の
オーケストレーションのサービスです。
具体例をみると分かりやすいかもしれません。
下記の図の各NodeがLambda、SQS等、 各種AWSのサービスを表しており、
それらの処理を組み合わせて定義することが可能です。
Tips
利用し始めるとStepFunctionsならではの
機能や制限があることに後から気付き、
処理を作り直すことが良くありました。
事前に知っておきたかったことを
会社の後輩に伝えたところ割と喜んでくれたので書いていきます。
例外処理、再実行レベルを考慮する
上述のようにStepFunctionsでは
複数のLambdaを組み合わせることができます。
StepfunctionsでもLambda実行時のエラー考慮が必要になります。
Lambdaにはデッドレターキューというエラーの処理方法がありますが、
StepFunctionsのときは、代わりにStepFunctions独自のエラーハンドリングを利用すると便利です。
外部環境により発生した例外の場合
Lambdaでは（コードが正しくても）稀に実行が失敗することがあります。
レート制限エラーや、ネットワーク等の影響による一時的なエラーです。
このような場合は、数秒おいて再実行すれ成功する可能性が高いため
StepfunctionsのRetry機能を利用するのが良いと思います。
docs.aws.amazon.com
具体的には、下記のように特定のLambdaの処理に下記のように
Retryを設定することで、StepfunctionsがLambdaを再実行してくれます。
"Retry": [ {
"ErrorEquals": [ "States.Timeout" ], #このエラーのときに
"IntervalSeconds": 3, #インターバル3秒で
"MaxAttempts": 2, #最大2回再試行
"BackoffRate": 1.5 #再実行の実行回数が増える毎にインターバルの秒数を増やす設定値
} ]
その他の例外の場合
上記以外ですと、
StepFunctionsのcatch機能を利用するのが良いと思います。
例外の内容により、次に実行する処理（Lambda）を制御できます。
docs.aws.amazon.com
具体的には、下記のように特定のLambdaの処理に下記のように
Catchを設定することで、StepfunctionsがLambdaがエラーだったときの
ハンドリングをしてくれます。
"Catch": [ {
"ErrorEquals": ["States.Timeout"], #このエラーのときは
"Next": "fallback" #次にfallbackの処理を実行する
} ],
上記機能を利用し、
Lambda内はエラー処理をごちゃごちゃ書かず
シンプルな状態を保つとメンテナンスしやすいです。
Lambda単位で冪等性を持つように作る
上述のように各Lambdaの再実行設定が容易なため、
Lambda単位で冪等性（何回実行しても同じ結果になる）を
持つようにしておくと
StepFunctionsで利用しやすいです。
Mapやループ処理の際、StepFunctionsを分割する
バッチ処理をStepFunctionsで組む場合、 大量のデータをループ処理または並列処理したいことがあります。
StepFunctionsでは、下記のようにループ処理を書くことや
下記のような並列処理（MAP）の記載が可能です。
ただし、StepFunctionsでは状態間の
データの受け渡し容量が262,144bytesと制限されています。
大量のデータをやりとりする場合は、この制限を超えてしまいます。
StepFunctionsではデータが制限を超える場合、S3等を利用し、
一時的にデータを別場所に保管することが推奨されています。
ただし、S3を利用しデータを受渡すると、
上記のような、ループや並列処理の記述ができません。
そこで、私の場合はStepFunctionsを2つに分けました。
3つ目の処理の中で、大量データを取得し、
データ毎に別のStepFunctionsを実行することで
並列処理が可能でした。
将来的にデータ量が拡張し、制限を超える場合は、
このような記述も良いと思います。
StepFunctionsの実行時の引数を活用する
Stepfunctionsのフロー図を作成すると、
極力それを使いまわしたいと思います。
例えば特定条件のリソースを停止する処理を作成するとします。
毎月末に対象を通知し、毎月初に停止処理を実行する場合
停止をするかしないか以外は、ほぼ同じ処理になります。
そんなとき、StepFunctionsの実行時の引数で処理を分岐すると便利でした。
具体的にはStepFunctions実行時の引数として変数を渡し
その変数によって処理を分岐するイメージです。
さいごに
Japan APN Ambassador Advent Calendarの
記事を書かせて頂き大変光栄でした！
会社を超えて、日々前向きな方達と交流が持てるのは
本当にありがたいです。
コロナ影響が早くなくなって、
もっとリアルでもお会いできるのを楽しみにしています。
AWS ClientVPNの構成図 7パターン
AWSのClientVPNには認証方式が複数あります。
認証方式により、構成やUXが微妙に変わり、その質問をいただくことが多いため、
ユーザ視点でどんな感じになるのかを、7パターンで整理してみたいと思います。
これ以外にも構成パターンはあると思いますが、それらは応用編で、
もし機会があればブログ化してみたいと思います。
構成は、認証方式に依存する形となります。
紹介するパターンは下記です。
- ADオンプレで認証
- AD(AWS managed)で認証
- SAML(Okta)で認証
- ADオンプレ+証明書で認証
- AD(AWS managed)+証明書で認証
- SAML(Okta)+証明書で認証
- 証明書のみで認証
(1)ADオンプレで認証
概要
こんな方向けです。
- 既存のオンプレADを認証情報として利用したい
- 認証はADユーザ/PASSのみでOK
処理の流れ
- クライアントPCがClientVPNのEndpointに接続します
- ADコネクタを通して、ClientVPNとオンプレADでユーザ情報が連携されます
- ADのユーザ情報で認証が実施されます
- ClientVPNが接続可能となります。 クライアントPCはVPC内にあるENI-NATを通じてVPCやオンプレと通信が可能となります
- VPC内のEC2と疎通が可能となります（RouteTableとSGの設定を忘れずに）
- オンプレのサーバと疎通が可能となります（サーバ側の疎通許可設定を忘れずに）
利用イメージ
ユーザが接続する時は下記の操作イメージです。
AWSが提供するClientVPNのソフトを起動します。
ユーザ名、パスワードを入力します
認証に通ると接続されます。
運用考慮点
ADとclientVPNの接続許可設定を連動させることができます 。
（例：特定のOUの人が、xx.xx.xx.xx/xxへの疎通が可能）
その設定を変更する際は、ADとClientVPNの設定を変更する必要があります
(2)AD(AWS managed)で認証
概要
こんな方向けです。
- AWSのマネージドのADを認証情報として利用したい
- 認証はADユーザ/PASSのみでOK
処理の流れ
- クライアントPCがClientVPNのEndpointに接続します
- ADのユーザ情報で認証が実施されます
- ClientVPNが接続可能となります。クライアントPCはVPC内にあるENI-NATを通じてVPCやオンプレと通信が可能となります
- VPC内のEC2と疎通が可能となります（RouteTableとSGの設定を忘れずに）
- オンプレのサーバと疎通が可能となります（サーバ側の疎通許可設定を忘れずに）
運用考慮点
(1)のパターンと同様です。
利用イメージ
(1)のパターンと同様です。
(3)SAML(Okta)で認証
概要
こんな方向けです。
- ID管理サービスを認証情報として利用したい（ADと紐付け不要、ADの管理したくない場合）
- 認証はID管理サービスのログインでOK
処理の流れ
- クライアントPCがClientVPNのEndpointに接続します
- ID管理サービス（Okta）のユーザ情報で認証が実施されます
- ClientVPNが接続可能となります。クライアントPCはVPC内にあるENI-NATを通じてVPCやオンプレと通信が可能となります
- VPC内のEC2と疎通が可能となります（RouteTableとSGの設定を忘れずに）
- オンプレのサーバと疎通が可能となります（サーバ側の疎通許可設定を忘れずに）
利用イメージ
ユーザが接続する時は下記の操作イメージです。
AWSが提供するClientVPNのソフトを起動します。
Oktaでの認証を求められるためid/passでログインします。
Oktaの認証に通るとclientVPNに接続可能となります。
利用イメージ(ユーザ管理)
Oktaでのユーザ管理は下記イメージです。
私も初めてOktaを利用したのですが、特に迷うことなく直感的に操作できました。
ユーザ管理画面です。
ユーザ登録画面です。
(4)ADオンプレ+証明書で認証
概要
こんな方向けです。
- 既存のオンプレADを認証情報として利用したい
- 認証はADユーザ/PASSとクライアント証明書による2要素の認証をしたい
処理の流れ
- クライアントPCがClientVPNのEndpointに接続します
- クライアントの持つ証明書が正しいことを確認します
- ADコネクタを通して、ClientVPNとオンプレADでユーザ情報が連携されます
- ADのユーザ情報で認証が実施されます
- ClientVPNが接続可能となります。クライアントPCはVPC内にあるENI-NATを通じてVPCやオンプレと通信が可能となります
- VPC内のEC2と疎通が可能となります（RouteTableとSGの設定を忘れずに）
- オンプレのサーバと疎通が可能となります（サーバ側の疎通許可設定を忘れずに）
運用考慮点
(1)に加えて証明書、認証局の管理が必要となります。
クライアント証明書を紛失した場合や、追加の証明書を発行したい場合等、
一般的な認証局の運用が発生します。
また、クライアント証明書を利用者に配布する必要があり、
証明書周りの運用が割と手間です。
利用イメージ
(1)のパターンと同様です。
(5)AD(AWS managed)+証明書で認証
概要
こんな方向けです。
- AWSのマネージドのADを認証情報として利用したい
- 認証はADユーザ/PASSとクライアント証明書による2要素の認証をしたい
処理の流れ
- クライアントPCがClientVPNのEndpointに接続します
- ADのユーザ情報で認証が実施されます
- クライアントの持つ証明書が正しいことを確認します
- ClientVPNが接続可能となります。クライアントPCはVPC内にあるENI-NATを通じてVPCやオンプレと通信が可能となります
- VPC内のEC2と疎通が可能となります（RouteTableとSGの設定を忘れずに）
- オンプレのサーバと疎通が可能となります（サーバ側の疎通許可設定を忘れずに）
運用考慮点
(1)に加えて証明書、認証局の管理が必要となります。
クライアント証明書を紛失した場合や、追加の証明書を発行したい場合等、
一般的な認証局の運用が発生します。
また、クライアント証明書を利用者に配布する必要があり、
証明書周りの運用が割と手間です。
利用イメージ
(1)のパターンと同様です。
(6)SAML(Okta)+証明書で認証
概要
こんな方向けです。
- ID管理サービスを認証情報として利用したい（ADと紐付け不要）
- 認証はID管理サービスのユーザ/PASSとクライアント証明書による2要素の認証をしたい
処理の流れ
- クライアントPCがClientVPNのEndpointに接続します
- ID管理サービス（Okta）のユーザ情報で認証が実施されます
- クライアントの持つ証明書が正しいことを確認します
- ClientVPNが接続可能となります。クライアントPCはVPC内にあるENI-NATを通じてVPCやオンプレと通信が可能となります
- VPC内のEC2と疎通が可能となります（RouteTableとSGの設定を忘れずに）
- オンプレのサーバと疎通が可能となります（サーバ側の疎通許可設定を忘れずに）
運用考慮点
(3)に加えて証明書、認証局の管理が必要となります。
クライアント証明書を紛失した場合や、追加の証明書を発行したい場合等、
一般的な認証局の運用が発生します。
また、クライアント証明書を利用者に配布する必要があり、
証明書周りの運用が割と手間です。
利用イメージ
(3)のパターンと同様です。
(7)証明書のみで認証
概要
こんな方向けです。
- 認証はクライアント証明書のみでOK
処理の流れ
- クライアントPCがClientVPNのEndpointに接続します
- クライアントの持つ証明書が正しいことを確認します
- ClientVPNが接続可能となります。クライアントPCはVPC内にあるENI-NATを通じてVPCやオンプレと通信が可能となります
- VPC内のEC2と疎通が可能となります（RouteTableとSGの設定を忘れずに）
- オンプレのサーバと疎通が可能となります（サーバ側の疎通許可設定を忘れずに）
運用考慮点
証明書、認証局の管理が必要となります。
クライアント証明書を紛失した場合や、追加の証明書を発行したい場合等、
一般的な認証局の運用が発生します。
また、クライアント証明書を利用者に配布する必要があり、
証明書周りの運用が割と手間です。
利用イメージ
特にユーザ/パスワードを入力することなく接続が可能です
どのパターンが良いのか
まず最初に認証がユーザ/パスワードのみで良いかを考えると良いかと思います。
ユーザ/パスワードのみの認証で十分な場合には(1)(2)(3)が候補です。
(1)(2)(3)は既存でADを利用しているかどうかで決めると良いと思います。
Enterpriseでセキュリティが厳しい場合は、
ユーザ/パスワードと証明書による認証で(4)(5)(6)が候補です。
(4)(5)(6)は既存でADを利用しているかどうかで決めると良いと思います。
(7)は現実的に利用する方は少ないと思います。
上記をまとめるにあたり、初めてOktaを利用してみたのですが、
個人的にはOktaがかなり使いやすく、Oktaおすすめです。
小規模の会社で、試しにClientVPNを利用してみるぐらいでしたら
パターン(3)が良いのではと思います。
証明書は、セキュリティ強度は上がると思うのですが、
人件費等の作業コストがかかることを考えると
Oktaのようなサービス利用料の方が
トータルで安くなるのかと思います。
AWS SSOでGsuiteと連携した
会社でGsuiteを利用しており、AWSとSSO連携させてみました。
微妙にdocumentが分かりにくかったので、作業内容をブログ化してみました。
Gsuite側
まずは、Gsuite側の作業から入ります。
Gsuiteの管理者コンソールにログインする必要がありますので、
事前に管理者権限を割り当ててもらう必要があります。
ここでは、管理者コンソールにログインした前提で進めます。
IDPメタデータをダウンロードしておきます。
AWS側
今度は、AWS SSO側で作業します。
こちらで、先ほどGsuiteでダウンロードしたファイルをアップロードします。
ここで3つのURLを控えておきます。
Gsuite側
上記で控えたURL3つをGsuite側の設定に書き込みます。
AWS側
上記を終えたらまたAWS側に戻ります。
ここで、ユーザ名はgoogleのメールアドレスである必要があります。
（そうでないと後々エラーとなる。私はそれでハマりました）
ここで、SSOでログインした際に所有させたい権限を選択します。
良くあるものはawsが定義してくれており、
カスタマイズが必要な場合は自作もできます。
Gsuite側
最後にGsuite側で、ログイン可能とすべく、権限を特定ユーザor全員に開放します。
ログインイメージ
SSOのログイン画面にアクセスすると、下記のような画面が開きます
ここで、上記で設定した権限の一覧が出てくるので、ログインしたい権限で
Management consoleをクリックすると画面遷移できます。
また、クレデンシャルも払い出してくれます。
Tips
上記を試すまで下記が気になっていたので、試してみました。
Q：SSOでログイン後に、さらにスイッチロールは可能か？
A：可能でした
Q：Organization外のAWSアカウントにSSOから直接遷移することは可能か？
A：可能です。ただし受け側で下記作業が必要です。
static.global.sso.amazonaws.com
Q：cloudtrailにユーザ名はどのように残るのか
A：ユーザ名(メールアドレス)で残ります
オンプレからAWS RDSへの移行方法まとめ
オンプレからAWS(RDS)への移行方法をまとめてみました。
AWS Database Specialityの勉強をする過程で、
何かとまとめておくと、後々便利と思い自分のメモにしていたのですが、きれいにしたので公開してみます。
RDSの種類 * 移行方式の数があるのでかなりの量がありますね。
AWS AuroraのレプリカAutoscalingを時間指定で増減させる
Auroraのリードレプリカ数をAutoscalingできます。
時間指定でもできるのか試してみました。
結論を言うとできます。
AWS コンソールではCPU使用率、または接続数でスケールする設定しか
できないようなのですが、基本はなんでもできそうです。
autoscaling設定をした後に
CLIでcron形式で試してみたら普通にできました。
aws application-autoscaling put-scheduled-action \ --service-namespace rds \ --schedule "cron(50 * * * ? *)" \ --scheduled-action-name 'achaction' \ --resource-id 'cluster:test-xxxx-aurora-cluster' \ --scalable-dimension rds:cluster:ReadReplicaCount \ --scalable-target-action 'MinCapacity=1,MaxCapacity=1'
スケジュール削除もCLIで簡単にできます
aws application-autoscaling delete-scheduled-action \ --service-namespace rds \ --scheduled-action-name achaction \ --scalable-dimension rds:cluster:ReadReplicaCount \ --resource-id cluster:test-xxxx-aurora-cluster
AWS Appsync(GraphQL)の概要をRDB慣れした人向けに説明してみます
AWS Appsync(GraphQL)のDynamoDBチュートリアルを触ってみました。
チュートリアル : DynamoDB リゾルバー - AWS AppSyncdocs.aws.amazon.com
私はインフラよりの仕事が中心なので
多くのエンジニアと同じくRDBを触ったことがあるのですが、
GraphQLには馴染みがありませんでした。
と言うかGraphQL自体を初めて触りました。
そこで、同じ立場の人もいると思い、
RDBの感覚を含めてGraphQLの理解を書いてみたいと思います。
間違ってたらコメント頂けるとありがたいです。
GraphQLは何が良いのか
REST形式のAPIでは、一般的なアプリケーションで下記のようなことがありました。
* 欲しいレスポンスに応じてエンドポイントを複数用意する
* エンドポイント毎にリクエスト方式や、レスポンス内容等を理解する必要がある
* レスポンス内の一部の情報しか必要なくても決められた情報が全部返ってくる
GraphQLではこれらの点が改善されて使いやすくなっています。
* エンドポイントは1つのみ
* 欲しい情報のみをリクエストし取得できる
この違いを知ったときに、これってRDBに感覚近いのではと思いました。
上記以外にもまだまだメリットや変化点はあると思いますが、
詳しくはGraphQLのドキュメントを参照です。
簡単な例
こんな風にクエリを書いて
{
me {
name
}
}
こんなレスポンスをもらえると言う感じです。
{
"me": {
"name": "Luke Skywalker"
}
}
各用語の整理
GraphQLのマネージドサービスであるAppsyncの概要を整理してみます。
各用語の説明は下記です。
GraphQL スキーマ
GraphQLで受け入れ可能なスキーマを定義します。
RDBとかでいうところのテーブル定義に近いと思います。
SQLでも存在しないテーブルにSelectしようとしたり、
key項目なしでInsertしようとしたらエラーになるように、
GraphQLでの受入可能なクエリを定義します。
データソース
データソースは、GraphQL API で操作できる AWS アカウント内のリソースです。
AWS AppSync は、AWS Lambda、Amazon DynamoDB、
リレーショナルデータベース (Amazon Aurora Serverless)、
Amazon Elasticsearch Service、HTTP エンドポイントを
データソースとしてサポートしています
RDBで例えて言うと、各テーブルやviewでしょうか。
何の情報を、どのオブジェクトに持たせるのかを整理します。
リゾルバー
GraphQL スキーマとデータソースの関連づけを定義します。
どのリクエストを、どのデータソースと紐付けるかを設定します。
ここはRDBでうまく例えられませんでした。
新しい考え方として認識頂いた方が早いかもしれません。
多分リゾルバーが１番イメージの沸きにくいところなので、実際の設定画面をみてみます。
この画面左がスキーマです。右側にResolverとありますが、ここの「アタッチ」ボタンで
各スキーマとデータの紐付けを設定します。
この画面でデータソースを選択します。
リクエストマッピングテンプレートで、リクエストデータとスキーマをどのように紐付けるかを定義します。
レスポンスマッピングテンプレートでレスポンスデータとスキーマをどのように紐付けるかを定義します。
リクエスト実行の流れ
まだ分かりにくいと思いますのでリクエストを実行してみます。
Appsyncの画面からリクエストを実行可能なので流してみます。
ここではMutation(書き込みとそれに続く取得。RDBのinsert+selectに近い)を試してみます
リクエスト
mutation addPost {
addPost(
id: 123
author: "AUTHORNAME"
title: "Our first post!"
content: "This is our first post."
url: "https://aws.amazon.com/appsync/"
) {
id
author
title
content
url
ups
downs
version
}
}
クライアントが上記のaddPostと言うクエリを投げます。
type Mutation {
addPost(
id: ID!,
author: String!,
title: String!,
content: String!,
url: String!
): Post!
}
type Post {
id: ID!
author: String
title: String
content: String
url: String
ups: Int!
downs: Int!
version: Int!
}
type Query {
getPost(id: ID): Post
}
schema {
query: Query
mutation: Mutation
}
スキーマで、送られてきたMutationのaddPostが含まれているかを確認します。
上記では定義されているため、AppsyncはaddPostを受入可能です。
マッピングテンプレート
{
"version" : "2017-02-28",
"operation" : "PutItem",
"key" : {
"id" : $util.dynamodb.toDynamoDBJson($context.arguments.id)
},
"attributeValues" : {
"author" : $util.dynamodb.toDynamoDBJson($context.arguments.author),
"title" : $util.dynamodb.toDynamoDBJson($context.arguments.title),
"content" : $util.dynamodb.toDynamoDBJson($context.arguments.content),
"url" : $util.dynamodb.toDynamoDBJson($context.arguments.url),
"ups" : { "N" : 1 },
"downs" : { "N" : 0 },
"version" : { "N" : 1 }
}
}
まずは、Mutationを受け取り、リクエスト内容を読み替えます。
$util.dynamodb.toDynamoDBJson：
DynamoDB用のJSONにエンコードしてくれる便利な書き方
$context.arguments：
リクエスト内容を参照する、RDBで言うプレースホルダ的な書き方
{
"version" : "2017-02-28",
"operation" : "PutItem",
"key" : {
"id" : { "S" : "123" }
},
"attributeValues" : {
"author": { "S" : "AUTHORNAME" },
"title": { "S" : "Our first post!" },
"content": { "S" : "This is our first post." },
"url": { "S" : "https://aws.amazon.com/appsync/" },
"ups" : { "N" : 1 },
"downs" : { "N" : 0 },
"version" : { "N" : 1 }
}
}
そして、Appsyncがリクエストマッピングテンプレートの定義に従い
GraphQLの形として下記に変換させます
上記では、operationがPutItemになっていますので
下記の内容がDynamoへのPutItemとして実行されます。
{
"id" : "123",
"author": "AUTHORNAME",
"title": "Our first post!",
"content": "This is our first post.",
"url": "https://aws.amazon.com/appsync/",
"ups" : 1,
"downs" : 0,
"version" : 1
}
そしてレスポンスマッピングテンプレートに
定義された項目がレスポンスとして返します。
下記は、そのまま返すの意味です。
$utils.toJson($context.result)
上記Mutationの流れにより、
DynamoへのPutItemが実行され、またその結果を得ることができます。
リクエスト側は、欲しい情報のみを記載するのと、
エンドポイントが複数にバラけないのが
フロントエンド側の実装としては嬉しいですね。
チュートリアルは、上記以外ににも、データをDeleteするパターンとかがあり 非常に分かりやすく纏まっていますので、ぜひ気になる方は試してみてください。
