What's New Qiita

20200226のAWSに関する記事は20件です。

  • 投稿日：2020-02-26T23:37:31+09:00

RDS作成(無料枠)

内容

RDS(12カ月無料枠)の作成
ss_000.JPG

前提

RDS作成するのみが目的であるため、以下のような構成を先に作成しておきます。
また、セキュリティグループ等も先に作成しておきます。
RDS構築.jpg

手順

RDS作成(12カ月無料枠)

AWSコンソールへログインして、[サービス]⇒[データベース]⇒[RDS]へ遷移します。
ss_001.JPG

RDSダッシュボードへ遷移後、左側メニューより[データベース]を選択します。
ss_002.JPG

データベース一覧へ遷移後、画面右側にある[データベースの作成]を押下します。
ss_003.JPG

まずはデータベース作成方法において[標準作成]を選択します。
ss_004.JPG

エンジンのオプションではAmazonAurora以外の好きなものを選択します。今回はMySQLを選択し、バージョンは5.7.22とします。

ss_006.JPG

テンプレートでは無料枠を使用したいので無料利用枠を選択します。
ss_007.JPG

DBインスタンス識別子は任意の名前を。
マスターユーザー、マスターパスワードは接続の際に必要となるので忘れないようにメモしておきます。
ss_008.JPG

無料枠は以下のようになってるので特に設定必要なし。!
ss_009.JPG

ストレージは汎用SD20GiBで今回はテスト目的で必要ないため自動スケーリングは無効にします。
ss_010.JPG

任意のVPC、サブネット、セキュリティグループを選択します。
今回はパブリックアクセスなし、セキュリティグループ作成を忘れていたので新規作成しています。
ss_011.JPG

データベース認証はテスト目的であるためパスワード認証を選択。
ss_012.JPG

後程作成するためデータベースは設定していません。
今回は検証したい事があるため自動バックアップを7日間で有効化しています。
バックアップウィンドウは設定なしを選択。
ss_013.JPG

拡張モニタリング、ログは今回は必要ないので特に設定せず。
マイナーバージョン自動アップグレードは無効化。
削除保護は今回は無効化。
ss_014.JPG

そして最後にデータベースの作成を押下します。
ss_015.JPG

そうするとステータスが作成中となるため、利用可能となるまで待ちます。
これでいったん無料枠RDSの作成は完了です。
ss_017.JPG
ss_018.JPG

セキュリティグループの設定

今回はEC2インスタンスよりRDSへ接続するため、その通信許可設定を行います。
[AWSコンソール]⇒[サービス]⇒[ネットワーキングとコンテンツ配信]
⇒[セキュリティ]⇒[セキュリティグループ]を選択してセキュリティグループ一覧へ移動します。
ss_021.JPG
ss_022.JPG

セキュリティグループ一覧より、[対象のセキュリティグループ]⇒[インバウンドタブ]⇒[ルールの編集]を押下します。
ss_019.JPG

インバウンドのルールの編集画面において、以下の設定をしてルールの保存を押下します。
タイプ：MySQL/Aurora
ソース：カスタム/接続元EC2のプライベートIPアドレス
説明：必要であれば
ss_020.JPG

EC2にmysqlクライアントをインストール

RDSへ接続するEC2へログインします。

ログイン後、以下コマンドを実行してmysqlクライアントをインストールします。
$ sudo yum install mysql

EC2⇒RDSで接続確認

以下コマンドでEC2⇒RDSで接続をします。
※エンドポイントは作成したRDSの接続とセキュリティタブに表示されているのでそこで確認します。

mysql -h <エンドポイント> -P 3306 -u <作成したユーザー> -p
Enter password:<パスワード入力>
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MySQL connection id is 12
Server version: 5.7.22-log Source distribution

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MySQL [(none)]>

これで無料枠でのRDS作成、接続確認まで完了となります。

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

AWS ソリューションアーキテクト アソシエイトを取得しました

初めまして，yourilと申します．
タイトルの通りAWSソリューションアーキテクト(アソシエイト)を取得しましたので，
自分が行った勉強方法などをまとめようと思います．

※本記事は2020年2月時点の内容です．

TL;DR

  • 取得までの期間: 4ヶ月(間に2ヶ月のブランクあり)
  • AWSの利用経験: なし
  • 勉強方法:
    • Udemyの動画講座+模擬試験
    • 対策本2冊
    • 公式の模擬試験

勉強前の知識

オンプレミスがメインのネットワークエンジニアとして働いており，
普段はAWSを始めとしたパブリッククラウドとはほぼ無縁な仕事をしています．
なのでNWはそれなりに分かるものの，サーバやストレージ，データベース等はあまり触れる機会がなく，
知識も新人研修で学んだ程度です(もう大分忘れてますが...)．

勉強期間

2019年10月下旬～2020年2月下旬の4ヶ月．
ただし11月下旬～1月下旬まで諸事情によりブランクがあったため，実質2ヶ月程度．
この期間は1日1～2時間程度，以下の教材を用いて学習していました．
ブランク後の思い出す期間も含めてなので，通しであればもう少し短い期間でも取得できたはず......

教材

AWS認定資格試験テキスト　AWS認定 ソリューションアーキテクト-アソシエイト

https://www.amazon.co.jp/dp/B07R1H87Y1/ref=dp-kindle-redirect?_encoding=UTF8&btkr=1

2019年4月発売の対策本．
試験範囲のサービスについて広く分かりやすく解説されており，用語レベルで分からない状態から概要が分かるところまでレベルアップできました．
AWSのサービスは日々進化しているので，この手の対策本は出来るだけ新しいものを選ぶことが重要．
自分は学習し始めた時に1周，試験を受ける前に1周の合計2周読みました．

これだけでOK！ AWS 認定ソリューションアーキテクト – アソシエイト試験突破講座（初心者向け22時間完全コース）

https://www.udemy.com/course/aws-associate/

大体どの合格体験記にも登場する動画教材．セールの時に買いましょう．
一昔前は20時間(?)のコースだったのが，今は22時間みたいです．
基本的な知識は前述の対策本で身についているのと，22時間はさすがに長いので，1.25倍～1.5倍速で見ると良いです．
ハンズオンも全部やる必要は無く，むしろ最後の模擬試験を繰り返し解いて知識を定着させる方が重要です．

公式の模擬試験

AWSが公式で出している1回2000円の模試．
本番と同じ形式なので，お布施練習と思って受けると良いです．
問題そのものよりも，見直し機能や英語に切り替える機能を試すための練習です(他のベンダー試験を受け慣れている人は不要かも)．
問題の難易度は本番試験よりも低め．

不要だった教材

  • AWS 認定ソリューションアーキテクト アソシエイト模擬試験問題集（5回分325問）
    • https://www.udemy.com/course/aws-knan/
    • Udemyで購入できる5回分の模擬試験．本番試験よりも難易度が高く，下手にやると自信を失くします．
    • 逆に本番試験でこの模試以上の難易度の問題はほぼ無かったため，これが解ければ十分とも言えます．
  • 合格対策 AWS認定ソリューションアーキテクト －アソシエイト

本番試験の所感

  • 単純な知識を問う問題はあまり無い．
  • 他の選択肢も間違いではないものの，コストやセキュリティの観点から最適なものを選ぶ必要がある．
  • 130分で65問を回答するので時間はあるが，問題文が長いので途中で疲れる．
  • 他のベンダー試験にありがちな，日本語が怪しい問題はほぼ無かった．
    • なので英語に切り替える機能もあまり使わなかった．

あとがき

自分は4ヶ月もかけてしまいましたが，1日2時間で毎日学習すれば，1ヶ月程度で取れるかと思います．
最後まで読んでいただきありがとうございました．

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

Amazon SES+Lambdaでメール受信をトリガーにしてあれこれする(前編)

メールの受信をトリガーにコードを動かす

…ことができます。そう、AWSならね。

Amazon SES はEメールの送受信を行うAWSのマネージドサービスです。
地味なサービスだなー誰が使うのかなーと思っていたんですが、こないだあるお店にネット経由で宅配を頼んだら、SESで注文メールが届きました。意外と使われているんですかね？

要約

  • Amazon SES をセットアップしてメールを受信できるようにする
  • SESでの受信をトリガーに、メールの生データをS3のバケットにPUTする
  • そのPUTをトリガーに、Lambdaを実行して必要な情報を取り出す

SESのトリガーで、S3へのPUTだけでなくLambdaの実行もできるんですが、この先を踏まえて、あえて分けています。

必要な物

DNSサーバなら何でもいいんですが、Route53 だとSESのセットアップに必要な設定をほとんど自動でやってくれるのでお勧めです1。

SESのセットアップ

SESは東京リージョンでは使えないので、ほかのリージョンを使います。ここでは「バージニア北部(us-east-1)」にしました。

ドメインの検証

SESのコントロールパネルを開きます。
https://console.aws.amazon.com/ses/home

左側のメニューで Domains を選びます。

ses-s3-domains.png

上部の Verify a New Domain を押します。
入力欄が出てくるので、 DNSサーバで自分が自由にレコードを操作できるFQDN を入力します。

私は keys.jp というドメイン名を持っていて、Route53 で自由にレコードを操作できます。なので今回は以下のFQDNにしました。

ses-s3-input-domain-name.png

サブドメインをランダムな文字列にしているのは、SESでは受信メール数・サイズによって課金されるので、スパムなど余計なものを受け取らないようにしたいからです2。

DKIMの設定は、今回は受信のみなのでしません3。

最後に Verify This Domain を押します。

ses-s3-verify-step.png

Route53 を使っているなら Use Route53 を押します。（使っていない場合、画面にある2つのレコードを手動で追加します）

ses-s3-use-route53.png

ここで必ず Email Receving Record にチェックをいれます。でないとメールを受け取れません。（MXレコードが設定されません）
Hosted Zones の部分は、サブドメインの委任をしているときに確認、選択します。覚えがないひとは気にしないでOKです。

Create Record Sets を押します。

ses-s3-veryfing.png

問題なければ Verification Status が pending verification になっているはずです。

しばらく経つと、

ses-s3-verified.png

こんな感じで verified になり、Enabled for も Yes になるはずです。

ドメインの設定はここまでです。

SESからのデータを置くS3バケットの準備

（※S3の使い方はたくさん資料があるのでざっくり書きます）

受け取ったメールをPUTするバケットを用意します。リージョンはどこでもいいような気がするのですが、SESと同じ場所にした方がトラブルが起きにくそうな気がします。気がするだけですが。他の設定はそのままでOKです。

PUTする先は2箇所です:

  • SESがPUTする、メールヘッダ付きでエンコードされた生データを置くところ
  • Lambdaで処理したデータを置くところ

バケットは一緒でも違っていても問題ないです。ここではFQDNで1つのバケットを作ることにしました。

set-s3-bucket-info.png

あとはSESがバケットに生データをPUTできるようにバケットポリシーを設定します。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowSESPuts",
            "Effect": "Allow",
            "Principal": {
                "Service": "ses.amazonaws.com"
            },
            "Action": "s3:PutObject",
            "Resource": "arn:aws:s3:::BUCKET-NAME/*",
            "Condition": {
                "StringEquals": {
                    "aws:Referer": "AWSACCOUNTID"
                }
            }
        }
    ]
}

受信用アドレスの設定

メニューの左側にある Rule Sets を選びます。

ses-s3-ruleset-list.png

ルールセットについていろいろ書いてありますが、ここは最初から用意されている default-rule-set を使います。

View Active Rule Set を押します。

ses-s3-ruleset.png

Create Rule を押します。

ses-s3-add-recipients.png

Recipient が、トリガーを引くためのアドレスです。さっきのFQDNで何か設定してください4。

ses-s3-recipient-added.png

FQDNは前もって設定したので Verify になっているはずです。
Next Step を押します。

メール受信時の動作設定

メールを受け取ったときに行う動作を設定します。

ses-s3-select-action.png

S3を選び、さっき用意したバケットを設定します。

ses-s3-action-selected.png

生データと処理データを1つのバケットにいれるときはプレフィクスを付けます。ここでは raw-data にしました。

（※ちなみにここでLambdaも同時にトリガーを引くことができます）

Next Step を押します。

set-s3-rule-details.png

ルール名を付けるだけで、他のところはそのままで大丈夫です。
Next Step を押します。

つぎに確認画面が出て、問題なければ Create Rule を押します。

ses-s3-rule-result.png

こんな感じで一覧に出ているはずです。
これで設定はすべて終わりです。

テスト

バケットの中身を確認する

ses-s3-bucket-raw.png

バケットに raw-data ができていればOKです。
AMAZON_SES_SETUP_NOTIFICATION というオブジェクトがありますが、消しても大丈夫です。

テストメールを送る

ses-s3-send-testmail.png

英数字以外だとエンコードされてテスト結果が分かりにくくなるので、まずは英数字だけでメールを書きます。

メールが受信できていることを確認する

ses-s3-bucket-after-received.png

時間がかかることがありますが、しばらくするとバケットにこんなオブジェクトができます。
中を見ると、さきほど送ったメールがヘッダとともに表示されるはずです。

