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するパターンとかがあり 非常に分かりやすく纏まっていますので、ぜひ気になる方は試してみてください。
AWS Cloudwatch Synthetics GUIワークフロービルダーを使ってみる
AWS Cloudwatch Syntheticsで先日記事を書いてみたのですが、
「GUIワークフロービルダー」なる機能があったので使ってみました。
機能概要
サイトの動作確認等に利用が可能です。
サイト死活監視に加え、自動テストのようなイメージで
検索ボックスに「xxx」を入れて「検索」ボタンを押下して・・・・
といった感じで、サイトの監視＋動作確認を実施する機能です。
感覚としてはseleniumに近いです。
テストのシナリオ
今回は、下記シナリオで動作テストをしてみました。
- Amazonのサイト（https://www.amazon.co.jp/）を訪問
- 検索ボックスに「AWS」と入力する
- 検索ボタンを押下する
設定方法
Canaryを作成で、GUIワークフロービルダを選択します。
Amazonのwebサイトで、各要素のidを調べておきます。
各セレクタの項目が下記と分かります。
[id='twotabsearchtextbox']
[id='nav-search-submit-text']
こちらをCanaryの設定に入力します。
テキストを入力で「[id='twotabsearchtextbox']」とし、テキストを「aws」
クリックで「[id='nav-search-submit-text']」とします。
上記でCanaryを作成します。
結果確認
しばらくすると作成が成功します。
Cloudwatch Synthetics画面下部のスクリーンショットを確認します。
各画像を確認すると、きちんと設定した通りのスクリーンショットが作成されていました。
Amazonのサイト（https://www.amazon.co.jp/）を訪問
検索ボックスに「AWS」と入力する
検索ボタンを押下する
まとめ
AWS Cloudwatch Synthetics では、
上記のような複雑な動きの監視設定も可能になりました。
これらを1回だけ利用することもできるので、
単純に簡単なテストとしても利用可能かと思います。
使い方が広がりますね。
AWS Cloudwatch Syntheticsを試してみる（Route53との違い）
CloudwatchにSyntheticsの新機能が追加されたので使ってみました。
サイトの死活監視が可能なようで、
Route53のHealthCheckと少し被っているのかと思ったのですが、
Route53よりも、より詳細なリクエストを送ることが可能なようです。
まずはベーシックなハートビートのモニタリングを動かしてみました。
機能概要
ハートビートのモニタリングでは、
指定したURLへのリクエストが成功するかを検証します。
いわゆるサイトの死活監視です。
設定方法
対象のURLをAmazonのサイトにしてみます。
https://www.amazon.co.jp/
URLの欄を入力するとスクリプトに反映されるようです。
こちらで作成し、2~3分ほど待ちます。
作成されると裏側でS3やLambdaが自動生成されるようです。
多分裏ではcloudformation(SAM)が動いているっぽいですね。
実行後のイメージ
実行後に下記アウトプットが取得できました。
HARファイル
ログ
自動生成されたスクリプトが実行された際のログが出力されるようです。
S3へのエビデンス保存
さらに、上記がS3に保存されているため、過去に遡ってスクリーンショットを見ることができます。
aws s3 ls s3://cw-syn-results-xxxxxxx-ap-northeast-1/canary/www-amazon-co-jp-f81-bf25b112823a/successes/2020/05/03/14/05-37-778/ 2020-05-03 23:05:39 1265313 00-loaded-loaded.png 2020-05-03 23:05:39 105985 2020-05-03T14-05-19-265Z-log.txt 2020-05-03 23:05:39 678506 results.har.html
Route53との違い
Route53ヘルスチェックの死活監視との主な違いは下記かと思いました。
Route53のメリット
- 複数拠点から死活監視が可能
- 複数拠点からのリクエスト成功率を統計的に判断材料としている
Syntheticsのデメリット
Syntheticsは単一リージョンのLambdaからの死活監視なので、
例えば対象リージョンのLambdaに障害があった場合が心配です。
死活監視としては信頼性に弱みがあるかと思いました。
AWS clientVPN 分割トンネル(split-tunnel)とは何か
AWS Client_vpnで分割トンネル(split-tunnel)と言う設定項目があったのですが
ドキュメントを読んだだけだと動作がよく分からなかったので調べてみました。
AWS Client VPN エンドポイントの分割トンネル - AWS Client VPN
デフォルトでは、AWS Client VPN エンドポイントがある場合、すべてのクライアントトラフィックは AWS Client VPN トンネル経由でルーティングされます。AWS Client VPN エンドポイントで分割トンネルを有効にすると、AWS Client VPN エンドポイントルートテーブル上のルートが AWS Client VPN に接続されているデバイスにプッシュされます。
構成図
上記構成を例に、有効時、無効時の動きを試してみました。
・ClientVPNで0.0.0.0/0のルーティングを設定済み
・クライアントではインターネットアウト(0.0.0.0/0)のルーティングを持つ
Your PCの部分は、自宅のPCとかだとお考えください。
split-tunnel無効時
下記2つが存在する場合、(1)が優先されます。
上図の構成例では、インターネット(0.0.0.0/0)への経路が重複します。
split-tunnel無効時には(1)が優先され
下記の赤線経路でインターネットへアクセスが行われます。
(1)ClientVPNで設定したルートテーブル
(2)接続クライアントが持つルートテーブル
split-tunnel無効時に、ClientVPNに接続したPCのnetstat結果は下記です。
defaultのルートに上書きして172.25.0.1宛てのルートがあることが分かります。
netstat -r Routing tables Internet: Destination Gateway Flags Netif Expire 0/1 172.25.0.1 UGSc utun2 default 192.168.10.1 UGSc en0
split-tunnel有効時
下記2つが存在する場合、(2)が優先されます。
上図の構成例では、インターネット(0.0.0.0/0)への経路が重複します。
split-tunnel有効時には(2)が優先され
下記の赤線経路でインターネットへアクセスが行われます。
(1)ClientVPNで設定したルートテーブル
(2)接続クライアントが持つルートテーブル
split-tunnel有効時に、ClientVPNに接続したPCのnetstat結果は下記です。
上記と比較し、default（192.168.10.1）となっていることが分かります。
netstat -r Routing tables Internet: Destination Gateway Flags Netif Expire default 192.168.10.1 UGSc en0 172.25/27 172.25.0.2 UGSc utun2
何が良いのか
では、分割トンネル(split-tunnel)を有効化しておく利点は
無駄な通信を発生させずに済むところです。
利用者観点では下記です。
・無駄にAWSのNW利用料が発生しない（低コスト）
・無駄なNetworkを経由しない（速度）
ただ、会社の規約等で通信経路を統一させる必要がある場合や、
ルーティングを強制させたい場合は無効化させておく必要がありそうです。
個人的な考えとしては、特に要件が厳しくなければ有効化させた方が良いと思います。
