- 投稿日：2021-06-13T21:42:34+09:00
TerraformとCognitoとVue.jsで認証機能付きサーバレスWebアプリを構築する
はじめに 記事タイトルの通り、CognitoはWebアプリ等の認証機能をサーバレスでお手軽に作ることができる。 では、実際どれくらいお手軽に作れるかを試してみよう。 なお、Cognito自体はお手軽なものの、Webアプリの基本の部分は結構使うことになる。 過去、記事でまとめた基本要素は、記事中に都度リンクを貼るので、今回は詳しくは説明しない。 前提となる基本知識としては以下だ。 Vue.jsの基本 API GatewayにおけるCORSの対応 S3の静的コンテンツのウェブサイトホスティングの基本 やりたいこと＆構成図 今回はシンプルに作るため、未認証時にはログイン画面を表示し、あらかじめCognitoに登録しているユーザIDで認証をしたら、該当ユーザの情報をDynamoDBから取得して画面に表示するといった簡単なアプリにする。 これを、以下のような構成で作っていく。 ①静的コンテンツ 静的コンテンツは、S3のウェブサイトホスティング機能を使う。 今回やりたいことからすると必須ではないが、CloudFrontを使ってS3のPrivateの状態のまま使えるようにしておこう。 このあたりの設定方法は、以下の記事を参考にしていただきたい。 S3の静的WebサイトホスティングをCloudFrontでキャッシュしてみる 今回のコンテンツは、 サインイン後のコンテンツ: index.html 上記のWebアプリ定義: app.js サインイン用のコンテンツ: signin.html 上記のWebアプリ定義: signin.js とする。Vue.js使うのにシングルページじゃないのかよ！というツッコミは無用で……。 簡易に対応するために、CDN版のVue.jsを使っている。 なお、あまり参考にならないかもしれないが、Vue.jsの基本は以下の記事あたりで解説している。 EC2作成直後の状態から最速でVue.js(CDN版)のWebサイトを立ち上げる サインイン後のコンテンツ index.html <html> <head> <style> [v-cloak] { display: none } </style> <meta charset="utf-8"> <title>Cognitoお試し</title> </head> <body> <div id="myapp"> <table border="1" v-if="employee_info" v-cloak> <tr><th>id</th><th>name</th><th>age</th></tr> <tr v-for="item in items"><td>{{ item['id'] }}</td><td>{{ item['name'] }}</td><td>{{ item['age'] }}</td></tr> </table> </div> <!-- Vue.js/axios を読み込む --> <script src="https://cdn.jsdelivr.net/npm/vue/dist/vue.js"></script> <script src="https://cdn.jsdelivr.net/npm/axios/dist/axios.js"></script> <script src="https://cdn.jsdelivr.net/npm/aws-sdk/dist/aws-sdk.js"></script> <script src="https://cdn.jsdelivr.net/npm/amazon-cognito-identity-js/dist/amazon-cognito-identity.js"></script> <script src="app.js"></script> </body> </html> これ自体は特別なことはしていない。 この後使う機能で、AWSとCognitoのSDKを使うことになるので、上記のようにCDNからそれぞれロードしておく。 app.js const app = new Vue({ el: '#myapp', data: function () { return { employee_info: false, items: null, token: '', cognito_userdata: {} } }, created: function () { AWS.config.region = 'ap-northeast-1' AWS.config.credentials = new AWS.CognitoIdentityCredentials({ IdentityPoolId: '${cognito_identity_pool_id}' }) const poolData = { UserPoolId: '${cognito_user_pool_id}', ClientId: '${cognito_user_pool_client_id}' } const userPool = new AmazonCognitoIdentity.CognitoUserPool(poolData) const cognitoUser = userPool.getCurrentUser() if (cognitoUser == null) { window.location.href = 'signin.html' } else { cognitoUser.getSession((err, session) => { if (err != null) { console.log(err) window.location.href = 'signin.html' } else { this.token = session.idToken.jwtToken cognitoUser.getUserAttributes((err, result) => { if (err) { console.log(err) window.location.href = 'signin.html' } else { for (let i = 0; i < result.length; i++) { this.$set(this.cognito_userdata, result[i].getName(), result[i].getValue()) } axios .get('${apigateway_invoke_url}/employee', { headers: { Authorization: this.token }, params: { id: this.cognito_userdata['custom:id'] } }) .then(response => { this.items = response.data this.employee_info = true }) } }) } }) } } }) app.$mount('#myapp') さて、ここではSDKを使いまくっている。 まずは、以下の部分で接続の設定を行う。 IdentityPoolId は②で取得するのでそこで解説する。なお、都度コンテンツを書き直すのは面倒なので、${cognito_identity_pool_id} の部分は、Terraformのtemplate_fileを使って、作成したリソースを参照した値で置換してS3にアップロードするようにしておくと楽で良い。 AWS.config.region = 'ap-northeast-1' AWS.config.credentials = new AWS.CognitoIdentityCredentials({ IdentityPoolId: '${cognito_identity_pool_id}' }) 次に、認証状態の確認だ。 認証ができていると、AmazonCognitoIdentity.CognitoUserPool() でCognitoのユーザプールを参照し、ユーザプールに接続している現在のユーザの情報をuserPool.getCurrentUser() で取得する。 未認証の場合は、この戻り値がnullになるため、それをハンドリングすることで、認証時と未認証時の動作を振り分けることが可能だ。 今回は、未認証の場合は、signin.htmlを表示するようにしている。 なお、${cognito_user_pool_id}と${cognito_user_pool_client_id}もTerraformのtemplate_fileで参照を行うと楽だ。 const poolData = { UserPoolId: '${cognito_user_pool_id}', ClientId: '${cognito_user_pool_client_id}' } const userPool = new AmazonCognitoIdentity.CognitoUserPool(poolData) const cognitoUser = userPool.getCurrentUser() if (cognitoUser == null) { window.location.href = 'signin.html' } else { さて、認証ができていた場合は、getSession() でセッション情報を取得できる。 セッション情報には、CognitoのIDトークン、アクセストークン、リフレッシュトークンが入っている。APIアクセスではIDトークンが必要になるので、session.idToken.jwtTokenをdataのトークン情報に入れておこう。 cognitoUser.getSession((err, session) => { if (err != null) { console.log(err) window.location.href = 'signin.html' } else { this.token = session.idToken.jwtToken さらに、getUserAttributes()でトークンに入っているユーザ情報から属性を取り出すことができる。 resultはJSON形式ではないので、ここで使いやすくJSON形式にしておいてあげよう。 cognitoUser.getUserAttributes((err, result) => { if (err) { console.log(err) window.location.href = 'signin.html' } else { for (let i = 0; i < result.length; i++) { this.$set(this.cognito_userdata, result[i].getName(), result[i].getValue()) } 最後に、ここで取得したトークンとユーザIDをAPIに送ることで、認証後のコンテンツの画面を表示することが可能だ。 サインイン用のコンテンツ signin.html <html> <head> <style> [v-cloak] { display: none } </style> <meta charset="utf-8"> <title>Cognitoサインインお試し</title> </head> <body> <div id="myapp"> <div> <input type="text" v-model="cognito_id" placeholder="ID"> </div> <div> <input type="text" v-model="cognito_pwd" placeholder="パスワード"> </div> <button v-on:click="signin" v-bind:disabled="is_invalid">サインイン</button> </div> <!-- Vue.js/axios を読み込む --> <script src="https://cdn.jsdelivr.net/npm/vue/dist/vue.js"></script> <script src="https://cdn.jsdelivr.net/npm/aws-sdk/dist/aws-sdk.js"></script> <script src="https://cdn.jsdelivr.net/npm/amazon-cognito-identity-js/dist/amazon-cognito-identity.js"></script> <script src="signin.js"></script> </body> </html> signin.js const app = new Vue({ el: '#myapp', data: { cognito_id: '', cognito_pwd: '', is_invalid: true }, watch: { cognito_id: function (newVal, oldVal) { this.is_invalid = (newVal.length === 0 && this.cognito_pwd.length) }, cognito_pwd: function (newVal, oldVal) { this.is_invalid = (newVal.length === 0 && this.cognito_id.length) } }, methods: { signin: function () { AWS.config.region = 'ap-northeast-1' AWS.config.credentials = new AWS.CognitoIdentityCredentials({ IdentityPoolId: '${cognito_identity_pool_id}' }) const poolData = { UserPoolId: '${cognito_user_pool_id}', ClientId: '${cognito_user_pool_client_id}' } const userPool = new AmazonCognitoIdentity.CognitoUserPool(poolData) const authenticationData = { Username: this.cognito_id, Password: this.cognito_pwd } const authenticationDetails = new AmazonCognitoIdentity.AuthenticationDetails(authenticationData) const userData = { Username: this.cognito_id, Pool: userPool } const cognitoUser = new AmazonCognitoIdentity.CognitoUser(userData) cognitoUser.authenticateUser(authenticationDetails, { onSuccess: function (result) { window.location.href = 'index.html' }, onFailure: function (err) { console.log(err) } }) } } }) app.$mount('#myapp') `` こちらも app.js 同様に、 ```Javascript AWS.config.region = 'ap-northeast-1' AWS.config.credentials = new AWS.CognitoIdentityCredentials({ IdentityPoolId: '${cognito_identity_pool_id}' }) const poolData = { UserPoolId: '${cognito_user_pool_id}', ClientId: '${cognito_user_pool_client_id}' } const userPool = new AmazonCognitoIdentity.CognitoUserPool(poolData) でユーザプールにアクセスする。 その後、以下のようにして認証を行い、成功時は元のコンテンツに飛ばすようにすれば良い。 const authenticationData = { Username: this.cognito_id, Password: this.cognito_pwd } const authenticationDetails = new AmazonCognitoIdentity.AuthenticationDetails(authenticationData) const userData = { Username: this.cognito_id, Pool: userPool } const cognitoUser = new AmazonCognitoIdentity.CognitoUser(userData) cognitoUser.authenticateUser(authenticationDetails, { ②ユーザ認証 さて、ここからが本番のCognitoのTerraformの記述となる。 まずは、以下のようにユーザプールを作成する。 IDについては、sub という払い出しIDが作成されるが、自分で払い出したい場合は以下のように schema で定義しよう。 なお、developer_only_attribute を true にすると、トークン情報に入らなくなるので注意しよう。 また、自分で定義したスキーマ情報については、custom:id といったかたちでトークン情報に入るため、注意しよう。 ```HCL resource "aws_cognito_user_pool" "example" { name = local.cognito_userpool_name schema { name = "id" attribute_data_type = "String" developer_only_attribute = false mutable = true required = false string_attribute_constraints { min_length = 5 max_length = 5 } } } 今回は、以下のようにCLIを使ってあらかじめユーザを払い出しておくようにする。 id は、この後定義する DynamoDB に合わせておく。 locals { cognito_users = [ { "user_name" = "sampleuser00001@google.com", "id" = "00001" }, { "user_name" = "sampleuser00002@google.com", "id" = "00002" }, { "user_name" = "sampleuser00003@google.com", "id" = "00003" }, { "user_name" = "sampleuser00004@google.com", "id" = "00004" }, { "user_name" = "sampleuser00005@google.com", "id" = "00005" }, ] } resource "null_resource" "create_user" { depends_on = [aws_cognito_user_pool.example] for_each = { for cognito_user in local.cognito_users : cognito_user.id => { user_name = cognito_user.user_name id = cognito_user.id } } provisioner "local-exec" { command = <<-EOF aws cognito-idp admin-create-user --user-pool-id ${aws_cognito_user_pool.example.id} --username ${each.value.user_name} --user-attributes Name=custom:id,Value=${each.value.id} && aws cognito-idp admin-set-user-password --user-pool-id ${aws_cognito_user_pool.example.id} --username ${each.value.user_name} --password Pass1234! --permanent EOF on_failure = fail } } 次に、クライアント(アプリ情報)の登録をする。 ここで払い出されたクライアントIDと、IDプールが、先ほどのVue.js内で設定した情報とリンクするのである。 なお、aws_cognito_user_pool_clientのsupported_identity_providers は、他のIdPも指定可能だが、今回はCognitoの機能を利用するため以下の通りとする。OpenID2.0の認証をするためには、以下の通り設定しておけば良い。 resource "aws_cognito_user_pool_client" "example" { user_pool_id = aws_cognito_user_pool.example.id name = local.cognito_client_name supported_identity_providers = ["COGNITO"] allowed_oauth_flows_user_pool_client = true allowed_oauth_flows = ["implicit"] allowed_oauth_scopes = ["openid"] explicit_auth_flows = [ "ALLOW_CUSTOM_AUTH", "ALLOW_REFRESH_TOKEN_AUTH", "ALLOW_USER_SRP_AUTH", ] callback_urls = ["https://${aws_cloudfront_distribution.s3_contents.domain_name}/"] } resource "aws_cognito_identity_pool" "example" { identity_pool_name = local.cognito_idpool_name allow_unauthenticated_identities = true allow_classic_flow = false cognito_identity_providers { client_id = aws_cognito_user_pool_client.example.id provider_name = aws_cognito_user_pool.example.endpoint } } ③API アクセス APIアクセス特に難しいことはしていない。 今回は、GETリクエストを飛ばしてくるので、Lambda側でCORSの対応が必要なのと、Chromeは今回のアクセスパターンでもOPTIONSのプリフライトリクエストを飛ばしてきたので、モック統合を使って処理できるようにしておこう。 モック統合によるOPTIONSメソッドのCORS対応は、以下の記事を参照。 Amazon API GatewayでサクッとCORS対応する また、Lambdaは以下のようにPythonでテキトーに定義した。 DynamoDBのテーブル名とCORSのオリジン名は、環境変数で渡して書き換え不要にしてある。 import os import json import boto3 from boto3.dynamodb.conditions import Key dynamodb = boto3.resource('dynamodb') table = dynamodb.Table(os.environ['DYNAMODB_TABLE_NAME']) def get_item(id): try: response = table.query( KeyConditionExpression=Key('id').eq(id) ) return response['Items'] except Exception as error: print(error) raise Exception('DynamoDB Error') def lambda_handler(event, context): print(event) status_code = 200 items = {} try: event['queryStringParameters']['id'] except: status_code = 400 if status_code == 200: try: items = get_item(event['queryStringParameters']['id']) except: status_code = 500 return { 'isBase64Encoded': False, 'statusCode': status_code, 'headers': { "Access-Control-Allow-Headers" : "*", "Access-Control-Allow-Origin": os.environ['CORS_ORIGIN'], "Access-Control-Allow-Methods": "GET" }, 'body': json.dumps(items) } DynamoDBは以下のように定義している。 resource "aws_dynamodb_table" "employee" { name = local.dynamodb_table_name billing_mode = "PAY_PER_REQUEST" hash_key = "id" attribute { name = "id" type = "S" } } locals { dynamodb_items = [ { "id" = "00001", "name" = "Taro", "age" = "45" }, { "id" = "00002", "name" = "Jiro", "age" = "42" }, { "id" = "00003", "name" = "Saburo", "age" = "40" }, { "id" = "00004", "name" = "Shiro", "age" = "35" }, { "id" = "00005", "name" = "Goro", "age" = "30" }, ] } resource "aws_dynamodb_table_item" "employee" { for_each = { for dynamodb_item in local.dynamodb_items : dynamodb_item.id => { id = dynamodb_item.id name = dynamodb_item.name age = dynamodb_item.age } } table_name = aws_dynamodb_table.employee.name hash_key = aws_dynamodb_table.employee.hash_key range_key = aws_dynamodb_table.employee.range_key item = <<ITEM { "id": {"S": "${each.value.id}"}, "name": {"S": "${each.value.name}"}, "age": {"S": "${each.value.age}"} } ITEM } 最後に、API GatewayのAPIを直接実行してしまうことができないように、APIにオーソライザーを設定しよう。 resource "aws_api_gateway_method" "employee_get" { rest_api_id = aws_api_gateway_rest_api.contents.id resource_id = aws_api_gateway_resource.employee.id http_method = "GET" authorization = "COGNITO_USER_POOLS" authorizer_id = aws_api_gateway_authorizer.cognito.id } resource "aws_api_gateway_authorizer" "cognito" { rest_api_id = aws_api_gateway_rest_api.contents.id name = "CognitoAuthorizer" type = "COGNITO_USER_POOLS" provider_arns = [aws_cognito_user_pool.example.arn] } これで、直接APIを実行しても $ curl -i https://xxxxxxxxxx.execute-api.ap-northeast-1.amazonaws.com/prod/employee?id=00005 HTTP/2 401 date: Sun, 13 Jun 2021 12:34:59 GMT content-type: application/json content-length: 26 x-amzn-requestid: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx x-amzn-errortype: UnauthorizedException x-amz-apigw-id: xxxxxxxxxxxxxxxx {"message":"Unauthorized"} と、エラーになるようになった。もちろん、トークンを直接貼り付ければアクセスできるし、トークンを改ざんしてアクセスしようとすると、{"Message":"Access Denied"}が返されるようになった(HTTPステータスコードは403)。この時の応答は、APIに入ってくる前なので、何もしないとCORS対応のヘッダが設定されない。必要であれば、aws_api_gateway_gateway_responseで返却するようにしておこう。
- 投稿日：2021-06-13T20:54:39+09:00
【AWS】S3を用いた画像のアップロード
目的 AWSのS3を使用し、画像をアップロードする。 開発環境 macOS: Big Sur Rubyバージョン: 2.6.5 Railsバージョン: 6.0.0 前提 S3のバケットが作成されている。 【AWS】S3バケット作成 アプリが作成されている。 【Rails】簡単な投稿アプリの作成 画像アップロード機能が実装されている。 【Rails】画像アップロード機能の導入 手順 はじめに Gemのインストール development.rbの編集 storage.ymlの編集 環境変数の設定 環境変数の使用 git-secretsの導入 git-secretsの条件設定 GitHub Desktopの利用設定 本番環境でのS3設定 Heroku上での環境変数設定 はじめに 今回はAWSのS3を用いた画像アップロードを実装していきます。 Gemのインストール まずはローカル環境での実装を行います。 なお、以降のコードを編集する際はmasterブランチで作業していきます。 それでは早速始めていきます！ S3を使用するために必要なaws-sdk-s3というGemをインストールします! Gemfile #中略 gem "aws-sdk-s3", require: false ターミナル % bundle install これでインストールできました! development.rbの編集 続いて、画像の保存先をlocalからS3に保存されるように設定を変更します！ まず、development.rbに記述している画像の保存先の設定を下記のように変更します。 config/environments/development.rb #省略 #config.active_storage.service = :local config.active_storage.service = :amazon #省略 これで画像の保存先が変更できました。 storage.ymlの編集 次に、S3で使用するバケット名とリージョン名を記述します。 storage.ymlに以下のコードを追記します。 config/storage.yml test: service: Disk root: <%= Rails.root.join("tmp/storage") %> local: service: Disk root: <%= Rails.root.join("storage") %> amazon: service: S3 region: ap-northeast-1 bucket: 「バケット名を入力」 #省略 「バケット名を入力」の箇所には、自分のバケット名を入力します！ 環境変数の設定 最後に、S3にアクセスするための認証情報を設定します。 秘密情報である「Access key ID」と「Secret access key」は直接記載してはいけないため、それぞれの環境変数に入れてソースコードに記述します。 まずは、環境変数を設定するファイルを編集するために、vimコマンドを使用します。 ターミナル $ vim ~/.bash_profile 続いて「i」を入力して、ファイルを編集モードにします。 ターミナル左下に「INSERT」という文字が表示されれば文字が入力できるようになっています。 環境変数に代入する「Access key ID」と「Secret access key」の値を調べるため、「new_user_credentials.csv」というcsvファイルを開き、以下のコードを追加します。 ターミナル export AWS_ACCESS_KEY_ID="CSVファイルのAccess key IDの値を貼り付け" export AWS_SECRET_ACCESS_KEY="CSVファイルのSecret access keyの値を貼り付け" 値を貼りつけたら「escキー」→「:wq」の順で入力し、環境変数の設定ファイルを保存します。 次にsourceコマンドを入力し、先ほど設定した環境変数を使えるようにします。 $ source ~/.bash_profile sourceコマンドとは現在開いているターミナルのタブで環境変数の設定ファイルを読み込み直してくれるものです。 環境変数の使用 ここまでで、環境変数を設定することができました！ 実際にソースコード内で環境変数を使用して、S3への認証情報を記述します。 config/storage.yml test: service: Disk root: <%= Rails.root.join("tmp/storage") %> local: service: Disk root: <%= Rails.root.join("storage") %> amazon: service: S3 region: ap-northeast-1 bucket: （自分のバケット名が記載されている状態） access_key_id: <%= ENV['AWS_ACCESS_KEY_ID'] %> secret_access_key: <%= ENV['AWS_SECRET_ACCESS_KEY'] %> #省略 これで安全にソースコード内で安全に秘密情報を記述することができました！ git-secretsの導入 ここまでの作業で、環境変数は設定できました。 しかし、うっかりミスで環境変数を使用し忘れてしまい、誤って秘密情報をGitHubにpushしてしまう可能性もあります。 そのため、誤操作で秘密情報をpushしないよう対策していきます！ AWSが公開している「git-secrets」というツールを使用して、誤ってGitHubにpushしないよう設定していきます。 git-secretsはcommitしようとしたコードをチェックし、パスワードだと推定されるような文字列が含まれている場合は、警告を出して処理が中断してくれる機能です。 まずはgit-secretsのインストールです。 ターミナル（ホームディレクトリで実行すること） % brew install git-secrets git-secretsが導入できたら、設定を適用したいアプリケーションのディレクトリに移動して、git-secretsを有効化します。 ターミナル % git secrets --install これで、git-secretsを使用する準備ができました! git-secretsの条件設定 続いて、どのようなコードのcommitを防ぐのかを設定していきます。 下記のコマンドを実行し、「Access key ID」や「Secret access key」など、アップロードしたくないAWS関連の秘密情報を一括で設定します。 ターミナル % git secrets --register-aws --global これで条件が設定出来ました！ GitHub Desktopの利用設定 commitなどソースコード管理をGitHub Desktopを使用して行なっている場合は、また追加で設定が必要になります。 以下のコマンドを実行してGitHub Desktopにgit-secretsを適用させます！ ターミナル % sudo cp /usr/local/bin/git-secrets /Applications/GitHub\ Desktop.app/Contents/Resources/app/git/bin/git-secrets このコマンドの際にパスワードの入力が必要となる場合があります。このパスワードはPCにログインする際のパスワードです。 git-secretsが適用範囲設定 ここまでの設定では、今後作成するリポジトリにはgit-secretsが適用されません。 そのため、以下のコマンドを実行して自動で適用されるようにします！ % git secrets --install ~/.git-templates/git-secrets % git config --global init.templatedir '~/.git-templates/git-secrets' これで、今後作成する他のアプリケーションにも、git-secretsが適用されるようになりました！ ここまでで、ローカル環境での設定とセキュリティ対策ができたので、実際に投稿した画像ファイルがS3に保存されるか確認してみましょう。問題がないようでしたら、成功です！ 本番環境でのS3設定 続いてローカル環境での設定と同様に、画像の保存先を指定します。 現状では画像の保存先がローカルに設定されているため、S3に保存されるように設定を変更します。 まずproduction.rbに記述している画像の保存先の設定を「:local」→「:amazon」に変更します。 config/environments/production.rb #省略 #config.active_storage.service = :local config.active_storage.service = :amazon #省略 Heroku上での環境変数設定 Herokuで環境変数を扱うには、heroku config:setコマンドを打ちます。 ターミナル % heroku config:set AWS_ACCESS_KEY_ID="CSVファイルのAccess key IDの値を貼り付け" ターミナル % heroku config:set AWS_SECRET_ACCESS_KEY="CSVファイルのSecret access keyの値を貼り付け" 環境変数が正しく設定できているかを確認するために、下記のコマンドを入力してください。 % heroku config 確認できたら、コミットしてHerokuに反映させます。 ターミナル % git push heroku master その後、本番環境で挙動確認し問題がなければ完了です。 最後に 以上で、S3を用いた画像アップロード機能実装は完了です。 では。
- 投稿日：2021-06-13T20:37:29+09:00
Amazon Cognitoで認証したGoogleユーザーのアクセストークンを使ってLamdaからGoogle APIを叩く
はじめに Cognitoで認証したユーザーでLamdaからGoogle APIを叩く方法を備忘録として書きます。LambdaからGoogle APIを叩いて、スプレッドシートに書き込みます。 * CognitoとApiGatewayやAppsyncの連携についてはこの記事で扱わないので、他の記事を参考にしてください。 環境 Lambda (Nodejs) AppSync appsyncからLambdaを呼び出していますが、API Gatewayから呼び出した場合でも、同様の実装で実行できると思います。 Cognitoの設定 以下のページを参考に、GoogleのApp IDとシークレットを取得します。 取得したIDとシークレットをCognitoのIDプロバイダーに登録して、Scopeを設定します。 Google APIのScopeは以下のページを参考にしてください。今回は、「openid」、「email」、「profile」とスプレッドシートの操作に必要な「https://www.googleapis.com/auth/spreadsheets 」を入力します。 https://developers.google.com/identity/protocols/oauth2/openid-connect#scope-param https://developers.google.com/identity/protocols/oauth2/scopes アプリクライアントの「有効なIDプロバイダー」にGoogleが追加されていると思うので、有効にします。 次に、アクセストークンを取得できるようにカスタム属性を設定します。「変更可能」にチェックが入っていないとアクセストークンが新しくなったときに上書きできなくなるので、必ずチェックを入れるようにしてください。 画像ではカスタム属性が2個ありますが、赤枠で囲んだほうだけを作成してください。 そして、アクセストークンがマッピングされるように属性マッピングの設定を追加します。これで、custom:google-accessTokenでアクセストークンが取得できるようになります。 上記の手順でGoogleを追加するとクライアント側では以下のようにGoogleでログインができるようになると思います。 LambdaでAcess Tokenを使う Cognitoで認証したユーザーからLambda関数が実行されたとき、eventにカスタム属性が入っています。今だとevent.identity.claims["custom:google-accessToken"]にアクセストークンが追加されているので、それを取り出して使用します。 取り出したアクセストークンをgoogleapisに設定してGoogle のAPIを呼び出すことができます。 ちなみに、これはGraphQLのMutationが呼び出されたときに実行される関数で、入力された値を変換してスプレッドシートに書き込んでいます。 import { AppSyncIdentityCognito, AppSyncResolverHandler } from "aws-lambda"; import { google } from "googleapis"; import { CreateMovieInput, MutationCreateMovieArgs } from "./generated/graphql"; const oauth2Client = new google.auth.OAuth2( "xxxxxxxxxxxxxxx(Client ID)", "xxxxxxxxxxxxxxx(Client Secret)" ); export const handler: AppSyncResolverHandler<MutationCreateMovieArgs, string> = async (event) => { const identity = event.identity as AppSyncIdentityCognito; const access_token = identity.claims["custom:google-accessToken"]; const tokens = { access_token, // refresh_token: "", }; oauth2Client.setCredentials(tokens); const { input } = event.arguments as MutationCreateMovieArgs; // inputToValuesは入力をスプレッドシートシートに書き込む値に変換する独自関数 const values = inputToValues(input); const sheets = google.sheets({ version: "v4", auth: oauth2Client }); // 指定したスプレッドシートの最後尾にデータを追加する const data = await sheets.spreadsheets.values.append({ spreadsheetId: "xxxxxxxxxxxxxxxxxxxxxxxxxxxxx", valueInputOption: "USER_ENTERED", insertDataOption: "INSERT_ROWS", range: "A1", requestBody: { values, }, }); return data.statusText; }; マッピングの設定でrefresh_tokenもマッピングするようにすれば、リフレッシュトークンも使えるようになります。 まとめ Amazon Cognitoで認証したGoogleユーザーのアクセストークンを使ってLamdaからGoogle APIを叩く方法について紹介しました。 設定は簡単にできるのでぜひ試してみてください。
- 投稿日：2021-06-13T16:47:09+09:00
MediaLiveのInputSwitch【備忘録】
MediaLiveのチャンネルのSchedule actionsでAction type: Input Switchとして作成するとInputの切り替えができます。 "Schedule"とはいいつつ、Start typeをimmediateにすることでactionは作成直後に実行されます。 これによって放送中の映像を任意のタイミングで切り替えることが可能になります。 今回はRTPM(Live配信)とMP4(S3に格納済み)で入力を切り替えてみます。 Input, Channelの作成 MediaStoreとか視聴用のHTMLは前もって作成しておきます。 Live配信用のInput Input type: RTMP(push)にします MP4用のInput Input typeはMP4に、Input sourceはコンテンツを格納したS3のURLを設定します。 Channnel 上記のInput2つをアタッチします。 MP4のコンテンツは繰り返し出力したいので、General input settings > Source End BehaviorでLOOPを選択しておきます。 Lambda チャンネルを切り替えるためのAPIをAPIGateway + Lambdaで作成します。 Pythonで実装します。 def lambda_handler(event, context): client = boto3.client('medialive') chennel = json.loads(event['body'])['Channel'] actionName = json.loads(event['body'])['ActionName'] response = client.batch_update_schedule( ChannelId='<作成したChannelのID>', Creates={ 'ScheduleActions': [ { 'ActionName': actionName, 'ScheduleActionSettings': { 'InputSwitchSettings': { 'InputAttachmentNameReference': chennel, 'UrlPath': [] } }, 'ScheduleActionStartSettings': { 'ImmediateModeScheduleActionStartSettings': {} } } ] } ) Live配信中にコンソールで下記コマンドを打つとMP4の映像に切り替わります。 私の環境ではAPIを叩いてから切り替えに15secくらいかかりました。 curl -X POST https://{API Gatewayのドメイン}/{ステージ}/{リソース} -d '{"Channel":"<MP4用のInput名>", "ActionName": "ChannelSwitch"}' 参考 参考にさせていただきました。 [アップデート] AWS Elemental MediaLiveでInputのスイッチングが可能になりました #reinvent #mediaservices | DevelopersIO AWS Elemental MediaLiveで番組編成っぽいことをしてみた | DevelopersIO AWS Elemental MediaLiveのスケジュール機能を使ってみた(コンソール版) - Qiita
- 投稿日：2021-06-13T16:37:56+09:00
【AWS】S3バケット作成
目的 AWSのS3を使用するためにバケットを作成する。 開発環境 macOS: Big Sur Rubyバージョン: 2.6.5 Railsバージョン: 6.0.0 前提 AWSアカウントのルートユーザー、IAMユーザーが作成されている。 手順 はじめに S3とは バケットとは リージョンとは バケットの作成 IAMユーザーの情報取得 バケットポリシーの設定 はじめに 今回はS3を使用する前準備として、自分用の保存場所を作成していきます。 S3とは AWSの中のサービスの1つであり、Simple Storage Serviceを略してS3と呼んでいます。 バケットとは S3では自分用のデータを保存する場所のことをバケットと呼びます。 リージョンとは S3に保存されたデータは実在の施設に分散して保管されています。 その実在の施設が所在している場所をリージョンといいます。 バケットの作成 それでは、実際にバケットを作成していきます! この作業はルートユーザーのまま設定を進めます。 ルートユーザーではないと確認できない情報があるため、もしIAMユーザーでログインしている場合は、ルートユーザーにログインし直しましょう。 まず画面上部のメニューバーからサービスをクリックし、サービス一覧からS3を選択してS3ページを開きます。 その後バケットを作成を選択し、S3バケットのページに遷移します。 次にバケット名を入力し、リージョンがアジアパシフィック（東京）になっていることを確認します。 バケットの名前はアクセスするときのURLに使用されるため、英数字で、まだ誰も付けたことがない名前を使う必要があります。 画面を下にスクロールすると、アクセス許可の設定が表示されます。 今回はバケットポリシーというものを使用して、S3のセキュリティ対策を行います。 まずは、パブリックアクセスをすべてブロックのチェックを外し、画像のように3つのチェックボックスにチェックを入れます。 この設定が誤っているとファイルのアップロードができなくなってしまいます。 入力できたら、下にスクロールししましょう。 オプション設定が表示されますが、何も入力せず、バケットを作成をクリックしましょう。 ここまでで、バケットを作成することができました。 IAMユーザーの情報取得 次にバケットポリシーの設定をするため、IAMユーザーの情報を取得します。 まずIAMユーザーの情報を取得します。画面上部のメニューバーからサービスをクリックし、IAMページへ遷移します。 次に左のサイドバーからユーザーをクリックし、IAMユーザーページの作成したIAMユーザー名をクリックします。 ユーザー概要のページに遷移したあと、「ユーザーのARN」をコピーします。 この「ユーザーのARN」は後ほど使用します！ バケットポリシーの設定 次に、バケットポリシーの設定を行います。 バケットポリシーとは、バケットに対して、どのユーザーがどの処理をできるか取り決めをするものです。 今回は、IAMユーザーのみバケットにアクセスできるよう設定していきます。 画面上部のメニューバーからサービスをクリックし、サービス一覧からS3を選択します。 その後、先ほど作成したバケット名をクリックします。 次に、画面中央のアクセス許可をクリックし、バケットポリシー設定の、編集をクリックします。 そして、下記のバケットポリシーのコードをコピーし、「ポリシー」という入力欄に貼り付けます。 バケットポリシー { "Version": "2012-10-17", "Id": "Policy1544152951996", "Statement": [ { "Sid": "Stmt1544152948221", "Effect": "Allow", "Principal": { "AWS": "①" }, "Action": "s3:*", "Resource": "arn:aws:s3:::②" } ] } 次に、ユーザーによって異なる個別の情報を入力します。 「①」の箇所に、先ほどコピーした「ユーザーのARN」を入力します。 「②」の箇所に、作成したバケット名を入力します。 問題なければ画面下にスクロールして、「変更の保存」をクリックしましょう。 問題なくバケット作成ができれば成功です。 最後に 以上でバケットの作成は完了です。 次回はアプリに導入する方法を投稿します。【AWS】S3を用いた画像のアップロード では。
- 投稿日：2021-06-13T16:35:24+09:00
Sec4 【EC2】Webサーバーを構築しよう
20. このセクションで構築するもの EC2 ← SSH ←apache ← ファイヤウォール パブリックサブネットをWebサーバーを設置。それに対してapacheをインストール。そしてインターネット表示できるようにファイヤウォールを設定 21. 22 EC2を設置しよう Elastic Compute Cloud AWSクラウド上の仮想サーバーのこと。OSより上のレイヤーは設定する事ができる。 AMIの選択 インスタンスタイプの選択 ストレージの追加 セキュリティグループの設定 SSHキーペア設定 AMI Amazon Machine Image インスタンスの起動に必要な情報が入った、OSイメージ。サーバーのテンプレートの様なもの。 OSを入れる必要がない。カスタムAMIも簡単に作れる。 インスタンスタイプ サーバーのスペックを定義する情報 m5.xlargeなど。（CPU、メモリ、ストレージなど ストレージ サーバーにくっつけるデータの保存場所。 EBS 高い可用性と持つストレージ、他のインスタンスに付け替え可能。 インスタンスストア インスタンス専用の一時的なストレージ 他のインスタンスには付ける事ができない、Stop/Terminateするとクリアされる。 23. SSHについて学ぼう 目的：サーバーを設置する。 → サーバーを設置し、必要なソフトウェアをインストールすること。 SSHでサーバーのログインするとはなんぞ？ サーバーにログインする 離れたサーバーに入って、自分のパソコンから操作すること。 SSH 自分のパソコンとサーバーをセキュアに接続するサービスのこと、通信内容が暗号化された遠隔運用システム SSHクライアント(自分のパソコン), SSHサーバー(Webサーバー) SSHクライアントがSSHサーバーにログインを要求し、認められるとサーバーにログイン → ログインすると、まるで目の前にサーバーが存在するかの様に操作可能 24. 公開鍵認証 EC2に誰でもログインできると困る → 公開鍵認証を扱う。 公開鍵認証 平文 × 暗号化(南京錠) ＝ 暗号化 暗号文 × 複合化(公開鍵) ＝ 平文 公開鍵 ＝ 南京錠 秘密鍵 ＝ 鍵 27. ポート番号について学ぼう ポート番号 Webサーバー内において、各プログラム毎に割り当てられた、窓口のこと。 SSH接続の場合 自分コンピューターから⁇IPアドレスの⁇ポート番号に対して、SSH接続リクエスト そのリクエストをルーティング経由で、指定されたIPアドレスのサーバーが受け取り、指定されたポート番号のプログラムが起動する。 今回の場合はSSH接続を可能にする“sshd”が起動する とい流れ ポート番号は、標準で割り当てられている場合と動的に設定される場合がある。 標準で割り当てられている場合は、接続元(クライアント・自分のコンピューター)から発信された種類によって定まる 動的に定めれる場合は、接続元が発信した場合にOSがランダムで決める。 28. apacheをインストールしよう apache HTTPリクエストがあると、それに対してリクエストを返し、ウェブページを表示するソフトウェア 29. ファイヤウォールを設定しよう ファイヤウォール ネットワークを不正アクセスから守る。「通して良い通信だけを通して、それ以外は遮断する」仕組み AWSでは、セキュリティグループがファイヤウォールの役割を担う。 30. Elastic IPアドレスでIPアドレスを固定しよう EC2インスタンスは起動・停止するとIPアドレスが割り当てられる。→動的にIPアドレスが変化する。 Elastic IPアドレス インターネット経由でアクセス可能な固定のグローバルIPアドレスを取得でき、インスタンスを付与できるサービス。
- 投稿日：2021-06-13T16:22:16+09:00
AWS SAAに3回目の受験で合格した勉強体験記
自己紹介 40歳で未経験からエンジニアに転職してサーバーサイドメインで仕事をしています。 2021年6月にAWS SAA合格しました！！（2021年3月にAWS CLF合格） 普段の業務ではAWSは全く扱っておらず、今後の自分の業務スキルの幅を広げていきたいと言う思いから学習を開始しました。 この度3回目の試験でようやく合格出来たわけですが、正直かなり難しかったです。 短期間&高得点で合格されている方の記事などを参考にしすぎたのか、自分のスペックを完全に過信していましたww そんな私のリアルな勉強体験を振り返りながら記事にしてみます。 ですのでスムーズに合格まで到達される優秀な方にはつまらない内容になってます。 泥臭くてもまずは何とか合格したいんじゃ〜と言う方の参考や多少の励ましになれば幸いです。 目次 1.受験結果 2.学習期間 3.使用した教材 4.おすすめの教材と学習手順 5.おわりに 1. 受験結果 ・１回目 ６７２点 不合格（２０２１年４月） ・２回目 ６９９点 不合格（２０２１年５月） ・３回目 ７４３点 合格（２０２１年６月） この点数の伸びなさに自分でもビックリです。 合格点は７２０点以上です。おそらく問題数にしたら１〜２問位しか余裕がなかったので最後まで苦労しました。 2. 学習期間 １回目は学習開始から１ヶ月半程度で受験しました。 当初は２〜３ヶ月程度の学習期間を見積もっていたのですが、模擬試験などの点数が思ったより良かったので、『ワンチャンあるんじゃね？』と言う気持ちと、早く実際の試験を体感しておきたかったと言う気持ちで挑みました。 １回目の不合格から約3週間スパンで２回目⇨３回目と受験しました。 正直２回目では合格するかなと思っていたので、不合格だった時はさすがに凹みました（次の日には気にならなかったですが）。 ３回目で合格した際は嬉しいと言うよりはホッとした気持ちでしたね。とにかく合格できて良かったです。 3. 使用した教材 次に学習で使用した教材などを紹介していきます。 ここは結構気になる方が多いと思うのでしっかり伝えていきたいと思います。（利用順に紹介します） ①改訂新版 徹底攻略 AWS認定 ソリューションアーキテクト − アソシエイト教科書［SAA-C02］対応 解りやすさ ★★★★ おすすめ度 ★★★ 楽天 amazon 先に合格された方でも紹介されている事が多かったので、学習の取っ掛かりとして購入。 まずはこれをひと通りザッと流し読みして全体像を摘みました。（４〜５日） 模擬問題も付いてます。 ネットで購入される場合は旧版も多く出回っていますので、最新版（2021年6月時点）は丸い部分が青色、旧版は丸い部分が緑色で判別してください。 全体的に説明もわかりやすくイラストも要所で散りばめられているので、AWS初学者には比較的親切なテキストになっているかと思います。 ただ後で解る事になるのですが、試験範囲全体はカバー出来ていません。 他の模擬試験などを受けていきその事に気付いてからは、解らない部分（用語）などを調べる際の辞書的な位置付けになりました。 後半はほとんど使用しませんでした。 ②AWS CloudTech 解りやすさ ★★★★★ おすすめ度 ★★★★★（無料会員なら★★★★★★★★★★） 今回の学習体験を通じてダントツでおすすめしたいコンテンツです。 YouTubeでも良く発信活動をされている有名なクラウドエンジニアの方が主催されているオンライン学習スクールです。 ・無料会員コース ・月額制コース（１ヶ月or3ヶ月） ・買い切り型の永久会員コース 3コースがあります（ちなみに私は永久会員コースです）。 当初は試験対策というより実践的なスキルを身に付ける目的で入会していたのですが、 これが結果的に私の合格を大きく近付けてくれる事になりました。 一番良かったと思う点は問題数の豊富さと問題文の解りやすさです。 特に問題文の解りやすさと解説の丁寧さが秀逸です。 CLFの時はそこまで感じなかったのですが、SAAは問題文そのものが解り辛いと言うどうしようもない壁を感じていました。 聞かれている事の意味が解らないのに正解に辿り着けるはずがないです。 問題が解ける様になってもそれは単なる暗記なので、本番で通用しない部分も多く学習効率も悪くなります。 AWS CloudTechで掲載されている問題文は他の教材で採用されている類似の問題も敢えて解りやすい日本語に置き換えてくれているので、ここの問題集を解きまくる事で大幅にレベルアップ出来ました。 その結果、他の教材の問題（実際の試験に近い問題文）への理解も深まりました。 私は学習前の時点から有料会員になっていたので問題集は全て触れる事が出来ました（約400問）。 無料会員の方でも200問位は利用出来ると思います（2021年6月時点）。 個人的には有料・無料で問題のレベルや出題範囲に遜色があったとは思いませんので、まずは無料会員で利用してみるのもオススメです。（逆に無料会員なら入らない理由が思い付きませんww） 特に私の様に『問題文自体の意味が解んないよ〜ぴえん』な方にはピッタリだと思います。 ぶっちゃけこれだけでも合格できる方もいるんじゃないかと思います。 まだ知らないと言う方はこちらから ③これだけでOK！ AWS 認定ソリューションアーキテクト – アソシエイト試験突破講座（SAA-C02試験対応版） 解りやすさ ★★★ おすすめ度 ★★★★ udemy教材は定期的にセールが行われているので、そのタイミングで購入するとテキスト１冊分の値段で受講できます。 試験範囲はほぼ網羅出来ているので、コスパで言えばダントツだと思います。 問題集も２００問程度付いています。 ただボリュームがあるが故にもう少し詳しく解説して欲しいなと思う箇所もかなり多かったです。 最初にこれをひと通りやってからと言う利用方法は学習効率の面では個人的にはあまりオススメしません。 (３回受験した私が言うのもなんですがww) １回目の試験時には利用していなく、２回目の試験学習期間から自分に足りない点がどこかを見付ける為に利用していました。 こちらもハンズオンの動画も一緒にあるので、体系的に学んでいきたい方には良いと思います。 結果的にはこちらの教材は半分くらい利用しました。 ④【SAA-C02版】AWS 認定ソリューションアーキテクト アソシエイト模擬試験問題集（6回分390問） 解りやすさ ★★★★ おすすめ度 ★★★ ③と同じ方が作成されているudemyの問題集です。１回目の試験から利用していました。 今回学習した問題集の中では一番レベルが高かったです。これも何周も利用しました。 ここである程度の得点を安定して出せる様になって、自信を持って試験に挑むと言う感じで使用するのもアリだと思います。 体感的には ・直近４〜５日以内に同じ問題を解いていない（良い意味で問題を忘れてる感じ） ・80~85％以上の正答率 がオススメのラインかなと思います。 注意点 あくまでも本番の試験は別物だと言う事を忘れないで下さい。 ここで出てくる問題文は確かに問われる内容も細かい部分が多いので、このレベル感の問題をずっと解いていると、 『俺ってかなりレベル上がってきたな』と言う錯覚を得られます。 内容が細か過ぎるが故に、本番では同じ問題に巡り会える可能性はかなり低いんじゃないかと思います。 そう言う意味ではこの問題集ばかりやり過ぎると、かえって学習効率が悪くなる傾向があるかも知れません。 問題文を正しく読み解く為の練習だと思って繰り返し解くのはありだと思います。 位置付け的には後２〜３問で合格ラインに届きそうだけど既存の教材だけではどうしても届かないので、自力ベースを上げる為に問題文１つずつへの理解を深めようとする視点で利用していました。 ⑤AWS認定資格 無料WEB問題集＆徹底解説 解りやすさ ★★★ おすすめ度 ★★★★ サイトへいく 無料で利用できる問題集サイトです。 ３回目の試験前に最後の腕試しのつもりで利用していました。 問題数は１６０問程度ですが回答の解説も解りやすく書かれているのでオススメです。 問題内容は別の問題集でも触れた事のある内容ばかりだったので、初見でもほとんど正解出来ました。 他の教材で問題を解きまくっていれば、これはやらなくても良いと思います。 ただこれも無料で利用できると言う点は魅力なので、先にこちらから利用していくのもアリかなと思います。 以上が私が利用した教材です。 他にもBlackBeltやAWS主催の模擬試験なども利用しましたが、合格という点ではそこまで影響なかったかなと思いますので、今回は割愛します。 4. おすすめの教材と学習手順 4-1マスト(これだけは有った方が良い） ②AWS CloudTech（問題の解りやすさダントツ） ③これだけでOK！ AWS 認定ソリューションアーキテクト – アソシエイト試験突破講座（試験範囲を網羅している） この2つは合格を目指す上で間違いないと思います。 問題集に関してもこの2つでかなりカバー出来ているので、どうしても他の問題も触れてみたいと言う方は ④【SAA-C02版】AWS 認定ソリューションアーキテクト アソシエイト模擬試験問題集（6回分390問） もあっても良いかと思います。 4-2学習手順（また初めから学習する場合） １・何かしらのテキストで全体像をザッと把握（長くても１週間程度） ２・問題を解きまくる（１０問〜２０問を１セットにして同じセットを繰り返し解く） ３・試験範囲全体カバーできるまで２を繰り返す ４・模擬試験などで時間配分や試験ボリュームに慣れる。問題を解く際に復習したい問題をチェックしておく ５・模擬試験で不正答だった問題やチェックした問題を繰り返し解く ６・手持ちの模擬試験範囲全体をカバーできるまで５を繰り返す ７・金銭的に問題がなければとりあえず１回受験して本番慣れしておく 要約すると繰り返し問題を解き、問題に慣れていく。これが一番近道かなと思います。 最初は問題の意味すら解らないって事も織り込み済みで繰り返し解いていきましょう。 何回も繰り返し解いていれば次第に慣れていきます。 それでもビビってしまうなら取り敢えず１回受けてしまいましょう。落ちても死にませんww 早く受かればラッキーです。空いた時間を更に有効活用していきましょう！！ ※現在AWS認定試験をオンラインで受験すると不合格でも次の受験料が無料になるキャンペーンを行っています。 私も２回目の受験時にこのキャンペーンを利用したので、３回目の受験料はタダでした。 （2021年7月31日までに１回目を受験した方が対象だそうです） キャンペーンのお知らせはこちらから 5. おわりに ここまで読んで頂いて有り難うございます。 今更ながら改めて自己紹介になりますが、私は40歳で未経験からエンジニアに転職しました。 普段はサーバーサイド業務がメインで仕事をしています。おっさん駆け出しエンジニアです。 最初はAWSの経験も無い上にただの資格ゲッターになっても仕方が無いと言う気持ちが働き、 体系的に学んだり実践経験に近い内容で学びながら合格を目指そうと思っていました。 でもよくよく考えたら実践経験を積む事と試験に合格する事ってかなり目標が違いますよね。 目的はあくまでもインフラ（クラウド）エンジニアとしての経験やスキルを積んでいく事。 試験に合格する事はその為の目標の１つに過ぎません。 まずは合格できればOKと割り切ってその為の最短ルートを目指した方が良いと考え方を変えました。 結果的には３回受験しましたが無事に合格出来ましたし、スケジュール的にもほぼ予定通りに受かる事が出来ました。 学習方法を間違えていれば半年経っても合格しなかったかも知れませんし、もしかしたら途中で諦めていたかも知れません。 ただインフラ経験ゼロで年齢もそこそこいってる私がいきなりAWSの業務に触れる事が出来る機会はかなり限られているんじゃないかと感じています。 資格はそんな私でも業務に触れる機会（チャンス）を広げる為のいわば入場チケットの様な物だと思っています。 AWS SAA合格をきっかけにこれからは目標を実務経験を積んでいく事に切り替えていこうと思います。 今回の記事が私と同じ様に学習方法や考え方で悩んでいる方の参考になれば幸いです。
- 投稿日：2021-06-13T15:47:46+09:00
aws transer family FSx cloudwatch-agent
wget https://s3.us-east-2.amazonaws.com/amazoncloudwatch-agent-us-east-2/centos/amd64/latest/amazon-cloudwatch-agent.rpm rpm -i ./amazon-cloudwatch-agent.rpm yum install amazon-cloudwatch-agent amazon-cloudwatch-agent-config-wizard systemctl start amazon-cloudwatch-agent.service /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a fetch-config -m onPremise -s -c file:./config.json /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a start sudo aws configure --profile AmazonCloudWatchAgent 送る側 vi /etc/rsyslog.conf . @@remote-host:5141 . @@ xxx.yyy.zzz.aaa:514 systemctl restart rsyslog iptables -A INPUT -p tcp --dport 514 -j ACCEPT ＊＊ 必要ない iptables -A INPUT -p tcp --sport 514 -j ACCEPT 受け側 vi /etc/rsyslog.conf tail /var/log/messages Provides TCP syslog reception $ModLoad imtcp $InputTCPServerRun 514 logger -p syslog.info -t TEST "Test" tail /var/log/messages nmtui nmcli device chkconfig yum chkconfig ntpd on systemctl list-units --type=service curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip" unzip awscliv2.zip sudo ./aws/install sudo aws configure --profile AmazonCloudWatchAgent sftp -oIdentityFile=/opt/aws/urataPri.ppk urataJbd@s-0832c55d03354dd19.server.transfer.us-east-2.amazonaws.com mount -r /dev/cdrom /media 1qazXSW"1qazXSW"
- 投稿日：2021-06-13T14:53:36+09:00
【160時間】AWS認定ソリューションアーキテクト – アソシエイト（SAA）私の勉強方法
はじめに 2021年5月に、AWS認定ソリューションアーキテクト – アソシエイト（SAA）に合格したので、私の勉強方法を紹介したいと思います。ブログは初めてなので、ダラダラと書いていきます！ 受験前までのスペック 非IT業界勤務の20代（AWS資格に役立つ業務知識ゼロ） 大学時代、少し情報系の授業を受講（プログラミングなど） 応用情報技術者試験合格 合格までのコスト 勉強期間は4月から5月までの2か月間 勉強時間は162時間53分（CLF1が39時間、SAAが123時間） 費用は試験代と教材で3万9千円 使用した教材 教材 略称2 役に立った コメント ①AWS認定資格試験テキスト AWS認定 クラウドプラクティショナー ①CLF緑本 ★★★ これを読んだら、AWSの全体像がなんとなくわかった ②図解即戦力 Amazon Web Servicesのしくみと技術がこれ1冊でしっかりわかる教科書 ②CLF図解本 ★★ ①よりも簡単で図表多めで読みやすい、網羅性は低めかも、1周読んだだけ ③AWS認定 クラウドプラクティショナー 模擬問題集 ③CLFオレンジ問題集 ★★ 普通 ④Udemy この問題だけで合格可能！AWS 認定クラウドプラクティショナー 模擬試験問題集（7回分455問） ④CLF Udemy問題集 ★★ 応用問題が難しすぎ、Udemyはセールのときに買うとお得 ⑤AWS認定資格試験テキスト AWS認定ソリューションアーキテクト - アソシエイト 改訂第2版 ⑤SAAオレンジ本 ★★★★★ 個人的に⑥よりも文章・図表・デザインの点で読みやすい ⑥改訂新版 徹底攻略 AWS認定 ソリューションアーキテクト − アソシエイト教科書［SAA-C02］対応 徹底攻略シリーズ ⑥SAA黒本 ★★★★ ⑤を読んで理解できない箇所や、不足情報を補うために使った ⑦AWS WEB問題集で学習しよう ⑦WEB問題集 ★★★★★ 本番に近い問題、豊富な問題数、合格記が読める ⑧この１冊で合格！ AWS認定ソリューションアーキテクト - アソシエイト テキスト&問題集 ⑧SAA黄色本 ★ ほとんど使ってない ⑨【SAA-C02版】AWS 認定ソリューションアーキテクト アソシエイト模擬試験問題集（6回分390問） ⑨SAA Udemy問題集 ★★★ 問題が本番より難しいと思う、セールのときに買うとお得 ⑩AWSサービス別資料 ⑩Black Belt ★★★ AWS公式の資料、最新で正確な情報 ⑪AWS公式模擬試験 ⑪AWS公式模擬試験 ★★★★ 操作画面を確認するため 勉強履歴 39時間 CLFの勉強 初めはCLF取得を目標に勉強しました。①CLF緑本と②CLF図解本を1周ずつ読んで、AWSの全体像をなんとなく把握。 ③CLFオレンジ問題集、65問1回分を解く。結果は60%ぐらい。 ④CLF Udemy問題集、基本レベル65問2回分を解く。これも60%ぐらい。 CLFは取得できそうだなと思ったので、早々にSAAの勉強にシフトしました。 107時間 SAAの勉強 ～⑦WEB問題集～ SAAの勉強は、色んな合格者さんのブログなどを参考に、⑦WEB問題集をメインに勉強しました。理由は、⑦WEB問題集の問題が本番の問題内容・難易度にとても近く、取り扱う問題数が多いからです。私が実際に本番を受けても、同じように感じました。 まずは#80～#146（#1つに7問、計469問）を1周解きました。その後、2週目は1周目の不正解問題、3周目は2周目の不正解問題を解きました。⑦WEB問題集は、正解不正解が履歴に残らないので、エクセルで表を作って管理してました。 正解率→1周目57%、2周目87%(累計)、3周目93%(累計) ⑦WEB問題集を解きながら、解説を読みつつ、⑤SAAオレンジ本、⑥SAA黒本、⑩Black Beltなどで調べながら進めていきました。解説を読んでも理解が難しい問題もたくさんあり、全体的に7割ぐらいの理解度で進めていきました（問題量を重視）。重要そうな単語は、暗記アプリで暗記カードを作って、隙間時間で覚えてました。解説や単語の意味を理解できたら、後は暗記あるのみだと思います！ 15時間 SAAの勉強 ～⑨SAA Udemy問題集～ ⑦WEB問題集を3周やっても、少し不安だったので⑨SAA Udemy問題集を解きました。 結果 基本問題の模擬試験① 1周目71% 2周目95% 高難易度の模擬試験② 1周目51% 2周目88% 高難易度の模擬試験③ 1周目52% 2周目91% 微妙な結果でした。調べてみると1周目でこのぐらいの正解率でも、合格してる方はいるので、本番を受けてみようかなと思いました。高難易度の問題は、重箱の隅をつつくような問題が多い印象でした。自分の実力を把握するには、解いて良かったかも？です。 1時間 SAAの勉強 ～⑪AWS公式模擬試験～ 試験前日に⑪AWS公式模擬試験を解きました。35分/25問/2,000円+税のAWS公式の模擬試験です。これを受けた目的は、本番と同じ操作画面を確認するためです。結果は75%でした。 さいごに 私のような未経験でも時間をかければ合格できたので、どなたでも合格のチャンスがあると思います。いつも資格勉強では、短期集中、長時間パフォーマンスを出せる環境を整えて挑んでいます。この記事が、SAAの資格取得を目指す方々へご参考になれば幸いです。 AWS認定クラウドプラクティショナー、AWSの最も基礎的な試験 ↩ 略称は私が勝手に付けた名前も含まれます ↩
- 投稿日：2021-06-13T10:53:03+09:00
goofys S3をマウントする
初めに goofys を使うと、S3 をファイルシステムとしてマウントすることができる。FSx for Lustre ではレプリケートされたオブジェクトを取り込むことができなかったが、goofys であれば取り込むことができた。 インストール～マウント インストール sudo curl -L https://github.com/kahing/goofys/releases/latest/download/goofys -o /usr/local/bin/goofys sudo chmod a+x /usr/local/bin/goofys sudo yum install golang fuse git -y 認証情報の設定 $ aws configure AWS Access Key ID [None]: XXXXXXXXXXXXXXX AWS Secret Access Key [None]: YYYYYYYYYYYYYYYYYYY Default region name [None]: ap-northeast-1 Default output format [None]: json マウント mkdir ~/dir goofys account-a-bucket-0525 ~/dir ファイルシステムを確認 $ df -h | grep 'dir' account-a-bucket-0525 1.0P 0 1.0P 0% /home/ec2-user/dir レプリケーションオブジェクトにアクセス レプリケーションオブジェクトであることを確認 $ aws s3api head-object --bucket account-a-bucket-0525 --key test_upload_4.txt --version-id JQnupBy2kZdOxhFHZ5v9VU9cvknOKOeA { "AcceptRanges": "bytes", "ContentType": "text/plain", "LastModified": "Thu, 10 Jun 2021 14:27:50 GMT", "ContentLength": 13, "ReplicationStatus": "REPLICA", "VersionId": "JQnupBy2kZdOxhFHZ5v9VU9cvknOKOeA", "ETag": "\"2e0d1f90dbe874f1217a0bbf644219e9\"", "ServerSideEncryption": "aws:kms", "SSEKMSKeyId": "arn:aws:kms:ap-northeast-1:0123456789012:key/xxxxxxxxxx", "Metadata": {} } レプリケーションオブジェクトにアクセス $ cat dir/test_upload_4.txt test upload プライベートサブネットからマウントできない プライベートサブネット プライベートサブネットからではマウントできない。 $ goofys account-a-bucket-0525 ~/dir 2021/06/13 00:43:11.956051 main.FATAL Unable to mount file system, see syslog for details パブリックサブネット マウントしてからインタネットゲートウェイをルートから外してみる。マウントできていることを確認。 $ df -h | grep 'dir' account-a-bucket-0525 1.0P 0 1.0P 0% /home/ec2-user/dir パブリックサブネット マウントポイントにアクセスできる。 $ ls dir sample.txt test_upload_2.txt test_upload_4.txt test_upload_6.txt test_goofys.txt test_upload_3.txt test_upload_5.txt test_upload.txt プライベートサブネット マウントポイントにアクセスできない。 $ ls dir ls: reading directory dir: Input/output error ゲートウェイ型S3エンドポイント プライベートサブネットからはゲートウェイ型・インターフェース型のS3エンドポイントを使ってもマウントできない。 ゲートウェイ型S3エンドポイント付きプライベートサブネット マウント後であればゲートウェイ型のS3エンドポイントを使用すればマウントポイントにアクセスできる。 $ ls dir sample.txt test_upload_2.txt test_upload_4.txt test_upload_6.txt test_goofys.txt test_upload_3.txt test_upload_5.txt test_upload.txt インターフェース型S3エンドポイント付きプライベートサブネット インターフェース型のS3エンドポイントではマウントポイントにアクセスできない。 $ ls dir ls: reading directory dir: Input/output error まとめ (1) goofys はレプリケーションオブジェクトにアクセスできる。 (2) プライベートサブネットから goofys を使うには、 パブリックサブネットでマウントする ゲートウェイ型S3エンドポイント付きのプライベートサブネットに切り替えてマウントポイントにアクセスする という流れ。 サブネット マウント マウントポイントアクセス パブリックサブネット 〇 〇 プライベートサブネット（ゲートウェイ型S3エンドポイント） × 〇 プライベートサブネット（インターフェース型S3エンドポイント） × × プライベートサブネット（エンドポイントなし） × × 参考記事
- 投稿日：2021-06-13T10:01:14+09:00
EC2にEIPつけたらアクセスできなくなった
SSHの既存の鍵を消して、再度アクセスする きっかけ EC2のパブリックIPを固定IP（EIP）にアタッチして、SSH接続をしようとした際に発生しました。 解決方法 yourPC@mbp .ssh % ssh-keygen -f "/Users/yourPC/.ssh/known_hosts" -R " XXX.XXX.XXX.XXX" ssh-keygenという、Linuxコマンド（SSHの公開鍵と秘密鍵をつくる）を利用して解決を行う。 コマンド 内容 -f ファイルを指定する（生成または読み出すファイルを指定）。ただし、併用するオプションによって意味が変化する（通常は鍵ファイル） -R 指定したホストに属する鍵を全て取り除く（-fオプションでknown_hostsファイルを指定可能 原因 SSH接続をする際、初回接続時にホストの公開鍵が保存される。（/Users/yourPC/.ssh/known_hosts） 次回ホストへ接続する際に、保存されている公開鍵を比較して同じホストか確認するが、今回はIPアドレスを振り直した状態（EIPによるIP変更）になったため、ホストの公開鍵自体が変わってしまったため、エラーメッセージが発生してしまいました。 なので、「-R」で公開鍵を消去してから、接続を計りました。 具体的な解決 1.SSH接続する際に、ターミナルにエラーが表示される @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that a host key has just been changed. The fingerprint for the ECDSA key sent by the remote host is ＊＊＊:＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊. Please contact your system administrator. Add correct host key in /Users/yourPC/.ssh/known_hosts to get rid of this message. Offending ECDSA key in /Users/yourPC/.ssh/known_hosts:14 ECDSA host key for XXX.XXX.XXX.XXX has changed and you have requested strict checking. Host key verification failed. ＠＠＠＠＠＠＠＠＠＠＠＠＠＠＠＠＠＠＠＠＠＠＠ 警告：リモートホストの識別が変更されました！ ＠＠＠＠＠＠＠＠＠＠＠＠＠＠＠＠＠＠＠＠＠＠＠ 誰かが何か厄介なことをしている可能性があります！ 誰かが今あなたを盗聴している可能性があります（man-in-the-middle攻撃）！ ホストキーが変更されたばかりである可能性もあります。 リモートホストから送信されるECDSAキーのフィンガープリントは次のとおりです。 ＊＊＊＊＊＊＊:＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊. システム管理者に連絡してください。 このメッセージを取り除くには、/ Users / yourPC / .ssh / known_hostsに正しいホストキーを追加します。 /Users/yourPC/.ssh/known_hosts:14の問題のあるECDSAキー XXX.XXX.XXX.XXXのECDSAホストキーが変更され、厳密なチェックを要求しました。 ホストキーの検証に失敗しました。 こちらの仕組みは中間者攻撃の対策としてとられている措置とのことでした（知りませんでした。） 2.ターミナルにエラーに表示されているように、14行目に問題がありそうです。ただしエディターで表示して逐一削除しなくとも、「-R」を利用してIPを記述すれば解決ができます。 yourPC@mbp .ssh % ssh-keygen -f "/Users/yourPC/.ssh/known_hosts" -R "XXX.XXX.XXX.XXX" # Host XXX.XXX.XXX.XXX found: line 14 /Users/yourPC.ssh/known_hosts updated. Original contents retained as /Users/yourPC/.ssh/known_hosts.old 3.改めてSSH接続をして、接続ができたら問題の解決です yourPC@mbp .ssh % ssh -i 秘密鍵.pem ec2-user@XXX.XXX.XXX.XXX The authenticity of host 'XXX.XXX.XXX.XXX (XXX.XXX.XXX.XXX)' can't be established. ECDSA key fingerprint is ＊＊＊:＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊. Are you sure you want to continue connecting (yes/no/[fingerprint])? yes Warning: Permanently added 'XXX.XXX.XXX.XXX' (ECDSA) to the list of known hosts. Last login: Fri Jun 11 12:25:01 2021 from 〜.net __| __|_ ) _| ( / Amazon Linux 2 AMI ___|\___|___| https://aws.amazon.com/amazon-linux-2/ おわりに AWSでEC2つくって、EIPつけてとポチポチ作成していますが中間者攻撃の対策であったりと、エラーから学べることは多いです。 それに今回はエラーメッセージそのものに、解決方法が書いてあったりしました。 こういったエラーやハンズオンを記事にしていければなと思います。 参考 「SSHホスト鍵が変わってるよ！」と怒られたときの対処
- 投稿日：2021-06-13T09:07:44+09:00
AWS(Elastic Beanstalk) + docker + flaskでwebアプリ(mecab利用)を公開
はじめに AWSでDocker経由でアプリ公開する手順の個人用の備忘録です。AWSは専門用語が多すぎて事前に対策しない初見で面食らいます（ました）。解説は全てAWSで詳しく書いてありますが、いかんせん情報量が多いので公開までの最低限のプロセスを自分用にまとめておきます。 以下ではmecabを使ったFlaskアプリをAWSで公開する手順になります。mecabは言語のパッケージ管理システム（pythonならpip）だけでインストールできずOS側のパッケージ管理システム（ubuntuならapt）で本体をインストールしなければならないので、AWSのelastic beanstalkにdocker経由でアプリ構築を行いました。 用語 [AWS]: Amazon Web Services、クラウドサーバー [EC2]: Elastic Compute Cloud、クラウド上でパソコンを使える。幅広いOSに対応している。 [EB]: Elastic Beanstalk、webアプリのファイルをアップロードするだけで勝手にデプロイしてくれてApacheなどの面倒な設定を省略できる。herokuと同様のサービス。この記事の中心になるサービス。 [EB CLI]: EBコマンドラインインターフェイス、EBの環境やアプリの管理をコンソール上で行うためのツール。 [IAM]: Identity and Access Management、EBコマンドを使う際に聞かれるIDとパスワード。 事前準備 docker、dockerhub、awsのアカウント登録。 dockerのインストール dockerの基礎知識は前提にしておく。 EBでの最初の動作確認 AWSにログインしたら、まず「AWSマネジメントコンソール」が表示される。EBでアプリ公開したいので、そのページから「ウェブアプリケーションの構築 Elastic Beanstalk」を選択してその先で表示される画面で環境を構築してサンプルコードで一旦アプリを動かして確認しておく。アップロードとデプロイが完了すると「ヘルス」と緑色のチェックが入った画面が表示される。 アップロード先のURL（環境名.ランダム文字列.リージョン名.elasticbeanstalk.com）をクリックしてみるとWelcomeというページが表示される。 Elastic meanstalkのトップページの左側から「環境」と「アプリケーション」のリンクからアプリの詳細を確認したり削除したりできる。先程つくったアプリは必要ないので削除しておいてよい。 EB CLIの導入 ブラウザ上でアプリをアップロードするのは基本的にコンソールでebコマンドで行うため、それのためのEB CLIをインストールする。 - EB CLIのインストール - macだとbrew install awsebcliで一発で入る。macOS で EB CLI をインストールします - pythonのpipでも簡単に入る。pip install awsebcliでもok - EBコマンドの説明 ebコマンドが使えるようになったら、まずガイダンスに従って、eb-docker-flaskというディレクトリを作成して。その中でeb initを実行する。そうすると、リージョン設定を行ったあとに(aws-access-id)と(secret-access-key)を聞かれる。 そこで、このページのアクセスキー（アクセスIDとシークレットアクセスキー）の欄から「新しいアクセスキーの作成」をクリックしてキーファイルのダウンロード（エクセスファイル）を行い。これを開くと、IDとアクセスキーが書かれているので、それをコピペしてコンソールに貼り付ければすすめる。 アプリケーション名などを聞かれるので、適当に命名しておく。 Select a platoformと聞かれるので、3) Dockerを選択する。 Select a platform branchはデフォルトのamazon linux 2で良い。(Dockerイメージによっては1のほうが良い。下記参照) キーペアを聞かれて既存のものがない場合そー新しく生成する。生成したものは＄HOME/.ssh/に保存される。 docker経由でアプリ生成＆デプロイ これ以降は主に「Docker プラットフォームの使用」にmecabを加えてまとめたものになる。 まず、最低限必要な、Dockerfileとapplication.pyのふたつのファイルを用意する。 Dockerfile FROM python:3.6 COPY . /app WORKDIR /app RUN apt update RUN apt install mecab -y RUN apt install mecab-ipadic -y RUN apt install libmecab-dev -y RUN apt install mecab-ipadic-utf8 -y RUN pip install flask -y RUN pip install mecab-python3 RUN cp /etc/mecabrc /usr/local/etc/ EXPOSE 5000 CMD ["python", "application.py"] OSのバージョンやなにかしらの環境が構築されているイメージを持ってくる場合は、一行目で次のように指定してあげる。 ubuntu18.04を指定する→FROM ubuntu:18.04 anaconda使いたい→FROM continuumio/anaconda3:2019.03 Flaskのサンプルコードに憲法序文とmecabを加えたもの。追加1〜3が変更点。 application.py from flask import Flask #追加1 import MeCab mecab = MeCab.Tagger( "-Owakati") # Print a nice greeting def say_hello(username = "World"): return '<p>Hello %s!</p>\n' % username # Some bits of text for the page header_text = ''' <html>\n<head> <title>EB Flask Test</title> </head>\n<body>''' instructions = ''' <p><em>Hint</em>: This is a RESTful web service! Append a username to the URL (for example: <code>/Thelonious</code>) to say hello to someone specific.</p>\n''' #追加2 instructions_jp = ''' 日本国民は、正当に選挙された国会における代表者を通じて行動し、われらとわれらの子孫のために、諸国民との協和による成果と、わが国全土にわたつて自由のもたらす恵沢を確保し、政府の行為によつて再び戦争の惨禍が起ることのないやうにすることを決意し、ここに主権が国民に存することを宣言し、この憲法を確定する。そもそも国政は、国民の厳粛な信託によるものであつて、その権威は国民に由来し、その権力は国民の代表者がこれを行使し、その福利は国民がこれを享受する。これは人類普遍の原理であり、この憲法は、かかる原理に基くものである。われらは、これに反する一切の憲法、法令及び詔勅を排除する。 日本国民は、恒久の平和を念願し、人間相互の関係を支配する崇高な理想を深く自覚するのであつて、平和を愛する諸国民の公正と信義に信頼して、われらの安全と生存を保持しようと決意した。われらは、平和を維持し、専制と隷従、圧迫と偏狭を地上から永遠に除去しようと努めてゐる国際社会において、名誉ある地位を占めたいと思ふ。われらは、全世界の国民が、ひとしく恐怖と欠乏から免かれ、平和のうちに生存する権利を有することを確認する。 われらは、いづれの国家も、自国のことのみに専念して他国を無視してはならないのであつて、政治道徳の法則は、普遍的なものであり、この法則に従ふことは、自国の主権を維持し、他国と対等関係に立たうとする各国の責務であると信ずる。 日本国民は、国家の名誉にかけ、全力をあげてこの崇高な理想と目的を達成することを誓ふ。''' home_link = '<p><a href="/">Back</a></p>\n' footer_text = '</body>\n</html>' # Elastic Beanstalk looks for an 'application' that is callable by default application = Flask(__name__) # Add a rule for the index page application.add_url_rule('/', 'index', (lambda: header_text + say_hello() + mecab.parse(instructions_jp) + footer_text)) #追加3 # say_hello() + instructions + footer_text)) # Add a rule when the page is accessed with a name appended to the site # URL application.add_url_rule('/<username>', 'hello', (lambda username: header_text + say_hello(username) + home_link + footer_text)) # Run the application if __name__ == "__main__": # Setting debug to True enables debug output. This line should be # removed before deploying a production application. application.debug = True application.run(host="0.0.0.0") 動作確認 ＆ デプロイ 以下のコマンドで、初期化してアプリを登録する。 console $ eb init -p docker [新しいアプリ名] まずはローカル環境で起動して動作確認する。上のアプリだと憲法前文がmecabで分かち書きされたものがブラウザに表示されていれば成功となる。 console $ eb local run --port 5000 動作を確認したら次にAWSに環境と作ってそこにアップロードする。次のコマンドで環境生成＆デプロイまで自動でしてくれる。 console $ eb create [新しい環境名] ただ、持ってくるDockerのイメージによっては「Amazon Linux 2」では動かない場合がある。上のanacondaが入ってるイメージではエラーがでてdeployできなかった。その場合は、「Amazon Linux」をプラットフォームに指定する。(こちら参照) console $ eb create [新しい環境名] -p "Docker running on 64bit Amazon Linux" アプリ更新 アプリを更新するときは、アプリのルートフォルダでeb deployと入力すればいいが、別の環境にアップロードしてURLだけスワップするのも簡単にできる。 console $ eb create [新しい環境名2] $ eb swap [新しい環境名] --destination_name [新しい環境名2]
- 投稿日：2021-06-13T01:47:14+09:00
Amazon Lookout for Metrics で始める異常検知入門 後編 ハンズオン
前置き 前編の基礎知識に引き続き、本稿では具体的な Lookout form Metrics の操作を学ぶためのハンズオンを記載する。 本稿のハンズオンにはこちらのイベントにて実施された内容が含まれています。 本編で行うハンズオンのデータセットは @kame92782224 さんがハンズオンのために用意されていたこちらのデータを使用させて頂きました。ありがとうございます。 対象読者 AWSのAI系マネージドサービスに興味のある方 AWSを使わずに異常検知モデルを構築している機械学習エンジニア 本稿で目指すゴール Lookout for Metricsの設定方法とその意味が理解できるようになること。 Lookout for Metricsを触ってみて具体的な異常検知の運用イメージをつかむこと。 2つの実験により、Lookout for Metricsを使用して異常検知を試してみる。 ハンズオン後に不要な料金がかからないように、AWSリソースのクリア方法も記載している。 実験1. backtestモードで異常検知の精度を確認する こちらはイベントのハンズオンでの実施した内容。 S3をデータソースとして履歴データを設置し、検出器を構築する。 学習完了後に推論（異常検知）の精度と発生要因を確認してみる。 データソースを用意する 今回の実験ではS3をデータソースとする。 S3にデータをアップロードする必要があるが、データ量が大きく時間がかかるため、CloudShellを使ってS3にアップロードする。この方法だとS3のコンソールからよりも数十倍早くアップロードができる。 S3バケットを作成する 適当な名前でデータソースとなるS3バケットを作成する。いまは実験のため設定はすべてデフォルトで問題ない。 CloudShell経由でS3バケットにデータをアップロードする 使用するデータはこちら。ecommerce.zip これをローカルマシンにダウンロードしておく。 AWSのCloudShellを起動する。 Actions > Upload file でecommerce.zipファイルをアップロードする。 ファイルを解凍する。 $ unzip ./ecommerce.zip 展開されたディレクトリをまとめてS3にアップロードする。 $ !aws s3 sync ./ecommerce/ s3://{s3バケット名}/ecommerce/ S3バケットの /ecommerce/ 以下にデータがアップロードされていることを確認する。 検出器を作成する Interval項目はデータのタイムスタンプカラム値のインターバルと合致している必要がある。backtestモードで使用するS3のデータを確認してみよう。 timestampカラムの値が指定したInterval項目と同じ1時間間隔であることが確認できる。 s3://{S3バケット名}/ecommerce/backtest/input.csv platform,marketplace,timestamp,views,revenue pc_web,us,2021-01-01 00:00:00,298,89.39999999999999 pc_web,uk,2021-01-01 00:00:00,476,142.79999999999998 pc_web,de,2021-01-01 00:00:00,152,45.6 ... pc_web,us,2021-01-01 01:00:00,214,64.2 pc_web,uk,2021-01-01 01:00:00,380,114.0 pc_web,de,2021-01-01 01:00:00,125,37.5 ... pc_web,us,2021-01-01 02:00:00,148,44.4 pc_web,uk,2021-01-01 02:00:00,297,89.1 pc_web,de,2021-01-01 02:00:00,106,31.799999999999997 ... すべて入力後、 Createボタンを押すと検出器が登録される。 検出器にデータセットを追加し、異常検知を開始する 登録した検出器の詳細画面に遷移する。 Amazon Lookout for Metrics > Detectors > backtest-test-1 Add a datasetボタンを押す。 データソースの設定画面に必要な値を入力する。 Historical data項目値には履歴データが存在するフォルダのS3オブジェクトキーを指定する。検出器はこのフォルダ内に在る1つ以上のデータファイルを読み込んで学習と推論を実行する。 s3://{S3バケット名}/ecommerce/backtest/input.csv 以下のように複数のデータファイルの指定も可能である。 s3://{S3バケット名}/ecommerce/backtest/20210104-20210110.csv 20210111-20210117.csv 20210118-20210125.csv また、このデータには285〜3000インターバル分のデータが必要であることに注意する。今回は検出器作成時に1時間のインターバル指定をしたため、最低でも285時間分（12日分弱）のインターバルのデータが必要である。 念の為input.csvを確認してみると、2021/01/01〜2021/09/30 の期間で1時間インターバルのデータであることがわかる。 ... mobile_app,es,2021-09-30 23:00:00,265,79.5 mobile_app,it,2021-09-30 23:00:00,193,57.9 mobile_app,jp,2021-09-30 23:00:00,631,189.29999999999998 Permissions項目では Create a roleボタンを選択し、Create a service roleダイアログで作成したS3バケット名を指定する。他の項目はデフォルトのままでよい。 入力後にNextボタンを押すと、inputするデータのメトリクスとタイムスタンプカラムを指定する画面に遷移する。 前編のデータセット項目にてメトリクスの説明をしたが、それはこの画面で設定をすることになる。 Measures欄には、データのカラムの中から異常検知の観測対象となる項目とその集計方法を選択する。集計とは、インターバル値ごとに区切られた複数のレコードの対象カラム値を観測対象値に変換する方法である。 例えば、データが以下の場合のことを考える。 platform,marketplace,timestamp,views,revenue pc_web,us,2021-01-01 00:00:00,298,89.39999999999999 pc_web,uk,2021-01-01 00:00:00,476,142.79999999999998 pc_web,de,2021-01-01 00:00:00,152,45.6 ... pc_web,us,2021-01-01 01:00:00,214,64.2 pc_web,uk,2021-01-01 01:00:00,380,114.0 pc_web,de,2021-01-01 01:00:00,125,37.5 ... pc_web,us,2021-01-01 02:00:00,148,44.4 pc_web,uk,2021-01-01 02:00:00,297,89.1 pc_web,de,2021-01-01 02:00:00,106,31.799999999999997 ... Measures指定カラムをviewsカラムとrevenueカラムだとすると、検出器はSUM値の推移を観測対象とすることになる。 タイムスタンプ値 viewsカラムSUM値 revenueカラムSUM値 2021-01-01 00:00:00 926 277.78 2021-01-01 01:00:00 719 215.7 2021-01-01 02:00:00 551 165.29 Dimensions欄には、データセットのレコードを分割するための指標となるカラムを指定する。 今回のデータを観察してみると、platform（PC / モバイル）とmarketplace（市場）という２つの指標でレコードが作成されているらしいことがわかる。これは、元データを観察した機械学習エンジニアが、プラットフォームと市場というファクターで元データを集計することが異常検知の精度向上につながると仮説をたてて前処理をし、このデータを作成したことを意味する。 入力後、Nextを押す。 最終確認画面にてSave and activateボタンを押すと、指定したデータソースを使った学習が開始される。backtestモードではデータの最初の70%を学習に、30％を推論（異常検知）に使用する。処理時間は数十分ほどかかる。 Detector一覧を確認してみる。 StatusがBacktest in progressとなったら学習が完了して推論が開始されている。異常を検知したら順次この一覧にリストアップされていく。もしアラートを設定していた場合は都度通知が実行される。 異常検知結果を確認する リストアップされた異常検知結果を確認してみる。 Amazon Lookout for Metrics > Detectors > backtest-test-1 > Anomalies 検出した異常がリストアップされている。各異常にはSeverity score（重大度スコア）という値が算出されており、一覧上部のスライダーで絞り込みが可能である。 Title列をクリックして各異常の詳細内容を確認してみる。 Measures指定カラムの観測値が推移していくなかで、検出器が異常と判定したタイミングで抽出されている。多くの異常は単一ディメンションで構成されているが、中には上記のように複数要因が絡んでいるものもある。 この例では、スペインと日本の両国でモバイルAPPの売上が急激に伸びていることを検知している。 グラフ右上の Is this relevant? のYes/Noボタンを押すと、検出器にこの異常検知結果についての関連性をフィードバックすることができる。 実験2. continuousモードで異常検知システムを運用する S3をデータソースとして履歴データと連続データを設置し、異常検知の運用を開始するまでの手順を確認してみる。 手順としては、データソースの選択欄でcontinuousモードのための設定をする以外は同じである。 データソースを用意する データソースはすでにS3にアップロードしてあるのでそれを使う。 検出器を作成する 同じ手順で問題ない。Interval項目では 1 hour intervals を選択しておく。 検出器にデータセットを追加し、異常検知を開始する Detector mode項目で、Continuousモードを選択する。 Path to an object in your continuous dataset項目には、最初に読み込ませる連続データファイルのS3オブジェクトキーを選択しておく。 s3://{S3バケット名}/ecommerce/live/20210101/0000/20210101_000000.csv そうすると、Continuous data S3 path pattern項目にて検出器に読み込ませるデータのパスのフォーマットが自動で選択肢に出てくる。パスの後ろが{{yyyyMMdd}}/{{HHmm}}のパスを選択する。検出器はこのフォーマット指定をもとにしてデータファイルをタイムスタンプ値の順番にinputするため、間違えないように注意すること。 Datasource interval項目では、検出器で指定したものと同じ 1 hour intervals を指定する。 Historical data項目はオプションである。backtestモードで指定したものと同じ履歴データファイルがあるフォルダのS3オブジェクトキーを指定しておこう。こうしておくと、検出器はまずこの履歴データで学習をしてから連続データで推論をするようになる。 もし未指定の場合、検出器は連続データの最初の285インターバル分のデータを使用して学習をし、それから推論（異常検知）をしていく。その分だけ推論の開始が遅れることになるため、基本的には指定をしておいたほうがよい。 異常検知結果を確認する backtestモードと同様に、学習が終わった後に随時異常検知のリストアップを実行していく。 continuousモードでは、データソースに継続的にデータが出力されることを前提としているため、データソース側にもデータ出力のための仕組みが必要となる。仮に検出器がデータソースからデータを読み込めない場合にはエラーが発生する（この時、欠落データとしてそのまま処理を進めるのか、処理がストップするのかは未検証）。 検出器は指定インターバルごとにデータソースからデータをコピーしてデータセットを作成し、推論を実行する。異常検知結果でのフィードバックをすることにより、異常検知の精度を高めていくことが可能である。 リソースをクリアする 一通り確認し終わったら、不要な課金をされないようにリソースを削除する。 Detector一覧でStatusが Backtest completeとなった検出器をDeleteする。 S3のバケットの中身を削除し、バケットを削除する。 所感 機械学習で最も労力を要するデータの前処理を楽にすることはできないが、それさえクリアできれば後は Lookout for Metrics がよろしくやってくれる。また、異常検知の通知や情報取得はSNSやLambdaでできるので、システムのUIも比較的簡単に構築できるという利便性は高いと思う。 Lookout for Metrics の処理プロセスは完全ブラックボックスであり、良くも悪くも開発エンジニアは関与できない。逆に言うと Lookout for Metrics で精度を高めるためのデータ前処理にだけ集中できるため、割り切って使うならばAWSに不慣れな機械学習エンジニアでもPoC案件で使用できると思われる。 いつくか注意点を挙げるとすれば、メトリクス数の制限とベンダーロックインだろうか。 現状では、Dimensions項目とMeasures項目を指定できるのはそれぞれ最大5つまでとなる。また、構築された検出器（異常検知モデル）のエクスポートはできないので、ベンダーロックインが許されない案件では使うことができないことに注意が必要である。 AWS SDKが用意されているので、データ前処理がうまく行って精度の良い検出器を作れれば、システムに組み込むことは容易にできるはず。 今回はできなかったが、いずれはAmazon AppFlow経由で外部データソースをinputするケースを試してみたい。
- 投稿日：2021-06-13T01:46:49+09:00
Amazon Lookout for Metrics で始める異常検知入門 前編 基礎知識
前置き Amazon Lookout for Metrics を使ったデータの異常検知について体系的にまとまった日本語情報がなかったので整理してみる。 書いていて長くなったので、前編と後編に分けています。 前編: 公式docsの個人的なまとめ 後編: こちらのイベントのハンズオンと個人的に試したこと 前編は Lookout for Metrics の概念と設定項目の説明となっており、人によっては後編のハンズオンから始めたほうがイメージをつかみやすいかもしれません。前篇と後編を行き来するなどしてやりやすい方法で読み進めてください。 対象読者 AWSのAI系マネージドサービスに興味のある方 AWSを使わずに異常検知モデルを構築している機械学習エンジニア 本稿で目指すゴール Lookout for Metricsの設定方法とその意味が理解できるようになること。 Lookout for Metricsを触ってみて具体的な異常検知の運用イメージをつかむこと。 Amazon Lookout for Metricsとは Amazon Lookout for Metricsとは、機械学習を使って時系列データから異常を検出し、その発生原因の抽出までを一貫して運用管理できるサービスである。 データソースにはAWSのS3やCloudWatch、RDS、RedShift、加えて様々な外部サービスを指定できる。 異常検知時は重大度スコアを算出してその発生要因となった項目値を抽出する。 検知時に通知先としてAWSのLambdaやSNSを指定できる(要するにどこにでも通知可能)。 「異常」の定義 ここでいう異常とはどんな状態を指すのか。 具体的には、時系列データにおいて観測対象の値が一定の推移パターンから乖離している状態のことである。 異常と言うと悪い状態のイメージがあるが、その状態の良し悪しは人間が判断するものであり、Lookout for Metrics はそのような意味付けまではしない。 異常検知結果の詳細コンソール。観測対象の値（売上）の急激UPを検知している例。 実行モード Amazon Lookout for Metricsには、用途に分けて2種類の実行モードが存在する。 backtestモード 過去の履歴データを用いて検出器を学習し、同時に推論（異常検知）を実行する。履歴データの70％は学習に、30%は推論に使われる。 後述のcontinuousモードで異常検知を継続運用する前段階として、そのデータでどの程度の精度が出せる検出器を構築できるかを試行錯誤する用途で使用する。 continuousモード 異常検知を継続運用するためのモードである。 履歴データ、連続データの両方を指定時は、履歴データを学習に使用してから連続データで推論（異常検知）を行う。 連続データのみを指定時は、連続データの最初を学習に使用してから連続データで推論（異常検知）を行う。 連続データは継続的にデータソースに提供されることが前提である。 指定インターバルでデータソースからデータをinputし、推論（異常検知）を繰り返し実行する。 データについて 本格的に運用する場合は、backtestモード使用の際に未処理データの前処理を行うための機械学習の知見が必要となる。加えて、データソース側で適切なデータ出力設計もせねばならない。 一応サンプルデータの作成はこちらのスクリプトを使えばできるようである。 後編で行うハンズオンのデータセットは @kame92782224 さんがハンズオンのために用意されていた以下のデータを使用させて頂きました。ありがとうございます。 Amazon Lookout for Metricsの基礎知識 Detector（検出器） 検出器は時系列データを監視する異常検知モデルであり、最初に登録するリソースである。 異常検知を始めるには、登録した検出器に時系列データで学習させる必要がある。 登録時には時系列データをデータソースからインプットする間隔（5m/10m/1h/1d）を指定せねばならない。 Datasource（データソース） 検出器で使用するデータを提供するサービス、もしくはリソースである。 AWSでは S3/CloudWatch/RDS/Redshift が対応している。 他にも、Amazon AppFlow のデータ転送経由で様々な外部サービスをデータソースとして連携可能である。 データの種類 データソースにはLookout for Metricsの実行モード別に必要とされる以下2種類のタイプがある。 Historical data / Continuous data backtestモード continuousモード Historical data 必須 必須ではない(※1) Continuous data - 必須 Historical data（履歴データ） backtestモード実行時には必須となるデータソース。 backtestモードを実行時、その70%は学習に、30％は推論（異常検知）のために使用される。 実行のためには、時系列を表現するタイムスタンプカラムに285〜3000のインターバル分の値が格納されたデータが必要となる。例えば、検出器登録時に指定するインターバル値を1h（1時間）とした場合、タイムスタンプカラムが285時間〜3000時間の範囲のデータが必要となる。 ※1: continuous実行モードでは指定は必須ではない。もし未指定の場合は、連続データでの学習が必要となるため、推論が開始されるタイミングが遅れることに注意。指定時は検出器は履歴データで学習を実行した後に連続データで推論（異常検知）を開始する。 Continuous data（連続データ） continuousモード実行時に指定をするデータソース。 continuousモードの性質上、継続的にデータソースにデータとして提供されることが前提となる。そのため、データソース側にもデータの継続出力のためのなんらかの仕組みが必要となる。 continuousモード実行時、履歴データを未指定の場合はこのデータを学習に使用する。学習は古いデータから順に使われる。推論（異常検知）の開始はその分だけ遅れることになる。 Dataset（データセット） データセットとは、学習と推論を実行する時にデータソースから検出器にコピーしたデータである。データセットには以下の要素が含まれる必要がある。 タイムスタンプカラム データを時系列で分析するために、Lookout for Metrics が検知可能なタイムスタンプを表現するカラム。 値は検出器登録時に指定したインターバル（5m/10m/1h/1d）で出力されている必要がある。 検出器が値を認識するために、タイムスタンプ値のフォーマットを指定せねばならない。 Metrics（メトリクス） ディメンション 元データをレコード単位に分割するための指標となるカラム。異常検知の精度に影響を与える。検出器にデータセットを学習にかける際、最大5つまで指定可能。 メジャー 異常検知を行う対象となる値。項目と集計方法を指定する。検出器にデータセットを学習にかける際、最大5つまで指定可能。 メトリック ディメンション項目とメジャー項目の組み合わせ。 補足 機械学習プロジェクトの成否を左右する最も重要なファクターは学習データの質と量である。 精度の良いモデルを構築するためには、まず顧客から受け取った前処理をしていないデータをよく観察することから始める。そして、精度向上に必要な特徴量を抽出するための仮説を立て、学習に使えるデータを作成する必要がある。これが一般的な機械学習プロジェクトのファーストアプローチである。 Lookout for Metrics を使う際も同様である。 検出器を作成するための学習モデルはAmazonが過去20年の研究開発を経て作り上げた優秀なモデルが使用されるようだが、データソースに提供されるデータの質が悪い場合は当然ながら実運用に使えるだけの異常検知精度は出せない。求められる精度を出せる検証器が構築されるまで、データの前処理とbacktestモードの実行を繰り返すことになると思われる。ここは機械学習の知見が要求される、もっとも労力を要するフェーズである。 Alerts（検知アラート） 検出器が異常を検知した時は、通知先にSNSやLambdaを指定できる。 Anomalies（検知結果） 異常検知一覧 異常検知詳細 検知した異常は検出器別に一覧でリストアップされ、詳細画面でその発生要因を確認することができる。このレポートには異常発生の要因となるメトリクスとその関連性情報が表示されている。 ユーザーはその情報を確認し、検出器にその関連性をフィードバック提供することができる。検出器はこのフィードバックを利用してさらに学習を進め、異常検知の精度を向上させることができる。 費用について 後編では、実際に Lookout for Metrics をコンソールから操作するハンズオンを行う。 backtestモードとcontinuousモードで異常検知を運用することによって、より具体的な利用イメージを持てるようになることを目指す。
- 投稿日：2021-06-13T00:08:40+09:00
AWS 認定 ソリューションアーキテクト – アソシエイト(SAA)取得のための勉強方法
はじめに AWS認定クラウドプラクティショナー(CLF)を取得した後、約5か月間の勉強期間を経てSAAを取得しました。 本記事ではSAA取得のために行った勉強方法を共有いたします。 SAAの勉強方法 以下の本をテキストとして使用しました。当時は初版でしたが、改訂版が出ていますので、そのリンクを張っておきます。 問題も掲載されていますが、初級(CLF)受験時に問題演習不足を実感したため、別途問題集を使用しました。当時は2019年版でした。 この問題集は解説が明快で、著者（Neal Davis）がAWSについて深く理解していることが実感できました。私が使用したのはペーパーバック版で、線を引く、ネットで調べた内容を書き込むといった使い方をしました。 余談ですが、青の油性ボールペンが使いやすいです。AWSのサービス名を白紙に書いて覚える、図にまとめる、テキストに線を引く等、全て1本でまかなえます。黒や赤のボールペンも試してみましたが、黒はテキストの文字色と区別がつきにくく、赤は色が強すぎると感じたため、青に落ち着きました。 試験本番 試験準備で多めに問題演習をしたため、実際の試験では自信をもって解答することができました。初級(CLF)と同様、SAAもあまり問題文が長くないため、時間的にも余裕がありました。 結果は合格で、試験後すぐに上級(SAP)の試験準備を開始しました。