:
: (先頭部分省略)
:
X-SES-DKIM-SIGNATURE: a=rsa-sha256; q=dns/txt; b=BW8HfmOz9lmLkndIH0QedyH+of6GJRNr+P0HthQdzqoLgywz+PYGbzBSaplWOtbPKEM6LPtwCxtq7+imZ5XGToDqZUZI6NemvjUf0MIv7/v0QlfmL7QOiVZuj52Yjxud8B8+UdPx7ToUeHEMrcW1ZYcnHTMD3mCfXyZn3salloQ=; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1582691942; v=1; bh=VVosbMywvKLFVhwuAQO2PounA7TnA2309xLqNuPoo9c=; h=From:To:Cc:Bcc:Subject:Date:Message-ID:MIME-Version:Content-Type:X-SES-RECEIPT;
Received: from mail-wr1-f54.google.com (mail-wr1-f54.google.com [209.85.221.54])
    (authenticated bits=0)
    by sendmail.example.com (8.15.2/8.15.2) with ESMTPSA id 01Q4cu6E003518
    (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=FAIL)
    for <ses-s3-test@brcizzx4kk.keys.jp>; Wed, 26 Feb 2020 13:38:59 +0900 (JST)
    (envelope-from otegami@devel.keys.jp)
Received: by mail-wr1-f54.google.com with SMTP id u6so1315624wrt.0
        for <ses-s3-test@brcizzx4kk.keys.jp>; Tue, 25 Feb 2020 20:38:58 -0800 (PST)
X-Gm-Message-State: APjAAAV84Ls0YaytYszZs4ag7EoUndQseX3PxXjkVJ9PKQGdj3l3/VZL
    FF6MB2WzKh0jp4FegCvMPfXcratyro5kFPawZfY=
X-Google-Smtp-Source: APXvYqwH6qSjHTDgtIIu8j8rOh2gsIEoAAkKHLNQNkc04ndEzLjRHuQ6UQ3+MyRLciBiqwxoVLvIv83yv16WE9f8Io0=
X-Received: by 2002:adf:fdc2:: with SMTP id i2mr3100315wrs.166.1582691936426;
 Tue, 25 Feb 2020 20:38:56 -0800 (PST)
MIME-Version: 1.0
From: Kei Onimaru <otegami@devel.keys.jp>
Date: Wed, 26 Feb 2020 13:38:45 +0900
X-Gmail-Original-Message-ID: <CAJJjJ4inEYUHn_NkJiD=JB2n9R1Hy4PXXwA8ZJavTXn2deyG+A@mail.gmail.com>
Message-ID: <CAJJjJ4inEYUHn_NkJiD=JB2n9R1Hy4PXXwA8ZJavTXn2deyG+A@mail.gmail.com>
Subject: This is test mail
To: ses-s3-test@brcizzx4kk.keys.jp
Content-Type: text/plain; charset="UTF-8"

SES S3 Test

-- 
Kei Onimaru <otegami@devel.keys.jp>.
https://devel.keys.jp/

次はLambdaの設定です。

……が、ちょっと記事が長くなったのでいったんここまでで。

  1. 他のサービスとの相性もいいので、AWSの機能をフルに試すなら使った方がいいです。月々0.55USD(≒60円、2020年2月現在)ですし。ただクエリ数でも課金されるので、ときどきbillingダッシュボードを見た方がいいかもです。 ↩

  2. アカウントの部分をランダムにしても同じ効果がありますが、その場合メールサーバまでのトラフィックが発生するので、DNSサーバのレコードを操作できるならこちらの方がいいでしょう。 ↩

  3. もちろん、しても全然問題ないです。DKIMで使うTXTレコードも、Route53 なら自動で書いてくれますし。 ↩

  4. 書いてあるとおり、なにも設定しないとそのドメイン宛てのメールすべてがトリガーになりますし、いろいろなパターンがあるので、必要ならドキュメントを見てみてください。 ↩

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

[AWS]メールを受け取って中身をS3に置く(前編)

メールの受信をトリガーにコードを動かす

…ことができます。そう、AWSならね。

Amazon SES はEメールの送受信を行うAWSのマネージドサービスです。
地味なサービスだなー誰が使うのかなーと思っていたんですが、こないだあるお店にネット経由で宅配を頼んだら、SESで注文メールが届きました。意外と使われているんですかね？

要約

  • Amazon SES をセットアップしてメールを受信できるようにする
  • SESでの受信をトリガーに、メールの生データをS3のバケットにPUTする
  • そのPUTをトリガーに、Lambdaを実行して必要な情報を取り出す

SESのトリガーで、S3へのPUTだけでなくLambdaの実行もできるんですが、この先を踏まえて、あえて分けています。

必要な物

DNSサーバなら何でもいいんですが、Route53 だとSESのセットアップに必要な設定をほとんど自動でやってくれるのでお勧めです1。

SESのセットアップ

SESは東京リージョンでは使えないので、ほかのリージョンを使います。ここでは「バージニア北部(us-east-1)」にしました。

ドメインの検証

SESのコントロールパネルを開きます。
https://console.aws.amazon.com/ses/home

左側のメニューで Domains を選びます。

ses-s3-domains.png

上部の Verify a New Domain を押します。
入力欄が出てくるので、 DNSサーバで自分が自由にレコードを操作できるFQDN を入力します。

私は keys.jp というドメイン名を持っていて、Route53 で自由にレコードを操作できます。なので今回は以下のFQDNにしました。

ses-s3-input-domain-name.png

サブドメインをランダムな文字列にしているのは、SESでは受信メール数・サイズによって課金されるので、スパムなど余計なものを受け取らないようにしたいからです2。

DKIMの設定は、今回は受信のみなのでしません3。

最後に Verify This Domain を押します。

ses-s3-verify-step.png

Route53 を使っているなら Use Route53 を押します。（使っていない場合、画面にある2つのレコードを手動で追加します）

ses-s3-use-route53.png

ここで必ず Email Receving Record にチェックをいれます。でないとメールを受け取れません。（MXレコードが設定されません）
Hosted Zones の部分は、サブドメインの委任をしているときに確認、選択します。覚えがないひとは気にしないでOKです。

Create Record Sets を押します。

ses-s3-veryfing.png

問題なければ Verification Status が pending verification になっているはずです。

しばらく経つと、

ses-s3-verified.png

こんな感じで verified になり、Enabled for も Yes になるはずです。

ドメインの設定はここまでです。

SESからのデータを置くS3バケットの準備

（※S3の使い方はたくさん資料があるのでざっくり書きます）

受け取ったメールをPUTするバケットを用意します。リージョンはどこでもいいような気がするのですが、SESと同じ場所にした方がトラブルが起きにくそうな気がします。気がするだけですが。他の設定はそのままでOKです。

PUTする先は2箇所です:

  • SESがPUTする、メールヘッダ付きでエンコードされた生データを置くところ
  • Lambdaで処理したデータを置くところ

バケットは一緒でも違っていても問題ないです。ここではFQDNで1つのバケットを作ることにしました。

set-s3-bucket-info.png

あとはSESがバケットに生データをPUTできるようにバケットポリシーを設定します。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowSESPuts",
            "Effect": "Allow",
            "Principal": {
                "Service": "ses.amazonaws.com"
            },
            "Action": "s3:PutObject",
            "Resource": "arn:aws:s3:::BUCKET-NAME/*",
            "Condition": {
                "StringEquals": {
                    "aws:Referer": "AWSACCOUNTID"
                }
            }
        }
    ]
}

受信用アドレスの設定

メニューの左側にある Rule Sets を選びます。

ses-s3-ruleset-list.png

ルールセットについていろいろ書いてありますが、ここは最初から用意されている default-rule-set を使います。

View Active Rule Set を押します。

ses-s3-ruleset.png

Create Rule を押します。

ses-s3-add-recipients.png

Recipient が、トリガーを引くためのアドレスです。さっきのFQDNで何か設定してください4。

ses-s3-recipient-added.png

FQDNは前もって設定したので Verify になっているはずです。
Next Step を押します。

メール受信時の動作設定

メールを受け取ったときに行う動作を設定します。

ses-s3-select-action.png

S3を選び、さっき用意したバケットを設定します。

ses-s3-action-selected.png

生データと処理データを1つのバケットにいれるときはプレフィクスを付けます。ここでは raw-data にしました。

（※ちなみにここでLambdaも同時にトリガーを引くことができます）

Next Step を押します。

set-s3-rule-details.png

ルール名を付けるだけで、他のところはそのままで大丈夫です。
Next Step を押します。

つぎに確認画面が出て、問題なければ Create Rule を押します。

ses-s3-rule-result.png

こんな感じで一覧に出ているはずです。
これで設定はすべて終わりです。

テスト

バケットの中身を確認する

ses-s3-bucket-raw.png

バケットに raw-data ができていればOKです。
AMAZON_SES_SETUP_NOTIFICATION というオブジェクトがありますが、消しても大丈夫です。

テストメールを送る

ses-s3-send-testmail.png

英数字以外だとエンコードされてテスト結果が分かりにくくなるので、まずは英数字だけでメールを書きます。

メールが受信できていることを確認する

ses-s3-bucket-after-received.png

時間がかかることがありますが、しばらくするとバケットにこんなオブジェクトができます。
中を見ると、さきほど送ったメールがヘッダとともに表示されるはずです。

:
: (先頭部分省略)
:
X-SES-DKIM-SIGNATURE: a=rsa-sha256; q=dns/txt; b=BW8HfmOz9lmLkndIH0QedyH+of6GJRNr+P0HthQdzqoLgywz+PYGbzBSaplWOtbPKEM6LPtwCxtq7+imZ5XGToDqZUZI6NemvjUf0MIv7/v0QlfmL7QOiVZuj52Yjxud8B8+UdPx7ToUeHEMrcW1ZYcnHTMD3mCfXyZn3salloQ=; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1582691942; v=1; bh=VVosbMywvKLFVhwuAQO2PounA7TnA2309xLqNuPoo9c=; h=From:To:Cc:Bcc:Subject:Date:Message-ID:MIME-Version:Content-Type:X-SES-RECEIPT;
Received: from mail-wr1-f54.google.com (mail-wr1-f54.google.com [209.85.221.54])
    (authenticated bits=0)
    by sendmail.example.com (8.15.2/8.15.2) with ESMTPSA id 01Q4cu6E003518
    (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=FAIL)
    for <ses-s3-test@brcizzx4kk.keys.jp>; Wed, 26 Feb 2020 13:38:59 +0900 (JST)
    (envelope-from otegami@devel.keys.jp)
Received: by mail-wr1-f54.google.com with SMTP id u6so1315624wrt.0
        for <ses-s3-test@brcizzx4kk.keys.jp>; Tue, 25 Feb 2020 20:38:58 -0800 (PST)
X-Gm-Message-State: APjAAAV84Ls0YaytYszZs4ag7EoUndQseX3PxXjkVJ9PKQGdj3l3/VZL
    FF6MB2WzKh0jp4FegCvMPfXcratyro5kFPawZfY=
X-Google-Smtp-Source: APXvYqwH6qSjHTDgtIIu8j8rOh2gsIEoAAkKHLNQNkc04ndEzLjRHuQ6UQ3+MyRLciBiqwxoVLvIv83yv16WE9f8Io0=
X-Received: by 2002:adf:fdc2:: with SMTP id i2mr3100315wrs.166.1582691936426;
 Tue, 25 Feb 2020 20:38:56 -0800 (PST)
MIME-Version: 1.0
From: Kei Onimaru <otegami@devel.keys.jp>
Date: Wed, 26 Feb 2020 13:38:45 +0900
X-Gmail-Original-Message-ID: <CAJJjJ4inEYUHn_NkJiD=JB2n9R1Hy4PXXwA8ZJavTXn2deyG+A@mail.gmail.com>
Message-ID: <CAJJjJ4inEYUHn_NkJiD=JB2n9R1Hy4PXXwA8ZJavTXn2deyG+A@mail.gmail.com>
Subject: This is test mail
To: ses-s3-test@brcizzx4kk.keys.jp
Content-Type: text/plain; charset="UTF-8"

SES S3 Test

-- 
Kei Onimaru <otegami@devel.keys.jp>.
https://devel.keys.jp/

次はLambdaの設定です。

……が、ちょっと記事が長くなったのでいったんここまでで。

  1. 他のサービスとの相性もいいので、AWSの機能をフルに試すなら使った方がいいです。月々0.55USD(≒60円、2020年2月現在)ですし。ただクエリ数でも課金されるので、ときどきbillingダッシュボードを見た方がいいかもです。 ↩

  2. アカウントの部分をランダムにしても同じ効果がありますが、その場合メールサーバまでのトラフィックが発生するので、DNSサーバのレコードを操作できるならこちらの方がいいでしょう。 ↩

  3. もちろん、しても全然問題ないです。DKIMで使うTXTレコードも、Route53 なら自動で書いてくれますし。 ↩

  4. 書いてあるとおり、なにも設定しないとそのドメイン宛てのメールすべてがトリガーになりますし、いろいろなパターンがあるので、必要ならドキュメントを見てみてください。 ↩

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

AWS EC2 + Amazon Linux + LAMP 作ってみたメモ

はじめに

私の現状「Linuxって名前だけは知ってるけどあまりに触ったことはない」

この状態でとりあえずAWSのEC2を使ってLinuxを触ってみようという試み

ここにLAMP環境をおったてるぜ…

なお、ほぼコピペです。

参考にさせていただいた記事のみなさん

ありがとうございました…！

AWSの初期設定

EC2インスタンス初期設定

PHPのインストール

phpmyadmin のインストール

副産物

環境構築

AWS EC2 インスタンス作成 ～ VSCode での接続のメモ

Amzon Linux の初期設定のメモ

Apacheの導入

# インストール
$ sudo yum -y install httpd

# サービスの起動
$ sudo service httpd start

# 自動起動設定
$ sudo chkconfig httpd on

自分のIPアドレスをブラウザに打ってみてテストページが表示されればOK

MySQLの導入(ここではmysql 5.5 を入れている)

ここで気づいた。
どうせ全部管理者権限なら管理者権限モードにしておけばよいのでは…？

# 管理者権限にしておく
$ sudo su

早速インストール

# yum install -y mysql-server

サービスの起動 ～ 設定

サービスを起動

