What's New Qiita

20200812のAWSに関する記事は25件です。

  • 投稿日：2020-08-12T23:15:58+09:00

wwwなしの、SSL(https)にリダイレクトしたいときのNGINXの設定 -Route 53 + ELB (ACM) + EC2構成-

全てのトラフィックをwwwなしの、SSL(https)にリダイレクトしたい

結論

長いので先に結論だけ書きます

  • SSL証明にACMを使い、ELBに証明書が適応されている状態を想定

  • ELB <-> EC2の接続がHTTP: 80の場合、NGINXはport 80でlistenする （ここの気付きが重要でした）

  • NGINXによるリダイレクトはwwwあり->wwwなしのみでよい

  • httpsリクエストをNGINXの80で受けるという設定に戸惑ったが、動作上これで良さそう

現状と目標

httpsかつ、wwwなしのドメインをリクエストしないとSSL接続されない

理想は以下の全ての条件でSSL接続にリダイレクトしたいが現状は

# wwwあり
http://www.mdclip.xyz -> http://mdclip.xyz  (no SSL)
https://www.mdclip.xyz ->  http://mdclip.xyz (no SSL)

# wwwなし
http://mdclip.xyz -> http://mdclip.xyz (no SSL)
https://mdclip.xyz -> https://mdclip.xyz (SSL)

環境

  • DNS (Route 53) -> ELB -> EC2 (NGINX -> Puma)
  • SSL証明: ACM
  • Rails 6 (config/environments/production.rb: config.force_ssl = true)