# service mysqld start

初期設定コマンド
初期のパスワードは無し、自分のパスワードを設定して、あとは全部y(YES)

mysql_secure_installation

MySqlの設定ファイルを修正

vi /etc/my.cnf

こんな感じに修正して保存

[mysqld]
~
~
~
# 文字コード[UTF-8]を追加
character-set-server = utf8  

[mysqld_safe]

サービスの再起動

service mysqld restart

余談

mysql 8.0 を最初に入れたけどパスワードポリシーとか、初期設定とかいろいろ面倒くさくてやめました。

mysql 8.0 の場合は初期パスワードが設定されているので
「cat /var/log/mysqld.log | grep password」
みたいなコマンドでパスワードを確認してから初期設定コマンドを実行するとよいです。

PHPの導入

# 管理者権限にしておく(すでに管理者権限で操作中の場合は省略)
$ sudo su

最初から入っているPHP関連のものをすべて消す

# yum -y remove php-*
# yum -y remove httpd-tools
# yum clean all

インストール

# yum install php73 php73-mbstring php73-pdo php73-devel php73-mysqlnd.x86_64
# yum install mod24_ssl.x86_64

設定ファイルのバックアップ

yyyyMMdd=日付

# cp /etc/php.ini /etc/php.ini.yyyyMMdd

設定ファイルを編集(初期設定)

# vi /etc/php.ini

vi editar を起動したら次のコマンドを入力すると行番号が表示される

:set number

行番号を表示したら設定をいじる
行番号：内容

※行番号は環境によって違うかもしれないので大体その周辺で探す。
※「;」でコメントアウトになっていたら「;」を外す

エラー表示の設定

460:error_reporting = E_ALL | E_STRICT
477:display_errors = On
498:log_errors = On
587:error_log = /var/log/php.log

文字コード関連の設定

 692:default_charset = "UTF-8"
1510:mbstring.language = Japanese
1517:mbstring.internal_encoding = UTF-8
1525:mbstring.http_input = pass
1525:mbstring.http_output = pass
1543:mbstring.encoding_translation = Off
1548:mbstring.detect_order = auto

phpMyAdminのインストール

最新はここで確認：https://www.phpmyadmin.net/downloads/

# 管理者権限にしておく
$ sudo su

移動しておく

# cd /var/www/html

最新バージョンをダウンロード
※ 4.9.4 ← この数字を変えればいけるはず

# wget https://files.phpmyadmin.net/phpMyAdmin/4.9.4/phpMyAdmin-4.9.4-all-languages.zip

解凍する

# unzip phpMyAdmin-4.9.4-all-languages.zip

リネームする

# mv phpMyAdmin-4.9.4-all-languages phpmyadmin

httpdの再起動

sudo service httpd restart

接続できるか確認する
http://xx.xx.xx.xx/phpmyadmin/index.php

※ xx.xx.xx.xx … グローバルIPアドレス

ユーザー：root
パスワード：自分で設定したパスワードを入力してログインできればOK

これで
L ... Linux
A ... Apache
M ... MySQL
P ... PHP

環境ができあがり！

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

AWS Budgets で月額料金管理!!!

こんにちは、risakoです:woman:
花粉だったりインフルエンザ、コロナウイルスと体調管理が大事な時期ですね:sweat_drops:
不要不急の外出は控えて予防を徹底しましょう:muscle:

今回はAWS Budgets を使用して予算の使いすぎ予防をご紹介します！

必要なもの

  • AWS Billing and Cost Management コンソールで予算を作成できるIAMユーザー
  • 月額の予算（USD）
  • 通知するメールアドレス
  • Amazon Simple Notification Service (Amazon SNS)

料金の予算を作成

  1. Billing and Cost Management コンソールを開き、ナビゲーションペインで[Budgets]を選択します。
  2. 右上の[予算を作成]を選択
  3. 指定された金額に対してコストをモニタリングし、これから定義するしきい値に達したときにアラートメールを受け取りたいので[コスト予算]を選択。
  4. [名前][予算額(USD)] を入力して、[アラートの設定]へ。
  5. 使用料金が予算額の何％に達したらアラートメールを飛ばすのか[アラートのしきい値] で指定します。
  6. 通知するメールアドレスを入力します。

ひとまずBilling and Cost Management コンソールでの作業は終わりです。Amazon SNSの設定後、また戻ってくるので一旦保存します。
現段階ではアラートメールは飛びません！！

Amazon SNS 設定