NGINXの設定はnginx.confに書く？conf.d/*.confに書く

NGINXの設定はnginx.confに記述されているが
その中で/etc/nginx/conf.d/*.confがincludeされており
conf.d以下の内容が呼び出されるようになっている

記事によってこの辺りが曖昧でどのように使い分けるか把握しにくかったが
以下の記事をもとにイメージを掴むことができた

参考: nginx連載3回目: nginxの設定、その1 - インフラエンジニアway - Powered by HEARTBEATS

NGINXではserverディレクティブ（サーバー個別の設定、server {...}で記述される）で定義された
仮想サーバーを複数稼働させることができる
そして、このバーチャルサーバー毎の設定を置く場所がconf.d以下とのこと

なのでconf.d以下のfoo.confには単一のサーバーについての記述に留め
複数のserverディレクティブが記述されているような運用は良くないのかもしれない

ただし、今回conf.d以下の設定ファイルにドメイン間のリダイレクトを担う
serverディレクティブを複数配置してみたが、動作上は問題なさそうでした

全てのトラフィックをwwwなしの、SSL(https://)にリダイレクトしたい場合のNGINXの設定

結論

後述の内容から、以下のように書けば良いと理解した

server {
    listen 80; 
    server_name example.com;
    return 301 https://example.com$request_uri;
}
server {
    listen 80;
    listen 443 ssl; 
    server_name www.example.com; 
    return 301 https://example.com$request_uri;　
}

もしくは

server {
    listen 80; 
    server_name example.com www.example.com;
    return 301 https://example.com$request_uri;
}
server {
    listen 443 ssl; 
    server_name www.example.com; 
    return 301 https://example.com$request_uri;　
}

wwwなし -> wwwあり（その逆パターン）

# add 'www'
server {
    listen 80;　#非SSL
    listen 443 ssl; #SSL こうやって2つ指定できる
    server_name example.com; #wwwなしを
    return 301 $scheme://www.example.com$request_uri; #wwwありへ
}

# 上記と同意
server {
    listen 80;　#非SSL
    server_name example.com;
    return 301 $scheme://www.example.com$request_uri;
}

server {
    listen 443 ssl; #SSL 
    server_name example.com;
    return 301 $scheme://www.example.com$request_uri;
}


# remove 'www'
server {
    listen 80; #非SSL
    listen 443 ssl; #SSL 
    server_name www.example.com; #wwwありを
    return 301 $scheme://example.com$request_uri;　#wwwなしへ
}

参考: How to Create NGINX Rewrite Rules | NGINX

Adding and Removing the www Prefix

These examples add and remove the www prefix:

# add 'www'
server {
listen 80;
listen 443 ssl;
server_name domain.com;
return 301 $scheme://www.domain.com$request_uri;
}

# remove 'www'
server {
listen 80;
listen 443 ssl;
server_name www.domain.com;
return 301 $scheme://domain.com$request_uri;
}

Again, return is preferable to the equivalent rewrite, which follows. The rewrite requires interpreting a regular expression – ^(.*)$ – and creating a custom variable ($1) that in fact is equivalent to the built‑in $request_uri variable.

# NOT RECOMMENDED
rewrite ^(.*)$ $scheme://www.domain.com$1 permanent;

http(非SSL) -> https(SSL)にリダイレクト

# http(非SSL) -> https(SSL)に転送
server {
    listen 80; 
    server_name www.example.com;
    return 301 https://www.example.com$request_uri;
}

古いドメインから新しいドメインに移行する場合などは
敢えて$request_uriを省略することでホームページへ都度リダイレクトすることも可能

参考: How to Create NGINX Rewrite Rules | NGINX

Example – Forcing all Requests to Use SSL/TLS

This server block forces all visitors to use a secured (SSL/TLS) connection to your site.

server {
 listen 80;
 server_name www.domain.com;
 return 301 https://www.domain.com$request_uri;
}

Some other blogs about NGINX rewrite rules use an if test and the rewrite directive for this use case, like this:

# NOT RECOMMENDED
if ($scheme != "https") {
 rewrite ^ https://www.mydomain.com$uri permanent;
}

But this method takes extra processing because NGINX must both evaluate the if condition and process the regular expression in the rewrite directive.

全てのトラフィックを特定のドメインにリダイレクト

server {
    listen 80 default_server; # http://
    listen 443 ssl default_server; # https://
    server_name _; # "_"全一致
    return 301 $scheme://www.example.com;
}

参考: How to Create NGINX Rewrite Rules | NGINX

Redirecting All Traffic to the Correct Domain Name

Here’s a special case that redirects incoming traffic to the website’s home page when the request URL doesn’t match any server and location blocks, perhaps because the domain name is misspelled. It works by combining the default_server parameter to the listen directive and the underscore as the parameter to the server_name directive.

server {
listen 80 default_server;
listen 443 ssl default_server;
server_name _;
return 301 $scheme://www.domain.com;
}

We use the underscore as the parameter to server_name to avoid inadvertently matching a real domain name – it’s safe to assume that no site will ever have the underscore as its domain name. Requests that don’t match any other server blocks in the configuration end up here, though, and the default_server parameter to listen tells NGINX to use this block for them. By omitting the $request_uri variable from the rewritten URL, we redirect all requests to the home page, a good idea because requests with the wrong domain name are particularly likely to use URIs that don’t exist on the website.

rewriteよりもreturnを用いることが望ましい理由

  • if...処理を都度行うことは効率的でない.
  • rewriteを用いるとNGINXが正規表現を処理する必要があり効率的でない.
  • ヒトにとってもNGINXが301コードを返すことが明示的で解釈しやすい.

以上を踏まえたNGINXの設定(NG)

nginx.conf
いずれのバーチャルサーバーにも該当しない場合のトラフィックを受ける
default_serverについての記述のみ残しました

user nginx;
worker_processes auto;
error_log /var/log/nginx/error.log;
pid /run/nginx.pid;

include /usr/share/nginx/modules/*.conf;

events {
    worker_connections 1024;
}

http {
    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    access_log  /var/log/nginx/access.log  main;

    sendfile            on;
    tcp_nopush          on;
    tcp_nodelay         on;
    keepalive_timeout   65;
    types_hash_max_size 2048;

    include             /etc/nginx/mime.types;
    default_type        application/octet-stream;

    include /etc/nginx/conf.d/*.conf;

    server {
        listen       80 default_server;
        listen       [::]:80 default_server;
        server_name  _;
        root         /usr/share/nginx/html;

        # Load configuration files for the default server block.
        include /etc/nginx/default.d/*.conf;

        location / {
        }

        error_page 404 /404.html;
            location = /40x.html {
        }

        error_page 500 502 503 504 /50x.html;
            location = /50x.html {
        }
    }
}

conf.d/app.conf

error_log  /var/www/myapp/shared/log/nginx.error.log;
access_log /var/www/myapp/shared/log/nginx.access.log;

upstream myapp {
    server unix://var/www/myapp/shared/tmp/sockets/puma.sock;
}

##　#1 以下の２つのserverディレクティブで, wwwなしのhttpsにリダイレクト
# http > https
server {
    listen 80;
    server_name example.com;
    return 301 https://example.com$request_uri;
}
# www > no_www
server {
    listen 80;
    listen 443 ssl;
    server_name www.example.com;
    return 301 https://example.com$request_uri;
}


server {
    listen 443 ssl; # #2 httpsで受ける
    client_max_body_size 4G;
    server_name example.com;

    keepalive_timeout 5;

    # Location of our static files
    root /var/www/myapp/current/public;

    location ~ ^/assets/ {
    root /var/www/myapp/current/public;
    }

    location / {
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $http_host;
        proxy_redirect off;

        if (!-f $request_filename) {
            proxy_pass http://myapp;
            break;
        }
    }

    error_page 500 502 503 504 /500.html;
    location = /500.html {
        root /var/www/myapp/current/public;
    }
}

ところがこの時点での結果は、

# wwwあり
http://www.mdclip.xyz -> http://www.mdclip.xyz  (no SSL)
https://www.mdclip.xyz ->  https://www.mdclip.xyz (SSL)

# wwwなし
http://mdclip.xyz -> http://mdclip.xyz (no SSL)
https://mdclip.xyz -> https://mdclip.xyz (SSL)

スクリーンショット 2020-08-12 22.19.34.png

しかも全てのトラフィックがPumaではなくdefault_serverに到達してしまった

以下再度検証へ...

最終検証・解決

AWS Route 53

example.comだけでなく、www.example.comのAレコードについても
ルーティング先にELBのエイリアスを指定する必要がありました

これがないとWWWありのリクエストがNGINXまで到達せず

”サーバーが見つからない”エラーが出ます

ELBの設定を確認

スクリーンショット 2020-08-12 21.07.01.png

Target groupの設定はEC2インスタンスにHTTP: 80で接続するようになっていました
（ここもHTTPS: 443に変更する方法もあるようです）

この状況を図にすると
（これがやりたかった！）

traffic_flow.png

重要なのはHTTPSリクエストに対しても
EC2は80ポートでELBと接続されているということ
(言葉が不適切でしたら訂正願います)

だから

  • NGINX側は443ではなく80でlistenする必要がある
  • 443 > 80へのリダイレクトはNGINXで設定不要(上図の緑の部分のみでいい)

NGINXの設定（再・OK）

nginx.conf
ここは変わりなし

user nginx;
worker_processes auto;
error_log /var/log/nginx/error.log;
pid /run/nginx.pid;

include /usr/share/nginx/modules/*.conf;

events {
    worker_connections 1024;
}

http {
    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    access_log  /var/log/nginx/access.log  main;

    sendfile            on;
    tcp_nopush          on;
    tcp_nodelay         on;
    keepalive_timeout   65;
    types_hash_max_size 2048;

    include             /etc/nginx/mime.types;
    default_type        application/octet-stream;

    include /etc/nginx/conf.d/*.conf;

    server {
        listen       80 default_server;
        listen       [::]:80 default_server;
        server_name  _;
        root         /usr/share/nginx/html;

        # Load configuration files for the default server block.
        include /etc/nginx/default.d/*.conf;

        location / {
        }

        error_page 404 /404.html;
            location = /40x.html {
        }

        error_page 500 502 503 504 /50x.html;
            location = /50x.html {
        }
    }
}

conf.d/app.conf

error_log  /var/www/myapp/shared/log/nginx.error.log;
access_log /var/www/myapp/shared/log/nginx.access.log;

upstream myapp {
    server unix://var/www/myapp/shared/tmp/sockets/puma.sock;
}

# www > no_www
server {
    listen 80;　#443は不要
    server_name www.example.com;
    return 301 https://example.com$request_uri;
}

server {
    listen 80; #80でlisten
    client_max_body_size 4G;
    server_name example.com;

    keepalive_timeout 5;

    # Location of our static files
    root /var/www/myapp/current/public;

    location ~ ^/assets/ {
    root /var/www/myapp/current/public;
    }

    location / {
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $http_host;
        proxy_redirect off;

        if (!-f $request_filename) {
            proxy_pass http://myapp;
            break;
        }
    }

    error_page 500 502 503 504 /500.html;
    location = /500.html {
        root /var/www/myapp/current/public;
    }
}

これで以下のように目標が達成されました

# wwwあり
http://www.mdclip.xyz -> https://mdclip.xyz  (SSL)
https://www.mdclip.xyz ->  https://mdclip.xyz (SSL)

# wwwなし
http://mdclip.xyz -> https://mdclip.xyz (SSL)
https://mdclip.xyz -> https://mdclip.xyz (SSL)

おまけ

AmazonLinux環境でのNGINX関連コマンド

設定をリロード

sudo systemctl reload nginx

再起動

sudo systemctl restart nginx

起動

sudo systemctl start nginx

終了

sudo systemctl stop nginx

NGINXのプロセスを確認 (残ったプロセスをkillするときなど)

sudo lsof -i | grep nginx
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-08-12T22:27:05+09:00

【AWS S3】静的ウェブサイトの設定方法

はじめに

Route53に登録されたカスタムドメインを使用した静的ウェブサイトの設定のサイトを元に、静的ウェブサイトを作成したい。（すでに作成したため、画像が一番はじめに作成したものと一部異なる場合がございますが、あらかじめご了承ください。）

手順

ドメイン購入

AWSでドメイン購入すると高いので（作成時点だと$9~だった）、基本的に1円〜購入可能であるお名前.comで購入する。取得方法はこちら。（サーバー購入はする必要なし。）

バケット作成

ルートドメインバケットを今回は例としてhoge.workとする。（実際は先ほど購入したドメイン名にして下さい。）
「S3」>「バケットを作成する」を選択。
スクリーンショット 2020-08-12 20.24.37.png
バケット名(hoge.workなど先ほど購入したドメイン名に合わせると良い)を入力。
リージョンは日本に住んでいれば、「アジアパシフィック(東京)」を選択する。
後はデフォルトの設定のままで、作成を押す。
スクリーンショット 2020-08-12 20.26.52.png

バケットの設定

先ほど作成したルートドメインバケットを選択する。
スクリーンショット 2020-08-12 20.34.53.png
「プロパティ」>「静的ホスティング」を選択。
スクリーンショット 2020-08-12 21.17.33.png
「このバケットを使用してウェブサイトをホストする」を選択する。
インデックスドキュメント名index.html、エラードキュメントerror.htmlと入力する。保存を選択する。
スクリーンショット 2020-08-12 21.22.58.png

サーバーアクセスのログ記録を有効化

同じリージョンで、ログ記録用のバケットを作成。（名前の例：logs.hoge.com）(適宜自分の作成したドメイン名で変更する。一意でないとダメなので、すでに存在するようなら、一意になるような名前にする。)
スクリーンショット 2020-08-12 20.24.37.png
作成したバケットに入り「概要」>「フォルダの作成」でログファイル用のフォルダを作成。 (名前の例:logs）
スクリーンショット 2020-08-12 21.35.51.png
ルートドメインバケットに入り、「プロパティ」>「Server access logging (サーバーアクセスのログ記録)」を選択。「ログの有効化」を選択する。ターゲットバケットで、下記項目を入力。
・ログファイル用に作成したバケット (logs.example.comなど)
・「ターゲットプレフィックス」 に、ログファイル用に作成したフォルダの名前に続けて区切り記号 (/) を入力(例:logs/)
「保存」を選択。
※ログは「概要」でみれる。
スクリーンショット 2020-08-12 21.41.58.png

アップロード

index.htmlを作成する。
ローカルのエディタで下記内容を入力し、index.htmlで保存する。（大文字ではなく。小文字でindex.htmlとする。）

<html xmlns="http://www.w3.org/1999/xhtml" >
<head>
    <title>My Website Home Page</title>
</head>
<body>
  <h1>Welcome to my website</h1>
  <p>Now hosted on Amazon S3!</p>
</body>
</html>

「ルートドメインバケット」>「概要」>「アップロード」を選択。
スクリーンショット 2020-08-12 21.50.20.png
先ほど作成したindex.htmlを追加し、アップロードする。
スクリーンショット 2020-08-12 21.51.53.png
「ルートドメインバケット」のバケットを選択し、「パブリックアクセス設定を編集する」を選択する。
スクリーンショット 2020-08-12 21.54.42.png
「Block all public access (すべてのパブリックアクセスをブロックする)」のチェックをはずし、[保存] を選択。
スクリーンショット 2020-08-12 21.57.10.png
確認を入力し、「確認」を選択する。
スクリーンショット 2020-08-12 21.58.11.png
「ルートドメインバケット」のバケットに入り、「アクセス権限」>「バケットポリシー」で以下のように入力する。
スクリーンショット 2020-08-12 21.59.24.png

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "PublicReadGetObject",
            "Effect": "Allow",
            "Principal": "*",
            "Action": [
                "s3:GetObject"
            ],
            "Resource": [
                "arn:aws:s3:::hoge.work/*"
            ]
        }
    ]
}

Resource内のexample.workは作成したバケット名に合わせる。
入力したら、「保存」を押す。

「プロパティ」>「静的ウェブサイトホスティング」で「エンドポイント」の横のURLを選択し、ブラウザにindex.htmlページが表示されれば、成功。
スクリーンショット 2020-08-12 21.17.33.png
スクリーンショット 2020-08-12 21.22.58.png
スクリーンショット 2020-08-12 22.07.41.png

エイリアスレコードを追加

「Route53」>「ホストゾーン」を選択。
スクリーンショット 2020-08-12 22.09.04.png
「ホストゾーンの作成」を押し、「ドメイン名」で作成したドメインを入力。タイプは「パブリックホストゾーン」とする。「作成」を押す。
スクリーンショット 2020-08-12 22.10.40.png
作成したドメインを選択し、「レコードセットの作成」を選択する。
下記の項目を確認・選択する。
名前　何も入力せず、そのままとする。

タイプ:「A – IPv4 アドレス」を選択。
エイリアス:「Yes」を選択。
エイリアス先:リストの「S3 website endpoints (S3 ウェブサイトエンドポイント)」セクションで、バケット名を選択。
ルーティングポリシー:デフォルト値の「Simple」をそのまま使用。
ターゲットの正常性の評価:デフォルト値の「No」をそのまま使用。

「作成」を選択する。
スクリーンショット 2020-08-12 22.10.40.png

ネームサーバーがお名前.comのままになっているので、変更する。お名前.comのネームサーバの変更の仕方はこちら
該当ドメインのNSレコードの値4つを「その他のネームサーバーを使う」に入力する。保存したら、変更されるまでしばらく待つ。

ウェブサイトを確認

ブラウザで、URLを入力。ドメイン 例：http://hoge.work。
下記のように出れば成功。
スクリーンショット 2020-08-12 22.07.41.png

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-08-12T21:43:22+09:00

小技: S3 のバケットの中のファイルを一斉書き換え

S3 の間でファイルを一斉に移動させた時などに ACL で public read が付与されていなかったり、SVG ファイルの metadata がなぜか binary/octat-stream になってて image/svg+xml でなかったりしました。

なので、シェルスクリプトで一括で変換できるスクリプトを作りました。

PREFIX で、特定のフォルダ (Key) のみに限定して実行させることもできるようにしました。

特定 Bucket の prefix に ACL public read を加える

シェル

s3-bucket-acl.sh
# /bin/bash
BUCKET=$1
PREFIX=$2
for KEY in $(aws s3api list-objects \
  --bucket ${BUCKET} | jq -r '.Contents[].Key')
  --prefix ${PREFIX}\
do
  aws s3api put-object-acl \
    --bucket ${BUCKET} \
    --key ${KEY} \
    --acl public-read
  echo "${BUCKET}/${KEY}"
done

実行例

sh s3-bucket-acl.sh [バケット名] [プリフィックス]

SVG 形式のファイルに正しい image/svg+xml の content-type を付与する

s3-bucket-svg.sh
# /bin/bash
BUCKET=$1
PREFIX=$2
for KEY in $(aws s3api list-objects \
    --bucket ${BUCKET}\
    --query "Contents[].[Key]" \
    --output text | grep "\.svg$")
    do
    aws s3api copy-object \
    --bucket ${BUCKET} \
    --copy-source ${BUCKET}/${KEY} \
    --key ${KEY} \
    --metadata-directive "REPLACE" \
    --content-type "image/svg+xml"
    echo "${BUCKET}/${KEY}"
    done

実行例

sh s3-bucket-svg.sh [バケット名] [プリフィックス]
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-08-12T20:52:45+09:00

AWSサーバレスでSPARQLエンドポイントを構築(Apache Jena編)

AWSサーバレスでSPARQLエンドポイントの構築を試してみた第2弾です。
第1弾はこちらです。

AWSサーバレス環境でSPARQLエンドポイントを作ろうとしたが上手くいかなかった話
https://qiita.com/uedayou/items/bdf7a802e27fe330044e

前回は利用したライブラリの関係で検索速度に難があり限定した用途であれば使える、という感じでした。
今回はRDFストアとしては実績があるApache Jenaを使ってみました。

環境

前回と同じくAWS Lambda+API Gatewayという構成です。
Apache Jena は

を使用しています。
TDBで使う方法以外にRDFファイルを直接使用することもできますが、以下の結果も踏まえてTDBに変換して使用することをお勧めします。

ソースコードは以下で公開しています。
https://github.com/uedayou/jena-sparql-server-aws-serverless

クエリ検索時間計測

検索にかかる時間は

  • TDBを使用する方法
  • RDFファイルを直接利用する方法

の2つについて計測しています。TDBは一旦ZIP圧縮したものをデプロイしています。

SPARQLクエリ

クエリは前回と同じです。
データセットも前回と同じく「図書館及び関連組織のための国際標準識別子（ISIL）」試行版LODを使いました。
分割されたTurtleファイルを1つずつ追加して作成したデータセット毎(RDFファイルは全ファイルを統合したもののみ)に計測しています。

(1) トリプルを100件取得

select * where {?s ?p ?o} limit 100

(2) 全トリプル数を取得

select (count(*) as ?count) where {?s ?p ?o}

(3) filterを使って文字列の絞り込み

prefix schema: <http://schema.org/>
prefix org:   <http://www.w3.org/ns/org#>
prefix dbpedia: <http://dbpedia.org/ontology/>

select * where {
  ?uri dbpedia:originalName ?name;
  org:hasSite/org:siteAddress/schema:addressRegion ?pref.
  filter( regex(?pref, "東京") )
}
limit 10

TDBの結果

TDBを使えばかなり高速に検索ができました。
ただ、AWS Lambdaはコンテナが生成される場合にその初期化とZIP圧縮されたTDBを解凍する時間が追加かかるため(一度生成されてしまえばしばらくはそのコンテナが再利用される)、その時(例えば初回起動時やしばらく実行がなくコンテナが破棄された状態の場合)にはそれらの処理の時間がかかり、今回使用したファイルでは約4秒ほどかかりました。
以下はコンテナがすでに生成されているときの時間です。コンテナ未生成時は以下の時間に＋4秒かかることになります。
前回は10秒以上かかるクエリもあり単純なクエリでも場合によってはタイムアウトで検索結果が得られないことが起こり得ました。
TDBコンテナ生成が必要な時でも5秒以内には結果が取得でき、よっぽど複雑なクエリでなければタイムアウトはしないと思います。

トリプル数 (1) (2) (3)
21,788 242ms 494ms 159ms
42,585 254ms 531ms 102ms
63,448 148ms 502ms 67ms
84,587 166ms 504ms 100ms
104,826 154ms 572ms 85ms
124,718 176ms 367ms 112ms
144,669 153ms 583ms 80ms
160,491 141ms 579ms 104ms

RDFファイルの結果

RDFファイルを直接利用する場合は、TDBよりも時間がかかりました。
以下はTDBと同じくコンテナ生成時の時間ですが、TDBよりも初期化に時間がかかりました(約7秒)。
TDBはZIPの解凍処理も入るのに、RDFファイルを使うほうが初期化の時間がかかるのは調べてみないとよくわかりませんが、それを差し引いてもTDBを使うほうが良いと思いました。

トリプル数 (1) (2) (3)
160,491 1587ms 1664ms 1215ms

まとめ

  • (個人的には)実用に耐えうる検索速度が出せるSPARQLエンドポイントがサーバレス環境で構築できた
  • AWS Lambdaのコールドスタート問題？によりコンテナ生成時に数秒時間がかかる
  • RDFファイルを直接利用するのではなくTDBに変換したほうがよい

Apache Jenaを使うAWSサーバレス版SPARQLエンドポイントは個人的には満足できるパフォーマンスだと思いますので、今後いろいろ使いたいと思います。

早速、鉄道オープンデータ提供サイト鉄道駅LODのSPARQLエンドポイントをApache Jena版に変更しました。

実際に試してみたい人は、以下の記事を参照してください。

鉄道駅LODのSPARQLエンドポイントを実験的に公開しました
https://qiita.com/uedayou/items/3ba823c5d3bede12af9c

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-08-12T19:22:44+09:00

aws ec2のRHEL8にrdp接続する

前提

  • cloud

    • AWS

  • ami

    • ami-07dd14faa8a17fb3e

必要なパッケージをinstall

yum update -y
dnf install https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm -y
yum install -y gcc-c++ make ksh sysstat xorg-x11-utils java-11-openjdk-devel libnsl
dnf group install "Server with GUI" -y
dnf install xrdp -y
systemctl enable xrdp --now

まとめ

  • OracleDBの検証にGUIが必要だったのでEC2のRHEL８にRDP接続してみました、もっと良い方法とか、ご指摘御座いましたらお願い致します。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-08-12T18:17:35+09:00

【サーバーレス初心者向け】Serverless Framework + SwaggerでWeb APIを作る！第2回 WAF適用編(全3回)

はじめに

こんにちは！
本記事は先日公開した【サーバーレス初心者向け】Serverless Framework + SwaggerでWeb APIを作る！第1回(全3回)の続きとなります。

前回はSwaggerで記載したAPI定義を取り込んだAPI Gatewayと簡単なメッセージを返すだけのLambda関数を実装し、Serverless Frameworkを使ってAWSへデプロイするところまで行いました。

第2回ではAWS WAFを適用し、特定のIPからしかAPI Gatewayにアクセスできないようにします。これはAPI Gatewayはパブリックに公開されてしまうので、なにもアクセス制限をしないとURLさえ知っていればアクセスできてしまうためです。IP制限をかけることで安心して開発ができるようになります。

今回作るもの(再掲)

今回は以下のアーキテクト図のようなWeb APIバックエンドを作っていきます。
API GatewayでクライアントからのAPIリクエストを受信し、該当するLambda関数を呼び出し、必要に応じてDynamoDBからのデータ読み出しおよび書き込みを行います。さらに、WAFを適用することでセキュアにします。

slsTestAppArchitect.png

APIとしては、ID・名前・身長・体重・年齢の情報を持つPersonモデルを登録・取得・更新・削除するAPIを作りたいと思います。

  • GET dev/slsTestApp/v1/api/person/{id}
  • POST dev/slsTestApp/v1/api/person
  • PUT dev/slsTestApp/v1/api/person/{id}
  • DELETE dev/slsTestApp/v1/api/person/{id}

第1回目の記事では、具体的なAPIロジックは実装せず、簡単なメッセージを返すだけのLambda関数をバックエンドとするAPI Gatewayを作りました。第2回となる本記事ではWAFを適用していきます。

AWS WAFについて

AWS WAFはCloudFront、API Gateway、ALBなどへのアクセス制限をかけることができるマネージドサービスです。
2019年11月にアップデートが行われており、CloudFromationのテンプレートのリソース名ではAWS::WAFv2と表現されます(古いバージョンはAWS::WAFとAWS::WAFRegional)。

GlobalなWAFとRegionalなWAF

AWS WAFには大きく分けて二種類あり、一つはリージョンを持たないグローバルなAWSサービスに紐づけるGlobalなWAFと、もう一つはリージョンを持つAWSサービスに紐づけるRegionalなWAFです。
簡単にいうと、

  • GlobalなWAF →　CloudFront
  • RegionalなWAF → API Gateway、ALBほか

という関係になります。それぞれ旧バージョンのWAFではAWS::WAFとAWS::WAFRegionalで表現されます。
新バージョンのWAFv2ではGlobalかRegionalかでリソースは分かれず、Scopeプロパティでどちらにするかを指定する方式に変わりました。

ここまで大雑把に新旧のWAFについて説明してきましたが、本記事では新バージョンのWAFv2を使うこととします。
以降、WAFと記載してもそれはWAFv2を指すこととします。

WAFの構成要素

今回はIP制限を掛けるため、以下の三つが大きな構成要素となります。

  • IPセット
  • WebACL
  • Association

各要素について、簡単な説明とテンプレート例を示します。

IPセット

対象のIPを配列形式で指定します。
ここで作成するのはIPのリストのみです。WebACLのアクセスルールでこのIPリストにあるもののみ通信を許可するか(ホワイトリスト形式)、反対にこのIPリストにあるもののみ通信を拒否するか(ブラックリスト形式)選ぶことができます。ほとんどの場合は前者のホワイトリスト形式だと思います。

テンプレート例は以下の通りです。WebACLを構築時にIPセットのArnを指定する必要があるため、OutputsでArnを出力するようにしています。
IPは皆さんの自宅のIPなどを指定してください。

waf-ipset.yml
Resources:
  SlsTestAppIPSet:
    Type: AWS::WAFv2::IPSet
    Properties:
      Addresses:
        - ${self:provider.environment.ALLOWEDIP}
      Description: IP set for slsTestApp Access.
      IPAddressVersion: IPV4
      Name: SlsTestAppAPIAllowedIPSet
      Scope: REGIONAL
Outputs:
  Arn:
    Value:
      "Fn::GetAtt": [SlsTestAppIPSet, Arn]
プロパティ名 説明
Addresses CIDER表記のIPアドレスを配列形式で指定します。上記コード例ではserverless.ymlの環境変数に指定したものを記載する方式にしています
Description IPセットの説明を記載します(任意)
IPAddressVersion IPV4またはIPV6を指定します
Name IPセットの名前を指定します(任意)
Scope CLOUDFRONTもしくはREGIONALを指定します。今回はリージョンごとのサービスであるAPI Gatewayに適用するため、上記コード例ではREGIONALを指定します

WebACL

WAFの具体的なルールを設定します。
テンプレート例は以下の通りです。Associationを構築時にWebACLのArnを指定する必要があるため、OutputsでArnを出力するようにしています。

ちなみにServerless Frameworkでは${cf:{スタック名}.{Outputsのキー名}}という書式を使うことで別スタックのOutputsで出力した値を読み込むことができます

web-webacl.yml
Resources:
  SlsTestAppWebACL:
    Type: AWS::WAFv2::WebACL
    Properties:
      DefaultAction:
        BLOCK: {}
      Description: WebACL for slsTestApp Access.
      Name: slsTestAppAPIWebACL
      Rules:
        - Action:
            ALLOW: {}
          Priority: 0
          Name: SlsTestAppAPIAccessRule
          VisibilityConfig:
            CloudWatchMetricsEnabled: false
            MetricName: SlsTestAppRuleMetric
            SampledRequestsEnabled: false
          Statement:
            IPSetReferenceStatement:
              Arn: ${cf:slsTestAppWAFIPSet-${self:provider.stage}.Arn}
      Scope: REGIONAL
      VisibilityConfig:
        CloudWatchMetricsEnabled: false
        MetricName: SlsTestAppWebACLMetric
        SampledRequestsEnabled: false
Outputs:
  Arn:
    Value:
      "Fn::GetAtt": [SlsTestAppWebACL, Arn]
プロパティ名 説明
DefaultAction WebACLのどのルールにも当てはまらない場合の動作を指定します。AllowもしくはBlockです。ルール外のリクエストは弾きたいので、上記コード例ではBlockを指定しています
Description IPセットの説明を記載します(任意)
Name IPセットの名前を指定します(任意)
Rules ルールの詳細をリスト形式で記載します。

Action→ルールに一致した場合の挙動を指定

Priority→ルールの優先度。最小値は0で、小さい順から優先的にルール判定が行われる

Statement→ルールの具体的な内容を指定します。今回はIP制限のため、IPSetReferenceStatementを指定し、先ほどのIPセットのArnを指定しています
Scope CLOUDFRONTもしくはREGIONALを指定します。今回はリージョンごとのサービスであるAPI Gatewayに適用するため、上記コード例ではREGIONALを指定します
VisibilityConfig CloudWatchメトリクスを送信するかどうか、メトリクス名、Webリクエストのサンプリングを行うかどうか指定します。今回はすべてfalseにしていますが、必要であればtrueに変えてください。

Association

WebACLをどのリソースに適用するかを定義します。
テンプレート例は以下の通りです。

waf-webacl-association.yml
Resources:
  SlsTestAppWebACLAssociation:
    Type: "AWS::WAFv2::WebACLAssociation"
    Properties:
      ResourceArn: arn:aws:apigateway:${self:provider.environment.REGION}::/restapis/${cf:slsTestApp-${self:provider.stage}.Id}/stages/${self:provider.stage}
      WebACLArn: ${cf:slsTestAppWAFWebACL-${self:provider.stage}.Arn}

ResourceArnにWAF(正確にはWebACL)を適用したいリソースのArn、 WebACLArnに適用するWebACLのArnを指定します。

API Gatewayは直接Arnを出力することができなさそうだったので、代わりにIDを出力するようAPIGatewayのテンプレートにOutputsを追加しています。

api-gateway.yml
Resources:
  ApiGatewayRestApi:
    Type: "AWS::ApiGateway::RestApi"
    Properties:
      Body: ${file(./templates/swagger.yaml)}
…中略…
Outputs:
  Id:
    Value:
      Ref: ApiGatewayRestApi

WAFの構築はスタックを分けたほうがいい

WAFは通常、そこまで変更があるものではないので、Lambda関数+API Gatewayなど変更が多いものとはスタックは分けておいたほうがよいと思います。なので、今回はこれに従い、WAFのテンプレートはLambda関数等とはディレクトリを分け、専用のServerless.ymlを作成し個別にデプロイをする方式をとります。

…ということで意気揚々とIPセット、WebACL、Associationを構築し、作業が終わったので削除しようとしたところ、以下のようなエラーが出てしまいました。

Serverless Error ---------------------------------------

  An error occurred: SlsTestAppIPSet - AWS WAF couldn?t perform the operation because your resource is being used by another resource or it?s associated with another resource. (Service: Wafv2, Status Code: 400, Request ID: XXXXX, Extended Request ID: null).

これは「紐づけられているWebAClがあるのにIPセットは削除できませんよ」と言っています。つまりIPセット、WebACL、Associationを同じスタックで構築すると削除する際に順番の関係でこういった問題が起こり、スムーズに削除できなくなってしまいます。
他に解決策はありそうですが、私はシンプルにIPセット、WebACL、Associationそれぞれを個別のスタックで構築することにしました。
先ほどのテンプレート例でOutputsが含まれていたのはこういった事情です。

WAFのデプロイ

先ほど記載した通りIPセット、WebACL、Associationをスタックを分けてデプロイをするため、それぞれでディレクトリを分け、配下にテンプレートとserverless.ymlを作成してください。私は以下のようにしました。

waf/
┗ ipset/
  ┗ templates/
    ┗ waf-ipset.yml
  ┗serverless.yml
┗ webACL/
  ┗ templates/
    ┗ waf-webacl.yml
  ┗serverless.yml
┗ association/
  ┗ templates/
    ┗ waf-webacl-association.yml
  ┗serverless.yml

各serverless.ymlはresourcesでテンプレートを読み込むくらいの内容になると思います。

デプロイするときは、各ディレクトリの配下に移動し、そこで'''sls deploy'''コマンドを実行してください。

デプロイする順番は「IPセット→WebACL→Association」になります。
削除する場合は反対に「Association→WebACL→IPセット」となります。

動作確認

キャリアの電波に接続したスマホなどでブラウザを開きAPIのURLを打ち込んでみてください。
{message:Forbidden}などのメッセージが表示されていれば成功です。
APIの実行方法はこちらを参照してください。

おわりに

今回は先日公開した【サーバーレス初心者向け】Serverless Framework + SwaggerでWeb APIを作る！第1回(全3回)で作成したAPI GatewayにAWS WAFを適用する方法を解説しました。
次回はバックエンドのロジックを作りこんでいきたいと思います。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-08-12T17:15:12+09:00

AWS Security資格（SCS）に合格しました

はじめに

先日（8/10）にAWS Certified Security - Specialty資格（以降SCS）に受かったので、その時の所感や実践した勉強などを残そうと思います。
とはいえ、勉強に使ったのは他の記事でも書いたBlackbeltとWhizlabs（と公式の模擬試験）ぐらいなので、試験の傾向や試験中に考えたことなどが中心になります。
誰かの役に立てば幸いです。

※過去の記事
AWS SAAに受かった話
AWS SOAに受かった話
AWS DVA(とCLP)に受かった話
AWS SAPに受かった話

ちなみにDOPも7/23に受かっていますが、勉強法は相変わらず「WhizlabsとBlackbeltをパパっとやって、終わり！」みたいな感じだったので特に書くことないと思って放置していたら、すっかり書くタイミングを失った次第です（更に言うとどんな問題が出たかも忘れた）
DOPも問題文が長いので簡単ではありませんが、ClouformationやOpsworks、ElasticBeanStalkといったコアとなるサービス（の少し細かいところ）と、デプロイ戦略の使い分けについて理解していれば少なくともSAPよりは受かりやすいのでは、と思います。

獲得スコア

受験日 スコア/合格点/満点 結果
2020/8/10 831/750/1000 合格

試験中の手応え的にはもう少し取れているかとも思いましたが、どちらとも取れる紛らわしい問題もいくつかあったので多少下振れした印象です。
（一応、スコアレポート上は全分野共に「知識レベルは十分」と出ました）

勉強に使った教材

Whizlabs

海外のWeb問題集。（自分は2番目に受けたSysopsからずっとお世話になっています）
https://www.whizlabs.com/

巷によくある、試験問題と答えをそのまま販売している（所謂クラムメディア的な）アレではなく、公式ドキュメントに基づいた問題を提供しています。
（少々雑な）解説と公式ドキュメントへのリンクもあるため、勉強の事始めから中終盤の追い込みにも幅広く使えます。
たまに重箱の隅を突いたものすごいマイナーな問題もあったりするので、実試験よりも難易度は高めです。

Blackbelt

親の顔よりも見たAWS公式の動画セミナー。
https://aws.amazon.com/jp/aws-jp-introduction/aws-jp-webinar-service-cut/

自分はまずWhizlabsの問題を解き、その時にわからなかったり理解が浅いと思ったサービスについて資料をざっと流し読みをする、という使い方をしていました。
その時には一度に全部覚えようとせず、問題の中で出てきた要素を5分程度で掻い摘む、というのを意識していました。（そしてまた問題を解き～の繰り返し）

自分はやりませんでしたが、時間が許せば動画も観た方が良いと思います。

模擬試験（AWS公式）

模擬試験の問題がそのまま出る、ということはありませんが、試験の傾向や出題範囲を知る上では受けた方が良いです。
自分は試験の直前ではなく、なるべく勉強を始めて間もない頃に受けるようにしています。
（自分の現在地点を知りたいのと、模擬試験の答えを調べる勉強を先にやっておきたい意図）

その他

インドで活動されている方のブログ（試験のポイントが記載されています）
https://jayendrapatil.com/

あとはSCSに関しては最近書籍も発売されていました。
その本の存在を知ったのが割と最近だったので今回は使用しませんでしたが、試験の帰りに書店でパラ見した限りでは役立ちそうな内容が書いてあったのでこれから受ける人は有用だと思いました。
（というより、試験を受けた人が狙い撃ちして書いた印象が強い）

試験の所感

  • 試験問題の難易度にかなりのばらつきがある
    • 三層Webシステムで設定するセキュリティグループのルールのような超絶簡単な問題から、KMSやCoginitoのコアな機能を問うような超絶難しい問題まで
  • 全体的にKMSの仕組みを知っていることが前提の試験
  • IAMポリシー（S3バケットポリシーやKMSキーポリシー含む）はかなり突っ込んで出題される
  • SAPやDOPよりもう一歩踏み込んだ知識が要求される
    • Trusted AdvisorとInspectorとSystems Managerでそれぞれ何ができて何ができないのか
    • 基本的にセキュリティ監査はConfigとCloudtrailが二大サービスなので、それらで検知できることの違いは把握しておく
    • WAFとShieldの使い分け
    • Cloudfrontの機能（多少詳しく）
  • Organization自体の問題はあまりないが、関連する問題はいくつか出る
  • 問題文は短いので、SAPのように時間が足りなくなることはない（自分は見直し含めて50/170余った）
  • AWS Macieって知ってるかい？（バクシンガー）
  • Cognitoをどうこうする問題は無かったが、CognitoとWebIdentityとSAMLがそれぞれどういう時に使われて、どうやって構成するのか（構成するのに何が必要か）は知っておく必要がある
  • セキュリティのトラブルシューティングの対応パターンは普段の業務で使わない分、弱点になりがち（ID侵害・フォレンジック分析・EC2接続用のキーペア失くしちゃった問題など）
  • VPCエンドポイントやAWS ADの問題もちらほら
  • AWSサービスの知識だけでなく、前提となる暗号化（データや通信）の知識もある程度必要

今後の予定

次はAdvanced Networking Specialty資格（ANS）の予定です。今年中にコンプしたいのでできれば今月中に取りたいですが、本格的な夏に入って太陽が眩しいので9月にずれ込むかもしれません（カミュ）

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-08-12T16:55:53+09:00

【AWS】ConsoleのSign-in時の通知やAlarmの設定

001.JPG

Sign-in Endpoint

Sign-in Endpointはログイン時に使用したURLによって変わる。
https://docs.aws.amazon.com/IAM/latest/UserGuide/cloudtrail-integration.html

「https://.signin.aws.amazon.com/console」でログインすればEndpointは「us-east-1」になる（テスト時）が、
「https://.signin.aws.amazon.com/console?region=ap-southeast-1」のようにパラメータでRegionを指定すれば、
Sign-in Endpointを明示的設定できる。

CloudTrial

Sign-in Eventを取得する場合、CloudTrialからTrailを1つ作成する必要がある。
作成したTrailはデフォルトで全Region対応のため、1つのTrailで足りる。

またAlarm設定のために、CloudWatch Logsにログを出力するよう、設定を行う。
002.JPG

EventBridge

Sign-inはRegionEventのため、Eventを取得したいRegionにEventBridgeのRuleを作成する。
EventのPatternはSign-in Eventのサンプルを参考に作成する。

{
   "eventSource":["signin.amazonaws.com"],
   "eventName":["ConsoleLogin"],
   "eventType": ["AwsConsoleSignin"]
}

SNS

Regionごとに作成する。

CloudWatch Logs

CloudTrialからCloudWatch Logsにログが出力するまで数分のラグがあるため、リアルタイムの通知には向いていない。
リアルタイム通知のためには通知を受けたいRegionにEventBridgeを設定する必要があるが、そうしたくない場合は、
LogGroupにFilterを設定し、MetricをCloudWatch Alarmで監視することで、SNSから通知を受けることができる。

us-east-1とap-northeast-1以外のEndpointにログインしたUserがいる際、Alarmを発生したい場合は以下のFilter Patternを使用し、Custom Metricを生成する。

{ $.responseElements.ConsoleLogin = "Success" && ($.awsRegion != "us-east-1" && $.awsRegion != "ap-northeast-1") }

003.JPG

CloudWatch Alarm

LogGroupのCustom Metricに対しAlarmの設定を行い、しきい値超過した際はSNSに通知するよう設定する。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-08-12T15:59:14+09:00

GPSマルチユニットとAWS IoT Eventsで作業記録システムを作った話

作業記録を付けよう

作業記録を付けるのは大事なことです。原価管理はもちろんですが、自分の作業を見える化することで自宅作業であまり効率的に動けてない部分や思った以上に自分が働きすぎている部分を確認することが出来ます。

とはいえ、慣れないうちはExcelシートなりにマメにログを付けるというのはついつい忘れがちです。せめて作業を切り替えた時間だけでも簡単に記録できないかと考えたのが今回の記事になります。

ボタンでやる？

最初に思いついたのはSORACOM LTE-M Buttonを使うことです。
以前「LTE-M Buttonで子育て支援するシステムを作ったお話」というのを作っていますので、これを持ってきて各作業開始時にポチッと押すことでGoogle Spreadsheetに時間を記録することが出来ます。

ただ、これにはいくつか欠点があります。

  • ボタンを押したかが思い出せない
    後からボタンを見ても、状態の変かが目に見えないので「さっき押したっけ？」というのが不安になります。もちろん、通知等を使えば解決は出来ますが、何か目に見えて変化があると安心できます。
  • ちゃんと通信できたかが分かりにくい
    LTE-Mの通信は時々失敗します。このとき、ボタンだとLEDの色で教えてくれるのですが、通信成功/失敗が分かるまで10秒程度の時間がかかり、それを待つ必要があります。また、私は赤緑色弱なのでLEDの色の判別がとても難しく、結局通信が成功したかは通知やSpreadsheetを見て判断することになります。
    さらに、失敗していればまた自身でボタンを押さないといけません。

1つめは通知や、それを受けて表示するデバイスなどで工夫できそうですが、2つめについてはできれば自動でリトライしてくれると楽ちんだなと思って一旦保留しました。

GPSマルチユニットでやる？

次に考えたのはGPSマルチユニットSORACOM Editionを使うことです。

SORACOMさんのIoT DIYレシピの一つ、「【IoT DIY レシピ】GPS マルチユニット SORACOM Edition で作る「在席状況の自動更新デバイス」」を参考にすると出来そうな気がします。GPSマルチユニットを裏返すというのは比較的大きい動作ですし、目で見て状態が変わってるので作業漏れにもボタンよりは気づきやすそうですし、通信に失敗したときも最短1分でリトライする(というか次の通信をする)ので良さそうです。

ただ、こちらのレシピだと「裏返ってる/表になってる状態」というのは取れるのですが、今回は「アクションした時間を取りたい」というのが目的です。どうにかして「裏表が変わった瞬間」というのを記録する必要があります。

つまり、「状態が変わった」と言うことを検知したいわけです。ボタンだと「ボタンを押した」というのが「状態が変わった」に当たるわけですが・・。

状態を持つ = ステートマシン

状態を持って判断して処理をするわけですが、ぱっと思いつくのはSORACOM FunkやBeamを使ってAWS Lambdaに送り、DynamoDBなどで前回のデータを覚えておいてそれと比較するという方法です。しかし、DynamoDBは目的の割にちょっと牛刀な気がします。

そこでふと思い出したのが、ソラコムのテクニカルエヴァンジェリスト maxの「AWS IoT Events は IoT デバイスの「ステートマシン」」という記事です。そう、このくらいのステートであればAWS IoT Eventsで持たせてやればいいのです。

AWS IoT Events

AWS IoT Eventsについては先述のmaxのブログを読んでいただくのがいいかと思いますので説明省略します(相変わらず人の記事におんぶに抱っこ)。

ここでは、以下のような状態を設定します。

  • スタート直後の状態(init)、上向き(up)、下向き(down)の3つの状態を作る
  • 入力の定義は、GPSマルチユニットのデータを使えるように以下のJSONを読み込ませ、名前を「gps_multiunit」としておく
{
  "payloads":{
   "lat":null,
   "lon":null,
   "bat":3,
   "rs":4,
   "temp":29.3,
   "humi":54.3,
   "x":0.0,
   "y":64.0,
   "z":-960.0,
   "type":0
  }
}
  • init/upからdownに向けて矢印を引き、遷移の条件に$input.gps_multiunit.payload.z < 0と入れる
  • init/downからupに向けて矢印を引き、遷移の条件に$input.gps_multiunit.payload.z > 0と入れる
  • up/downのonEnterイベントにLambda関数を指定する
  • Lambda関数は、起動したらGoogle Spreadsheetに記録する(こちらを参照)

実際の画面で見るとこんな感じですね。

image.png

AWS IoT CoreとSORACOM Funnelの設定

こちらのドキュメントを参考に、AWS IoT CoreとSORACOM Funnelを設定します。

ルールはSELECT payloads as value FROM '#'とし、アクションを「IoT Events入力にメッセージを送信する」とします。Funnelで送信すると、GPSマルチユニットからのデータはJSONの中のpayloadsというキーに入っていますので、ルールでその部分だけを取り出して(SELECT payloadsの所)、IoT Eventsに渡すようにします。

IoT Events側でも受け取るときに名前がズレないよう、上記の通り「payloads」と名前を合わせておきましょう。私はうっかり最初にIoT Eventsで入力の設定でJSONを読み込ませる際に「value」なんて名前にしてたのでうまく動かないで悩んだのですが、そんなときは慌てずIoT Coreのルール側で

SELECT payloads AS value FROM '#'

と名前を付け替えてあげると動きます。

動作検証

GPSマルチユニットを「平日の業務時間中は1分おきに送信」としておき、裏返してみて様子を見ます。

image.png

無事取れてますね！

まとめ

  • GPSマルチユニットを裏返したり表にしたりすることで、作業の切り替わり時間を記録してみた
  • 「前回の入力から変わったら」というようなステートを持つ作業はLambdaだけでやらずにIoT Eventsを挟むと楽ちん
  • IoT Eventsの入力のパラメータ名と、IoT Coreから飛んでくるデータのパラメータ名はちゃんと合わせよう
  • もしうっかり違う名前を付けたらIoT Coreのルールで「SELECT x AS y」と名前を付け替えればOK
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-08-12T15:38:18+09:00

【学習記録】AWS VPCについて

Amazon VPCとは？

VPCとは、Virtual Private Cloudの略です。Amazon VPCはAmazonが提供している仮想ネットワークのこと。
この仮想ネットワーク内で、AWSリソースを起動できる。

VPCを学ぶ上で必要な知識

アベイラビリティゾーン（AZ）

AWSの各リージョンに存在するデータセンターのこと。アベイラビリティゾーンにサブネットを配置する。

リージョン

AWSの各サービスが提供されている地域のこと。AWSでサービスを利用するときは、まずリージョンを指定する。リージョンによって使えるサービスは異なる。

サブネット

VPCを細かく区切ったネットワークのこと。VPCのIPアドレスの範囲。
例えば、Webサーバー（公開）とDBサーバー（非公開）を分けたいときVPC内でpabulicサブネットとprivateサブネットのように区切って使用する。

ルーティング

どのデータをどこに送るか采配すること。VPCとインターネットをつなげたい場合は、このルーティングでインターネットゲートウェイとのルーティング設定を行わないとつながらない。

ルートテーブル

ルーティングに関する設定が書かれたテーブル。１つのサブネットに１つルートテーブ
ルを用意できる。
宛先のIPアドレスと次のルーター（ターゲット）の２つを記載している。

インターネットゲートウェイ

VPCをインターネット接続できるようにするコンポーネント。インターネットへの出入り口。

参考

書籍：Amazon Web Serviceのしくみと技術がこれ１冊でしっかりわかる教科書

講義：ゼロから実践するAmazon Web Services。手を動かしながらインフラの基礎を習得

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-08-12T14:54:20+09:00

databricks on AWS deploy手順~その3~

はじめに

databricks on AWSをdeployするまでの手順をご紹介したいと思います。
databricks on AWSのdeploy完了までには
databricks側とAWS側でいくつかの登録&設定作業が必要となっているため以下3章に分けてご説明いたします。

  • その1 databricksアカウントの作成
  • その2 AWSアカウントとの連携
  • その3 databricks用S3バケットとの連携　← 今回はここ

本題

長かったdatabricks on AWS のdeploy手順もいよいよ最後のその3まできました。
今回もAWSアカウントとdatabricksアカウントの両方使用するので、
ログインした状態でご準備をお願いいたします。

➀databricks用S3バケットの作成

databricks用のS3バケットを作成します。
databricks公式サイトでも、databricks専用のS3バケットを作成することがベストプラクティスとされているのでそちらに則って進めていきたいと思います。

S3のコンソール画面に移動します。
「バケットを作成する」をクリックしてdatabricks用新規バケット作成作業に入ります。
image.png

名前とリージョン

バケット名は任意のものでOK(私はs3-for-databricks-testという名前にしました)
リージョンは「アジアパシフィック(東京)」
既存のバケットから設定をコピーは入力不要です。
バケット名とリージョンを記入したら「次へ」をクリック
スクリーンショット 2020-08-14 14.45.09.png

オプションの設定

ここでは様々なオプションを設定することができます。
今回は、databricks公式サイトの方で強く推奨されている「バージョニング」機能のみ設定してとりあえず先に進みたいと思います。
一番上の「バージョニング」にチェックを入れて「次へ」をクリック
スクリーンショット 2020-08-14 14.45.29.png

アクセス許可の設定

何も変更せずに「次へ」をクリック
スクリーンショット 2020-08-14 14.45.42.png

確認

バケット名
バージョニングの有効化
アクセス権限
を確認したら、「バケットを作成」をクリックして、
databricks用S3バケットの作成が完了です。
スクリーンショット 2020-08-14 14.46.10.png

➁バケットポリシーの作成

databricksコンソール画面から左部の「AWS Storage」欄を選択するとこの画面になります。
画面中央部の空欄に作成したdatabricks用S3バケット名を記入して「Generate Policy」をクリック。
image.png

生成されたバケットポリシーをコピーしておく。
image.png

S3コンソール画面に戻って
「databricks用S3バケット」→「アクセス権限」→「バケットポリシー」の順に進みます。
バケットポリシーエディターに先ほどコピーしたバケットポリシーを貼り付けます。
画面右側の「保存」をクリック。

image.png

databricksのAWS Storage画面に戻り
「Apply Change」をクリック。
このような画面になったらS3の設定完了です。
image.png

➂Deploy Databricks

databricksのコンソール画面に戻り、
画面左部から「Deploy Databricks」を選択するとこの画面になります。
空欄にチェックをいれて「Deploy」をクリック。
Deployが完了するまで30分ほどかかります。
image.png

deployが完了するとdatabricksからこのようなメールが届き、
image.png
databricksコンソール画面でもこのような表示になります。
image.png

以上で、作業は終了です。

おわりに

3章にわたるdeploy作業も今回でついに終わりを迎えました。
お疲れさまでした。
本記事がどなたかのお役に立てていれば幸いです。

今後も引き続きdatabricks公式ドキュメントを参考に記事をupしていく予定です。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-08-12T14:24:11+09:00

新卒1年目が1.5ヶ月でAWS認定 クラウドプラクティショナーを取得するまで

はじめに

新卒1年目のエンジニアである私が、勉強はじめて1.5ヶ月で先日AWS認定 クラウドプラクティショナーに無事一発合格できたので体験記みたいな感じでアウトプットしてみます。

あまり経験がない方や、私みたいな新卒エンジニアの方が資格取得を目指す際に役立つといいなと思います。

受験を決めたときの自分

  • ピッカピカの新卒一年目エンジニア

    • 研修終わってすぐ試験対策を始めたので、現場経験はありません！

  • IT知識

    • 大学で情報系を専攻していたので、ある程度のITの知識は持っていました。
      しかし、CGなどをメインに扱っていたのでインフラなどはそこまで詳しくないです。

  • クラウドの知識

    • ほとんど0でした。AWSに関しては専門用語を全く知らず、EC2ってなんぞやレベルでした。

合格点数

クラウドプラクティショナーは100~1000のスコアで700以上取れれば合格となります。
私は809で合格となりました。
(なんでこんなに中途半端な点数なんや...)
score.png
また、スコアと評価というフィードバックがあり、自分が受験した中でとれたところととれていなかったところを示してくれます。
自分はすべて「十分な知識を有する」だったので、満遍なく学習できていたなと思います。
scoreandeva.png

試験までに行ったこと

次がメインとなります。
自分が試験までに行ったことをリストアップしてみますので、参考にしていただけたら幸いです。

オンプレミスの基礎知識を定着させる(2週間)

  • インフラ(70%)
  • アプリ(フロント・サーバサイド)(30%)

個人的になんですが、結構オンプレミスの知識も必要なのかなと思います。
勉強途中によく見るELBだったり、Route53が負荷分散の役割を持っている話は、
「ロードバランサ」の役割や「DNSラウンドロビン」などの知識がないと理解しにくい分野だと思います。
いくらクラウドだといってもある程度システムアーキテクチャを理解してないと扱えないですしね...(身に染みて感じてます)

AWSの基本用語などの基礎知識を軽く触れる(1日)

参考にさせていただいた記事はこちらです。(非常にわかりやすかったです！)
基本的なシステム構成図を理解するための AWS 基礎をまとめてみた

こちらの記事を読みながら一番柱となるリソースを学びました。
わからない言葉が出てきたら調べて公式のドキュメント読んで納得する感じです。

ハンズオンによって使い方を体系的に学ぶ(1日)

用いた学習リソース
AWS Hands-on for Beginners

AWS公式のハンズオン講座です。日本語で公開されているのですこぶるわかりやすかったです。
プラクティショナー取得目指している人ではなくとも、AWSをとりあえず触ってみたい方にお勧めです。

所感も書いてますので併せてどうぞ。
【初心者】AWS Hands-on for Beginnersをやってみた感想

AWSなどが開催しているセミナーに参加し、知識定着を目指す(1.5週間程度)

数個参加しました。そのうちのいくつかをピックアップして掲載します。

ひたすら模擬試験を解く(残り数日)

ここまで来たら基礎知識は問題ないかと思います。
なので、慣れる意味でも模擬試験をひたすら解きました。
どの試験でもいえることかもしれませんがこのフェイズが一番重要だと思います。

おすすめはUdemyの模擬試験です。
この問題だけで合格可能！AWS 認定クラウドプラクティショナー 模擬試験問題集（7回分455問）
結構割引してるみたいで、割引期間中にポチっておくといいのかなと思います。

ちなみに私は、基礎問題は9割、応用問題は8割取れるまで繰り返しました。
問題を覚えてしまっても効果があると思うので繰り返しやってみるのがおすすめです。

まとめ

プラクティショナーのために勉強していく中でクラウドの知識の基礎固めができたかなと思います。
今後の業務に活かしていきたいです。

次はソリューションアーキテクト アソシエイトを目標にクラウドの知識を高められたらなと思ってます！

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-08-12T12:58:32+09:00

AWS初心者がEC2を最低限の利用料金で利用する

概要

AWS請求$2.84。。。先月の私のAWS利用料です。
まぁ少額なのでいいですが、予想より使ってしまったな。という印象。
image.png

というのも先月はEC2で少しやりたいことがあり、ポチポチとEC2インスタンスを作成して
不要な時は停止していました。
が、費用削減できていなかったのは、EBS$2.01。。。
EC2よりよっぽど費用がかかってしまった。

image.png

詳細を見ると、EC2はインスタンスタイプの時間料金なので今回は「$0.0152/1時間」または「$0.0198/1時間」ですね。
対し、EBSは、Snapshotかボリュームのままかで料金が分かれており、単位はGB月ですね。
GB月はちょっとわかりにくいですが、30GBのディスクを1ヶ月まるまる使ったら（EC2の起動／停止に関係なく）30GB月で、
2週間だった場合、およそ15GB月となる感じですね。
それがSnapshotは「$0.05/1GB月」、ボリュームは「$0.12/1GB月」という感じ。
結果、ボリュームの単位料金が他の料金として比較して高く「$0.1」を超えているため
予想より利用料がかかってしまったという感じです。

ということで、今回はEBS利用料金を削減すべく、Snapshotを取って、使うときに戻す
という内容で自分への手順確立のための投稿です。
興味ある方はご覧ください(_ _)

EBS Snapshot手順概要

ざっくり以下の手順でSnapshot作成およびSnapshotからのボリューム作成を行います。

  • Snapshot作成手順
    • 1.EC2停止
    • 2.ボリュームからSnapShot作成
    • 3.ボリュームのデタッチ
    • 4.ボリュームの削除
  • Snapshotからボリューム作成
    • 1.Snapshotからボリューム作成
    • 2.ボリュームをアタッチ
    • 3.EC2起動

Snapshot作成手順

1.EC2停止

とりあえずEC2停止。停止しなくてもSnapshotは取れるけど心情的に停止^^;
その時重要なのは、ルートデバイスをメモっておくこと。

image.png

2.ボリュームからSnapShot作成

EBSの「ボリューム」メニューから、対象のボリュームを選択し「スナップショットの作成」

image.png

確認画面でもう一度「スナップショットの作成」

image.png

3.ボリュームのデタッチ

対象のボリュームを「デタッチ」する

image.png

4.ボリュームの削除

デタッチ出来たら対象のボリュームを「削除」する
これでボリューム料金の「$0.12/1GB月」の使用料がなくなる！

image.png

Snapshotからボリューム作成

1.Snapshotからボリューム作成

EC2を改めて起動したくなったら、まず
EBSの「スナップショット」メニューから、対象のボリュームを選択し「ボリュームの作成」

image.png

確認画面でもう一度「ボリュームの作成」

image.png

2.ボリュームをアタッチ

Snapshotから作成したボリュームを選択し「アタッチ」する

image.png

アタッチのメニューでデタッチした時のインスタンスを指定し、
「デバイス」欄にインスタンス停止時に確認しておいたルートデバイスを指定
表示されたデフォルトのままではダメ

image.png

3.EC2起動

アタッチが終わったらEC2を普通に起動する

image.png

この時、アタッチのところでデバイスを間違っていると、インスタンス開始のエラーが発生する
エラーメッセージを読んでそのままだが、rootにボリュームがアタッチされてないよ。と言われる
（「2.ボリュームをアタッチ」のやり直し）

image.png

まとめ

これで使用料は、EC2/EBS起動している分だけ、EBSは「＄0.05/1GB」となる。
今月は＄1.00くらいに抑えられるかなぁ。
GUIの簡単操作だけど起動の度やるのは面倒になってくる。自動化（CLI?）しようかな。。。

補足

ちなみにEIPを使っている場合は、EC2停止時には料金がかかるのでお気を付けを。。。
EC2を起動しているとEIP自体は無料ですが、使っていないのにEIPを保持しているとお金がかかります。

https://dev.classmethod.jp/articles/cost-of-eip/

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-08-12T12:48:57+09:00

IAMユーザーを請求情報にアクセスさせる

AWSアカウント登録後に外部の方のクレカ情報を登録してもらう際のメモまでに。

Billing and Cost Managementコンソールへのアクセスのアクティブ化

https://console.aws.amazon.com/billing/home?#/account

アカウントの設定画面をスクロールして「IAM ユーザー/ロールによる請求情報へのアクセス」を編集します。

  • IAM アクセスのアクティブ化

ここをチェック入れて「更新」を押下します。

請求データにアクセス許可を付与する IAM ポリシーを作成する

新たに「BillingFullAccess」ポリシーを作成、適応します。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": "aws-portal:*",
            "Resource": "*"
        }
    ]
}

参考

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-08-12T11:29:20+09:00

databricks on AWS deploy手順~その1~

はじめに

databricks on AWSをdeployするまでの手順をご紹介したいと思います。
databricks on AWSのdeploy完了までには
databricks側とAWS側でいくつかの登録&設定作業が必要となっているため以下3章に分けてご説明いたします。

  • その1 databricksアカウントの作成 ← 今回はここ
  • その2 AWSアカウントとの連携
  • その3 databricks用S3バケットとの連携

本題

➀databricksアカウント登録

では、さっそく本題に参ります。
以下URLから登録画面に飛びます。
https://databricks.com/try-databricks?_ga=2.231496607.1278047542.1597105290-1399252035.1593565763
image.png

必要情報を埋めていきましょう。
How would you describe your role?(あなたは役割なに？)
What is intended use case?(用途は？)
の質問に関しては、正確でなくてOKです。
※当てはまるものがなければ、とりあえず何か選択して先に進みましょう。
すべて記入したら画面下部の「SIGN UP」をクリック
image.png

記入漏れなどがなければ、この画面に進みます。
2020-08-12_10h10_05.png
画面下部の
GET STARTED ON 「Azure」OR 「AWS」
でAWSの方をクリック
image.png

問題がなければ、databricksから以下のメールが届きます。
メール内のリンクを踏んでdatabricksアカウントのパスワード設定画面に飛びます。
※メール内の2つのリンクは同じですので、どちらからでもOKです。
image.png

パスワード設定画面です。
ここでパスワードを設定します。メモを忘れずに。
image.png

➁決済情報の登録

パスワード設定が完了し、ログインすると以下画面になります。
画面左部の「Billing Details」欄から決済情報の登録を行います。
必要事項の記入したら「Next Step」をクリックで登録は完了です。
image.png

その1の内容はここまでです。

おわりに

今回はdatabricksアカウント登録~決済情報の登録までを行いました。
次回「その2」ではAWSアカウントとの連携についての作業を行います。
引き続き頑張っていきましょう。
ひとまずお疲れさまでした。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-08-12T08:39:32+09:00

【lambda】インスタンスの状態を取得してlambdaでslackへ通知する

概要

インスタンスを立ち上げてテストしたあと、よく停止し忘れるのでlambdaでEC2/RDS/ElastiCacheの状態を確認し、不要なインスタンスが起動中であればslackで通知する処理を作る
(強制停止だと不味い場合があるので通知だけ)

フロー

CloudWatchEventのスケジュール -> lambda実行

前準備

lambda実行用に以下のポリシーがついたロールを用意
・AmazonEC2ReadOnlyAccess
・AmazonElastiCacheReadOnlyAccess
・AmazonRDSReadOnlyAccess

コード

import boto3
import json
import urllib.request

ALLWAYS_RUNNING_EC2_INSTANCE_ID_LIST = [
    'i-hogehoge', # hogehoge
]
AS_INSTANCE_NAME_LIST = [
    'auto-scale-instance-name',
]
ALLWAYS_AVAILABLE_RDS_INSTANCE_NAME_LIST = [
    'hogehoge',
]
ALLWAYS_AVAILABLE_CACHE_CLUSTER_ID_LIST = [
    'hogehoge',
]

def get_needless_rds_instance_list(region):
    client = boto3.client('rds', region)
    tmp = client.describe_db_instances().get('DBInstances')
    ret = []
    for instance in tmp:
        if instance['DBInstanceStatus'] != 'available':
             continue

        if instance['DBClusterIdentifier'] in ALLWAYS_AVAILABLE_RDS_INSTANCE_NAME_LIST:
            continue

        ret.append(instance['DBClusterIdentifier'])

    return ret

def get_needless_cache_instance_list(region):
    client = boto3.client('elasticache', region)
    tmp = client.describe_cache_clusters().get('CacheClusters')
    ret = []
    for cluster in tmp:
        if cluster['CacheClusterStatus'] != 'available':
             continue

        if cluster['CacheClusterId'] in ALLWAYS_AVAILABLE_CACHE_CLUSTER_ID_LIST:
            continue

        ret.append(cluster['CacheClusterId'])

    return ret

def get_needless_ec2_instance_list(region):
    client = boto3.client('ec2', region)
    tmp = client.describe_instances()
    ret = []
    for reservation in tmp['Reservations']:
        for instance in reservation['Instances']:
            if instance['State']['Name'] != 'running':
                continue

            if instance['InstanceId'] in ALLWAYS_RUNNING_EC2_INSTANCE_ID_LIST:
                continue

            if 'Tags' not in instance:
                ret.append('名前なし : ' + instance['InstanceId'])
                continue

            for tag in instance['Tags']:
                if tag['Key'] == 'Name' and tag['Value'] not in AS_INSTANCE_NAME_LIST:
                    ret.append(tag['Value'] + ' : ' + instance['InstanceId'])
    return ret

def post_slack(message):
    send_data = {
        "text": message,
    }
    send_text = json.dumps(send_data)
    request = urllib.request.Request(
        'https://hooks.slack.com/HOGEHOGE',
        data = send_text.encode('utf-8'), 
        method = "POST"
    )
    with urllib.request.urlopen(request) as response:
        response_body = response.read().decode('utf-8')

def lambda_handler(event, context):
    message = ''
    try:
        needless_ec2_instance_list = get_needless_ec2_instance_list('ap-northeast-1')
        needless_rds_instance_list = get_needless_rds_instance_list('ap-northeast-1')
        needless_cache_instance_list = get_needless_cache_instance_list('ap-northeast-1')

        if needless_ec2_instance_list:
            message += '下記EC2インスタンスが起動中です\n' + '\n'.join(needless_ec2_instance_list) + '\n'
        if needless_rds_instance_list:
            message += '下記RDSインスタンスが起動中です\n' + '\n'.join(needless_rds_instance_list) + '\n'
        if needless_cache_instance_list:
            message += '下記redisクラスターが起動中です\n' + '\n'.join(needless_cache_instance_list) + '\n'
    except Exception as e:
        message = '\n'.join(e.args)

    if message:
        post_slack(message)

改善点

・オートスケールインスタンスはインスタンスIDが一定ではないので名前で弾いていますが、もっと良い方法を探したいところ

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-08-12T08:35:41+09:00

Amazon EKSのKubernetes ダッシュボードをデプロイする

はじめに

本記事はAWS環境におけるEKSクラスターのKubernetesダッシュボードをデプロイする手順について記載しています。

オンプレミスのKubernetesに比べて、EKSなどのマネージドサービスを初めて操作する場合は勝手が違います。本記事ではチュートリアル: Kubernetes ダッシュボード (ウェブ UI) のデプロイを基に解説します。

準備作業

Kubernetesクラスタを制御するためには、オンプレミスやクラウドに関わらずクライアント側にkubectlなどのインターフェイスが必要になります。

また、AWS環境におけるEKSのクラスターを制御する場合は、eksctl (Amazon EKS での Kubernetes クラスターの作成および管理用のシンプルなコマンドラインユーティリティ) もありますが、本記事では汎用性が高いkubectlを利用します。詳細はAWS マネジメントコンソール の使用開始を参照。

本記事の前提条件は以下になります。

  • 操作するローカルの端末(Mac）に、AWS コマンドラインインターフェイス（CLI）がインストールされていること
  • EKSでKubernetesが既に構築済

AWS CLI 認証情報の設定

AWSのリソースを操作するためには、AWSの認証情報の設定が必要です。

以下のコマンドを実行し、必要な認証情報を対話的に入力します。

$ aws configure

AWS Access Key ID [None]: hoge
AWS Secret Access Key [None]: hoge
Default region name [None]: ap-northeast-1
Default output format [None]: json

認証情報を設定後に再度aws configureコマンドを実行すると、先ほど設定した認証情報が表示されます。

AWS Access Key ID [****************hoge]: 
AWS Secret Access Key [****************hoge]: 
Default region name [ap-northeast-1]: 
Default output format [json]:

kubectlのインストールと設定

kubectlもコマンドラインツールとして用意されています。

kubectlのバイナリとkubectlのハッシュ値が記載されたファイルをダウンロード します。
$ curl -o kubectl https://amazon-eks.s3.us-west-2.amazonaws.com/1.17.7/2020-07-08/bin/darwin/amd64/kubectl

$ curl -o kubectl.sha256 https://amazon-eks.s3.us-west-2.amazonaws.com/1.17.7/2020-07-08/bin/darwin/amd64/kubectl.sha256

ダウンロードしたkubectlのバイナリとkubectlのハッシュ値が記載されたファイルを突合し、kubectlのバイナリの正真性が正しいことを確認します。以下はコマンドラインで突合する場合の例になります。

$ kubectl=`openssl sha1 -sha256 kubectl | awk '{print $2}'`
$ kubectl_sha256=`cat kubectl.sha256 | awk '{print $1}'`
$ if [ ${kubectl} = ${kubectl_sha256} ]; then  echo "true"; else echo "false";fi;
true

kubeconfigファイルの作成

kubectlを用いてKubernetesクラスターのMaster（AWSで言うEKS）と通信するためには、接続先クラスや認証情報等を記載したkubeconfigが必要です。

以下のコマンドを実行し、kubeconfigファイルを作成します。※＜cluster_name＞はクラスター名を指定
$ aws eks --region ap-northeast-1 update-kubeconfig --name ＜cluster_name＞

ダッシュボードのデプロイ

以下のコマンドを実行し、proxyを起動します。
$ kubectl proxy

以下のコマンドを実行し、トークンを抽出します。
$ kubectl -n kube-system describe secret

ブラウザを起動し、ダッシュボードエンドポイントにアクセスします。

http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/#!/login

上記で抽出したトークンを入力し、「サインイン」をクリックします。

スクリーンショット 2020-08-12 0.56.19.png

ダッシュボードにログインできます。

スクリーンショット 2020-08-12 0.56.33.png

おわりに

初見の場合、公式のチュートリアルの内容が分かりずらいと感じたため、一連の作業についてまとめました。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-08-12T06:59:01+09:00

Dockerの使い方　2日でDocker習得編 (udemy 米国AI開発者がゼロから教えるDocker講座）

夏のDocker合宿2日目

機械学習の環境構築をDockerで行う（Jupiter Lab)
メリット　
★環境構築のエラー回避
チーム開発の手間を下げる
リソースの有効活用（企業レベル？）

前提
Q「パス」を通すとは？
環境変数　＄PATHにパスを追加すること。
コンピューターがプログラムをそのパスから持ってこれるようにすること。
パスを通すためのLinuxコマンド

sudo
どのコマンドもルート権限で実行できるようになる。

1　＄echo＄PATH （今どこにパスが通っているのか確認）
2  ＄export PATH=/path/to/something:＄PATH パスを追加する

実践 Anacondaをコンテナに持っていき、インストールする

手順
１　docker run
２ sh Anaconda~(パッケージ名）.sh
３ export PATH ~
４ sh /パス -b -p /パス　　　（インストール時、面倒なインタラクティブなやりとりを回避するため）

ブラウザでlocal:host8888にアクセスする（Jupyterlabにアクセスする）
ブラウザ上でコンテナのなかでJupyterlabを立ち上げ、ホストにコードが保存される形で、コンテナからコードを書く。
（マウントする）

docker run -p 8888:8888 -v ~/Desktop/フォルダ名（Host側）:/(コンテナ側） --name my-lab \ <docker image>

Dockerfileの中身

FROM ubuntu:latest
RUN apt-get update && apt-get install -y \
sudo \
wget \
vim
WORKDIR /opt 
RUN wget https://repo.continuum.io/archive/Anaconda3-2020.02-Linux-x86_64.sh&& \
    sh Anaconda3-2020.02-Linux-x86_64.sh -b -p /opt/anaconda3 && \
    rm -f Anaconda3-2020.02-Linux-x86_64.sh

ENV PATH /opt/anaconda3/bin:$PATH

RUN pip install --upgrade pip
WORKDIR /
CMD ["jupyter","lab","--ip=0.0.0.0","--allow-root","--LabApp.token=''"]

大事なことは、上のコマンドの流れを覚えることではなくて、(いきなりスラスラ作るのは無理！）
Dockerfileをどういう風に作るかのプロセスを試行錯誤しながら慣れていくこと

AWSにDockerを立ち上げる

jmeter-in-aws-ec2.png

EC２ににアクセスするときの、権限を書く (sshで接続)

chmod400<file>
ssh -i  <keyname> ubuntu@<インスタンスDNS>

※キーがあるディレクトリからアクセスを行う。　（場所が違うとキーを見つけられずアクセスできない）

SFTP(Secure File Transfer Protocol) ファイルを送信するためのプロトコル（コマンド）
SSH　（Secure Shell) シェルを動かすためのコマンド

AWSでDockerコンテナを起動する方法
１　tarファイルに圧縮して送る　（EC２のサーバーのセキュリティが厳しい時など）

#docker image → tar ファイル  ... dockerimageを　tar.fileに変換する
$docker save {image} > {tar.file}

#tarファイル→docker image  ...EC２コンテナに送り、コンテナ内でtar.file（image)を開く
docker load < {tar.file}

２　Dockerfileを送って、開く　

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-08-12T02:38:32+09:00

LambdaのIP固定

実行毎に変わるLambdaのIPを固定。
呼び出し先のAPIにIPをホワイトリスト登録するなどで利用。

構成図

image.png

環境

  1. VPCを1つ用意する。
  2. サブネットとルーティングテーブルを2つずつ用意し、それぞれアタッチする。
  3. インターネットゲートウェイを作成し、VPCにアタッチ
  4. パブリックサブネットのルーティングテーブルの0.0.0.0/0をインターネットゲートウェイに向ける。
  5. EIP確保、NATゲートウェイ作成、プライベートサブネットのテーブルの0.0.0.0/0をNATに向ける。

Lambdaの作成/配置

  1. IAMロールの作成。ポリシーはAWSLambdaVPCAccessExecutionRole
  2. Lambda作成。
  3. LambdaコンソールのVPCを編集し、上記で作成した環境を選択する。適応までちょっと待つ。

検証

API Gatewayで呼び出し元のIPを表示してみる。

統合リクエストから以下を設定することで呼び出し元のIPを取得できる。

統合リクエストのマッピング
{
  "sourceIp" : "$context.identity.sourceIp",
  "input" : $input.path('$')
}
Lambda側のコード抜粋
request_url = "https://******.execute-api.ap-northeast-1.amazonaws.com/****"
api_key = "**********"

def lambda_handler(event, context):
    headers = {'x-api-key': api_key, "Content-Type":"application/json"}
    req = urllib.request.Request(url=request_url, method="GET", headers=headers)
    with urllib.request.urlopen(req) as res:
        body = res.read().decode("utf-8")
    return json.loads(body)

参考

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-08-12T02:15:43+09:00

AWS 認定ソリューションアーキテクト–アソシエイトの「AWS未経験でもできる勉強法の紹介」と「自宅で受験してみた感想」

AWS 認定ソリューションアーキテクト- アソシエイトを新卒やこれからAWSを始める人でも，できるだけ合格できるような勉強法を自分が実験体となって検証してみたという話です

他にも2020年5月からAWSの資格取得で始まった『自宅受験』の感想とかを書いてみました．
よかったら覗いてみていってください ! :bow_tone1:

対象となる人

  • AWSの勉強したいけど，どこから手をつければいいかわからない人向け
  • AWS 認定ソリューションアーキテクトを取りたい人向け
  • 自宅受験に興味があるけど，手を出すのをためらっている人向け

目次

  1. なぜAWSソリューションアーキテクトを受けようと考えたか
  2. 教材選び，実験の条件，勉強法・勉強スケジュール
  3. 自宅受験（ピアソンVUE [OnVue]はどうだったか）
  4. 感想

1. なぜAWSソリューションアーキテクトを受けようと考えたか

　僕はAWSを触り始めて1年が経ちますが，AWSを特殊な使い方？AIサービスに特化した使い方？をしていため，基礎知識が抜けている部分が多くあるだろうなと感じていました．

　また，AWS自体，お金がかかるし確立した勉強法がないため，初心者にはハードルが高いサービスになっているなと感じていました．

　そこで，自分が実験体となって，AWSの資格の勉強法などの検証してみて効果がでたら，
自分の役にも立つし，多くの人の助けにもなるのではないかと思ったのがきっかけです．

2. 教材選び，実験の条件，勉強法・勉強スケジュール

2-1. Qiitaの合格・不合格記事などをほとんど全て読んだ所…

  • Udemy最強説が浮上
  • よし，Udemyだけで合格してみようとなる（錯乱）．
  • Udemyだけで合格できれば，勉強法の説得力はあがるかなという謎の使命感
  • そして，自分が実験体となり，以下の条件を決めました．

2-2. 実験の条件

  1. 10日以内に勉強を終わらせること（長い期間勉強を行うと，サービスを使ったことで身についた効果と混ざるため）
  2. Udemy 縛り（ググるのはセーフ）
  3. 新卒のときの気分で1から勉強すること（自分が新人だと思いこむ（狂気））
  4. せっかくだし合格しよう

2-3. 勉強法・勉強スケジュール

10日間と決めましたが，勉強時間としては割とやったほうな気がします．
業務が終わってあと，寝落ちするまでやったりもしていました．
そのため，実際に初めてAWSを使う人や，時間に余裕がある人は，ゆっくりじっくり取り組んだ方がいいと思います．

勉強については，以下のUdemyの講座3つだけに絞りました．
いろいろとみてみましたが，最終的に以下のコースがいいのでは？という結論に至りました．
セールだとどれも2000円くらい．Udemyはアカウント登録時にセール行うらしいです．

Udemy講座1. AWS：ゼロから実践するAmazon Web Services．手を動かしながらインフラの基礎を習得

https://www.udemy.com/course/aws-and-infra/
講座時間：13時間　
検証時間：1.5倍速 (8.7時間）2日間の勉強
内容：
すごくわかりやすいです．
AWSをよく使う人からしたら簡単すぎると思われるかもしれないですが，何も知らない人はここから始めるくらいでいいと思います．
こういった基礎部分を身につけることで，他のサービスを理解する上での手助けになると思います．
また，ハンズオンと一緒に行われ，解説も丁寧にわかりやすく説明してくれるため，
例え何もしらなくても，なぜかできそうな気持ちになります．
全体的なレビューも高く，まったく触ったことのない人からのレビューも高かったです．EED4023D-ACD1-409B-B3B0-0335BB6042CB.png

Udemy講座2. これだけでOK！ AWS 認定ソリューションアーキテクト - アソシエイト試験突破講座（SAA-C02試験対応版）

https://www.udemy.com/course/aws-associate/
講座時間：26時間　
検証時間：1.5倍速　(17.4時間）4日間の勉強
内容：
AWS SAAのためにいろいろなサービスをハンズオンで学ぶことができます．
正直，あまりわかりやすいわけではなかったですが，
ボリュームがあり，試験範囲をある程度は網羅できました．
情報量がすごく多く．あまり面白くはなかったです．
ただ，この講座で知っておいた方が良いサービスを身に付けることができたと思います．
SAAを対策するなら，これをやっておいた方が良いと思いました．
動画の最後に，模擬試験（簡単）も3回分ついています，
この範囲がでるからこういうサービスを重点的にやったほうがいいなど，SAAに特化した内容になっている所がよかったです．
レビューに『これだけでOKではない！』というコメントが多かったです．www

77086923-54A4-4B50-9B20-F60755F64ABD.png

Udemy講座3. 【SAA-C02版】AWS 認定ソリューションアーキテクト アソシエイト模擬試験問題集（6回分390問）

https://www.udemy.com/course/aws-knan/
講座時間：動画なし（6回分模擬試験）
検証時間：4日間の勉強
内容：
6回分模擬試験を受けることができるという内容です．
1回目は講座2の模擬試験とかぶっています，2~5回目は高難易度問題集．6回目は，SAA-C02版に対応したものでした．
全ての試験で初見で50〜%以上取れていれば，合格が見えてくると思います．
本番より難しいですが，本番で出ないような新しいサービスに触れられて勉強になりました．
2周しましたが，やはり1周目が大事（初見でどのくらいとれるか）です
ボリュームがあり復習がするのが結構しんどかったです．苦手な分野を講座2で復習するとよいと思います．
390問遊べる！！
しんどかったけど，これをやってよかったと本当に思います．
スクリーンショット 2020-08-12 0.52.11.png

これらの3つの講座をしっかりやり込んでしっかり理解すれば，
AWSソリューションアーキテクトを合格できる知識を身につけることができると思います．
ただ，レビューとかにもありましたが，舐めているとガンガン試験に落ちるので，しっかりと復習が必要です．

3. 自宅受験（ピアソンVUE [OnVue]はどうだったか）

コロナの影響もあって，2020年5月あたりからAWSの資格取得を自宅でできるようになりました．

当たり前ですが，自宅受験でも試験内容は以下の通りで同じです．

制限時間：130分
問題数：65問
試験料：16,500円（税込）
合格点：720 ~ (1000点）

まだ始まったばかりなため，自宅受験したことがある人は少ないのかなと思っています．
特に以下の3つの点で挑戦できている人が少ないのではないかなと思います．

1. OnVUEのセッティング
2. 自宅の整備
3. 試験監督とのやりとりが英語のみ

それぞれ，僕が受けた印象を話していきたいと思います．

3-1. OnVUEのセッティング

先に結論を言うと，そんなに環境設定は難しくなかったです．

自宅受験ですが，OnVUE（Pearson VUE社が提供するオンライン監督試験）で受験できます．
まず，OnVUEの環境を自分のPCに作るために，
以下の画像の3つのステップの順に進んでいき，試験準備を進めていきます．
スクリーンショット 2020-08-12 1.05.19.png
どうやっていくかについては，以下の記事を参考にしました．
https://dev.classmethod.jp/articles/aws-exam-at-home/
基本的に，上記の記事かOnVUEの言うとおりに進んでいけば，問題なくセッティングが終わります．

強いて，つまった点を言うと，
　上記の記事だと環境を作る際（試験より前）にパスポートor免許書の画像を送信する必要があるように見えますが，実際は試験直前（上の画像の3番目）に言われた通りに写真をとるということくらいです（勘違いしたのは自分だけかもしれないです）．

あと，補足として，
一般的な受験の『会場指定』の方は，当日とかの受験はできなかったのですが，
今回紹介した『自宅受験』であれば，当日受験とかもできました．
ただ，当日の場合は，試験候補日時をだされたあと，すぐ埋まったり，
時間をおいてリロードしたら，また候補日時が更新されたりと，割とスピード勝負でした．
いかにクレジットカード情報を速く入力するかみたいな勝負になっていました．
僕の場合は，当日夜の9時くらいから受けました．30分前からチェックインできます．
チェックインするときに，パスポートor免許書を写真で撮り，受験部屋の4方向の写真をとり，送信しました．

3-2. 自宅の整備

結論：部屋が綺麗であれば大体大丈夫！！
（※もちろん，手の届く範囲に電子機器があったりしてはいけないです）
正面にテレビとかがありましたが，全然大丈夫でした．

3-3. 試験監督とのやりとりが英語のみ

結構英語でしゃべらないといけないのかな？と思っていましたが，
だいたいはチャットでやりとりして，マイクテストの時に『Can you hear me?』とか聞かれたくらいでした．
チャットでは『腕見せて』とか，『カメラをデスクに向けて』ぐらいで，やりとりはほとんどありませんでした．
試験中に話しかけられることもなく，無事終了して合格しました．

3-4.自宅受験の感想

セッティングやら英語でしかやりとりできないやら，
いろいろ大変そうだなと思っていましたが，
とりあえず何事も挑戦ということでやってみたら，意外と簡単に受けられました．

実際に自宅で受験してみて，明らかに自宅の方が楽だなーという印象を受けたので
今後も使えるなら使いたいと思いました．
ちょっと迷っている人も挑戦してみてもいいんじゃないかなと思います．

以上の検証の結論

  • 短い期間でUdemyの勉強のみでAWSソリューションアーキテクトを合格できた．
    →　Udemyの効果を検証できた．
    もちろん主観も入っていると思いますし，ベストではないかもしれませんが，
    上記の3講座をしっかりやっておけば，最低限の知識はを学べるかなと思いました．

  • 自宅受験はすばらしい

4. 感想

最初は，『新人やAWSを基礎から学びたい人におすすめの講座がないかな？』
と思って検証していましたが，
学習していくうちに自分の力にもなっていった実感がありました．

僕はあるあるだと思っているのですが，
だんだんAWSのサービスに触れていくと（AWSに限らず），
知らなかったことが自分自身のなかで当たり前となってしまい，
その当たり前のことを共有するのが難しくなっていくものだと思っています．

だからこそ，今回は初心者になりきって（初心者の気持ちになれたかは怪しいですが），
初めから勉強し，新人やAWSを基礎から学びたい人向けの記事を共有できてよかったと思っています．

今回の記事が少しでも多くの人の助けになれば嬉しいです！

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-08-12T02:15:43+09:00

AWS 認定ソリューションアーキテクト–アソシエイト(SAA)の「AWS未経験でもできる勉強法」と「自宅受験してみた感想」

AWS 認定ソリューションアーキテクト- アソシエイトを新卒やこれからAWSを始める人でも，できるだけ合格できるような勉強法を自分が実験体となって検証してみたという話です

他にも2020年5月からAWSの資格取得で始まった『自宅受験』の感想とかを書いてみました．
よかったら覗いてみていってください ! :bow_tone1:

対象となる人

  • AWSの勉強したいけど，どこから手をつければいいかわからない人向け
  • AWS 認定ソリューションアーキテクトを取りたい人向け
  • 自宅受験に興味があるけど，手を出すのをためらっている人向け

目次

  1. なぜAWSソリューションアーキテクトを受けようと考えたか
  2. 教材選び，実験の条件，勉強法・勉強スケジュール
  3. 自宅受験（ピアソンVUE [OnVue]はどうだったか）
  4. 感想

1. なぜAWSソリューションアーキテクトを受けようと考えたか

　僕はAWSを触り始めて1年が経ちますが，AWSを特殊な使い方？AIサービスに特化した使い方？をしていため，基礎知識が抜けている部分が多くあるだろうなと感じていました．

　また，AWS自体，お金がかかるし確立した勉強法がないため，初心者にはハードルが高いサービスになっているなと感じていました．

　そこで，自分が実験体となって，AWSの資格の勉強法などの検証してみて効果がでたら，
自分の役にも立つし，多くの人の助けにもなるのではないかと思ったのがきっかけです．

2. 教材選び，実験の条件，勉強法・勉強スケジュール

2-1. Qiitaの合格・不合格記事などをほとんど全て読んだ所…

  • Udemy最強説が浮上
  • よし，Udemyだけで合格してみようとなる（錯乱）．
  • Udemyだけで合格できれば，勉強法の説得力はあがるかなという謎の使命感
  • そして，自分が実験体となり，以下の条件を決めました．

2-2. 実験の条件

  1. 10日以内に勉強を終わらせること（長い期間勉強を行うと，サービスを使ったことで身についた効果と混ざるため）
  2. Udemy 縛り（ググるのはセーフ）
  3. 新卒のときの気分で1から勉強すること（自分が新人だと思いこむ（狂気））
  4. せっかくだし合格しよう

2-3. 勉強法・勉強スケジュール

10日間と決めましたが，勉強時間としては割とやったほうな気がします．
業務が終わったあと，寝落ちするまで勉強していました．
そのため，実際に初めてAWSを使う人や，時間に余裕がある人は，ゆっくりじっくり取り組んだ方がいいと思います．

勉強については，以下のUdemyの講座3つだけに絞りました．
いろいろとみてみましたが，最終的に以下のコースがいいのでは？という結論に至りました．
セールだとどれも2000円くらい．Udemyはアカウント登録時にセール行うらしいです．

Udemy講座1. AWS：ゼロから実践するAmazon Web Services．手を動かしながらインフラの基礎を習得

https://www.udemy.com/course/aws-and-infra/
講座時間：13時間　
検証時間：1.5倍速 (8.7時間）2日間の勉強
内容：
すごくわかりやすいです．
AWSをよく使う人からしたら簡単すぎると思われるかもしれないですが，何も知らない人はここから始めるくらいでいいと思います．
こういった基礎部分を身につけることで，他のサービスを理解する上での手助けになると思います．
また，ハンズオンと一緒に行われ，解説も丁寧にわかりやすく説明してくれるため，
例え何もしらなくても，なぜかできそうな気持ちになります．
全体的なレビューも高く，まったく触ったことのない人からのレビューも高かったです．EED4023D-ACD1-409B-B3B0-0335BB6042CB.png

Udemy講座2. これだけでOK！ AWS 認定ソリューションアーキテクト - アソシエイト試験突破講座（SAA-C02試験対応版）

https://www.udemy.com/course/aws-associate/
講座時間：26時間　
検証時間：1.5倍速　(17.4時間）4日間の勉強
内容：
AWS SAAのためにいろいろなサービスをハンズオンで学ぶことができます．
正直，あまりわかりやすいわけではなかったですが，
ボリュームがあり，試験範囲をある程度は網羅できました．
情報量がすごく多く，あまり面白くはなかったです．
ただ，この講座で知っておいた方が良いサービスを身に付けることができたと思います．
SAAを対策するなら，これをやっておいた方が良いと思いました．
動画の最後に，模擬試験（簡単）も3回分ついています，
この範囲がでるからこういうサービスを重点的にやったほうがいいなど，SAAに特化した内容になっている所がよかったです．
レビューに『これだけでOKではない！』というコメントが多かったです．www

77086923-54A4-4B50-9B20-F60755F64ABD.png

Udemy講座3. 【SAA-C02版】AWS 認定ソリューションアーキテクト アソシエイト模擬試験問題集（6回分390問）

https://www.udemy.com/course/aws-knan/
講座時間：動画なし（6回分模擬試験）
検証時間：4日間の勉強
内容：
6回分模擬試験を受けることができるという内容です．
1回目は講座2の模擬試験とかぶっています，2~5回目は高難易度問題集．6回目は，SAA-C02版に対応したものでした．
全ての試験で初見で50〜%以上取れていれば，合格が見えてくると思います．
本番より難しいですが，本番で出ないような新しいサービスに触れられて勉強になりました．
2周しましたが，やはり1周目が大事（初見でどのくらいとれるか）です
ボリュームがあり復習がするのが結構しんどかったです．苦手な分野を講座2で復習するとよいと思います．
390問遊べる！！
しんどかったけど，これをやってよかったと本当に思います．
スクリーンショット 2020-08-12 0.52.11.png

これらの3つの講座をしっかりやり込んでしっかり理解すれば，
AWSソリューションアーキテクトを合格できる知識を身につけることができると思います．
ただ，レビューとかにもありましたが，舐めているとガンガン試験に落ちるので，しっかりと復習が必要です．

3. 自宅受験（ピアソンVUE [OnVue]はどうだったか）

コロナの影響もあって，2020年5月あたりからAWSの資格取得を自宅でできるようになりました．

自宅受験でも試験内容は以下の通りで同じです．

制限時間：130分
問題数：65問
試験料：16,500円（税込）
合格点：720 ~ (1000点）

まだ始まったばかりなため，自宅受験したことがある人は少ないのかなと思っています．
特に以下の3つの点で挑戦できている人が少ないのではないかなと思います．

1. OnVUEのセッティング
2. 自宅の整備
3. 試験監督とのやりとりが英語のみ

それぞれ，僕が受けた印象を話していきたいと思います．

3-1. OnVUEのセッティング

先に結論を言うと，そんなに環境設定は難しくなかったです．

自宅受験ですが，OnVUE（Pearson VUE社が提供するオンライン監督試験）で受験できます．
まず，OnVUEの環境を自分のPCに作るために，
以下の画像の3つのステップの順に進んでいき，試験準備を進めていきます．
スクリーンショット 2020-08-12 1.05.19.png
どうやっていくかについては，以下の記事を参考にしました．
https://dev.classmethod.jp/articles/aws-exam-at-home/
基本的に，上記の記事かOnVUEの言うとおりに進んでいけば，問題なくセッティングが終わります．

強いて，つまった点を言うと，
　上記の記事だと環境を作る際（試験より前）にパスポートor免許書の画像を送信する必要があるように見えますが，実際は試験直前（上の画像の3番目）に言われた通りに写真をとるということくらいです（勘違いしたのは自分だけかもしれないです）．

あと，補足として，
一般的な受験の『会場指定』の方は，当日とかの受験はできなかったのですが，
今回紹介した『自宅受験』であれば，当日受験とかもできました．
ただ，当日の場合は，試験候補日時をだされたあと，すぐ埋まったり，
時間をおいてリロードしたら，また候補日時が更新されたりと，割とスピード勝負でした．
いかにクレジットカード情報を速く入力するかみたいな勝負になっていました．
僕の場合は，当日夜の9時くらいから受けました．30分前からチェックインできます．
チェックインするときに，パスポートor免許書を写真で撮り，受験部屋の4方向の写真をとり，送信しました．

3-2. 自宅の整備

結論：部屋が綺麗であれば大体大丈夫！！
（※もちろん，手の届く範囲に電子機器があったりしてはいけないです）
正面にテレビとかがありましたが，全然大丈夫でした．

3-3. 試験監督とのやりとりが英語のみ

結構英語でしゃべらないといけないのかな？と思っていましたが，
だいたいはチャットでやりとりして，マイクテストの時に『Can you hear me?』とか聞かれたくらいでした．
チャットでは『腕見せて』とか，『カメラをデスクに向けて』ぐらいで，やりとりはほとんどありませんでした．
試験中に話しかけられることもなく，無事終了して合格しました．

3-4.自宅受験の感想

セッティングやら英語でしかやりとりできないやら，
いろいろ大変そうだなと思っていましたが，
とりあえず何事も挑戦ということでやってみたら，意外と簡単に受けられました．

実際に自宅で受験してみて，明らかに自宅の方が楽だなーという印象を受けたので
今後も使えるなら使いたいと思いました．
ちょっと迷っている人も挑戦してみてもいいんじゃないかなと思います．

以上の検証の結論

  • 短い期間でUdemyの勉強のみでAWSソリューションアーキテクトを合格できた．
    →　Udemyの効果を検証できた．
    もちろん主観も入っていると思いますし，ベストではないかもしれませんが，
    上記の3講座をしっかりやっておけば，最低限の知識はを学べるかなと思いました．

  • 自宅受験はすばらしい

4. 感想

最初は，『新人やAWSを基礎から学びたい人におすすめの講座がないかな？』
と思って検証していましたが，
学習していくうちに自分の力にもなっていった実感がありました．

僕はあるあるだと思っているのですが，
だんだんAWSのサービスに触れていくと（AWSに限らず），
知らなかったことが自分自身のなかで当たり前となってしまい，
その当たり前のことを共有するのが難しくなっていくものだと思っています．

だからこそ，今回は初心者になりきって（初心者の気持ちになれたかは怪しいですが），
初めから勉強し，新人やAWSを基礎から学びたい人向けの記事を共有できてよかったと思っています．

今回の記事が少しでも多くの人の助けになれば嬉しいです！

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-08-12T02:15:43+09:00

AWS 認定ソリューションアーキテクト–アソシエイト(SAA)の「10日で合格した勉強法」と「自宅受験してみた感想」

AWS 認定ソリューションアーキテクト- アソシエイトを新卒やこれからAWSを始める人でも，できるだけ合格できるような勉強法を自分が実験体となって検証してみたという話です

他にも2020年5月からAWSの資格取得で始まった『自宅受験』の感想とかを書いてみました．
よかったら覗いてみていってください ! :bow_tone1:

対象となる人

  • AWSの勉強したいけど，どこから手をつければいいかわからない人向け
  • AWS 認定ソリューションアーキテクトを取りたい人向け
  • 自宅受験に興味があるけど，手を出すのをためらっている人向け

目次

  1. なぜAWSソリューションアーキテクトを受けようと考えたか
  2. 教材選び，実験の条件，勉強法・勉強スケジュール
  3. 自宅受験（ピアソンVUE [OnVue]はどうだったか）
  4. 感想

1. なぜAWSソリューションアーキテクトを受けようと考えたか

　僕はAWSを触り始めて1年が経ちますが，AWSを特殊な使い方？AIサービスに特化した使い方？をしていため，基礎知識が抜けている部分が多くあるだろうなと感じていました．

　また，AWS自体，お金がかかるし確立した勉強法がないため，初心者にはハードルが高いサービスになっているなと感じていました．

　そこで，自分が実験体となって，AWSの資格の勉強法などの検証してみて効果がでたら，
自分の役にも立つし，多くの人の助けにもなるのではないかと思ったのがきっかけです．

2. 教材選び，実験の条件，勉強法・勉強スケジュール

2-1. Qiitaの合格・不合格記事などをほとんど全て読んだ所…

  • Udemy最強説が浮上
  • よし，Udemyだけで合格してみようとなる（錯乱）．
  • Udemyだけで合格できれば，勉強法の説得力はあがるかなという謎の使命感
  • そして，自分が実験体となり，以下の条件を決めました．

2-2. 実験の条件

  1. 10日以内に勉強を終わらせること（長い期間勉強を行うと，サービスを使ったことで身についた効果と混ざるため）
  2. Udemy 縛り（ググるのはセーフ）
  3. 新卒のときの気分で1から勉強すること（自分が新人だと思いこむ（狂気））
  4. せっかくだし合格しよう

2-3. 勉強法・勉強スケジュール

10日間と決めましたが，勉強時間としては割とやったほうな気がします．
業務が終わったあと，寝落ちするまで勉強していました．
そのため，実際に初めてAWSを使う人や，時間に余裕がある人は，ゆっくりじっくり取り組んだ方がいいと思います．

勉強については，以下のUdemyの講座3つだけに絞りました．
いろいろとみてみましたが，最終的に以下のコースがいいのでは？という結論に至りました．
セールだとどれも2000円くらい．Udemyはアカウント登録時にセール行うらしいです．

Udemy講座1. AWS：ゼロから実践するAmazon Web Services．手を動かしながらインフラの基礎を習得

https://www.udemy.com/course/aws-and-infra/
講座時間：13時間　
検証時間：1.5倍速 (8.7時間）2日間の勉強
内容：
すごくわかりやすいです．
AWSをよく使う人からしたら簡単すぎると思われるかもしれないですが，何も知らない人はここから始めるくらいでいいと思います．
こういった基礎部分を身につけることで，他のサービスを理解する上での手助けになると思います．
また，ハンズオンと一緒に行われ，解説も丁寧にわかりやすく説明してくれるため，
例え何もしらなくても，なぜかできそうな気持ちになります．
全体的なレビューも高く，まったく触ったことのない人からのレビューも高かったです．EED4023D-ACD1-409B-B3B0-0335BB6042CB.png

Udemy講座2. これだけでOK！ AWS 認定ソリューションアーキテクト - アソシエイト試験突破講座（SAA-C02試験対応版）

https://www.udemy.com/course/aws-associate/
講座時間：26時間　
検証時間：1.5倍速　(17.4時間）4日間の勉強
内容：
AWS SAAのためにいろいろなサービスをハンズオンで学ぶことができます．
正直，あまりわかりやすいわけではなかったですが，
ボリュームがあり，試験範囲をある程度は網羅できました．
情報量がすごく多く．あまり面白くはなかったです．
ただ，この講座で知っておいた方が良いサービスを身に付けることができたと思います．
SAAを対策するなら，これをやっておいた方が良いと思いました．
動画の最後に，模擬試験（簡単）も3回分ついています，
この範囲がでるからこういうサービスを重点的にやったほうがいいなど，SAAに特化した内容になっている所がよかったです．
レビューに『これだけでOKではない！』というコメントが多かったです．www

77086923-54A4-4B50-9B20-F60755F64ABD.png

Udemy講座3. 【SAA-C02版】AWS 認定ソリューションアーキテクト アソシエイト模擬試験問題集（6回分390問）

https://www.udemy.com/course/aws-knan/
講座時間：動画なし（6回分模擬試験）
検証時間：4日間の勉強
内容：
6回分模擬試験を受けることができるという内容です．
1回目は講座2の模擬試験とかぶっています，2~5回目は高難易度問題集．6回目は，SAA-C02版に対応したものでした．
全ての試験で初見で50〜%以上取れていれば，合格が見えてくると思います．
本番より難しいですが，本番で出ないような新しいサービスに触れられて勉強になりました．
2周しましたが，やはり1周目が大事（初見でどのくらいとれるか）です
ボリュームがあり復習がするのが結構しんどかったです．苦手な分野を講座2で復習するとよいと思います．
390問遊べる！！
しんどかったけど，これをやってよかったと本当に思います．
スクリーンショット 2020-08-12 0.52.11.png

これらの3つの講座をしっかりやり込んでしっかり理解すれば，
AWSソリューションアーキテクトを合格できる知識を身につけることができると思います．
ただ，レビューとかにもありましたが，舐めているとガンガン試験に落ちるので，しっかりと復習が必要です．

3. 自宅受験（ピアソンVUE [OnVue]はどうだったか）

コロナの影響もあって，2020年5月あたりからAWSの資格取得を自宅でできるようになりました．

当たり前ですが，自宅受験でも試験内容は以下の通りで同じです．

制限時間：130分
問題数：65問
試験料：16,500円（税込）
合格点：720 ~ (1000点）

まだ始まったばかりなため，自宅受験したことがある人は少ないのかなと思っています．
特に以下の3つの点で挑戦できている人が少ないのではないかなと思います．

1. OnVUEのセッティング
2. 自宅の整備
3. 試験監督とのやりとりが英語のみ

それぞれ，僕が受けた印象を話していきたいと思います．

3-1. OnVUEのセッティング

先に結論を言うと，そんなに環境設定は難しくなかったです．

自宅受験ですが，OnVUE（Pearson VUE社が提供するオンライン監督試験）で受験できます．
まず，OnVUEの環境を自分のPCに作るために，
以下の画像の3つのステップの順に進んでいき，試験準備を進めていきます．
スクリーンショット 2020-08-12 1.05.19.png
どうやっていくかについては，以下の記事を参考にしました．
https://dev.classmethod.jp/articles/aws-exam-at-home/
基本的に，上記の記事かOnVUEの言うとおりに進んでいけば，問題なくセッティングが終わります．

強いて，つまった点を言うと，
　上記の記事だと環境を作る際（試験より前）にパスポートor免許書の画像を送信する必要があるように見えますが，実際は試験直前（上の画像の3番目）に言われた通りに写真をとるということくらいです（勘違いしたのは自分だけかもしれないです）．

あと，補足として，
一般的な受験の『会場指定』の方は，当日とかの受験はできなかったのですが，
今回紹介した『自宅受験』であれば，当日受験とかもできました．
ただ，当日の場合は，試験候補日時をだされたあと，すぐ埋まったり，
時間をおいてリロードしたら，また候補日時が更新されたりと，割とスピード勝負でした．
いかにクレジットカード情報を速く入力するかみたいな勝負になっていました．
僕の場合は，当日夜の9時くらいから受けました．30分前からチェックインできます．
チェックインするときに，パスポートor免許書を写真で撮り，受験部屋の4方向の写真をとり，送信しました．

3-2. 自宅の整備

結論：部屋が綺麗であれば大体大丈夫！！
（※もちろん，手の届く範囲に電子機器があったりしてはいけないです）
正面にテレビとかがありましたが，全然大丈夫でした．

3-3. 試験監督とのやりとりが英語のみ

結構英語でしゃべらないといけないのかな？と思っていましたが，
だいたいはチャットでやりとりして，マイクテストの時に『Can you hear me?』とか聞かれたくらいでした．
チャットでは『腕見せて』とか，『カメラをデスクに向けて』ぐらいで，やりとりはほとんどありませんでした．
試験中に話しかけられることもなく，無事終了して合格しました．

3-4.自宅受験の感想

セッティングやら英語でしかやりとりできないやら，
いろいろ大変そうだなと思っていましたが，
とりあえず何事も挑戦ということでやってみたら，意外と簡単に受けられました．

実際に自宅で受験してみて，明らかに自宅の方が楽だなーという印象を受けたので
今後も使えるなら使いたいと思いました．
ちょっと迷っている人も挑戦してみてもいいんじゃないかなと思います．

以上の検証の結論

  • 短い期間でUdemyの勉強のみでAWSソリューションアーキテクトを合格できた．
    →　Udemyの効果を検証できた．
    もちろん主観も入っていると思いますし，ベストではないかもしれませんが，
    上記の3講座をしっかりやっておけば，最低限の知識はを学べるかなと思いました．

  • 自宅受験はすばらしい

4. 感想

最初は，『新人やAWSを基礎から学びたい人におすすめの講座がないかな？』
と思って検証していましたが，
学習していくうちに自分の力にもなっていった実感がありました．

僕はあるあるだと思っているのですが，
だんだんAWSのサービスに触れていくと（AWSに限らず），
知らなかったことが自分自身のなかで当たり前となってしまい，
その当たり前のことを共有するのが難しくなっていくものだと思っています．

だからこそ，今回は初心者になりきって（初心者の気持ちになれたかは怪しいですが），
初めから勉強し，新人やAWSを基礎から学びたい人向けの記事を共有できてよかったと思っています．

今回の記事が少しでも多くの人の助けになれば嬉しいです！

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-08-12T02:15:43+09:00

AWS SAA 資格を10日間の自宅学習だけで合格する方法！ついでに自宅受験も試してみました！

AWS 認定ソリューションアーキテクト- アソシエイト(SAA)を新卒やこれからAWSを始める人でも，できるだけ合格できるような勉強法を自分が実験体となって検証してみたという話です

他にも2020年5月からAWSの資格取得で始まった『自宅受験』の感想とかを書いてみました．
よかったら覗いてみていってください ! :bow_tone1:

対象となる人

  • AWSの勉強したいけど，どこから手をつければいいかわからない人向け
  • AWS 認定ソリューションアーキテクトを取りたい人向け
  • 自宅受験に興味があるけど，手を出すのをためらっている人向け

目次

  1. なぜAWSソリューションアーキテクトを受けようと考えたか
  2. 教材選び，実験の条件，勉強法・勉強スケジュール
  3. 自宅受験（ピアソンVUE [OnVue]はどうだったか）
  4. 感想

1. なぜAWSソリューションアーキテクトを受けようと考えたか

　僕はAWSを触り始めて1年が経ちますが，AWSを特殊な使い方？AIサービスに特化した使い方？をしていため，基礎知識が抜けている部分が多くあるだろうなと感じていました．

　また，AWS自体，お金がかかるし確立した勉強法がないため，初心者にはハードルが高いサービスになっているなと感じていました．

　そこで，自分が実験体となって，AWSの資格の勉強法などの検証してみて効果がでたら，
自分の役にも立つし，多くの人の助けにもなるのではないかと思ったのがきっかけです．

2. 教材選び，実験の条件，勉強法・勉強スケジュール

2-1. Qiitaの合格・不合格記事などをほとんど全て読んだ所…

  • Udemy最強説が浮上
  • よし，Udemyだけで合格してみようとなる（錯乱）．
  • Udemyだけで合格できれば，勉強法の説得力はあがるかなという謎の使命感
  • そして，自分が実験体となり，以下の条件を決めました．

2-2. 実験の条件

  1. 10日以内に勉強を終わらせること（長い期間勉強を行うと，サービスを使ったことで身についた効果と混ざるため）
  2. Udemy 縛り（ググるのはセーフ）
  3. 新卒のときの気分で1から勉強すること（自分が新人だと思いこむ（狂気））
  4. せっかくだし合格しよう

2-3. 勉強法・勉強スケジュール

10日間と決めましたが，勉強時間としては割とやったほうな気がします．
業務が終わったあと，寝落ちするまで勉強していました．
そのため，実際に初めてAWSを使う人や，時間に余裕がある人は，ゆっくりじっくり取り組んだ方がいいと思います．

勉強については，以下のUdemyの講座3つだけに絞りました．
いろいろとみてみましたが，最終的に以下のコースがいいのでは？という結論に至りました．
セールだとどれも2000円くらい．Udemyはアカウント登録時にセール行うらしいです．

Udemy講座1. AWS：ゼロから実践するAmazon Web Services．手を動かしながらインフラの基礎を習得

https://www.udemy.com/course/aws-and-infra/
講座時間：13時間　
検証時間：1.5倍速 (8.7時間）2日間の勉強
内容：
すごくわかりやすいです．
AWSをよく使う人からしたら簡単すぎると思われるかもしれないですが，何も知らない人はここから始めるくらいでいいと思います．
こういった基礎部分を身につけることで，他のサービスを理解する上での手助けになると思います．
また，ハンズオンと一緒に行われ，解説も丁寧にわかりやすく説明してくれるため，
例え何もしらなくても，なぜかできそうな気持ちになります．
全体的なレビューも高く，まったく触ったことのない人からのレビューも高かったです．EED4023D-ACD1-409B-B3B0-0335BB6042CB.png

Udemy講座2. これだけでOK！ AWS 認定ソリューションアーキテクト - アソシエイト試験突破講座（SAA-C02試験対応版）

https://www.udemy.com/course/aws-associate/
講座時間：26時間　
検証時間：1.5倍速　(17.4時間）4日間の勉強
内容：
AWS SAAのためにいろいろなサービスをハンズオンで学ぶことができます．
正直，あまりわかりやすいわけではなかったですが，
ボリュームがあり，試験範囲をある程度は網羅できました．
情報量がすごく多く，あまり面白くはなかったです．
ただ，この講座で知っておいた方が良いサービスを身に付けることができたと思います．
SAAを対策するなら，これをやっておいた方が良いと思いました．
動画の最後に，模擬試験（簡単）も3回分ついています，
この範囲がでるからこういうサービスを重点的にやったほうがいいなど，SAAに特化した内容になっている所がよかったです．
レビューに『これだけでOKではない！』というコメントが多かったです．www

77086923-54A4-4B50-9B20-F60755F64ABD.png

Udemy講座3. 【SAA-C02版】AWS 認定ソリューションアーキテクト アソシエイト模擬試験問題集（6回分390問）

https://www.udemy.com/course/aws-knan/
講座時間：動画なし（6回分模擬試験）
検証時間：4日間の勉強
内容：
6回分模擬試験を受けることができるという内容です．
1回目は講座2の模擬試験とかぶっています，2~5回目は高難易度問題集．6回目は，SAA-C02版に対応したものでした．
全ての試験で初見で50〜%以上取れていれば，合格が見えてくると思います．
本番より難しいですが，本番で出ないような新しいサービスに触れられて勉強になりました．
2周しましたが，やはり1周目が大事（初見でどのくらいとれるか）です
ボリュームがあり復習がするのが結構しんどかったです．苦手な分野を講座2で復習するとよいと思います．
390問遊べる！！
しんどかったけど，これをやってよかったと本当に思います．
スクリーンショット 2020-08-12 0.52.11.png

これらの3つの講座をしっかりやり込んでしっかり理解すれば，
AWSソリューションアーキテクトを合格できる知識を身につけることができると思います．
ただ，レビューとかにもありましたが，舐めているとガンガン試験に落ちるので，しっかりと復習が必要です．

3. 自宅受験（ピアソンVUE [OnVue]はどうだったか）

コロナの影響もあって，2020年5月あたりからAWSの資格取得を自宅でできるようになりました．

自宅受験でも試験内容は以下の通りで同じです．

制限時間：130分
問題数：65問
試験料：16,500円（税込）
合格点：720 ~ (1000点）

まだ始まったばかりなため，自宅受験したことがある人は少ないのかなと思っています．
特に以下の3つの点で挑戦できている人が少ないのではないかなと思います．

1. OnVUEのセッティング
2. 自宅の整備
3. 試験監督とのやりとりが英語のみ

それぞれ，僕が受けた印象を話していきたいと思います．

3-1. OnVUEのセッティング

先に結論を言うと，そんなに環境設定は難しくなかったです．

自宅受験ですが，OnVUE（Pearson VUE社が提供するオンライン監督試験）で受験できます．
まず，OnVUEの環境を自分のPCに作るために，
以下の画像の3つのステップの順に進んでいき，試験準備を進めていきます．
スクリーンショット 2020-08-12 1.05.19.png
どうやっていくかについては，以下の記事を参考にしました．
https://dev.classmethod.jp/articles/aws-exam-at-home/
基本的に，上記の記事かOnVUEの言うとおりに進んでいけば，問題なくセッティングが終わります．

強いて，つまった点を言うと，
　上記の記事だと環境を作る際（試験より前）にパスポートor免許書の画像を送信する必要があるように見えますが，実際は試験直前（上の画像の3番目）に言われた通りに写真をとるということくらいです（勘違いしたのは自分だけかもしれないです）．

あと，補足として，
一般的な受験の『会場指定』の方は，当日とかの受験はできなかったのですが，
今回紹介した『自宅受験』であれば，当日受験とかもできました．
ただ，当日の場合は，試験候補日時をだされたあと，すぐ埋まったり，
時間をおいてリロードしたら，また候補日時が更新されたりと，割とスピード勝負でした．
いかにクレジットカード情報を速く入力するかみたいな勝負になっていました．
僕の場合は，当日夜の9時くらいから受けました．30分前からチェックインできます．
チェックインするときに，パスポートor免許書を写真で撮り，受験部屋の4方向の写真をとり，送信しました．

3-2. 自宅の整備

結論：部屋が綺麗であれば大体大丈夫！！
（※もちろん，手の届く範囲に電子機器があったりしてはいけないです）
正面にテレビとかがありましたが，全然大丈夫でした．

3-3. 試験監督とのやりとりが英語のみ

結構英語でしゃべらないといけないのかな？と思っていましたが，
だいたいはチャットでやりとりして，マイクテストの時に『Can you hear me?』とか聞かれたくらいでした．
チャットでは『腕見せて』とか，『カメラをデスクに向けて』ぐらいで，やりとりはほとんどありませんでした．
試験中に話しかけられることもなく，無事終了して合格しました．

3-4.自宅受験の感想

セッティングやら英語でしかやりとりできないやら，
いろいろ大変そうだなと思っていましたが，
とりあえず何事も挑戦ということでやってみたら，意外と簡単に受けられました．

実際に自宅で受験してみて，明らかに自宅の方が楽だなーという印象を受けたので
今後も使えるなら使いたいと思いました．
ちょっと迷っている人も挑戦してみてもいいんじゃないかなと思います．

以上の検証の結論

  • 短い期間でUdemyの勉強のみでAWSソリューションアーキテクトを合格できた．
    →　Udemyの効果を検証できた．
    もちろん主観も入っていると思いますし，ベストではないかもしれませんが，
    上記の3講座をしっかりやっておけば，最低限の知識はを学べるかなと思いました．

  • 自宅受験はすばらしい

4. 感想

最初は，『新人やAWSを基礎から学びたい人におすすめの講座がないかな？』
と思って検証していましたが，
学習していくうちに自分の力にもなっていった実感がありました．

僕はあるあるだと思っているのですが，
だんだんAWSのサービスに触れていくと（AWSに限らず），
知らなかったことが自分自身のなかで当たり前となってしまい，
その当たり前のことを共有するのが難しくなっていくものだと思っています．

だからこそ，今回は初心者になりきって（初心者の気持ちになれたかは怪しいですが），
初めから勉強し，新人やAWSを基礎から学びたい人向けの記事を共有できてよかったと思っています．

今回の記事が少しでも多くの人の助けになれば嬉しいです！

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-08-12T02:15:43+09:00

AWS SAA 資格を10日間の自宅学習だけで合格しました！ついでに自宅受験も試してみました！

AWS 認定ソリューションアーキテクト- アソシエイト(SAA)を新卒やこれからAWSを始める人でも，できるだけ合格できるような勉強法を自分が実験体となって検証してみたという話です

他にも2020年5月からAWSの資格取得で始まった『自宅受験』の感想とかを書いてみました．
よかったら覗いてみていってください ! :bow_tone1:

対象となる人

  • AWSの勉強したいけど，どこから手をつければいいかわからない人向け
  • AWS 認定ソリューションアーキテクトを取りたい人向け
  • 自宅受験に興味があるけど，手を出すのをためらっている人向け

目次

  1. なぜAWSソリューションアーキテクトを受けようと考えたか
  2. 教材選び，実験の条件，勉強法・勉強スケジュール
  3. 自宅受験（ピアソンVUE [OnVue]はどうだったか）
  4. 感想

1. なぜAWSソリューションアーキテクトを受けようと考えたか

　僕はAWSを触り始めて1年が経ちますが，AWSを特殊な使い方？AIサービスに特化した使い方？をしていため，基礎知識が抜けている部分が多くあるだろうなと感じていました．

　また，AWS自体，お金がかかるし確立した勉強法がないため，初心者にはハードルが高いサービスになっているなと感じていました．

　そこで，自分が実験体となって，AWSの資格の勉強法などの検証してみて効果がでたら，
自分の役にも立つし，多くの人の助けにもなるのではないかと思ったのがきっかけです．

2. 教材選び，実験の条件，勉強法・勉強スケジュール

2-1. Qiitaの合格・不合格記事などをほとんど全て読んだ所…

  • Udemy最強説が浮上
  • よし，Udemyだけで合格してみようとなる（錯乱）．
  • Udemyだけで合格できれば，勉強法の説得力はあがるかなという謎の使命感
  • そして，自分が実験体となり，以下の条件を決めました．

2-2. 実験の条件

  1. 10日以内に勉強を終わらせること（長い期間勉強を行うと，サービスを使ったことで身についた効果と混ざるため）
  2. Udemy 縛り（ググるのはセーフ）
  3. 新卒のときの気分で1から勉強すること（自分が新人だと思いこむ（狂気））
  4. せっかくだし合格しよう

2-3. 勉強法・勉強スケジュール

10日間と決めましたが，勉強時間としては割とやったほうな気がします．
業務が終わったあと，寝落ちするまで勉強していました．
そのため，実際に初めてAWSを使う人や，時間に余裕がある人は，ゆっくりじっくり取り組んだ方がいいと思います．

勉強については，以下のUdemyの講座3つだけに絞りました．
いろいろとみてみましたが，最終的に以下のコースがいいのでは？という結論に至りました．
セールだとどれも2000円くらい．Udemyはアカウント登録時にセール行うらしいです．

Udemy講座1. AWS：ゼロから実践するAmazon Web Services．手を動かしながらインフラの基礎を習得

https://www.udemy.com/course/aws-and-infra/
講座時間：13時間　
検証時間：1.5倍速 (8.7時間）2日間の勉強
内容：
すごくわかりやすいです．
AWSをよく使う人からしたら簡単すぎると思われるかもしれないですが，何も知らない人はここから始めるくらいでいいと思います．
こういった基礎部分を身につけることで，他のサービスを理解する上での手助けになると思います．
また，ハンズオンと一緒に行われ，解説も丁寧にわかりやすく説明してくれるため，
例え何もしらなくても，なぜかできそうな気持ちになります．
全体的なレビューも高く，まったく触ったことのない人からのレビューも高かったです．EED4023D-ACD1-409B-B3B0-0335BB6042CB.png

Udemy講座2. これだけでOK！ AWS 認定ソリューションアーキテクト - アソシエイト試験突破講座（SAA-C02試験対応版）

https://www.udemy.com/course/aws-associate/
講座時間：26時間　
検証時間：1.5倍速　(17.4時間）4日間の勉強
内容：
AWS SAAのためにいろいろなサービスをハンズオンで学ぶことができます．
正直，あまりわかりやすいわけではなかったですが，
ボリュームがあり，試験範囲をある程度は網羅できました．
情報量がすごく多く，あまり面白くはなかったです．
ただ，この講座で知っておいた方が良いサービスを身に付けることができたと思います．
SAAを対策するなら，これをやっておいた方が良いと思いました．
動画の最後に，模擬試験（簡単）も3回分ついています，
この範囲がでるからこういうサービスを重点的にやったほうがいいなど，SAAに特化した内容になっている所がよかったです．
レビューに『これだけでOKではない！』というコメントが多かったです．www

77086923-54A4-4B50-9B20-F60755F64ABD.png

Udemy講座3. 【SAA-C02版】AWS 認定ソリューションアーキテクト アソシエイト模擬試験問題集（6回分390問）

https://www.udemy.com/course/aws-knan/
講座時間：動画なし（6回分模擬試験）
検証時間：4日間の勉強
内容：
6回分模擬試験を受けることができるという内容です．
1回目は講座2の模擬試験とかぶっています，2~5回目は高難易度問題集．6回目は，SAA-C02版に対応したものでした．
全ての試験で初見で50〜%以上取れていれば，合格が見えてくると思います．
本番より難しいですが，本番で出ないような新しいサービスに触れられて勉強になりました．
2周しましたが，やはり1周目が大事（初見でどのくらいとれるか）です
ボリュームがあり復習がするのが結構しんどかったです．苦手な分野を講座2で復習するとよいと思います．
390問遊べる！！
しんどかったけど，これをやってよかったと本当に思います．
スクリーンショット 2020-08-12 0.52.11.png

これらの3つの講座をしっかりやり込んでしっかり理解すれば，
AWSソリューションアーキテクトを合格できる知識を身につけることができると思います．
ただ，レビューとかにもありましたが，舐めているとガンガン試験に落ちるので，しっかりと復習が必要です．

3. 自宅受験（ピアソンVUE [OnVue]はどうだったか）

コロナの影響もあって，2020年5月あたりからAWSの資格取得を自宅でできるようになりました．

自宅受験でも試験内容は以下の通りで同じです．

制限時間：130分
問題数：65問
試験料：16,500円（税込）
合格点：720 ~ (1000点）

まだ始まったばかりなため，自宅受験したことがある人は少ないのかなと思っています．
特に以下の3つの点で挑戦できている人が少ないのではないかなと思います．

1. OnVUEのセッティング
2. 自宅の整備
3. 試験監督とのやりとりが英語のみ

それぞれ，僕が受けた印象を話していきたいと思います．

3-1. OnVUEのセッティング

先に結論を言うと，そんなに環境設定は難しくなかったです．

自宅受験ですが，OnVUE（Pearson VUE社が提供するオンライン監督試験）で受験できます．
まず，OnVUEの環境を自分のPCに作るために，
以下の画像の3つのステップの順に進んでいき，試験準備を進めていきます．
スクリーンショット 2020-08-12 1.05.19.png
どうやっていくかについては，以下の記事を参考にしました．
https://dev.classmethod.jp/articles/aws-exam-at-home/
基本的に，上記の記事かOnVUEの言うとおりに進んでいけば，問題なくセッティングが終わります．

強いて，つまった点を言うと，
　上記の記事だと環境を作る際（試験より前）にパスポートor免許書の画像を送信する必要があるように見えますが，実際は試験直前（上の画像の3番目）に言われた通りに写真をとるということくらいです（勘違いしたのは自分だけかもしれないです）．

あと，補足として，
一般的な受験の『会場指定』の方は，当日とかの受験はできなかったのですが，
今回紹介した『自宅受験』であれば，当日受験とかもできました．
ただ，当日の場合は，試験候補日時をだされたあと，すぐ埋まったり，
時間をおいてリロードしたら，また候補日時が更新されたりと，割とスピード勝負でした．
いかにクレジットカード情報を速く入力するかみたいな勝負になっていました．
僕の場合は，当日夜の9時くらいから受けました．30分前からチェックインできます．
チェックインするときに，パスポートor免許書を写真で撮り，受験部屋の4方向の写真をとり，送信しました．

3-2. 自宅の整備

結論：部屋が綺麗であれば大体大丈夫！！
（※もちろん，手の届く範囲に電子機器があったりしてはいけないです）
正面にテレビとかがありましたが，全然大丈夫でした．

3-3. 試験監督とのやりとりが英語のみ

結構英語でしゃべらないといけないのかな？と思っていましたが，
だいたいはチャットでやりとりして，マイクテストの時に『Can you hear me?』とか聞かれたくらいでした．
チャットでは『腕見せて』とか，『カメラをデスクに向けて』ぐらいで，やりとりはほとんどありませんでした．
試験中に話しかけられることもなく，無事終了して合格しました．

3-4.自宅受験の感想

セッティングやら英語でしかやりとりできないやら，
いろいろ大変そうだなと思っていましたが，
とりあえず何事も挑戦ということでやってみたら，意外と簡単に受けられました．

実際に自宅で受験してみて，明らかに自宅の方が楽だなーという印象を受けたので
今後も使えるなら使いたいと思いました．
ちょっと迷っている人も挑戦してみてもいいんじゃないかなと思います．

以上の検証の結論

  • 短い期間でUdemyの勉強のみでAWSソリューションアーキテクトを合格できた．
    →　Udemyの効果を検証できた．
    もちろん主観も入っていると思いますし，ベストではないかもしれませんが，
    上記の3講座をしっかりやっておけば，最低限の知識はを学べるかなと思いました．

  • 自宅受験はすばらしい

4. 感想

最初は，『新人やAWSを基礎から学びたい人におすすめの講座がないかな？』
と思って検証していましたが，
学習していくうちに自分の力にもなっていった実感がありました．

僕はあるあるだと思っているのですが，
だんだんAWSのサービスに触れていくと（AWSに限らず），
知らなかったことが自分自身のなかで当たり前となってしまい，
その当たり前のことを共有するのが難しくなっていくものだと思っています．

だからこそ，今回は初心者になりきって（初心者の気持ちになれたかは怪しいですが），
初めから勉強し，新人やAWSを基礎から学びたい人向けの記事を共有できてよかったと思っています．

今回の記事が少しでも多くの人の助けになれば嬉しいです！

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-08-12T01:16:08+09:00

FargateからFireLensで三つ股出力（1 of 2）

単一のFargateから、FireLensを使ってCloudWatch Logs（以下CWL）、Kinesis Data Firehose（以下KFH）、Amazon Elasticsearch Service（以下AES）に三つ股ログ出力する方法について。

やりたいこと

  • FargateタスクからFireLensを介して複数ターゲットにログをルーティングする。

アプリコンテナ（ログ設定をawsfirelensに指定）→FireLens
→CWL
→KFH
→AES

事前準備

まずはテスト用にFireLens行き設定を含むアプリコンテナと、FireLensコンテナを準備する。
FireLensはいわゆるサイドカー（同じタスク定義内での別のコンテナ）として用意する。
タスク定義にFireLens統合のセクションがあるので、こちらを参考に作成。今回は、以前作成したタスク定義（myFargateSvc）に新しいリビジョンを追加する形で行う。それにしても、ECSをマネジメントコンソールから操作しようとするとコマンドラインよりむしろ辛い気がするのは何故なのか。

有効化するにはここにチェックを入れるだけ。
スクリーンショット 2020-08-12 午前0.46.47.png
スクリーンショット 2020-08-12 午前1.59.11.png

Beforeが
スクリーンショット 2020-08-12 午前0.51.04.png

Afterになる。サイドカーとはよく言ったものだ。
スクリーンショット 2020-08-12 午前0.49.40.png

あっさり完了かと思いきや、エラー。
スクリーンショット 2020-08-12 午前0.56.07.png

どうやら、アプリコンテナ側に明示的にawsfirelensログドライバーを指定してあげないとだめらしい。やってよそれぐらい。
スクリーンショット 2020-08-12 午前1.59.11.png

どうにかタスク更新完了。
スクリーンショット 2020-08-12 午前1.03.59.png

このあと、当該サービスでタスクのリビジョンを新たに作成したものに置き換えれば、下準備は完了。
スクリーンショット 2020-08-12 午前1.14.06.png

Step by Step

アプリコンテナからFireLensに吐き出す準備ができたので、以下、三つ股ログ設定のStep by Step。

1. CWL

まずはCWLに吐き出すところから。
これだけだと、別にFireLensを介在させる必要はなくてawslogsドライバーで事足りるわけだが、何はともあれ、FireLens（fluentbit）がちゃんと動くことを確認しなくては始まらない。
一応整理しておくと、以下のようになる。

構成 ログドライバー 経路
いつもの構成 awslogs アプリコンテナ→awslogs→CWL
今回の構成 awsfirelens アプリコンテナ→awsfirelens→FireLensコンテナ（fluentbit）→awslogs→CWL

と、ここまで書いたところで（エラーもあって）やや力尽きたので、続きは改めて。

同日 2:10am 追記：
FireLensコンテナ（log_router）は、デフォルトだとそれ自身のターゲットが指定されていないため、このままだとタスク更新時にエラーになることが判明。
タスクのリビジョン追加時に、log_routerコンテナの設定に移動してAuto Config CloudWatch Logsにチェックを入れ（またはCWL設定を手入力し）、FireLensコンテナ自身のロググループを構成して初めて、正常にサービスが更新可能になる模様。やってよそれくらい。

また、アプリコンテナ側も、手なりでawsfirelens設定をするとNameというキーがバリューなしで設定されてしまい、CWLにログこそ吐き出されるようになるものの以下のような残念なメッセージでサービス起動が失敗する羽目になるので注意。
スクリーンショット 2020-08-12 午前2.08.19.png

8/12追記：
少々わかりにくいところだが、FireLensコンテナに入れるawslogs（CWL出力）設定は、あくまでFireLensコンテナ上のfluent-bitが自身のシステムログを吐き出すための設定で、本題であるアプリコンテナのログ出力先とは違う。それはアプリコンテナのawsfirelens設定で書くわけだが、書いた結果が最終的にFireLensコンテナ上のfluent-bit.confに反映されてアプリコンテナのログルーティングに使われる、という関係性になる。

というわけで、アプリコンテナ側のログ設定にキー/バリューの形でCWL設定を入れていけば「アプリコンテナからFireLens経由でCWL」というここでの目的が達せられるのだが、詳細は次回。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

日付別

タグ一覧