トピックスの作成

  1. Amazon SNS コンソールを開き、[トピックの作成] を選択します。
  2. トピックの[名前] を入力
  3. アクセスポリシーを設定します。メソッドの選択で[Advanced]を選択しJSONを少し書き換えます。"Statement": [ の後に入力し、"your topic ARN" は各自トピックのARNに書き換えます。
    {
      "Sid": "AWSBudgets-notification-1",
      "Effect": "Allow",
      "Principal": {
        "Service": "budgets.amazonaws.com"
      },
      "Action": "SNS:Publish",
      "Resource": "your topic ARN"
    },

全てのアクセスポリシーの記述はこのようになります。

{
  "Version": "2008-10-17",
  "Id": "__default_policy_ID",
  "Statement": [
    {
      "Sid": "AWSBudgets-notification-1",
      "Effect": "Allow",
      "Principal": {
        "Service": "budgets.amazonaws.com"
      },
      "Action": "SNS:Publish",
      "Resource": "your topic ARN"
    },
    {
      "Sid": "__default_statement_ID",
      "Effect": "Allow",
      "Principal": {
        "AWS": "*"
      },
      "Action": [
        "SNS:Publish",
        "SNS:RemovePermission",
        "SNS:SetTopicAttributes",
        "SNS:DeleteTopic",
        "SNS:ListSubscriptionsByTopic",
        "SNS:GetTopicAttributes",
        "SNS:Receive",
        "SNS:AddPermission",
        "SNS:Subscribe"
      ],
      "Resource": "your topic ARN",
      "Condition": {
        "StringEquals": {
          "AWS:SourceOwner": "AWS ACCOUNT"
        }
      }
    }
  ]
}

4.[トピックの作成]を押下し、トピックの作成は完了です。

サブスクリプションの作成

  1. ナビゲーションペインで[サブスクリプション] を選択、または、作成したトピックからサブスクリプションを作成します。
  2. トピックARNを入力し、今回はメールで通知するのでプロトコルは[Eメール]を選択。
  3. エンドポイントに送信したいメールアドレスを入力する。
  4. [サブスクリプションの作成]を押下で完了です。
  5. 作成後、指定したメールアドレスに[Confirm subscription]のタイトルで承認メールが届くので、メール内の[Confirm subscription]押下で承認します。
  6. サブスクリプションのステータスが[確認済み]になればOKです！ スクリーンショット 2020-02-26 18.01.22.png

Budgetsに戻ります

最後に残していたAWS Billing and Cost Management コンソールコンソールでの作業です。

  1. 作成したBudgetsを選択し、右上の[予算を編集]を押下します。

  2. [アラートの設定]に進み、メールアドレス下のAmazon Simple Notification Service (SNS) トピックを通じて通知 にチェックし、作成したトピックARNを入力します。
    スクリーンショット 2020-02-26 18.09.49.png

  3. 設定を保存したら、終わりです！

設定が終わると登録したメールアドレスにSNS Topic Verified!のタイトルでメールが届きます。

まとめ

気づいたら料金が高くなっていた！となる前に一定の料金を使ったらお知らせしてくれる便利な機能だと思いました！！
今回つまづいたのは、通知したいメールアドレスはSNSとBudgetsの両方に登録しないといけないということです。
後からメールアドレスを追加する場合は、どちらか片方だけではなく、両方に登録することを忘れないようにしましょう:point_up::sparkles:

以上、AWS Budgetsでの月額料金管理方法でした:sunny:

参考

AWS Billing and Cost Management ユーザーガイド
https://docs.aws.amazon.com/ja_jp/awsaccountbilling/latest/aboutv2/billing-what-is.html

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

AWS の EC2 に Amazon Linux を立ち上げて最初にやったことメモ

OS最新にアップデート

$ sudo yum update -y

とりあえずどの記事見てもみんなやってる。
普通にパソコン買っても最新に更新かけるもんね。

セキュリティの更新とか不具合の修正とかいろいろあるんだろう。

タイムゾーンを日本に変更

$ sudo ln -sf /usr/share/zoneinfo/Asia/Tokyo /etc/localtime

yum-cron

「yum-cron」ってなんだ？

yum-cron パッケージは、アップデートを自動的に確認し、ダウンロードし、適用するための便利な方法を提供します。
パッケージをインストールするとすぐに yum-cron パッケージの cron ジョブが有効になり、特別な設定は必要ありません。
通常の日次 cron ジョブの実行時に、このジョブが実行します。

なるほど

# yum-cron インストール
$ sudo yum install yum-cron -y

# 有効化確認
$ sudo chkconfig --list yum-cron

# 有効化
$ sudo chkconfig yum-cron on

# 自動更新設定
$ sudo sed -i "s/^apply_updates.*$/apply_updates = yes/g" /etc/yum/yum-cron.conf

# 起動
$ sudo service yum-cron start

# 起動確認
$ sudo service yum-cron status

文字コードを日本語に変更

# 文字コードを日本語に変更
$ sudo sed -i "s/en_US\.UTF-8/ja_JP\.UTF-8/g" /etc/sysconfig/i18n

不要なサービスの停止

# 不要サービスの一括設定（GUI）
$ sudo ntsysv

現時点で何が不要なのか分からないのでそのままにしておく。
[Tab]で移動、[Space]で決定、という操作は分かった。

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

お金あんまりないけどそこそこAWS使ってるユーザがAWSサポートを利用するときの個人的ガイドライン

※個人的ガイドライン=これまで AWS サポートと何度かやりとりした中で得たノウハウをまとめたもの
※AWSサポートを非難するつもりはまったくない。むしろいつも大変お世話になっています。

私のスペック

  • AWSをそこそこ使っている（コスト的ではなく、テクニカル的に）。
  • 利用しているAWSサービスの挙動をなるべく詳しく把握したい。
  • 新し目のAWSサービスをちょこちょこ試して仕様を確認したい。
  • 金融系サービス的なクリティカル案件はないので、基本的にはAWSへ調査依頼は行わない。
  • サポートに入るお金があんまりない。

AWSサポート

参考

サポートプラン

  • AWSサポートは４つある（ベーシック、開発者、ビジネス、エンタープライズ）。
  • AWSアカウント開通直後のデフォルトのプランは「ベーシック」で、無料。
  • ベーシック以外はすべて有料。
  • とうぜん、サポートプランが高価なものほど手厚いサポートを受けられる。

どのサポートがベストなのか

  • お金があれば、ビジネスなりエンタープライズ。
  • お金が無ければ無料のベーシックプラン。
  • ベーシックプランでは質問できない技術的なことを質問したい場合は開発者プラン以上。
  • 問い合わせ以外のサポート利用
    • ビジネスプラン以上だと、AWS Trusted Advisor のフル機能が利用できる。（ベーシック、開発者プランでは、一部利用制限がある）
    • ELBの暖機運転申請は、ビジネスプラン以上で可能になる。

私のスペックの場合・・

  • 技術的問い合わせは大きく分けると次の２つ

    1. 各サービスの技術的な仕様に関する疑問
      ⇒ ちょっと試してみて疑問に思ったことを質問したい。

    2. 各リソースに発生した問題についての原因調査・究明
      ⇒ 金融系サービス的なクリティカル案件はないので、調査依頼はしない。
      （何かあったら問題のリソースを削除して作り直したり、停止⇒起動で対応・・）

  • サポート料金は、「基本料金」または「毎月の AWS 料金の ◯％ 」のどちらか高い方なので、技術的問い合わせ専用のAWSアカウントで「開発者プラン」に入り、基本の 29.00USD/月 で抑えたい。
    ただし、各サービスの技術的な仕様に関する疑問を質問する場合でも、その疑問に至った実際のリソースの状態を調査してもらうことになるので、調査が終わって回答をもらうまではそのリソースに対する従量課金が発生する。

  • なので、開発者プラン専用のAWSアカウントで普段は各種AWSリソースは作らず、 他のAWSアカウントのリソース利用時に発生した疑問や、新し目のことをちょっと試したときの仕様の確認をするときに、開発者プラン専用のAWSアカウントでその状態を作って質問をするようにしている。確認が終わったら速やかに調査用リソースを削除する。

質問内容と問い合わせ窓口

アカウントや料金に関する質問

  • ベーシックプランからでも質問可能。
  • AWS カスタマーサービス窓口へ質問する。
  • AWS Support ページから、Create case で「Account and billing support」をチェックして、Type からカテゴリを選択する。 20200226-01.png
  • AWSサービスで発生するコストに関する質問にも答えてくれる。
  • 質問例
    • AWS Backup で同一リソースID（EC2インスタンスID）の バックアップを複数作成した場合、 ２つ目以降のEBSスナップショットは増分バックアップになり、ストレージコストは削減されますでしょうか？
    • スナップショットのコストとなる容量の計算は、次であっていますでしょうか？「最初に取得したEBSの実質容量＋２番目に取得したEBSの増分量」

各サービスの技術的な仕様に関する疑問

  • ベーシックプランからでは質問できない。開発者プラン以上から質問する。
  • 質問するAWSアカウントと同じAWSアカウント内に、その疑問に至った状態のリソースが存在する必要がある。
  • AWS Support ページから、Create case で「Technical support」をチェックして、Service から質問対象のAWSサービスを選択する。
    Severityでは、一般的な質問・仕様確認の場合は「General guidance」を、原因調査の場合は「System impaired」を選択する。 20200226-02.png
  • 質問例
    • AWS Backup EC2 で作成した AMI を復元した EC2 にパブリックIPアドレスがアタッチされないのですが、そういう仕様なのでしょうか？

料金とサービスの仕様が密接に関わっている場合

  • ベーシックプランからでは質問できない。開発者プラン以上から質問する。
  • カスタマーサービス担当窓口と技術サポートのどちらに問い合わせたらよいか迷ったときは、ユーザー側で判断してどちらかに質問を投げると、AWSサポート側で適切な窓口へ引き継いでくれる。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-02-26T14:54:03+09:00

AWS ECS 細かい箇所を整理してみた

クラスター

ネットワーキングのみ

Fargate タスクに使用する新しい VPC でクラスターを起動できます。

クラスターの設定

image.png

クラスターの設定
クラスター名 クラスターの名称です。

ネットワーキング

image.png

ネットワーキング
VPCの設定 新しいVPCで起動する場合はチェックを入れ、以下の項目を入力します。デフォルト設定を使用する場合は不要です。
CIDRブロック 「VPCの設定」でチェックをいれた場合
サブネット1/2 「VPCの設定」でチェックをいれた場合　

CloudWatch Container Insights

image.png

CloudWatch Container Insights は、コンテナ化されたアプリケーションとマイクロサービスのメトリクスとログを収集、集計、要約します。

EC2 Linux + ネットワーキング

※「ネットワーキングのみ」と異なる箇所のみ記載。

インスタンスの設定

image.png

インスタンスの設定
プロビジョニングモデル オンデマンドインスタンスまたはスポットから選択。
※以下はすべてオンデマンドインスタンスを選択した場合のみ　
EC2 インスタンスタイプ コンテナインスタンスに使用するインスタンスタイプ
インスタンス数 クラスターで起動するインスタンスの数
EC2 Ami Id コンテナインスタンスに使用する EC2 AMI ID
EBS ストレージ (GiB)　 Amazon ECS-optimized AMI は 8 GiB および 22 GiB で起動します。
※22以上を指定する必要があります。
キーペア SSHで接続するキーペア

ネットワーキング

スクリーンショット 2020-02-15 15.56.27.png

ネットワーキング
セキュリティグループ コンテナインスタンスのセキュリティグループ

コンテナインスタンス IAM ロール

スクリーンショット 2020-02-15 15.59.37.png

ネットワーキング
コンテナインスタンスの IAM ロール ECSクラスターへ参加を行う際に必要となるIAMロール。
ecsInstanceRoleがない場合は自動で作成される。

EC2 Windows + ネットワーキング

※「ネットワーキング」「EC2 Linux + ネットワーキング」と異なる箇所のみ記載。

インスタンスの設定

スクリーンショット 2020-02-15 16.29.58.png

インスタンスの設定
EBS ストレージ (GiB) ECS-Optimized Windows Server AMI は 50 GiB ルートボリュームで起動します。

タスク定義

EC2

タスクとコンテナ定義の設定

image.png

タスクとコンテナ定義の設定
タスク定義名 タスクの定義の名前
タスクロール コンテナ単位でのIAMロール
ネットワークモード <デフォルト> は bridge 。
none はコンテナ定義にポートマッピングを指定することはできず、タスクのコンテナに外部接続できなくなる。
awsvpc の場合、タスクに ENI が割り当てられます。
host および awsvpc は、コンテナのネットワークパフォーマンスは最大限に高まる。bridge とは異なり、仮想化ネットワークではなく、EC2 ネットワークを使用するためです。ただし、公開されるコンテナポートは対応するホストポートに直接マッピングされるため、ポートマッピングが使用されている場合は、1 つのコンテナインスタンスで同じタスクの複数のインスタンスを実行することはできない。

タスクの実行 IAM ロール

image.png

タスクの実行 IAM ロール
タスク実行ロール ECSコンテナエージェント(=ECS-Agent)がECS APIを実行するために使用されるIAMロールとなります。

タスクサイズ

スクリーンショット 2020-02-22 19.23.30.png

タスクサイズ
タスクメモリ (MiB) タスクの固定サイズを指定。
※EC2 起動タイプはオプション。タスクサイズは Windows コンテナではサポートされない。
タスク CPU (単位) 同上

コンテナの定義

スタンダード

スクリーンショット 2020-02-18 19.07.38.png

スタンダード
コンテナ名 コンテナの名前
イメージ コンテナのイメージ
プライベートレジストリの認証 認証が必要なプライベートレジストリからコンテナイメージを取得する場合に指定します
AWS Secrets Manager を使用して有効になる。
メモリ制限 (MiB) ハード制限を指定した場合、コンテナはその制限を超えると強制終了される。
ソフト制限を指定した場合は、ECS によってコンテナ用にメモリの容量が予約されます。
ポートマッピング ホストポート→コンテナポートのポートマッピング

詳細コンテナ設定

ヘルスチェック

スクリーンショット 2020-02-20 20.43.14.png

ヘルスチェック　 　
コマンド ヘルスチェックに利用したいコマンド
間隔 実行間隔
タイムアウト 失敗と見なされるまでの時間
開始時間 失敗するまでのブートストラップまでの時間をコンテナに提供するオプションの猶予期間は、最大再試行回数にカウントされます。0～300 秒の間で指定できます。
再試行 異常と見なされるまでの回数　

環境

スクリーンショット 2020-02-22 18.25.50.png

環境　 　
CPU ユニット数 コンテナ用に予約する CPU ユニットの数
GPU コンテナ用に予約する GPU ユニットの数
基本 trueはそのコンテナが何らかの理由で失敗または停止すると、タスクに含まれる他のすべてのコンテナは停止される
falseは、その失敗はタスクに含まれる残りのコンテナに影響は与えない。
エントリポイント コンテナに渡すDocker エントリポイント
コマンド　 コンテナに渡す Docker CMD
作業ディレクトリ　 コンテナ内でバイナリを実行するための作業ディレクトリ
環境変数　 コンテナに渡す環境変数　

コンテナタイムアウト

スクリーンショット 2020-02-22 18.35.23.png

コンテナタイムアウト　 　
タイムアウト開始 コンテナの依存関係解決の再試行を止めるまでの待機時間　
停止タイムアウト コンテナが正常に終了しなかった場合にコンテナが強制終了されるまでの待機時間

ネットワーク設定

スクリーンショット 2020-02-22 18.45.00.png

ネットワーク設定　 　
ネットワーキングの無効化 trueのとき、ネットワーキングはコンテナ内で無効となる。
リンク -linkパラメータを利用できる。ただし、Dockerでは非推奨とされている。
ホスト名 コンテナに使用するホスト名
DNS サーバー コンテナに渡すDNSサーバ
DNS 検索ドメイン コンテナに渡す DNS 検索ドメイン
追加ホスト コンテナ上の /etc/hosts ファイルに追加する、ホスト名と IP アドレスのマッピング

ストレージとログ

スクリーンショット 2020-02-22 19.09.09.png

ストレージとログ　 　
読み取り専用ルートファイルシステム trueのとき、コンテナには、ルートファイルシステムに対する読み取り専用アクセス権限が付与される
マウントポイント コンテナ内のデータボリュームのマウントポイント
ボリュームソース 別のコンテナのデータボリュームをマウント
ログ設定 コンテナのログ設定の仕様

セキュリティ

スクリーンショット 2020-02-22 19.09.39.png

セキュリティ　 　
特権付与 trueのとき、コンテナには、root ユーザーと同様の権限が付与される。
ユーザー コンテナ内で使用するユーザー名
Docker セキュリティオプション SELinux と AppArmor のマルチレベルセキュリティシステムのカスタムラベルになる文字列のリスト
※Fargate 起動タイプは無効

リソースの制限

リソースの制限　 　
ulimit コンテナ内で設定する ulimit

DOCKER ラベル

DOCKER ラベル　 　
キー/値ペア コンテナに追加するラベルのキー/値

（サービス統合）

AWS App Mesh は マイクロサービスを簡単に監視し制御することができるサービスです。

（プロキシ設定）

上記の App Mesh 統合オプションを適用した後に自動的に設定されます。それ以外の場合は、手動で設定する必要があります。

（ログルーターの統合）

FireLens for Amazon ECS では、ログ保存や分析のため、AWS サービスまたは AWS パートナーネットワーク (APN) の宛先にログをルーティングします。

ボリューム

image.png
↓「ボリュームの追加」
image.png

タスクサイズ
名前 ボリュームの名前
ボリュームタイプ Dockerは複数のコンテナにマウントすることもでき、複数のコンテナで共通のファイルを読み書きすることができる。
bind mountはホストが管理しているファイルやディレクトリをコンテナにマウントする。
EFSを利用すれば、ストレージ容量が伸縮自在になる。

Tags

image.png

ECSリソースにタグをつけることができる。

FARGATE

※「EC2」と異なる仕様の部分のみ記載。

タスクとコンテナ定義の設定

image.png

タスクとコンテナ定義の設定
ネットワークモード awsvpcのみでしか動作しません。

タスクサイズ

image.png

タスクサイズ
タスクメモリ (MiB) Fargate 起動タイプは必須。
タスク CPU (単位) 同上

サービス

EC2

サービスの設定

スクリーンショット 2020-02-24 17.05.09.png

サービスの設定
起動タイプ タスクを実行する起動タイプ
タスク定義 実行するタスク
クラスター サービスを実行するクラスター
サービス名 サービスの名称
サービスタイプ REPLICAはクラスター全体で必要な数のタスクの配置および維持を行う。
DAEMONは、各コンテナインスタンスにタスクのコピーを 1 つ配置し維持する。
タスクの数 起動するタスクの数。
DAEMONでは指定不可。
最小ヘルス率 最低でもタスク数を維持する値（ローリングアップデートのみ）
最大率 起動するタスク数の最大値（ローリングアップデートのみ）

デプロイメント

スクリーンショット 2020-02-24 17.22.25.png

デプロイメントタイプ
デプロイメントタイプ ローリングアップデートはサービス内の現在のバージョンを新しいバージョンに置き換えます。デプロイ面と中に実行中のタスクを維持するには、「サービスの設定」で最小ヘルス率と最大率を指定する。
Blue/Green デプロイメント (AWS CodeDeploy を使用)は新しいバージョンのデプロイは本番のトラフィックが流れていない方の環境に行い、その環境上で正しく動作していることを確認したら、トラフィックをその環境に切り替えることで新しいバージョンをリリースする。
CodeDeploy のサービスロール Blue/Green デプロイメント (AWS CodeDeploy を使用)のみ

タスクの配置

スクリーンショット 2020-02-24 17.24.25.png

タスクの配置
配置テンプレート randomはランダムに配置。
binpackはCPU またはメモリの最小利用可能量に基づいてタスクを配置
spreadは指定された値に基づいてタスクを均等に配置する。
※制約を利用することで、タスクの配置に使用されるコンテナインスタンスをフィルタできる。

ネットワーク構成

スクリーンショット 2020-02-24 17.29.09.png

ネットワーク構成
VPC とセキュリティグループ タスク定義のネットワークモードが awsvpc である時に設定可能。
ヘルスチェックの猶予期間 ECS サービススケジューラが、タスクが最初に開始された後で異常な ELB ターゲットのヘルスチェックを無視する猶予期間
以下、ロードバランシングを設定した場合のみ指定可能

ロードバランシング

スクリーンショット 2020-02-24 17.29.59.png

ロードバランシング
ロードバランサーの種類 ALBもしくはNLBを指定可能
サービス用の IAM ロールの選択 サービスおよびロードバランサーで使用する IAM ロール
ロードバランサー名 使用するロードバランサー

サービスの検出 (オプション)

スクリーンショット 2020-02-26 20.55.01.png

サービスの検出 (オプション)
サービスの検出の統合の有効化 Route 53 を使用してサービスの名前空間を作成。これにより、サービスはDNS を介して検出可能とする。
名前空間 既存の名前空間/新しいプライベート名前空間
例えば、back.example.comでアクセスしたい場合、名前空間名にはexample.comを指定
サービスの検出サービスの設定 新しい検出サービスを作成するか、既存の検出サービスを利用するかを指定する
サービスの検出名 このECSサービスに対する検出名を入力。これは、作成するDNSレコードのプレフィックスとして使用される。
上の例だと、backを指定します。
ECS タスク状態の伝達の有効化 ECS はタスク状態を Route 53 に伝え、異常なタスクを DNS から削除するためにかかる時間を減らす。
Docker ヘルスチェック Docker ヘルスチェックは、タスク定義で定義される。

サービスの検出の DNS レコード

スクリーンショット 2020-02-26 21.02.30.png

サービスの検出の DNS レコード
DNS レコード型 レコードセットの種類。
bridgeまたはhostでタスク定義を使用する場合、Service Discoveryでは SRV DNS レコードのみ。
awsvpc使用すると、A または SRV DNS レコードを設定できます。
ネットワークアドレス SRV DNS レコードに関連付けるネットワークの詳細。
bridgeまたはhostでタスク定義を使用している場合は、タスク定義内の特定のポートマッピングを参照。
awsvpcでタスク定義を使用している場合は、タスク定義で独自のポートまたは特定のポートマッピングのいずれかを選択できる。
TTL リソースレコードキャッシュの有効期限

Auto Scaling (オプション)

Auto Scaling (オプション)
Service Auto Scaling CloudWatch アラームに応じてサービスの必要数を指定範囲内で調整する
タスクの最小数/必要数/最大数 EC2のAuto Scalingと考え方は同じ。
Service Auto Scaling 用の IAM ロール ECS で Auto Scaling の使用を許可する IAM ロール。
自動タスクスケーリングポリシー ターゲットの追跡
ポリシー名 ポリシーの名称
ECS サービスメトリクス メトリクスタイプ
ターゲット値 メトリクスのターゲット値
スケールアウトクールダウン期間 スケールアウトアクティビティが完了してから別のスケールアウトアクティビティが開始されるまでの時間。
スケールインクールダウン期間 スケールインアクティビティが完了してから別のスケールインアクティビティが開始されるまでの時間。
スケールインの無効化 スケールインの無効化
自動タスクスケーリングポリシー ステップスケーリング
ポリシー名 ポリシーの名称
次の場合にポリシーを実行 必要数を増やすポリシー
スケーリングアクション 必要数を減らすポリシー

FARGATE

※「EC2」と異なる仕様の部分のみ記載。

ネットワーク構成

image.png

ネットワーク構成 ※awsvpcのみ
VPC とセキュリティグループ クラスターのコンテナインスタンスが存在する VPC を選択
サブネット サブネットを選択
セキュリティグループ セキュリティグループを指定
パブリック IP の自動割り当て パブリック IP の自動割り当ての有効/無効

image.png

ロードバランシング
ロードバランサーの種類 ALBもしくはNLB、CLBを指定可能
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-02-26T14:54:03+09:00

Amazon ECS 細かい箇所を整理してみた

クラスター

ネットワーキングのみ

Fargate タスクに使用する新しい VPC でクラスターを起動できます。

クラスターの設定

image.png

クラスターの設定
クラスター名 クラスターの名称です。

ネットワーキング

image.png

ネットワーキング
VPCの設定 新しいVPCで起動する場合はチェックを入れ、以下の項目を入力します。デフォルト設定を使用する場合は不要です。
CIDRブロック 「VPCの設定」でチェックをいれた場合
サブネット1/2 「VPCの設定」でチェックをいれた場合　

CloudWatch Container Insights

image.png

CloudWatch Container Insights は、コンテナ化されたアプリケーションとマイクロサービスのメトリクスとログを収集、集計、要約します。

EC2 Linux + ネットワーキング

※「ネットワーキングのみ」と異なる箇所のみ記載。

インスタンスの設定

image.png

インスタンスの設定
プロビジョニングモデル オンデマンドインスタンスまたはスポットから選択。
※以下はすべてオンデマンドインスタンスを選択した場合のみ　
EC2 インスタンスタイプ コンテナインスタンスに使用するインスタンスタイプ
インスタンス数 クラスターで起動するインスタンスの数
EC2 Ami Id コンテナインスタンスに使用する EC2 AMI ID
EBS ストレージ (GiB)　 Amazon ECS-optimized AMI は 8 GiB および 22 GiB で起動します。
※22以上を指定する必要があります。
キーペア SSHで接続するキーペア

ネットワーキング

スクリーンショット 2020-02-15 15.56.27.png

ネットワーキング
セキュリティグループ コンテナインスタンスのセキュリティグループ

コンテナインスタンス IAM ロール

スクリーンショット 2020-02-15 15.59.37.png

ネットワーキング
コンテナインスタンスの IAM ロール ECSクラスターへ参加を行う際に必要となるIAMロール。
ecsInstanceRoleがない場合は自動で作成される。

EC2 Windows + ネットワーキング

※「ネットワーキング」「EC2 Linux + ネットワーキング」と異なる箇所のみ記載。

インスタンスの設定

スクリーンショット 2020-02-15 16.29.58.png

インスタンスの設定
EBS ストレージ (GiB) ECS-Optimized Windows Server AMI は 50 GiB ルートボリュームで起動します。

タスク定義

EC2

タスクとコンテナ定義の設定

image.png

タスクとコンテナ定義の設定
タスク定義名 タスクの定義の名前
タスクロール コンテナ単位でのIAMロール
ネットワークモード <デフォルト> は bridge 。
none はコンテナ定義にポートマッピングを指定することはできず、タスクのコンテナに外部接続できなくなる。
awsvpc の場合、タスクに ENI が割り当てられます。
host および awsvpc は、コンテナのネットワークパフォーマンスは最大限に高まる。bridge とは異なり、仮想化ネットワークではなく、EC2 ネットワークを使用するためです。ただし、公開されるコンテナポートは対応するホストポートに直接マッピングされるため、ポートマッピングが使用されている場合は、1 つのコンテナインスタンスで同じタスクの複数のインスタンスを実行することはできない。

タスクの実行 IAM ロール

image.png

タスクの実行 IAM ロール
タスク実行ロール ECSコンテナエージェント(=ECS-Agent)がECS APIを実行するために使用されるIAMロールとなります。

タスクサイズ

スクリーンショット 2020-02-22 19.23.30.png

タスクサイズ
タスクメモリ (MiB) タスクの固定サイズを指定。
※EC2 起動タイプはオプション。タスクサイズは Windows コンテナではサポートされない。
タスク CPU (単位) 同上

コンテナの定義

スタンダード

スクリーンショット 2020-02-18 19.07.38.png

スタンダード
コンテナ名 コンテナの名前
イメージ コンテナのイメージ
プライベートレジストリの認証 認証が必要なプライベートレジストリからコンテナイメージを取得する場合に指定します
AWS Secrets Manager を使用して有効になる。
メモリ制限 (MiB) ハード制限を指定した場合、コンテナはその制限を超えると強制終了される。
ソフト制限を指定した場合は、ECS によってコンテナ用にメモリの容量が予約されます。
ポートマッピング ホストポート→コンテナポートのポートマッピング

詳細コンテナ設定

ヘルスチェック

スクリーンショット 2020-02-20 20.43.14.png

ヘルスチェック　 　
コマンド ヘルスチェックに利用したいコマンド
間隔 実行間隔
タイムアウト 失敗と見なされるまでの時間
開始時間 失敗するまでのブートストラップまでの時間をコンテナに提供するオプションの猶予期間は、最大再試行回数にカウントされます。0～300 秒の間で指定できます。
再試行 異常と見なされるまでの回数　

環境

スクリーンショット 2020-02-22 18.25.50.png

環境　 　
CPU ユニット数 コンテナ用に予約する CPU ユニットの数
GPU コンテナ用に予約する GPU ユニットの数
基本 trueはそのコンテナが何らかの理由で失敗または停止すると、タスクに含まれる他のすべてのコンテナは停止される
falseは、その失敗はタスクに含まれる残りのコンテナに影響は与えない。
エントリポイント コンテナに渡すDocker エントリポイント
コマンド　 コンテナに渡す Docker CMD
作業ディレクトリ　 コンテナ内でバイナリを実行するための作業ディレクトリ
環境変数　 コンテナに渡す環境変数　

コンテナタイムアウト

スクリーンショット 2020-02-22 18.35.23.png

コンテナタイムアウト　 　
タイムアウト開始 コンテナの依存関係解決の再試行を止めるまでの待機時間　
停止タイムアウト コンテナが正常に終了しなかった場合にコンテナが強制終了されるまでの待機時間

ネットワーク設定

スクリーンショット 2020-02-22 18.45.00.png

ネットワーク設定　 　
ネットワーキングの無効化 trueのとき、ネットワーキングはコンテナ内で無効となる。
リンク -linkパラメータを利用できる。ただし、Dockerでは非推奨とされている。
ホスト名 コンテナに使用するホスト名
DNS サーバー コンテナに渡すDNSサーバ
DNS 検索ドメイン コンテナに渡す DNS 検索ドメイン
追加ホスト コンテナ上の /etc/hosts ファイルに追加する、ホスト名と IP アドレスのマッピング

ストレージとログ

スクリーンショット 2020-02-22 19.09.09.png

ストレージとログ　 　
読み取り専用ルートファイルシステム trueのとき、コンテナには、ルートファイルシステムに対する読み取り専用アクセス権限が付与される
マウントポイント コンテナ内のデータボリュームのマウントポイント
ボリュームソース 別のコンテナのデータボリュームをマウント
ログ設定 コンテナのログ設定の仕様

セキュリティ

スクリーンショット 2020-02-22 19.09.39.png

セキュリティ　 　
特権付与 trueのとき、コンテナには、root ユーザーと同様の権限が付与される。
ユーザー コンテナ内で使用するユーザー名
Docker セキュリティオプション SELinux と AppArmor のマルチレベルセキュリティシステムのカスタムラベルになる文字列のリスト
※Fargate 起動タイプは無効

リソースの制限

リソースの制限　 　
ulimit コンテナ内で設定する ulimit

DOCKER ラベル

DOCKER ラベル　 　
キー/値ペア コンテナに追加するラベルのキー/値

（サービス統合）

AWS App Mesh は マイクロサービスを簡単に監視し制御することができるサービスです。

（プロキシ設定）

上記の App Mesh 統合オプションを適用した後に自動的に設定されます。それ以外の場合は、手動で設定する必要があります。

（ログルーターの統合）

FireLens for Amazon ECS では、ログ保存や分析のため、AWS サービスまたは AWS パートナーネットワーク (APN) の宛先にログをルーティングします。

ボリューム

image.png
↓「ボリュームの追加」
image.png

タスクサイズ
名前 ボリュームの名前
ボリュームタイプ Dockerは複数のコンテナにマウントすることもでき、複数のコンテナで共通のファイルを読み書きすることができる。
bind mountはホストが管理しているファイルやディレクトリをコンテナにマウントする。
EFSを利用すれば、ストレージ容量が伸縮自在になる。

Tags

image.png

ECSリソースにタグをつけることができる。

FARGATE

※「EC2」と異なる仕様の部分のみ記載。

タスクとコンテナ定義の設定

image.png

タスクとコンテナ定義の設定
ネットワークモード awsvpcのみでしか動作しません。

タスクサイズ

image.png

タスクサイズ
タスクメモリ (MiB) Fargate 起動タイプは必須。
タスク CPU (単位) 同上

サービス

EC2

サービスの設定

スクリーンショット 2020-02-24 17.05.09.png

サービスの設定
起動タイプ タスクを実行する起動タイプ
タスク定義 実行するタスク
クラスター サービスを実行するクラスター
サービス名 サービスの名称
サービスタイプ REPLICAはクラスター全体で必要な数のタスクの配置および維持を行う。
DAEMONは、各コンテナインスタンスにタスクのコピーを 1 つ配置し維持する。
タスクの数 起動するタスクの数。
DAEMONでは指定不可。
最小ヘルス率 最低でもタスク数を維持する値（ローリングアップデートのみ）
最大率 起動するタスク数の最大値（ローリングアップデートのみ）

デプロイメント

スクリーンショット 2020-02-24 17.22.25.png

デプロイメントタイプ
デプロイメントタイプ ローリングアップデートはサービス内の現在のバージョンを新しいバージョンに置き換えます。デプロイ面と中に実行中のタスクを維持するには、「サービスの設定」で最小ヘルス率と最大率を指定する。
Blue/Green デプロイメント (AWS CodeDeploy を使用)は新しいバージョンのデプロイは本番のトラフィックが流れていない方の環境に行い、その環境上で正しく動作していることを確認したら、トラフィックをその環境に切り替えることで新しいバージョンをリリースする。
CodeDeploy のサービスロール Blue/Green デプロイメント (AWS CodeDeploy を使用)のみ

タスクの配置

スクリーンショット 2020-02-24 17.24.25.png

タスクの配置
配置テンプレート randomはランダムに配置。
binpackはCPU またはメモリの最小利用可能量に基づいてタスクを配置
spreadは指定された値に基づいてタスクを均等に配置する。
※制約を利用することで、タスクの配置に使用されるコンテナインスタンスをフィルタできる。

ネットワーク構成

スクリーンショット 2020-02-24 17.29.09.png

ネットワーク構成
VPC とセキュリティグループ タスク定義のネットワークモードが awsvpc である時に設定可能。
ヘルスチェックの猶予期間 ECS サービススケジューラが、タスクが最初に開始された後で異常な ELB ターゲットのヘルスチェックを無視する猶予期間
以下、ロードバランシングを設定した場合のみ指定可能

ロードバランシング

スクリーンショット 2020-02-24 17.29.59.png

ロードバランシング
ロードバランサーの種類 ALBもしくはNLBを指定可能
サービス用の IAM ロールの選択 サービスおよびロードバランサーで使用する IAM ロール
ロードバランサー名 使用するロードバランサー

サービスの検出 (オプション)

スクリーンショット 2020-02-26 20.55.01.png

サービスの検出 (オプション)
サービスの検出の統合の有効化 Route 53 を使用してサービスの名前空間を作成。これにより、サービスはDNS を介して検出可能とする。
名前空間 既存の名前空間/新しいプライベート名前空間
例えば、back.example.comでアクセスしたい場合、名前空間名にはexample.comを指定
サービスの検出サービスの設定 新しい検出サービスを作成するか、既存の検出サービスを利用するかを指定する
サービスの検出名 このECSサービスに対する検出名を入力。これは、作成するDNSレコードのプレフィックスとして使用される。
上の例だと、backを指定します。
ECS タスク状態の伝達の有効化 ECS はタスク状態を Route 53 に伝え、異常なタスクを DNS から削除するためにかかる時間を減らす。
Docker ヘルスチェック Docker ヘルスチェックは、タスク定義で定義される。

サービスの検出の DNS レコード

スクリーンショット 2020-02-26 21.02.30.png

サービスの検出の DNS レコード
DNS レコード型 レコードセットの種類。
bridgeまたはhostでタスク定義を使用する場合、Service Discoveryでは SRV DNS レコードのみ。
awsvpc使用すると、A または SRV DNS レコードを設定できます。
ネットワークアドレス SRV DNS レコードに関連付けるネットワークの詳細。
bridgeまたはhostでタスク定義を使用している場合は、タスク定義内の特定のポートマッピングを参照。
awsvpcでタスク定義を使用している場合は、タスク定義で独自のポートまたは特定のポートマッピングのいずれかを選択できる。
TTL リソースレコードキャッシュの有効期限

Auto Scaling (オプション)

Auto Scaling (オプション)
Service Auto Scaling CloudWatch アラームに応じてサービスの必要数を指定範囲内で調整する
タスクの最小数/必要数/最大数 EC2のAuto Scalingと考え方は同じ。
Service Auto Scaling 用の IAM ロール ECS で Auto Scaling の使用を許可する IAM ロール。
自動タスクスケーリングポリシー ターゲットの追跡
ポリシー名 ポリシーの名称
ECS サービスメトリクス メトリクスタイプ
ターゲット値 メトリクスのターゲット値
スケールアウトクールダウン期間 スケールアウトアクティビティが完了してから別のスケールアウトアクティビティが開始されるまでの時間。
スケールインクールダウン期間 スケールインアクティビティが完了してから別のスケールインアクティビティが開始されるまでの時間。
スケールインの無効化 スケールインの無効化
自動タスクスケーリングポリシー ステップスケーリング
ポリシー名 ポリシーの名称
次の場合にポリシーを実行 必要数を増やすポリシー
スケーリングアクション 必要数を減らすポリシー

FARGATE

※「EC2」と異なる仕様の部分のみ記載。

ネットワーク構成

image.png

ネットワーク構成 ※awsvpcのみ
VPC とセキュリティグループ クラスターのコンテナインスタンスが存在する VPC を選択
サブネット サブネットを選択
セキュリティグループ セキュリティグループを指定
パブリック IP の自動割り当て パブリック IP の自動割り当ての有効/無効

image.png

ロードバランシング
ロードバランサーの種類 ALBもしくはNLB、CLBを指定可能
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-02-26T13:41:17+09:00

Boto3を使って、S3のファイルリストから1000件以上のPrefixを取り出す

備忘録として

S3からのPrefixはデフォルトで1000件までしか取得できないので、1000件以上ある場合はpaginatorを利用する。

Boto3 ドキュメント

import boto3

# Create a client
client = boto3.client('s3', region_name='us-west-2')

# Create a reusable Paginator
paginator = client.get_paginator('list_objects')

# Create a PageIterator from the Paginator
page_iterator = paginator.paginate(Bucket='my-bucket')

for page in page_iterator:
    print(page['Contents'])

ドキュメントのデフォルトでは以上の通りで、page_iteratorのリストの中に、1000件ずつのPrefixのリストが格納されています。
それらを扱いやすくするために、展開してしまいます。

import boto3
import itertools

client = boto3.client('s3', region_name='us-west-2')
paginator = client.get_paginator('list_objects')
page_iterator = paginator.paginate(Bucket='my-bucket')
contents = list(itertools.chain.from_iterable(page_iterator))

これで、1000件以上のprefixを扱うことができます

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

Herokuでデプロイしたアプリで投稿画像の保存先をS3に設定してみた。

はじめに

前回記事でHerokuにデプロイしたアプリですが、投稿した画像が時間が経つと次のように表示されなくなります。
スクリーンショット 2020-02-25 21.43.43.png

原因

git上で管理されている画像は表示されますが、ブラウザ上で投稿した画像については保存されないため、一定時間で表示されなくなってしまいます。

これは、実装した画像アップローダーは、開発環境で動かす分には問題はありませんが、本番環境には適していません。app/uploaders/image_uploader.rbのstorage :fileというコードによって、ローカルのファイルシステムに画像を保存するようになるためです。本番環境でも投稿した画像を保存するためには、ファイルシステムではなくクラウドストレージサービスに画像を保存する必要があります。

対処法

今回AWS/S3のクラウドストレージサービスを利用します。なにぶん初心者のためエラーにぶつかる事が多く、スマートな処理ではないですがじぶんの備忘録として同じようなエラーに苦労される方の助けになればと思います。

※注意事項として、試行錯誤しながらやっと解決できた感じなので、決してスマートな解決方法ではないと思います。その点はご了承ください。そしてこうしたらスマートに解決できるよ！というご意見がございましたら是非コメントいただければ幸いです！

前提条件

・Railsアプリ作成済
・CarrierWaveとMiniMagickで画像投稿機能は実装済
・AWSアカウント登録済
・AmazonS3FullAccess権限を与えたIAMユーザーを作成済

以下実装の流れ

1.fogのインストール

本番環境でクラウドストレージに保存するために、fog gemを使います。

Gemfile.
gem 'bootstrap', '~> 4.4.1'
gem 'jquery-rails'
gem 'devise', '~> 4.6.1'
gem 'carrierwave', '~> 1.0'
gem "mini_magick"
gem 'fog' 　　　　 <= 追加

$ bundle install path --vendor/bundle

2.S3で保存先を準備

AWSでバケットの作成します。
スクリーンショット 2020-02-02 12.51.01.png

オリジナルのバケット名を入力し、アクセス許可をパブリックに設定します。

スクリーンショット 2020-02-26 12.01.27.png

3.設定

Herokuでの画像の保存先をAmazon S3に保存できるように設定します。
基本的な話ですが、アクセスキーIDとシークレットアクセスキーは直接入力厳禁です。これをするととんでもないことになります。ですので、必ず環境変数を設定します。私は身をもって体験いたしました。

config/initializers/carrierwave.rb
　〈中略〉　以下を追加
require 'carrierwave/storage/abstract'
require 'carrierwave/storage/file'
require 'carrierwave/storage/fog'

if Rails.env.production?
  CarrierWave.configure do |config|
    config.fog_credentials = {
      :provider              => 'AWS',
      :region                => ENV['S3_REGION'],     
      :aws_access_key_id     => ENV['S3_ACCESS_KEY'],
      :aws_secret_access_key => ENV['S3_SECRET_KEY']
    }
    config.fog_directory     =  ENV['S3_BUCKET']
  end
end
app/uploaders/image_uploader.rb
class ImageUploader < CarrierWave::Uploader::Base
  # Include RMagick or MiniMagick support:
  # include CarrierWave::RMagick
  include CarrierWave::MiniMagick

　# 以下を追加
 if Rails.env.production?
    storage :fog
  else
    storage :file
  end

4.herokuへ環境変数登録

herokuに環境変数を登録（IAMでCSVダウンロードした中身通りに値を入力）

$ heroku config:set S3_ACCESS_KEY="Accessキーを入力"
Setting S3_ACCESS_KEY and restarting ⬢ [アプリ名]... done, v15
S3_ACCESS_KEY: Accessキー

$ heroku config:set S3_SECRET_KEY="Secretキーを入力"
Setting S3_SECRET_KEY and restarting ⬢ [アプリ名]... done, v16
S3_SECRET_KEY: Secretキー

$ heroku config:set S3_BUCKET="Bucket名を入力"
Setting S3_BUCKET and restarting ⬢ [アプリ名]... done, v17
S3_BUCKET: Bucket名

$ heroku config:set S3_REGION="Region名を入力"
Setting S3_REGION and restarting ⬢ [アプリ名]... done, v18
S3_REGION: Region名

以上でherokuへ再度pushして'heroku open'してみると……

スクリーンショット 2020-02-02 14.43.49.png
上手くいっていないようです。ログを確認してみます。

$ heroku logs -t
2020-02-02T05:42:54.905758+00:00 app[web.1]: from /app/vendor/bundle/ruby/
2.6.0/gems/bootsnap-1.4.5/lib/bootsnap/load_path_cache/core_ext/kernel_require.
rb:22:in `block in require_with_bootsnap_lfi'
・
・
・
2020-02-02T05:43:15.180513+00:00 heroku[router]: at=error code=H10 
desc="App crashed" method=GET path="/" host=photo-ogiri.herokuapp.com 
request_id=ba2d6298-7c81-40a0-843d-02b9e2a700ef fwd="126.233.30.95" 
dyno= connect= service= status=503 bytes= protocol=https

アプリがクラッシュしたとの内容のみで修正が必要な箇所がわからない。

$ heroku run rails c
・
・
・
in `block in load_missing_constant': uninitialized constant CarrierWave::Storage::Fog (NameError)

見つけました。carrierwaveの部分でエラーが出ているようです。

5.エラー対処

確認すると carrierwave.rb が config/initializers 配下になく、 vendor/bundle 配下にしかなかったため、 config/initializers 配下に新たに carrierwave.rb を作成し、再度、heroku pushすると別のエラーが発生しました。

$ git push heroku master
・
remote:        rake aborted!
remote:        NameError: uninitialized constant CarrierWave::Storage::Fog
・
・
remote:  !
remote:  !     Precompiling assets failed.
remote:  !
remote:  !     Push rejected, failed to compile Ruby app.
・

まずは開発環境でPrecompileするために、以下を実行し成功することを確認しました。

$ RAILS_ENV=development bundle exec rails assets:precompile
・
・
yarn install v1.21.1
info No lockfile found.
[1/4] ?  Resolving packages...
[2/4] ?  Fetching packages...
[3/4] ?  Linking dependencies...
[4/4] ?  Building fresh packages...
success Saved lockfile.
✨  Done in 0.11s.

続いて本番環境でPrecompileできるか試してみました。

$ RAILS_ENV=production bin/rails assets:precompile
rails aborted!
NameError: uninitialized constant CarrierWave::Uploader

carrierwaveの設定に修正が必要な様子。調べてみるとRailsガイドではRails5.2以降の変更点として次の記載がありましたので、carrierwave.rbを修正しました。

config/credentials.yml.encファイルが追加され、productionアプリケーションの秘密情報（secret）をここに保存できるようになりました。これによって、外部サービスのあらゆる認証credentialを、config/master.keyファイルまたはRAILS_MASTER_KEY環境変数にあるキーで暗号化した形で直接リポジトリに保存できます。

carrierwave.rb
require 'carrierwave/storage/fog'

  CarrierWave.configure do |config|
    if Rails.env.production?
    config.fog_provider = 'fog/aws'
    config.fog_credentials = {
      provider:              'AWS',
      aws_access_key_id:     Rails.application.credentials.aws[:access_key_id],
      aws_secret_access_key: Rails.application.credentials.aws[:secret_access_key],
      region:                'ap-northeast-1'
    }
    config.fog_directory  = 'S3バケット名'
    config.fog_public     = true
    config.fog_attributes = { cache_control: "public, max-age=#{365.days.to_i}" }
    end
  end

再度、本番環境でPrecompileできるか試してみました。

$ RAILS_ENV=production bundle exec rails assets:precompile
rails aborted!
ArgumentError: Missing `secret_key_base` for 'production' environment, set this string with `rails credentials:edit`

失敗しましたがエラーは変わりました。secret_key_baseあたりを確認します。

$ EDITOR=vim rails credentials:edit
aws:
   access_key_id: ~~~~~~~~~~~~~~~~~~~~~~~
   secret_access_key: ~~~~~~~~~~~~~~~~~~~
# Used as the base secret for all MessageVerifiers in Rails, including the one protecting cookies.
   secret_key_base: ~~~~~~~~~~~~~~~~~~~~~~~~~

値もきちんと入っていますが、rails cで1つずつキーを確認するとsecret_key_baseのみがnillでした。

$ bundle exec rails c
>Rails.application.credentials.secret_key_base
=> nil
>Rails.application.credentials.aws[:access_key_id]
=> ~~~~~~~~~~~~~~~~~
>Rails.application.credentials.aws[:secret_access_key]
=> ~~~~~~~~~~~~~~~~~

ここでかなり苦戦しましたが、結果インデントの位置がおかしかったため生じていたエラーでした。修正後のcredentials.yml.encファイルがこちら。secret_key_base:のインデントを左に寄せただけです。恐らく修正前のコードだとaws:配下のコードとみなされてしまって、secret_key_base:の値が読み取られなかったことが原因です。

$ EDITOR=vim rails credentials:edit
aws:
   access_key_id: ~~~~~~~~~~~~~~~~~~~~~~~
   secret_access_key: ~~~~~~~~~~~~~~~~~~~
# Used as the base secret for all MessageVerifiers in Rails, including the one protecting cookies.
secret_key_base: ~~~~~~~~~~~~~~~~~~~~~~~~~

無事プリコンパイル処理もとおりました。

$ RAILS_ENV=production bundle exec rails assets:precompile
yarn install v1.21.1
[1/4] ?  Resolving packages...
success Nothing to install.
success Saved lockfile.
✨  Done in 0.15s.

あとはherokuにmaster.keyをセットして完了です。master.key は git 管理していないので、heroku にはデプロイされていません。そのため、最初この状態でheroku pushするとNoMethodError: undefined method '[]' for nil:NilClassと怒られました。

$ heroku config:set RAILS_MASTER_KEY=`cat config/master.key`
$ git push heroku master

無事heroku上のアプリに画像が表示されるようになり、S3のバケットに画像が保存されていることも確認できました。

スクリーンショット 2020-02-26 12.17.52.png

参考記事

https://railsguides.jp/asset_pipeline.html
https://github.com/carrierwaveuploader/carrierwave#using-amazon-s3
https://railsguides.jp/5_2_release_notes.html#credential%E7%AE%A1%E7%90%86
https://workabroad.jp/posts/2166

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

秘密鍵の共有「Secret Manager」

前置き

:warning:基本、秘密鍵の共有はよろしくないので、そちらを許容できる方のみ対応ください。

EC2のキーペアのプライベートキーの管理をどのように共有するかを模索していた段階でしたが、AWS Secret Managerで実現できそうなので、検証してみました。

AWS Secret Manager

【AWS公式】AWS Secrets Manager

アプリケーション、サービス、IT リソースへのアクセスに必要なシークレットの保護
データベースの認証情報、API キー、その他のシークレットをそのライフサイクルを通して容易にローテーション、管理、取得できるようにします。

秘匿情報の管理をこいつはやってくれます。

秘密鍵をバイナリデータで登録

※バイナリデータの登録・参照・取り出しは、AWSマネジメントコンソールではサポートされておらず、AWS CLIやSDKを使う必要があります。

登録用のシェル

register.sh
#! bin/bash
if [ -z "$1" ]; then
    echo "引数を入力してください"
    exit
else
    KEYPAIR_NAME=$1
    aws secretsmanager create-secret \
        --name ${KEYPAIR_NAME} \
        --secret-binary file:///data/secret-manager/keypair/${KEYPAIR_NAME}.pem
    aws secretsmanager get-secret-value \
        --secret-id ${KEYPAIR_NAME}
fi

登録シェル実行

$ sh register.sh [秘密鍵の名称（.pem除く）]

コンソールで確認

一応、コンソール画面で登録されているか確認してください。
Screenshot from 2020-02-26 11-39-33.png

秘密鍵を取り出し、ファイルで保存する

他の人が、登録した秘密鍵を取得する目線で、やっていきます。
先程、登録したシークレットキーを取得します。

取り出し用のシェル

getValue.sh
#! bin/bash
if [ -z "$1" ]; then
    echo "引数を入力してください"
    exit
else
    KEYPAIR_NAME=$1
    aws secretsmanager get-secret-value \
        --secret-id ${KEYPAIR_NAME} \
        --query 'SecretBinary' \
        --output text \
        | base64 -d > ./get-keypair/${KEYPAIR_NAME}.pem
fi

取り出しシェル実行

引数の名称で、シークレットキーを取得してきます。

$ sh getValue.sh [秘密鍵の名称（.pem除く）]

これでファイルが保存され、秘密鍵として使用できると思います。

参考サイト

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

# 秘密鍵の共有「Secret Manager」

EC2のキーペアのプライベートキーの管理をどのように共有するかを模索していた段階でしたが、AWS Secret Managerで実現できそうなので、検証してみました。

AWS Secret Manager

【AWS公式】AWS Secrets Manager

アプリケーション、サービス、IT リソースへのアクセスに必要なシークレットの保護
データベースの認証情報、API キー、その他のシークレットをそのライフサイクルを通して容易にローテーション、管理、取得できるようにします。

秘匿情報の管理をこいつはやってくれます。

秘密鍵をバイナリデータで登録

※バイナリデータの登録・参照・取り出しは、AWSマネジメントコンソールではサポートされておらず、AWS CLIやSDKを使う必要があります。

:warning:自身の権限を確認してから実施ください。

登録用のシェル

register.sh
#! bin/bash
if [ -z "$1" ]; then
    echo "引数を入力してください"
    exit
else
    KEYPAIR_NAME=$1
    aws secretsmanager create-secret \
        --name ${KEYPAIR_NAME} \
        --secret-binary file:///data/secret-manager/keypair/${KEYPAIR_NAME}.pem
    aws secretsmanager get-secret-value \
        --secret-id ${KEYPAIR_NAME}
fi

登録シェル実行

$ sh register.sh [秘密鍵の名称（.pem除く）]

コンソールで確認

一応、コンソール画面で登録されているか確認してください。
Screenshot from 2020-02-26 11-39-33.png

秘密鍵を取り出し、ファイルで保存する

他の人が、登録した秘密鍵を取得する目線で、やっていきます。
先程、登録したシークレットキーを取得します。

取り出し用のシェル

getValue.sh
#! bin/bash
if [ -z "$1" ]; then
    echo "引数を入力してください"
    exit
else
    KEYPAIR_NAME=$1
    aws secretsmanager get-secret-value \
        --secret-id ${KEYPAIR_NAME} \
        --query 'SecretBinary' \
        --output text \
        | base64 -d > ./get-keypair/${KEYPAIR_NAME}.pem
fi

取り出しシェル実行

引数の名称で、シークレットキーを取得してきます。

$ sh getValue.sh [秘密鍵の名称（.pem除く）]

これでファイルが保存され、秘密鍵として使用できると思います。

参考サイト

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

AWS RDS MySQLについて知らなければならない最も大切なこと

AWS RDS MySQLについて知らなければならない最も大切なことを簡単に、簡潔にご紹介しようと思います、

メジャーバージョンをあげるな。

特にフロントエンドまわりの方は、バージョンを最新にあげるのが最低限のマナーだと思っている方が多いかと思います。私もそうです。しかしながら、AWS RDS MySQLはバージョンを最新にすると使えなくなるサービスが多々あります。ざっとあげると

  • Amazon Aurora MySQL（MySQL5.6/5.7のみレプリケーション可能）
  • RDSパフォーマンスインサイト （MySQL5.6/5.7のみ可能）

まだこのふたつは問題ありません。Auroraは別途のチューニングが必要ですし、パフォーマンスインサイトは分析しなければ利用しなければいいだけです。致命的なのは

  • Amazon RDS Proxy （MySQL5.6/5.7のみ可能）

現在、MySQLバージョン5.6または5.7で実行されるAmazon RDS MySQL、または、Aurora MySQLをサポートしています。
https://aws.amazon.com/jp/blogs/news/using-amazon-rds-proxy-with-aws-lambda/

いや、プレビュー版なのはわかってます。けど、Lambdaでコネクションプールを考えるとRDS Proxyはまさに救世主でプレビュー版でも本番に投下したかったのです。私のプロダクション環境はRDS MySQL8系なので上記は一切使えませんが。Lambdaで環境構築をすませましたが、ElasticBeanstalkに切り替えます・・・。

使う予定はない？私もなかったです。けど、使いたくなるときはいつくるかわかりません。

AWS RDS MySQL使うなら「最新バージョンにしよう」とか思わずに、5.7のマイナーアップデートにしておくことをおすすめします。
それでは、また。

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

Elasticsearchの負荷検証

結論

  • Elasticsearch の queueサイズを上げると全体的にレスポンスは遅くなる
  • しかし、その分多くのリクエストに対応できる
  • 予算などと相談して適切な設定をすると良い

負荷テスト結果

  • timeout設定: 60000ms
queue size fastest slowest total request count error rate
1000 1973 59461 16736 50%
10000 7195 59219 21472 1%
20000 10447 59715 19548 5%

負荷テスト考察

  • 大きくしすぎた場合、逆に遅くなるしエラーも増えていいことない。
  • queueのサイズはメモリに大きな影響を与えない。
  • メモリはclient nodeの方に多めにあげたほうがいい
  • data node は結局ディスクIOが足を引っ張るので限界がある。
  • client node にあげとくと429を正常に返してくれる確率が上がる
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-02-26T10:21:06+09:00

AWS試験対策【自分メモ用】

S3 Intelligent-Tiering

  • 最適なストレージ利用を自動化
  • 高頻度と低頻度という2つのアクセス階層が組み込まれています
  • 両方の階層とも、Standard(標準)ストレージクラスと同等の低レイテンシーを提供

Amazon CloudFrontのコスト

  • トラフィックの分散：データ転送とリクエストの価格は地域によって異なり、価格はコンテンツが配信されるエッジの場所によって異なる
  • リクエスト：リクエスト（HTTPまたはHTTPS）の数と種類、およびリクエストが行われた地域。
  • データ転送アウト：Amazon CloudFrontエッジロケーションから転送されたデータの量

利用可能なリザベーションモデル

  • EC2リザーブドインスタンス
  • RDSリザーブドインスタンス
  • ElastiCacheリザーブドノード
  • DynamoDBリザーブドキャパシティ
  • Redshiftリザーブドノード

Amazon EMRを適用するべきユースケース

  • MACHINE LEARNING
  • 抽出、変換、読み込み (ETL)
  • クリックストリーム分析
  • リアルタイムストリーミング
  • インタラクティブ分析
  • ゲノミクス

AWS Server Migration Service (SMS)

  • 数千のオンプレミスワークロードを従来よりも簡単に、かつ短時間で AWS に移行できるエージェントレスサービス
  • ライブサーバーボリュームの増分レプリケーションの自動化、スケジュール設定、および追跡が可能
  • サーバー仮想マシンをクラウドホストの Amazon マシンイメージ (AMI) として段階的にレプリケートし、Amazon EC2 にデプロイ
  • オンプレミスの VMware vSphere、Microsoft Hyper-V/SCVMM、または Azure 仮想マシンの AWS クラウドへの移行を自動化

AWS Database Migration Service(DMS)

  • 広く使用されている商用およびオープンソースのほとんどのデータベースとの間でデータを移行するために使用

AWS Application Discovery Service(ADS)

  • オンプレミスサーバーのインベントリと動作を検出するために使用
  • AWSへの移行計画を作成するときに利用

AWS Globel Accelerator

  • 世界中の顧客に提供するアプリケーションの可用性とパフォーマンスを改善するネットワークサービス
  • EC2 インスタンスと Global Accelerator を接続するには、アクセラレーターを作成し、EC2 インスタンス ID を使用するエンドポイントとして、EC2 インスタンスを追加するだけ

リサーブドインスタンスのコンバーティブルのみで変更可能な内容

  • インスタンスファミリー
  • OS
  • テナンシー
  • 支払オプション

DynamoDB にはテーブルで読み込みおよび書き込みを処理するための読み込み/書き込みキャパシティーモード

  • オンデマンド
  • プロビジョンドスループット (デフォルト、無料利用枠の対象)

DynamoDBにはオートスケーリングスループットというオプションはありません

AWS DataSync

  • オンプレミスストレージと Amazon EFS の間でデータを迅速かつ簡単に移動することができるマネージド型のデータ転送サービス

AWS バックアップ

  • Amazon EFS ファイルシステムの中央管理とバックアップの自動化が簡単にできる完全管理バックアップサービス

効率的にEC２インスタンスを多数起動

  • ブートストラップ（Bashシェルスクリプトの利用）
  • ゴールデンイメージ

AWS X-Ray

  • リクエスト動作の確認
  • アプリケーションの問題の検出
  • アプリケーションのパフォーマンスの向上

AWSリソースのタグ

  • タグには常に標準化された大文字と小文字を区別する形式を使用し、すべてのリソースタイプにわたって一貫して実装します。
  • リソースアクセス制御、コスト追跡、自動化、および組織を管理する機能をサポートするタグディメンションを検討します。
  • リソースタグの管理に役立つ自動化ツールを実装します。
  • 少なすぎるタグではなく、多すぎるタグを使用することは誤り
  • ビジネス要件の変化に対応するためにタグを変更するのは簡単ですが、特にタグベースのアクセス制御、自動化、またはアップストリーム請求レポートに関連する将来の変更の影響を考慮

AWS Managed VPN

  • リモートの顧客ネットワークとインターネット上のAmazon VPCの間にIPsec VPN接続を作成するオプション
  • VPN接続のAWS側に組み込まれた自動化されたマルチデータセンターの冗長性とフェイルオーバー

AWS Snowmobile

  • 超大容量データを AWS に移動するために使用できるエクサバイト規模のデータ転送サービス
  • セミトレーラートラックが牽引する長さ 14 m の丈夫な輸送コンテナで、Snowmobile 1 台あたり 100 PB まで転送できます

AWS Snowball

  • 安全なデバイスを使用して AWS クラウドの内外に大量のデータを転送するペタバイト規模のデータ転送サービス
  • 最大50テラバイトのデータをデータソースから筐体に1日以内に転送できるよう設計されています

AWS Snowball Edge

  • データ移行とエッジコンピューティングのデバイス
  • 統合されたストレージとコンピューティング機能を備えた 100 TB のデータ転送デバイスであり、ペタバイト規模のデータの移動、遠隔地やオフラインのロケーションでの簡単な事前処理の実行に使用

AWS Certificate Manager（ACM）

  • ACMまたはIAMを使用して、サーバー証明書を保存および展開
  • ACMでサポートされていない地域でHTTPS接続をサポートする必要がある場合にのみ、IAMを証明書マネージャーとして使用
  • IAMはすべてのリージョンでのサーバー証明書のデプロイをサポートしていますが、AWSで使用するには外部プロバイダーから証明書を取得する必要があります

Amazon CloudSearch

  • AWS クラウドにおけるマネージド型サービスであり、ウェブサイトまたはアプリケーション向けの検索ソリューションを容易かつコスト効率良く設定、管理、スケールできます

拡張VPCルーティング

  • Amazon Redshift 拡張された VPC のルーティングを使用すると、Amazon Redshift はクラスターとデータリポジトリ間のすべての COPY と UNLOAD トラフィックが Amazon VPC を通るよう強制

AWS Artifact

  • 重要なコンプライアンス関連情報の頼りになる一元管理型のリソース
  • AWS のセキュリティおよびコンプライアンスレポートと特定のオンライン契約にオンデマンドでアクセスできます
  • Service Organization Control (SOC)、Payment Card Industry (PCI) レポート、AWS セキュリティ制御の実装と運用の有効性を検証する、さまざまな地域やコンプライアンスの認定機関からの認定が含まれます

Amazonリソースネーム（ARN）

  • AWSリソースを一意に識別
  • arn:partition:service:region:account-id:resource-id

CloudFormation スタックセット

  • CloudFormation テンプレート内に AWS リソースの設定を定義して、それから数回のクリックで複数の AWS アカウント及び/あるいはリージョンにそれらを水平展開できます。
  • クロスアカウントやクロスリージョンのシナリオを解決する AWS 機能のベースラインレベルのセットアップにこの機能を活用できます。
  • 一度セットアップしてしまえば、追加のアカウントやリージョンに対しても容易に展開することができます。

AWS Firewall Manager

  • お客様の複数のアカウントとアプリケーションにわたって一元的に AWS WAF ルールを設定、管理することを容易にするセキュリティ管理サービス

AWS WAF

  • アプリケーションの可用性に対する影響、セキュリティの侵害、過剰なリソース消費を生じる可能性がある一般的なウェブエクスプロイトからウェブアプリケーションを保護するために役立つウェブアプリケーションファイアウォール

AWS Sheild

  • マネージド型の分散サービス妨害 (DDoS) に対する保護サービス
  • 直接的にDDoS攻撃を回避するにはWAFではなくAWS Sheildを設定することが優先

Elastic Network Interface

  • 実行中（ホットアタッチ）
  • 停止したとき（ウォームアタッチ）
  • インスタンスが起動されているとき（コールドアタッチ）

Amazon Data Lifecycle Manager (Amazon DLM)

  • 定期的なバックアップスケジュールを実施して貴重なデータを保護する
  • 監査担当者または社内のコンプライアンスが必要とするバックアップを保持する
  • 古いバックアップを削除してストレージコストを削減する

Amazon Simple Workflow(SWF)

  • 開発者が並行または順次のステップを持つバックグラウンドジョブを構築、実行、およびスケーリングするのに役立ちます
  • 業務的に2回注文が行われてしまう場合の重複防止
  • 分離アーキテクチャを作成するために使用できるサービス

AWS IoT Core

  • インターネットに接続されたデバイスから、クラウドアプリケーションやその他のデバイスに簡単かつ安全に通信するためのマネージド型クラウドサービス
  • アプリケーションがインターネットに接続されていない場合でも、すべてのデバイスを常に追跡して通信できます

Amazon S3 Select

  • Amazon S3バケット内のオブジェクト内のデータをより迅速かつ安価に分析および処理できる
  • 単純なSQL式を使用してAmazon S3のオブジェクトからデータのサブセットを取得する機能

Amazon Athena

  • インタラクティブなクエリサービス
  • 標準のSQL式を使用してAmazon S3のデータを簡単に分析できるインタラクティブなクエリサービス
  • S3のデータをポイントし、スキーマを定義し、標準のSQL式を使用してクエリを開始するだけ

Redshift Spectrum

  • S3のエクサバイトの非構造化データに対してSQLクエリを直接実行
  • 取得されるデータに基づいてクエリの計算能力を自動的にスケーリングするため、データセットのサイズに関係なく、Amazon S3に対するクエリは高速に実行

Amazon Polly

  • 文章をリアルな音声に変換するサービス
  • 発話できるアプリケーションを作成、全く新しいタイプの音声対応製品

Amazon SageMaker

  • すべての開発者とデータサイエンティストに機械学習モデルを迅速に構築、トレーニング、デプロイできる手段を提供
  • フルマネージドサービスで、機械学習ワークフロー全体に対応

Amazon Lex

  • 音声やテキストを使用して、任意のアプリケーションに対話型インターフェイスを構築するサービス
  • 音声のテキスト変換には自動音声認識 (ASR)、テキストの意図認識には自然言語理解 (NLU) という高度な深層学習機能が使用できる

Amazon Rekognition

  • 画像分析と動画分析
  • 顔を検出、分析、比較して、多岐にわたるユーザー検証、人数計数、公共安全のユースケース
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-02-26T09:33:56+09:00

AWS認定機械学習専門知識(MLS)を、２ヶ月の集中期間で取得したやったことまとめ

はじめに

AWS認定機械学習専門知識(MLS)について、受験者数の絶対数が少ないのか試験対策に関する参考記事の投稿が少なく情報収集に苦労しました。

今回、２ヶ月ほどの準備をして取得できた試験準備のコツなどについてまとめてみました。機械学習専門知識に関わるAWS関連サービスのイメージを掴んでいただければ幸いです。

本記事の主な対象者

  • AWS認定の他の試験区分は取得済みで、機械学習専門知識の受験を検討している方
  • 取得に向けて有効な学習方法などの情報収集したい方

筆者のAWS認定履歴

AWS認定 取得日
ソリューションアーキテクト - アソシエイト 2018-05-13
デベロッパー - アソシエイト 2018-06-03
SysOpsアドミニストレーター - アソシエイト 2018-06-10
ソリューションアーキテクト - プロフェッショナル 2018-07-29
DevOpsエンジニア - プロフェッショナル 2018-08-26
ビッグデータ専門知識 2019-08-25
セキュリティ専門知識 2019-12-08
機械学習専門知識 2020-02-23

昨年12月にラスベガスで開催された re:Invent 2019 で 多くの機械学習関連のサービスのアップデートがアナウンスされました。
今回の受験モチベーションは、機械学習の知識は、エンジニアの教養としてもはや特別なものではなくなってきていると感じ、これらの知識ついて一度体系立てた学習をしてみたくなったのがきっかけです。

今回のスコア(2020-02-23受験)

総合スコア: 755/1000 (ボーダー750)

スコアと評価
分野 1: データエンジニアリング  ->  十分な知識を有する
分野 2: 探索的データ解析  ->  十分な知識を有する
分野 3: モデリング  ->  再学習の必要あり
分野 4: 機械学習の実装と運用  ->  十分な知識を有する

AWS認定機械学習専門知識(MLS)について

ここからが本題となります。
まずは、以下の公式ページから試験概要の把握を行いました。

具体的な試験準備で効果があったと思えること

実際に受験をしてみて、試験対策として効果があったと思う内容について、主観的な効果度合いで順に記載します。

  • 機械学習に関する基礎の習得
    前提として、著者の生業はサーバーサイドのエンジニアで、一般的な機械学習の知識はあれど、教育機関で機械学習アルゴリズムを学んだ経験があったり、対価を頂く仕事として機械学習に携わっている立場ではありません。
    今回、専門的な機械学習の知識の習得の為、スタンフォード大学Andrew Ng教授のCoursera機械学習コースを年末年始の休暇を利用して集中的に学習しました。
    このコースの講義は英語の動画ですが、日本語の字幕が丁寧につけられています。また、無料のオンラインコースですので、AWS認定取得に関わらず、エンジニアの教養として機械学習に触れたい方にもオススメできる内容です。
    このコースの詳細な紹介については多くの方がQiita記事を投稿されていますので、紹介はそちらに委ねたいと思います。

  • 動画学習サイトの活用
    英語力は必要となりますが、網羅的な試験対策コースがあります。動画を視聴する時間はそれなりに取られます。何れかのサイトを利用しておくと試験前の安心感が得られると思います（サイトのみの紹介、コースはお好みで）

抑えるべき３つのポイント

実際に認定試験を受けてみて、試験ガイドとは別軸で大きく３つのカテゴリーがあるのかなと感じました。

1. 機械学習に関わるAWS関連サービスの理解

  • 機械学習と間接的に関わるAWS関連サービスを問われます。この部分については、ほぼAWS認定ビッグデータ専門知識の試験内容と重複しています。逆の言い方をすると、先にビックデータを取得する（学習する）と、この部分はおのずとクリアできるのかなと思います。いずれにしても、機械学習のプリプロセスは大量のトレーニングデータを扱う部分ですので、作業量や費用対効果、セキュリティなどの条件に照らした場合、AWSサービスとして何がベストプラクティスなのかの理解が必要です。

2. 機械学習の基礎知識

  • 純粋に機械学習の基礎知識を問われます。例えば、欠損・不均衡データのデータ補完や、オーバーフィッティング（過学習）への対処、学習率・バッチサイズそれぞれ大小の振る舞いなどなど。この部分については、先に紹介した Coursera機械学習コースをしっかり理解していれば、認定試験をクリアできる知識が身につくかと思います。

3. SageMaker

  • SageMakerのビルトインアルゴリズムを中心に広い範囲で知識を問われます。事前に、Coursera機械学習コースを受講しており、数学的な側面からベースとなる機械学習アルゴリズムのいくつかに触れていましたので、ビルトインアルゴリズムには取っ付き易いものも有りました。ですが、日頃SageMakerを活用している方でも、全てのビルトインアルゴリズムには触れてはいないだろうという位のボリューム感です。ここは素直に、Amazon SageMaker-開発者ガイドを、ユースケース（分類、レコメンド、異常検知・・・）を想像しながら読み進めるのがオススメかと思います。

その他試験TIPS

以下、私見を多分に含むメモです。キーワードの参考に。

  • データ分布

    • 正規分布 / ２項分布 / ポアソン分布 / ベルヌーイ分布

  • 欠損データ補完

    • 平均値置換
    • 中央値置換
    • 行削除
    • 機械学習で推定値補完
    • トレーニングデータ追加

  • 不均衡データの対処

    • オーバーサンプリング
    • アンダーサンプリング
    • SMOTE

  • 外れ値の対処

    • 分散、標準偏差
    • Random Cut Forest

  • トレーニングデータ前処理

    • ビン分割
    • 対数変換
    • One-hotエンコーディング / ラベルエンコーディング
    • Scaling
    • 正則化
    • シャッフル

  • トレーニング

    • 学習率
    • バッチサイズ
    • 過学習/未学習
    • 勾配消失(爆発)問題
    • L1 / L2正則化

  • トレーニング評価

    • 混同マトリックス
    • Recall
    • Precision
    • F1
    • ROC / AUC

  • AWS関連サービス

    • S3
    • Kinesis
    • Glue
    • Data Pipeline
    • Batch
    • DMS
    • Step Functions
    • Athena
    • QuickSight
    • EMR
    • ECR
    • ML
    • SageMaker
    • SageMaker Ground Truth
    • SageMaker Neo
    • IoT Greengrass
    • Comprehend
    • Translate
    • Transcribe
    • Polly
    • Rekognition
    • Forecast
    • Lex
    • Personalize
    • Textract
    • DeepRacer
    • DeepLens

  • SageMakerビルトインアルゴリズム

    • BlazingText
    • DeepAR
    • 因数分解機
    • イメージ分類
    • IP Insights
    • K-Means
    • KNN
    • LDA
    • 線形学習
    • NTM
    • Object2Vec
    • オブジェクト検出
    • PCA
    • RCF
    • セマンティックセグメンテーション
    • Sequence to Sequence
    • XGBoost
    • 強化学習

おわりに

正直に、昨年度アソシエイトレベルの準備を始めた頃は、機械学習専門知識の認定は、天上人のみが取得できるものだと思っていました。ですが今回、認定をひとつづつクリアしていくうちに自然とたどり着くことができました。

大事なことは、行動を起こしてみる。そして学習を習慣づけるといったことではないでしょうか。
今後受験を検討される方の一助になれば幸いです。

著者関連リンク

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

Amazon Cognitoの設定をAWSコンソールから操作する際に気になっていること

前置き

以前から気にはなっていましたが、AWSコンソールからCognitoを操作する際、ロールを設定する画面でプルダウンにアカウントが持つ全てのロールが表示されていませんでした。問い合わせて回答をいただいたのでメモがてら共有しておこうと思います。

TL;DR

  • ユーザープールとIDプールの2箇所で発生
  • コンソール上で選べるロールの数は最大100件(現時点での仕様)
  • プルダウンの表示順はアルファベット昇順
  • 回避策はCLIの利用や、画面でのロールの新規作成など

詳細

以下の2箇所のプルダウンにはアカウントが持つロールが100個までしか表示されていません。

Cognito User Pool : Group作成時のロール設定
スクリーンショット 2020-02-26 0.33.29.png

Cognito Federated Identity : 認証された・されていないユーザーへのロール設定
スクリーンショット 2020-02-26 0.32.40.png

回避策

  1. AWS CLI
  2. 新しくロールを作成する
  3. アルファベットの昇順で表示されるように名前をつける(一応......)

1. AWS CLI

※リファレンスの例にはunauthのコマンドは見つからなかったけど、多分こんな感じでしょう。

aws cognito-identity set-identity-pool-roles \
--identity-pool-id "${YourIdentityPoolId}" \
--roles authenticated="${YourAuthenticatedRoleArn}" \
--roles unauthenticated="${YourUnauthenticatedRoleArn}"

2. 新しくロールを作成する

画像をもう一度見てみると、どちらもプルダウンのすぐ右に Create Role と、新しいRoleを作成しそのままアタッチすることが可能です。
スクリーンショット 2020-02-26 0.33.29.png

3. アルファベットの昇順で表示されるように...

まぁ、、表示はされますよ...

挙げといてなんですが、１以外はおすすめしません。

最後に

不便っちゃ不便ですよね。
個人用のアカウントならまだしも、企業のアカウントとなるとロールの数は100をゆうに超えるでしょう。AWSの基本思想に則ると開発者用のアカウントではインフラ担当者がCLIの利用は制限していることが多く、CLIを使って設定するためにはSREやインフラ担当にお願いをする必要がありますからね。

機能改善としてフィードバックを挙げたのと、AWSの担当者的にも既知の状況であること(実際に使いづらい)は判明したので、これがきっかけとなって改善されるといいなぁ。

参照

AWS CLI Reference - CognitoIdentity

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

Cloudfrontが400エラーを返す問題とその解決策

問題

S3においたファイルを参照しているCloudfrontが、ある時からアクセスすると400エラーしか返さなくなってしまった。

原因

cookieが長すぎた。
アプリケーションの実装側のバグで、ある特定の条件下で外部のユーザー管理サービスに繰り返しリダイレクトし、そのたびにcookieがつけられていたため、非常に長くなっていた。

解決策

cookieを消す。
ただあくまで本質的な問題は、cookieの長さが問題になるほど繰り返しリダイレクトしていたことなので、その部分を治す必要あり。

cloudfront s3 returns 400 error とかググってもなかなか出てこず、なんとなくcookieを見た時にやっと気づいたので、だれかの参考になれば幸いです。

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

日付別

タグ一覧