20200518のAWSに関する記事は30件です。

AWS EC2でAWS SDK for PHPインストール(PHP7.2+Apache2.4.41 + OPCashe + Composer)

Amazon Linux EC2でAPI叩いてからDynamoDBに保存するときに
PHPでやりたかったので、AWS SDK for PHPを入れようとしました。

しかし、色々課題が発生したので、備忘録にします。自分用ですが、
対象読者は、「色々やったけど調べる内に、ここに行き着いた人」です。
助力になれば、幸いです。

$ cat /etc/system-release
Amazon Linux release 2 (Karoo)

AmazonLinux2 ExtrasLibraryで PHP7.2をインストール

$ sudo amazon-linux-extras install php7.2
$ sudo yum install php php-mbstring

$ sudo yum list installed | grep php
php-cli.x86_64                        7.2.30-1.amzn2                 @amzn2extra-php7.2
php-common.x86_64                     7.2.30-1.amzn2                 @amzn2extra-php7.2
php-fpm.x86_64                        7.2.30-1.amzn2                 @amzn2extra-php7.2
php-json.x86_64                       7.2.30-1.amzn2                 @amzn2extra-php7.2
php-mysqlnd.x86_64                    7.2.30-1.amzn2                 @amzn2extra-php7.2
php-pdo.x86_64                        7.2.30-1.amzn2                 @amzn2extra-php7.2

参考:https://qiita.com/owlbeck/items/20f3e5402cb782f6291e

Apache をインストール

$ sudo yum install httpd
$ systemctl start httpd
$ systemctl status httpd
● httpd.service - The Apache HTTP Server
   Active: active (running) 

OPCashe をインストール

sudo yum install php-opcache

Composer をインストール

$ curl -sS https://getcomposer.org/installer | php
$ ls
composer.phar

$ php composer.phar
$ mv composer.phar /usr/local/bin/composer
$ composer

最後の二行はPATHが通っている場所に引っ越しただけです。これでかっこいいロゴを表示できます。
参考:https://getcomposer.org/doc/00-intro.md
参考:https://qiita.com/kakijin/items/02364adacf36410f449e

AWS SDK for PHP の使用開始

$ sudo -i
$ cd /usr/local/bin/composer
$ vi composer.json //jsonに書き込み
composer.json
{
    "require": {
        "aws/aws-sdk-php": "2.*"
    }
}
$ php composer.phar install
phpに書き込んで終了
require '/path/to/sdk/vendor/autoload.php';

終了

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

AWS IP アドレスの範囲

はじめに

セキュリティグループのInBound、OutBoundにてAWSのサービス(API Gateway、S3など)を許可するように設定したい場合は、AWS IP アドレスの範囲を見て設定可能です。

AWS IP アドレスの範囲

https://ip-ranges.amazonaws.com/ip-ranges.json

image.png

AWS の IP アドレス範囲の変更通知

AWS の IP アドレス範囲に変更がある際に、SNS通知設定をし、受信したら差分をメンテする。

設定方法:https://docs.aws.amazon.com/ja_jp/general/latest/gr/aws-ip-ranges.html#subscribe-notifications

PythonであるサービスのIPを取り出す例

import urllib.request
import json

def get_ip_groups_json(url):

    response = urllib.request.urlopen(url)
    ip_json = response.read()

    return ip_json

def get_ranges_for_service(ip_range_url, service, subset):

    ip_ranges_json = json.loads(get_ip_groups_json(ip_range_url))

    service_ranges = list()

    for prefix in ip_ranges_json['prefixes']:
        if prefix['service'] == service and subset == prefix['region']:
            service_ranges.append(prefix['ip_prefix'])

    return service_ranges


ip_ranges = get_ranges_for_service('https://ip-ranges.amazonaws.com/ip-ranges.json', 'S3', 'ap-southeast-1')

for ip in ip_ranges: print(str(ip))

結果:
image.png

Lambdaで自動更新

メンテ作業を自動化にしたい場合は、Lambdaでセキュリティグループを更新することも可能です。
サンプル:update-security-groups

参考Doc:AWS IP アドレスの範囲

以上

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

VPC エンドポイントとは

VPC エンドポイント

VPC のインスタンスは、サービスのリソースと通信するためにパブリック IP アドレスを必要としません。VPC と他のサービス間のトラフィックは、Amazon ネットワークを離れません。

インターフェイスエンドポイント

インターフェイスエンドポイントは、サポートされるサービスを宛先とするトラフィックのエントリポイントとして機能するサブネットの IP アドレス範囲のプライベート IP アドレスを持つ Elastic Network Interface です。インターフェイスエンドポイントは、プライベート IP アドレスを使用してサービスにプライベートにアクセスできるようにするテクノロジである AWS PrivateLink を使用します。

スクリーンショット 2020-05-18 22.46.31.png

プライベート DNS を使用するには、VPC 属性のenableDnsHostnames および enableDnsSupport を true に設定する必要があります。

ゲートウェイエンドポイント

ゲートウェイエンドポイントは、サポートされる AWS のサービスを宛先とするトラフィックのルートテーブルで、ルートのターゲットとして指定するゲートウェイです。以下の AWS のサービスがサポートされています。

  • S3
  • DynamoDB

スクリーンショット 2020-05-18 22.48.23.png

VPC エンドポイント によるサービスのアクセスコントロール

エンドポイントを作成するときは、接続先のサービスへのアクセスを制御するエンドポイントポリシーを、エンドポイントにアタッチできます。エンドポイントのポリシーは、JSON 形式で記述される必要があります。

VPC エンドポイントポリシーは、エンドポイントの作成時または変更時にエンドポイントにアタッチする IAM リソースポリシーです。エンドポイントの作成時にポリシーをアタッチしない場合、サービスへのフルアクセスを許可するデフォルトのポリシーがアタッチされます。

デフォルトでは、特にアウトバウンドアクセスを制限していない限り、Amazon VPC セキュリティグループですべてのアウトバウンドトラフィックが許可されます。

参考文献

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

Amazon VPC とは?

Amazon VPC とは?

定義した仮想ネットワーク内で AWS リソースを起動できます。

IPV6設定

1 つのパブリックサブネットを持つ VPC

スクリーンショット 2020-05-18 19.06.13.png

パブリックサブネットとプライベートサブネットを持つ VPC (NAT)

スクリーンショット 2020-05-18 22.13.51.png

パブリックサブネットとプライベートサブネット、および AWS Site-to-Site VPN アクセスを持つ VPC

スクリーンショット 2020-05-18 22.18.34.png

プライベートサブネットのみおよび AWS Site-to-Site VPN アクセスを持つ VPC

スクリーンショット 2020-05-18 22.19.38.png

Amazon VPC のネットワーク間トラフィックプライバシー

スクリーンショット 2020-05-18 22.26.49.png

NAT インスタンスと NAT ゲートウェイの比較

トラフィックをセキュリティグループで制御できないくらい

VPC ピア機能について

参考文献

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

Docker / ECR / ECS コンテナ入門まとめ 〜Docker編〜

参考文献

Docker 基本コマンド

イメージの取得

$ docker images [リポジトリ名]  ※リポジトリ名:DockerHubアカウントで作成

<例>
$ docker images username/sample

タグ設定

$ docker tag [イメージ名]:タグ名 ユーザ名/[イメージ名]:タグ名

<例>
$ docker tag testimage:1.0 username/testimage:1.0

DockerHubアップロード

$ docker login   ※DockerHubログイン

$ docker push ユーザ名/[イメージ名]:タグ名

<例>
$ docker push username/testimage:1.0

コンテナ作成/起動

$ docker run [オプション] イメージ名[:タグ名] [引数]

<例>
$ docker run -it --name "sample" testimage /bin/bash

稼働中のコンテナに接続

$ docker attach コンテナ名

<例>
$ docker attach sample   ※プロセス終了:ctrl + P,Q

AWS上でDockerを使用する場合

Dockerインストール

$ sudo yum update -y

$ sudo amazon-linux-extras install docker

Docker起動

$ sudo service docker start
         or
$ sudo systemctl start docker

dockerグループにユーザ追加

$ sudo usermod -a -G docker ec2-user

dockerアクセス確認

$ docker info

"No space left on device" エラー対処

ファイル数の消費量を表示

$ sudo find . -xdev -type f | cut -d "/" -f 2 | sort | uniq -c | sort -n

未使用のコンテナ/イメージ/ボリュームの一括削除

$ docker system prune -af --volumes
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWS SAA(SAA-C02) を2ヶ月ぐらいで取得したお話

2020年3月23日から受験が可能になったAWS 認定ソリューションアーキテクト – アソシエイトのバージョン2を3月〜5月頭まで週20時間ぐらい勉強して受験しました。

試験途中マジ半端ない腹痛に襲われましたが、なんとか合格できたので勉強したことや、受験の流れなんかをまとめておこうと思います。

経歴

  • 3年ほど前から開発業務、チーム全体の開発環境の整備(コンテナ化, CI/CD...etc)に従事
  • AWSサービスの業務での利用歴は1年くらい。といってもEC2, Lambda, ELB, S3, CloudFrontを時々触るぐらい
  • ネットワーク関係の知識はマスタリングTCP/IP 入門編を読んだくらい
  • AWS SAA-C01は未受験

受験の経緯

AWS.png
なんとな〜く雰囲気でAWS使ってるけど、ちゃんと体系的に理解したい。
あと半端ない数あるサービス達の概要ぐらい知っておいて、アーキテクチャ設計の中で「あのAWSサービスを使う」という選択肢を検討出来るようにしたかった。

その学習の一環としてSAAを取ろうという思い立った次第です。

学習内容

アウトライン

大きく分けて3つのことを順番にやりました。

1. 主要なAWSサービスについて概要レベルで理解
2. Udemy & Blackbelt
3. 模擬試験問題を解きまくる

主要なAWSサービスについて概要レベルで理解

学習期間:1ヶ月

まずはAWSマネジメントコンソールの

スクリーンショット 2020-05-16 11.16.53.png

をクリックした際に表示される全サービスについて自分の言葉でざっくり概要を説明できるようにしました。

【2020年5月版】AWSのサービスをゆるく大体3行で に学習した内容をまとめています。

...が、正直SAA合格だけを目指すならこの工程はやりすぎでした。
SAAの出題範囲に全く関係ないサービスもまとめていたので。。。

ただ概要レベルでもサービスを知っておくことで試験問題の選択肢にサービス名が含まれていた時に「この択は今問われていることと関係があるサービスか?」をすぐに判断できたのは良かったです。

後は「AWS全体でどんなことが簡単に出来るのか?」ということが理解できたのが、今後AWSを利用していく中で大きな収穫でした。

とりあえずSAAに合格したいんじゃい!という方は飛ばしていいです。(断言)

Udemy & Blackbelt

学習期間:3週間

これだけでOK! AWS 認定ソリューションアーキテクト – アソシエイト試験突破講座(SAA-C02試験対応版)

を3週間くらいで全レクチャーを完了しました。
レクチャーの中で登場したサービスをBlackbeltで追加で学習するということを行っていたため、そこそこ時間がかかりました。

レクチャーの内容はハンズオンが多く実際に構築するという工程を踏むことでより深く理解ができました。
...が、レクチャーの中では触れられない内容も出題されることがあるため、Blackbeltでの追加学習は行っておいたほうが間違いない気がします。

余談

Udemyは定期的にセールをやっていてセール時は最大90%OFFぐらいのお値段でレクチャーが購入できる時がありますので、その時に色々気になるやつを買うとよさそうです。

模擬試験問題を解きまくる

学習期間:1週間

受験日の1週間前から

【SAA-C02版】AWS 認定ソリューションアーキテクト アソシエイト模擬試験問題集(6回分390問)

を2週しました。

問題を解いて答え合わせ > 間違っていた場所を学習...のサイクルを繰り返してわからない点を潰していきました。

個人的な所感ですが実際のSAA試験と比較しても難易度が高い問題が多く、1週目はかなり間違えていて「やべぇよ...やべぇよ...絶対受かんねぇよ...」と震えてました。
ですが解説もついてくるため、間違った場所について解説を参考に学習をすることで理解が足りていなかった部分の穴埋めができたと思います。

個人的には本試験っぽい問題文に慣れるのも兼ねて、一番重要なフェーズだったと思います。
やってなかったら多分落ちてた。

受験の流れ

アウトライン

  • 受験の予約
  • 受験当日
  • 受験後

受験の予約

AWS Traning and Certificate ポータルサイトから申し込みをします。
住んでいる場所に近い受験会場を選択して、受験可能な日程から受験したい日を選択して予約します。

受験費は税抜15000円とお高いので、会社が負担してくれる方は遠慮なくお願いすることをオススメします。。。

予約後、予約完了メールが届きます。

予約完了メールに記載された性と名が、身分証明書(免許証やクレジットカード)と一致していないと受験ができないそうなので性名が逆になっていないか?
などはしっかりチェックした方が良さそうです。

受験当日

受付完了後、紙と鉛筆2本を渡されて受験用のPCまで案内されて試験スタート。
制限時間130分で65問の問題を解いていきます。
1000点満点の720点以上で合格らしいです。

腹痛がマジ半端なかったものの、50分くらい残して一通り解き終わりました。
その後見直しを30分ほどして、試験終了。

いくつかのアンケートに答えた後に合格と表示されました。
※ この時点ではスコアはわかりません

余談

もしかしたら私が受験した会場だけかもしれませんが、やたら横広のディスプレイに問題文が端から端に表示されるものでテキストを追っかけるのが大変でした。

そういった実際に受験してみないとわからないことがあるかもなので、気になる方は模擬試験(税抜2000円)を受験するといいかもです。

受験後

受験日より5営業日以内にAWS Traning and Certificate ポータルサイトにスコアレポートが登録されて、詳細なスコアが確認できるようになる...とのことですが、翌日には登録されていました。

スクリーンショット 2020-05-18 17.15.52.png
スコア822...普通だな!

SAA-C01からSAA-C02になって変わったこと

SAA-C01を受験していないため、私個人の体感などはお話できないのですが、SAA-C02は試験範囲の分野がSAA-C02から一つ減って出題分野の比重が変わっているようです。

SAA-C01 > SAA-C02の変更点をわかりやすく纏めてくださっている方の記事が参考になると思います。

まとめ

既に合格している知人から「覚えゲーだよ覚えゲー!」なんて言われて「そうかな...そうかも!」とその気になっていたお前の姿はお笑いだったぜ!

ネットワークなどのシステムを構築する上での基本的な知識がなかったら、2ヶ月で合格までは漕ぎ着けられなかった(確信)

(でも他の方の体験記を拝見すると、AWS未経験で1ヶ月で合格!とかインフラ未経験だけど2ヶ月で合格!というしゅごい方が沢山いて自分の学習能力の低さに笑ってる (泣いてる)

まだまだAWSの認定試験はありますし、3年後の更新時にわたわたしたくないので引き続き学習は継続していこうと思います。

スクリーンショット 2020-05-18 17.08.35.png

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

AWS認定 高度なネットワーキング - 専門知識に合格したので、実践した勉強方法を共有します

はじめに

AWS認定 高度なネットワーキング - 専門知識にスコア84%で合格しました。勉強期間は約1ヶ月でした。
(1度目は62%で不合格となり、2度目の受験で合格しました。)

私が実践した勉強方法を共有しますので、これから受験する方の参考になれば幸いです。

私とAWSとネットワーク

AWS歴は約4年です。インフラエンジニアとしてアサインされることが多いので、VPCはよく触っています。
ただし、DirectConnectとVPNの構築経験はほぼありません。

こんな感じの人が以下の勉強方法で約1ヶ月勉強したら合格できたと思ってください。

実践した勉強方法

私が実践した勉強方法を共有します。基本的に上から順番に実施していきました。

先駆者の方々のまとめ記事を見る

既に受験された方々のまとめ記事を見て、出題範囲のAWSサービスや問われる知識分野を把握しました。
私は以下の記事を参考にさせて頂きました。

BlackBeltを読む

出題範囲のAWSサービスが分かったら、対象サービスのBlackBeltを読んで、サービス概要をざっくり理解しました。

DirectConnect,VPNの概要を理解する

DirectConnect,VPNに関してはドキュメントの文字を読むだけだと中々イメージしずらいものでした。
以下の資料と記事は図が多めで全体像を理解するのに大変参考になりました。

サンプル問題を解く

サンプル問題を解きました。満点取るまで繰り返し解きました。

公式のStudy Guideで提供されている模擬問題を解く

高度なネットワーキング試験は公式の参考書が販売されています。こちらを電子版で購入しました。本を買うと問題が約300問提供されている専用サイトに登録することができます。解答の解説も付いており、大変参考になりました。英語ですが、Google翻訳を活用しました。こちらを繰り返し解きました。

ちなみに、本体の書籍の方はほぼ読んでいませんw
英語のままで勉強するのは精神的に辛いし、Kindleだと全てを一気に翻訳して読むことができず1ページずつ翻訳しながら読み込むのは時間がかかりすぎると判断しました。

非公式の問題集を解く

examtopics

無料で113問提供されています。こちらを繰り返し解きました。
解答が間違っているものもあるのですが、コメント欄でみんなが正解不正解を議論しているので、勉強する上で大変参考になります。

感想

DirectConnectとVPNに関する問題が全体の半分近くあったと思うので、重点的に学習することをおすすめします。
高度なネットワーキング試験は模擬試験とAWSトレーニングルームのeラーニングが提供されていなかったりと、学習教材を探すのが大変でした。
また、試験が開始されたのが若干古いため、以下のように解答が最新のベストプラクティスとなっていない問題がいくつかありました。

  • Route53リゾルバーを使うとオンプレミスとVPC間の名前解決が簡単にできるようになるが、問題だとEC2でプロキシリゾルバを構築してフォワードさせる解答となっている
  • トランジットゲートウェイを使うとオンプレミスとVPC間の通信を簡単に通信させることができるが、問題だとトランジットVPCにEC2でルーターを構築する解答となっている

今回の試験勉強を通して、今まで触ったことのないサービスの概要や特徴を多く知ることができました。学んだことが今後役立つ日がくれば良いなと思います。

※1度不合格となり、2回目の受験で合格したのですが、9割近くが同じ問題でした。他のAWS認定試験でも毎回同じ問題がでるものなんでしょうか?

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

コロナ自粛期間を利用してAWSソリューションアーキテクトアソシエイトを取得した話

試験を受けた背景

昨今のコロナ自粛の影響で完全リモートかつ土日も外に出れない状況に
なったので隙間時間に何か勉強したいというのが大きな動機になります。
その中で短期間で目に見えた結果がほしいと思い
兼ねてから気になっていた本試験に臨むことにしました。

勉強方法と勉強期間

勉強期間は約一ヶ月で最初は主にAWS各種サービスの概要と使い方と選択する優位性を網羅的に勉強しました。
その後は試験勉強でおなじみ過去問を繰り返し解くということを中心に行いました。
総仕上げとしてAWS公式のオンライン模擬試験を受けました。

参考にしたコンテンツ

徹底攻略 AWS認定 ソリューションアーキテクト – アソシエイト教科書 徹底攻略

言わずと知れたテッパン書籍の黒本をまずは一通り読破しました。
AWSをあまり知らない人がまず理解する本としてはとてもおすすめです。
ですがこの本だけでは合格は難しいと思います。

一夜漬け AWS認定 ソリューションアーキテクト アソシエイト 直前対策テキスト

こちらはより試験対策に特化したポイントをわかりやすく書いてある本です。
試験前の最終確認としてとても役に経ちました。

Udemy これだけでOK! AWS 認定ソリューションアーキテクト – アソシエイト試験突破講座

Udemyのこちらの試験対策教材は最強です。
各種主要サービスの概要、ハンズオン、模擬問題集を網羅して勉強することができます。
これを一通りやるだけで70%の確率で受かる気がしています。

Udemy AWS 認定ソリューションアーキテクト アソシエイト模擬試験問題集

さらに問題の傾向になれたい、合格確率を上げたいという人におすすめです。
この問題集の正解率が75%を超えている人はかなりの確率で受かると思います。
ただ問題の難易度はかなり高いので最初に受けると挫折するかもしれないので注意です。

問題の傾向

AWSの実務経験が少なくとも1年以上はある人前提の問題なので少なくとも
下記に関しては理解が必要だと思います。

  • グローバルサービス、リージョンサービス、AZサービスの違い
  • VPC、サブネット、セキュリティーグループ、AZなどの基本構成
  • EC2、Cloudfront、ELB、AutoScaling、CloudWatch、Route53、S3、RDSなどの基本サービスについて
  • IAMユーザー、グループ、ロール、Organizationsなどの認証について

システム構築では当たり前のデータベースやキャッシュについては確実出題されるかと思います。
またログ収集や分析についても多くはないですが出題されるかと思います。

  • RDSとAuroraの違いと選定するべき理由など
  • DynamoDBやElastiCacheなどの違いと選定理由など
  • Kinesis、Redshift、Athna、EMR、S3Selectなどの用途

適切なコスト算出が求められるのでストレージの用途や種別の理解は必要だと思います。
とくにS3について多く出題される傾向があると思います。

  • EBSの種別と違い
  • EFSを選択するシュチュエーション
  • S3の種別、ライフサイクルとGlacierについて

最近のモダンアーキテクチャとしてサーバレスやDockerコンテナについての
問題もいくつか出題される傾向にあると思います。
またマイクロサービスアーキテクチャが主流になっているため、
コンポーネント間を連携する仕組みについても問われるかと思います。

  • APIGateWay、lambdaなどのサーバレスについて
  • ECS、EKSなどのコンテナオーケストレーションツールについて
  • SQS、SNSなどのメッセージングサービスについて

クラウドファーストな時代ではありますが、まだまだオンプレミスは多くのこっているので、
AWSへの移行やオンプレとの接続方法についても少なからず問われるかと思います。

  • DirectConnectによる専用線について
  • StorageGatewayについて
  • Snowballによる移行について

この資格は実務に役立つかどうか

試験である以上合格対策があるため必ずしもこの資格を持っているイコールAWSでインフラを構築できるというわけではないと思います。
しかしながら最近のビジネスソリューションを構築する上では、
AWSを網羅して理解し最適なソリューションを選定する必要があるので一つの指標にはなるかと思います。特に私は最近ではアーキテクチャの設計や選定をすることが多いので勉強してみてかなり役に経ちました。
また限られた時間で文章を読み最適な解答を導き出すということが必要になるので、
ビジネススキルとしても勉強しておいて役にたつと思います。

まとめ

認定資格登竜門とはいえ勉強しなければ絶対に受からない資格かと思います。
かつ問題の構成がうまいのがやはり理解していないと解けない問題ばかりだと思います。
個人的にはコロナ自粛期間に何かしら目に見える結果を残したいと思い勉強してみましたが、
それが形になって素直に嬉しいです。
これをきっかけに次はプロフェッショナルをゆるゆると勉強しようとかなと考えてます。

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

コロナ自粛期間を利用してAWSソリューションアーキテクトアソシエートを取得した話

試験を受けた背景

昨今のコロナ自粛の影響で完全リモートかつ土日も外に出れない状況に
なったので隙間時間に何か勉強したいというのが大きな動機になります。
その中で短期間で目に見えた結果がほしいと思い
兼ねてから気になっていた本試験に臨ことにしました。

勉強方法と勉強期間

勉強期間は約一ヶ月で最初は主にAWS各種サービスの概要と使い方と選択する優位性を網羅的に勉強しました。
その後は試験勉強でおなじみ過去問を繰り返し解くということを中心に行いました。
総仕上げとしてAWS公式のオンライン模擬試験を受けました。

参考にしたコンテンツ

徹底攻略 AWS認定 ソリューションアーキテクト – アソシエイト教科書 徹底攻略

言わずと知れたテッパン書籍の黒本をまずは一通り読破しました。
AWSをあまり知らない人がまず理解する本としてはとてもおすすめです。
ですがこの本だけでは合格は難しいと思います。

一夜漬け AWS認定 ソリューションアーキテクト アソシエイト 直前対策テキスト

こちらはより試験対策に特化したポイントをわかりやすく書いてある本です。
試験前の最終確認としてとても役に経ちました。

Udemy これだけでOK! AWS 認定ソリューションアーキテクト – アソシエイト試験突破講座

Udemyのこちらの試験対策教材は最強です。
各種主要サービスの概要、ハンズオン、模擬問題集を網羅して勉強することができます。
これを一通りやるだけで70%の確率で受かる気がしています。

Udemy AWS 認定ソリューションアーキテクト アソシエイト模擬試験問題集

さらに問題の傾向になれたい、合格確率を上げたいという人におすすめです。
この問題集の正解率が75%を超えている人はかなりの確率で受かると思います。
ただ問題の難易度はかなり高いので最初に受けると挫折するかもしれないので注意です。

問題の傾向

AWSの実務経験が少なくとも1年以上はある人前提の問題なので少なくとも
下記に関しては理解が必要だと思います。

  • グローバルサービス、リージョンサービス、サブネットサービスの違い
  • VPC、サブネット、セキュリティーグループ、AZなどの基本構成
  • EC2、Cloudfront、ELB、Route53、S3、RDSなどの基本サービスについて
  • IAMユーザー、グループ、ロールなどの認証について

システム構築では当たり前のデータベースやキャッシュについては確実出題されるかと思います。
またログ収集や分析についても多くはないですが出題されるかと思います。

  • RDSとAuroraの違いと選定するべき理由など
  • DynamoDBやRedshiftやElastiCacheなどの違いと選定理由など
  • KinesisやAthna、EMR、S3Selectなどの用途

適切なコスト算出が求められるのでストレージの用途や種別の理解は必要だと思います。
とくにS3について多く出題される傾向があると思います。

  • EBSの種別と違い
  • EFSを選択するシュチュエーション
  • S3の種別、ライフサイクルとGlacierについて

最近のモダンアーキテクチャとしてサーバレスやDockerコンテナについての
問題もいくつか出題される傾向にあると思います。
またマイクロサービスアーキテクチャが主流になっているため、
コンポーネント間を連携する仕組みについても問われるかと思います。

  • APIGateWay、lambdaなどのサーバレスについて
  • ECS、EKSなどのコンテナオーケストレーションツールについて
  • SQS、SNSなどのメッセージングサービスについて

クラウドファースの時代ではありますが、まだまだオプレミスは多くのこっているので、
AWSへの移行やオンプレとの接続方法についても少なからず問われるかと思います。

  • DirectConnectによる専用線について
  • StorageGatewayについて
  • Snowballによる移行について

この資格は実務に役立つかどうか

試験である以上合格対策があるため必ずしもこの試験を持っているイコールAWSでインフラを構築できるというわけではないと思います。
しかしながら最近のビジネスソリューションを構築する上では、
AWSを網羅して理解し最適なソリューションを選定する必要があるので一つの指標にはなるかと思います。特に私は最近でアーキテクチャの設計や選定をすること多いので勉強する上でかなり役に経ちました。
また限られた時間で文章を読み最適な解答を導き出すということが必要になるので、
ビジネススキルとしても勉強しておいて役にたつと思います。

まとめ

コロナ自粛期間に何かしら目に見える結果を残したいと思い勉強してみましたが、
それが形になって素直に嬉しいです。
これをきっかけに次はプロフェッショナルをゆるゆると勉強しようとかなと考えてます。

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

AWS Storage Gateway とは

AWS Storage Gateway とは

AWS Storage Gateway は、オンプレミスのソフトウェアアプライアンスをクラウドベースのストレージと接続し、お客様のオンプレミスの IT 環境と AWS のストレージインフラストラクチャとの間にデータセキュリティ機能を備えたシームレスな統合を実現するサービスです。このサービスを使用すると、AWS クラウドにデータを保存し、データのセキュリティを維持するために役立つ、スケーラブルで費用効率が高いストレージを利用できます。

ファイルゲートウェイ

  • NFS バージョン 3 または 4.1 プロトコルを使用して、ファイルを直接保存し取得
  • SMB ファイルシステムのバージョン 2 および 3 のプロトコルを使用してファイルを直接保存および取得
  • AWS クラウドアプリケーションまたはサービスから Amazon S3 のデータに直接アクセス
  • ライフサイクルポリシー、クロスリージョンレプリケーション、およびバージョニングを使用して Amazon S3 のデータを管理できます。ファイルゲートウェイ を S3 上のファイルシステムマウントとして考えることができます。

サービス統合

  • AWS Identity and Access Management (IAM) を使用した一般的なアクセス管理
  • AWS Key Management Service (AWS KMS) を使用した暗号化
  • Amazon CloudWatch (CloudWatch) を使用したモニタリング
  • AWS CloudTrail (CloudTrail) を使用した監査
  • AWS マネジメントコンソール と AWS Command Line Interface (AWS CLI) を使用したオペレーション
  • 請求情報とコスト管理

スクリーンショット 2020-05-18 18.35.58.png

ボリュームゲートウェイ

ボリュームゲートウェイは、オンプレミスのアプリケーションサーバーから iSCSI (Internet Small Computer System Interface) デバイスとしてマウントできる、クラウドベースのストレージボリュームを提供

キャッシュボリューム

データを Amazon Simple Storage Service (Amazon S3) に保存し、頻繁にアクセスするデータサブセットのコピーをローカルに保持します。プライマリストレージのコストを大幅に削減し、ストレージをオンプレミスで拡張する必要を最小限に抑えます。また、頻繁にアクセスするデータへのアクセスを低レイテンシーに保つことができます。

スクリーンショット 2020-05-18 18.39.51.png

ゲートウェイがキャッシュストレージとして使用するディスク

アプリケーションがデータを AWS のストレージボリュームに書き込むとき、ゲートウェイは最初にデータをキャッシュストレージに使用されるオンプレミスのディスクに保存します。次に、ゲートウェイはデータを Amazon S3 にアップロードします。キャッシュストレージは、オンプレミスで耐久性の高い保存場所として、アップロードバッファから Amazon S3 へのアップロードを保留中のデータを保存する働きをします。

ゲートウェイがアップロードバッファとして使用するディスク

ゲートウェイは、受け取ったデータを Amazon S3 にアップロードする前に、アップロードバッファと呼ばれる待機領域にいったん保存します。 ゲートウェイはこのバッファからデータを暗号化 Secure Sockets Layer (SSL) 接続で AWS にアップロードし、そこでデータは暗号化されて Amazon S3 に保存されます。

データのバックアップを復元する

Amazon EBS スナップショットをゲートウェイストレージボリュームに復元できます。また、16 TiB までのスナップショットの場合、新しい Amazon EBS ボリュームの場合は、開始点としてスナップショットを使用できます。この新しい Amazon EBS ボリュームを Amazon EC2 インスタンスにアタッチできます。

キャッシュボリューム用のすべてのゲートウェイデータとスナップショットデータは、Amazon S3 に保存され、サーバー側の暗号化 (SSE) 機能を使用して保管時に暗号化されます。

保管型ボリューム

データセット全体への低レイテンシーアクセスが必要な設定は、最初にすべてのデータをローカルに保存するようにオンプレミスのゲートウェイを設定します。次に、このデータのポイントインタイムスナップショットを非同期的に Amazon S3 にバックアップします。この設定は、ローカルデータセンターや Amazon Elastic Compute Cloud (Amazon EC2) に復元できる、耐久性が高く低コストのオフサイトバックアップを提供します。たとえば、障害復旧のための代替容量が必要な場合は、Amazon EC2 にバックアップを復元できます。

スクリーンショット 2020-05-18 18.45.02.png

データのバックアップを復元する

Amazon EBS スナップショットをオンプレミスのゲートウェイストレージボリュームに復元できます。このスナップショットから新たに Amazon EBS ボリュームを作成し、それを Amazon EC2 インスタンスにアタッチすることもできます。

テープゲートウェイ

テープゲートウェイは、クラウドベースの仮想テープストレージを提供します。テープゲートウェイは、VMware ESXi、KVM、または Microsoft Hyper-V ハイパーバイザーで実行される VM としてオンプレミス環境にデプロイ

テープゲートウェイを使用すると、バックアップデータをコスト効果や耐久性の高い方法で GLACIER または DEEP_ARCHIVE にアーカイブできます。テープゲートウェイは仮想テープインフラストラクチャとして、お客様事業での需要に応じシームレスにスケーリングができ、物理テープインフラストラクチャのプロビジョニング、スケーリング、保守といった運用の負担を解消

オンプレミスで VM アプライアンスとして、ハードウェアアプライアンスとして、または AWS で Amazon EC2 インスタンスとして実行できます。EC2 インスタンスにゲートウェイをデプロイして、AWS の iSCSI ストレージボリュームをプロビジョニング

スクリーンショット 2020-05-18 18.47.15.png

アーカイブ

アーカイブは現実でいえばオフサイトのテープ保管施設にあたります。ゲートウェイ VTL からアーカイブに仮想テープをアーカイブできます。必要に応じて、アーカイブからゲートウェイ VTL にテープを取得

テープのアーカイブ

VTS は S3 Glacier または S3 GlacierDeep Archive (データのアーカイブ、バックアップ、長期データ保持のための低コストのストレージサービス) によってサポートされます。

テープの取り出し

アーカイブされたテープは、直接読み取ることができません。アーカイブされたテープを読み取るには、まず、Storage Gateway コンソールまたは Storage Gateway API を使用して、テープゲートウェイ に取り出す必要があります。

テープを GLACIER にアーカイブした場合、通常 3 〜 5 時間以内に取り出すことができます。テープを DEEP_ARCHIVE にアーカイブした場合、通常 12 時間以内に取り出すことができます。

Storage Gateway のモニタリング

AWS Storage Gateway は Amazon CloudWatch メトリクスを追加料金なしで提供します。Storage Gateway メトリクスは 2 週間の間、記録されます。これらのメトリクスを使用することにより、履歴情報にアクセスして、ゲートウェイとボリュームのパフォーマンスをより的確に把握できます。

参考文献

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

[メモ] AWS SAMのsam local start-apiでcode 400, message Bad ~と出る時は

事象

sam local start-apicode 400, message Bad request version とか code 400, message Bad HTTP/0.9 request type と表示されて文字化けしたメッセージが出てエラーになる。

対応

HTTPSでリクエストしていないか確認すること。
sam local start-api した場合 http でリクエストの受付が開始されるが、そこに https でリクエストするとこうなる。

なおDevツール等でよく見ると net::ERR_SSL_PROTOCOL_ERROR と出ている。

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

AWS Direct Connect とは

AWS Direct Connect とは

AWS Direct Connect は、お客様の内部ネットワークを AWS Direct Connect ロケーションに、標準のイーサネット光ファイバケーブルを介して接続するサービスです。ケーブルの一端がお客様のルーターに、他方が AWS Direct Connect のルーターに接続されます。この接続を使用すると、パブリックな AWS のサービス (Amazon S3 など) または Amazon VPC への仮想インターフェイスを直接作成できるため、お客様のネットワークパスの中でインターネットサービスプロバイダーをバイパスできるようになります。AWS Direct Connect ロケーションとは、対応するリージョンでの AWS へのアクセスの中継地となるものです。パブリックリージョン または AWS GovCloud (US) の単一の接続を使用して、他のすべてのパブリックリージョンのパブリック AWS のサービスにアクセスすることができます。

スクリーンショット 2020-05-18 18.06.25.png

Link Aggregation Group (LAG)

Link Aggregation Group (LAG) は、Link Aggregation Control Protocol (LACP) を使用して、1 つの AWS Direct Connect エンドポイントに複数の接続を集約し、それらを 1 つのマネージド型接続として扱うことを可能にする論理インターフェイスです。

次の図では、各ロケーションに 2 つずつ、合計 4 つの接続があります。同じ場所を終端とする接続の LAG を作成すれば、4 つの接続ではなく 2 つの LAG を使って設定と管理を行うことができます。

スクリーンショット 2020-05-18 18.11.41.png

Direct Connect ゲートウェイ

同一リージョン内に複数の VPC がある場合は トランジットゲートウェイ

仮想プライベートゲートウェイ

仮想プライベートゲートウェイの関連付け

次の図では、Direct Connect ゲートウェイによって、米国東部(バージニア北部) リージョンの AWS Direct Connect 接続を使用し、米国東部(バージニア北部) と 米国西部 (北カリフォルニア) の両方のリージョンでご自身のアカウントの VPC にアクセスできます。

スクリーンショット 2020-05-18 18.14.08.png
/qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/321923/6d5a75e4-c86c-168f-38b2-751797f589b3.png">

アカウント間の仮想プライベートゲートウェイの関連付け

Direct Connect ゲートウェイを所有している Direct Connect 所有者 (アカウント Z) のシナリオを考えてみます。アカウント A とアカウント B は Direct Connect ゲートウェイの使用を希望しています。アカウント A とアカウント B はそれぞれ、関連付け提案をアカウント Z に送信します。アカウント Z はこの関連付け提案を承諾し、必要に応じて、アカウント A の仮想プライベートゲートウェイまたはアカウント B の仮想プライベートゲートウェイから許可されるプレフィックスを更新します。アカウント Z が提案を承諾すると、アカウント A とアカウント B はそれぞれの仮想プライベートゲートウェイから Direct Connect ゲートウェイにトラフィックをルートできるようになります。また、アカウント Z はゲートウェイを所有しているため、顧客へのルーティングを所有します。

スクリーンショット 2020-05-18 18.16.08.png

アカウント間のトランジットゲートウェイの関連付け

Direct Connect ゲートウェイを所有している Direct Connect 所有者 (アカウント Z) のシナリオを考えてみます。アカウント A が トランジットゲートウェイ を所有していて、Direct Connect ゲートウェイを使用したいと考えています。アカウント Z は関連付け提案を受け入れ、オプションで、アカウント A の トランジットゲートウェイ から許可されるプレフィックスを更新できます。アカウント Z が提案を受け入れた後で、トランジットゲートウェイ にアタッチされた VPC は、トランジットゲートウェイ から Direct Connect ゲートウェイにトラフィックをルーティングできます。また、アカウント Z はゲートウェイを所有しているため、顧客へのルーティングを所有します。

スクリーンショット 2020-05-18 18.17.47.png

参考文献

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

Site-to-Site VPN

Site-to-Site VPN

VPN 接続は VPC とお客様独自のオンプレミスのネットワーク間の接続を指します。Site-to-Site VPN は、インターネットプロトコルセキュリティ (IPsec) VPN 接続をサポートしています。

概念

  • VPN 接続: オンプレミス機器と VPC 間の安全な接続
    • 高可用性のために同時に使用できる 2 つの VPN トンネルが含まれています。
  • VPN トンネル: お客様のネットワークと AWS の間でデータを送受信できる暗号化されたリンク。
  • カスタマーゲートウェイ: カスタマーゲートウェイデバイスに関する情報を AWS に提供する AWS リソース。
  • カスタマーゲートウェイデバイス: Site-to-Site VPN 接続のユーザー側にある物理的なデバイスまたはソフトウェアアプリケーション。

AWS Site-to-Site VPN の仕組み

Site-to-Site VPN 接続は、仮想プライベートゲートウェイまたは AWS 側の トランジットゲートウェイ と、リモート (オンプレミス) 側のカスタマーゲートウェイの間に 2 つの VPN トンネルを提供します。

  • 仮想プライベートゲートウェイ スクリーンショット 2020-05-18 17.37.09.png

仮想プライベートゲートウェイを作成するとき、Amazon 側のゲートウェイのプライベート自律システム番号 (ASN) 指定できます。ASN を指定しない場合、仮想プライベートゲートウェイはデフォルトの ASN (64512) で作成されます。仮想プライベートゲートウェイの作成後に ASN を変更することはできません。

  • トランジットゲートウェイ スクリーンショット 2020-05-18 17.38.25.png

トランジットゲートウェイ は仮想プライベートクラウド (VPC) とオンプレミスのネットワークの相互接続に使用できる中継ハブです。

ルートテーブルと VPN ルーティングの優先度

Site-to-Site VPN 接続または AWS Direct Connect 接続から伝播されるルートが VPC のローカルルートと重複する場合は、伝播されたルートがより詳細であっても、ローカルルートが最優先されます。

Site-to-Site VPN 接続または AWS Direct Connect 接続から伝播されるルートと他の既存静的ルート (プレフィックスの最長一致は適用できません) が同じ宛先 CIDR ブロックの場合は、ターゲットがインターネットゲートウェイ、仮想プライベートゲートウェイ、ネットワークインターフェイス、インスタンス ID、VPC ピアリング接続、NAT ゲートウェイ、トランジットゲートウェイ、またはゲートウェイ VPC エンドポイントの静的ルートが優先されます。

Site-to-Site VPN アーキテクチャ

  • 単一の Site-to-Site VPN 接続

スクリーンショット 2020-05-18 17.54.20.png

  • トランジットゲートウェイを持つ単一の Site-to-Site VPN 接続

スクリーンショット 2020-05-18 17.54.37.png

  • 複数の Site-to-Site VPN 接続 スクリーンショット 2020-05-18 17.54.55.png

VPN CloudHub を使用して安全なサイト間通信を提供する

スクリーンショット 2020-05-18 17.56.39.png

冗長な Site-to-Site VPN 接続を使用してフェイルオーバーを提供する

カスタマーゲートウェイデバイスが使用できなくなった場合に接続が失われるのを防ぐために、2 番目のカスタマーゲートウェイデバイスを使用して、VPC および仮想プライベートゲートウェイへの 2 番目の Site-to-Site VPN 接続を設定できます。冗長な Site-to-Site VPN 接続とカスタマーゲートウェイデバイスを使用すれば、1 つのデバイスでメンテナンスを実行しながら、2 番目のカスタマーゲートウェイの Site-to-Site VPN 接続を通してトラフィックの送信を継続することができます。

スクリーンショット 2020-05-18 17.57.50.png

Amazon CloudWatch を使用した VPN トンネルのモニタリング

CloudWatch を使用して VPN トンネルをモニタリングすることで、VPN サービスから未加工データを収集し、リアルタイムに近い読み取り可能なメトリクスに加工することができます。これらの統計は 15 か月間記録されるため、履歴情報にアクセスしてウェブアプリケーションやサービスの動作をより的確に把握できます。VPN メトリクスデータは、利用可能になると自動的に CloudWatch に送信されます。

参考文献

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

EC2インスタンスをコピーする方法

コピー元インスタンスのAMIをつくってそこからインスタンスを作成することで、インスタンスのコピーを作れる

Amazon マシンイメージ (AMI) は、ソフトウェア構成 (オペレーティングシステム、アプリケーションサーバー、アプリケーションなど) を記録したテンプレートです。
インスタンスと AMI - Amazon Elastic Compute Cloud

EC2インスタンスの画面を表示する

  1. AWSのコンソールにログイン > [EC2]

イメージを作成する

  1. サイドメニューの[インスタンス] > コピー元のインスタンスを選択
  2. [アクション] > [イメージ] > [イメージの作成]でダイアログを表示する
  3. [イメージ名]に何のイメージかわかるような値を設定する
    • [再起動しない]チェックボックス : コピー元インスタンスを再起動しないでイメージを作成したい場合はチェックを入れる
    • [終了時に削除]チェックボックス : コピーしたインスタンスを終了した時にボリュームを削除する場合はチェックを入れる
  4. [イメージの作成]ボタンでイメージを作成 > [閉じる]ボタンでダイアログを閉じる
  5. サイドメニューの[AMI] > 一覧に作成したイメージが表示される
  6. [ステータス]カラムが「pending」から「available」に変わったら出来上がり

コピー元のインスタンス情報を表示する

インスタンス作成時に参照できるように以降のインスタンス作成とは別画面でコピー元のインスタンス情報を表示しておく。

  1. 別画面でインスタンスの一覧を表示する
  2. コピー元のインスタンスを選択して、画面下部に詳細情報を表示しておく

インスタンスを作成する

  1. サイドメニューの[AMI] > 作成したAMIを選択
  2. [起動]ボタンでインスタンス作成画面を表示する
  3. コピー元の情報を参照しながら設定をする
    1. コピー元のインスタンスは作成画面で設定してくれないので別画面で表示しておいたコピー元のインスタンス情報を見ながら設定していく
    2. [ステップ 2: インスタンスタイプの選択]
    3. [ステップ 3: インスタンスの詳細の設定]
    4. [ステップ 4: ストレージの追加]
      • ボリュームの情報 : コピー元インスタンス情報 > [設定]タブ > [ルートデバイス]リンク > ポップアップの[EBS ID]リンクからみられる
  4. [起動]ボタンでSSH鍵情報のダイアログを表示する
  5. 接続用の鍵をどうするか選択する
    • image.png
  6. [インスタンスの作成]ボタンでインスタンスを作成 > [インスタンスの表示]ボタンでインスタンスの一覧に戻る
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWS Single Sign-On とは

AWS Single Sign-On とは

AWS Single Sign-On は、AWS アカウントおよびクラウドアプリケーションへの SSO アクセスの一元管理を容易にするクラウドベースのシングルサインオン (SSO) サービスです。特に、AWS Organizations 内のすべての AWS アカウントを対象に SSO アクセスとユーザーアクセス許可を管理するうえで役立ちます。AWS SSO はまた、一般的に使用されているサードパーティー SaaS (Software-as-a-Service) や Security Assertion Markup Language (SAML) 2.0 をサポートするカスタムアプリケーションに対するアクセスとアクセス許可を管理するのにも便利です。AWS SSO には、エンドユーザーが自分に割り当てられている AWS アカウント、クラウドアプリケーション、カスタムアプリケーションを一元的に検索したり確認したりできるユーザーポータルが含まれます。

らしいです。SAMLを使ったSSOには必須でしょう。

AWS Single Sign-On(SSO)でAWSアカウントへシングルサインオン

http://blog.serverworks.co.jp/tech/2020/03/06/sso/

AWS Orgnizationにて全ての機能の有効化が必須

参考文献

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

s3 sync コマンドを使ってS3バケット間を同期する

AWS CLI にはS3 のファイルコマンドが用意されています。ありがたい!
s3 sync コマンドを使ってS3バケット間を同期するコマンドをご紹介します。

やりたいこと

  • テスト用バケットのオブジェクトを本番用バケットにすべて同期したい
  • テスト用バケットに存在せず、本番用バケットに存在するオブジェクトは削除したい

aws-s3copy.png

AWS CLI ってなに

AWS CLI = AWS Command Line Interface
コマンドを使ってAWSサービスと対話できるオープンソースツールです。

もっとくわしく知りたい方には、AWS CLI のBlackBelt がおすすめです。

利用可能なOS

  • Windows
  • Mac
  • Linux
  • Amazon Linux ※

※ EC2インスタンス作成時に Amazon Linux のAMI を選択すれば、
 あらかじめプレインストールされています

CLI はこちらからインストールできます。

AWS CLI を使うと何がうれしいのか

AWSコンソールから画面をポチポチやる作業をコマンド一発で自動化できたら楽ですよね。そういうことや!

sync コマンド

aws s3 sync s3://[同期元のバケット名] s3://[同期先のバケット名]

※ 指定するのはバケット名です。
 私は最初誤ってARN(リソース名)を指定してしまい、ちょっと時間をロスしました。。

▼ 今回使ったコマンド

aws s3 sync s3://[同期元のバケット名] s3://[同期先のバケット名] --exact-timestamps --delete

今回使ったオプションの詳細については以下の通りです。

オプション 詳細
--exact-timestamps S3からローカルに同期するとき、同じサイズのアイテムは、タイムスタンプが正確に一致したときだけ無視されます。デフォルトの動作は、ローカルのバージョンがS3のバージョンよりも新しいものでない限り、同じサイズのアイテムを無視します。
--delete コピー先には存在するが、コピー元には存在しないファイルは同期中に削除されます。

sync をdryrun したいとき

aws s3 sync s3://[同期元のバケット名] s3://[同期先のバケット名] --dryrun
オプション 詳細
--dryrun 指定したコマンドを実際に実行せずに、指定したコマンドを使って実行されるであろう操作を表示します。

オプションの詳細はリファレンスをDeepLで翻訳して載せました。
他にもさまざまなオプションがあるので、一読してみるといいかもです!

参考

AWS コマンドラインインターフェイス(CLI: AWSサービスを管理する統合ツール)| AWS
S3 sync で s3からファイルを同期させる時の注意点 | Developers.IO
sync — AWS CLI 1.18.61 Command Reference

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

AWS認定 データ分析 - 専門知識に合格したので、実践した勉強方法を共有します

はじめに

AWS認定 データ分析 - 専門知識にスコア776点で合格しました。勉強期間は約3週間でした。

私が実践した勉強方法を共有しますので、これから受験する方の参考になれば幸いです。

私とAWSとデータ分析

AWS歴は約4年です。業務でデータ分析を扱ったことはありません。
元々のデータ分析に関する知識もほぼ皆無でした。絞り出すとしたら、以下くらいです。

  • Redshift,Glue,EMRという名のサービスがデータ分析で使われているらしい
  • DWHは列指向のデータベースらしい

こんな感じの人が以下の勉強方法で約3週間勉強したら合格できたと思ってください。

実践した勉強方法

私が実践した勉強方法を共有します。基本的に上から順番に実施していきました。

先駆者の方々のまとめ記事を見る

既に受験された方々のまとめ記事を見て、出題範囲のAWSサービスや問われる知識分野を把握しました。
私は以下の記事を参考にさせて頂きました。

BlackBeltを読む

出題範囲のAWSサービスが分かったら、対象サービスのBlackBeltを読んで、サービス概要をざっくり理解しました。

AWSトレーニングルーム(eラーニング)を受講する

Exam Readiness: AWS Certified Data Analytics - Specialtyを受講しました。
講義内でサンプル問題を解くことができるので、満点を取るまで繰り返し解きました。
英語表記のトレーニングなので、Google翻訳を活用しました。

サンプル問題を解く

サンプル問題を解きました。満点取るまで繰り返し解きました。

公式の模擬試験を受験する

公式の模擬試験を受験しました。正答率は75%(20問中15問正解)でした。
終わった後も繰り返し解けるように、問題文と選択肢の画面を試験時間中にスクショしておきました。
公式の模擬試験は各問の回答が分かりません。なので、公式ドキュメント等の記事を調べて、自分で答えを見つける必要があります。
本当に合っている答えかは分かりませんが、満点が取れるまで繰り返し解きました。

非公式の問題集を解く

Udemy

以下2つの講座をセール期間中を狙って、どちらも¥1500くらいで購入しました。ただし、どちらも内容が微妙だったのでキャンセルしています。

  • AWS Certified Data Analytics Specialty 2020 (ex Big Data)
    • ビデオ講義,ハンズオン,演習問題が付いている講座です。 講義についてはAWSトレーニングルームで十分の内容を学習できていたので、演習問題目当てで購入しました。しかし、問題内容が簡単すぎて参考にならないと判断し、キャンセルしました。
  • AWS Certified Data Analytics Specialty Practice Tests
    • 演習問題オンリーの講座です。解答は付いていますが、解説はありません。解答が明らかに間違っていたり、問題文に出題されるサービスが古かったりと参考にならないと判断し、キャンセルしました。

examtopics

参考になりそうな問題を探して、ネットをさまよっていたら、examtopicsというサイトに流れ着きました。
ビッグデータ専門知識に関する問題集で内容が少し古いですが、無料で85問提供されています。こちらを繰り返し解きました。
解答が間違っているものもあるのですが、コメント欄でみんなが正解不正解を議論しているので、勉強する上で大変参考になります。

感想

データ分析に関する知識がほぼゼロの状態だったので、勉強には苦労しました。AWSトレーニングルームの講義が非常に分かりやすくまとまっているため、大変参考になりました。今回の試験勉強を通して、今まで触ったことのないサービスの概要や特徴を多く知ることができました。学んだことが今後役立つ日がくれば良いなと思います。

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

AWS Directory Service とは

AWS Directory Service とは

AWS Directory Service では、Amazon Cloud Directory および Microsoft Active Directory (AD) を他の AWS サービスと併用するための複数の方法を提供します。ディレクトリはユーザー、グループ、デバイスに関する情報を保存します。管理者は、これらのディレクトリを通じて情報やリソースへのアクセスを管理します。AWS Directory Service は、既存の Microsoft AD やライトウェイトディレクトリアクセスプロトコル (LDAP) –対応のアプリケーションをクラウド上で使用するユーザー向けに複数のディレクトリオプションを提供します。また、開発者がディレクトリを通じてユーザー、グループ、デバイス、およびアクセスを管理する場合にも、同じオプションを提供します。

ディレクトリオプションの選択

  • SaaS アプリケーションを開発する

    • 高スケールの SaaS アプリケーションを開発する場合、受信者を管理および認証するために、ソーシャルメディア ID に対応するスケーラブルなディレクトリが必要なときは、Amazon Cognito を使用
  • 複雑な関係を持つ階層データを管理するクラウドアプリケーションを開発する

    • アプリケーション間での階層データの共有やアクセス管理にクラウドスケールのディレクトリが必要な場合は、Amazon Cloud Directory を使用します。
  • クラウド内のアプリケーションに Active Directory または LDAP が必要である

    • Active Directory– 対応のワークロードや AWS のアプリケーションとサービス (Amazon WorkSpaces、Amazon QuickSight など) をサポートする実際の Microsoft Active Directory が AWS クラウドで必要な場合、または Linux アプリケーション用に LDAP サポートが必要な場合
      • AWS Directory Service for Microsoft Active Directory
    • オンプレミスのユーザーが Active Directory 認証情報で AWS アプリケーションやサービスにログインすることを許可する
      • AD Connecter
    • Samba 4 互換アプリケーションをサポートする基本的な Active Directory 互換性を持つ低スケール、低コストのディレクトリが必要な場合、または LDAP 対応アプリケーションの LDAP 互換性が必要な場合
      • SimpleAD

AWS Managed Microsoft AD のユースケース

スクリーンショット 2020-05-18 15.54.53.png

ユースケース 1: AD 認証情報で AWS アプリケーションとサービスにサインインする

ユーザーが AWS マネジメントコンソール に AD 認証情報でサインインできるようにすることが可能です。そのためには、ディレクトリ内のアプリケーションとして AWS マネジメントコンソール を有効にしてから、AD ユーザーとグループを IAM ロールに割り当てます。ユーザーが AWS マネジメントコンソール にサインインすると、AWS リソースを管理するための IAM ロールが割り当てられます。

ユースケース 2: Amazon EC2 インスタンスを管理する

使い慣れた AD 管理ツールを使用し、インスタンスを AWS Managed Microsoft AD ドメインに結合して、AD グループポリシーオブジェクト (group policy objects、GPO) を適用して Amazon EC2 for Windows または Linux インスタンスを一元管理できます。

また、ユーザーはインスタンスに AD 認証情報でサインインできます。これにより、個別のインスタンス認証情報を使用したり、プライベートキー (PEM) ファイルを配布したりする必要がなくなります。その結果、使い慣れた AD ユーザー管理ツールで、ユーザーに対してアクセスをすばやく許可または取り消すことができます。

ユースケース 3: AD 対応ワークロードにディレクトリサービスを提供する

従来の AD 対応ワークロード (リモートデスクトップライセンスマネージャや Microsoft SharePoint and Microsoft SQL Server Always On など) を AWS クラウド上で使用できるようにする

ユースケース 4: Office 365 およびその他のクラウドアプリケーションに SSO する

AWS Managed Microsoft AD を使用して、クラウドアプリケーションへの SSO を有効にすることができます。Azure AD Connect を使用してユーザーを Azure AD に同期させた後、Active Directory フェデレーションサービス (AD FS) を使用して、Microsoft Office 365 およびその他の SAML 2.0 クラウドアプリケーションにユーザーが AD 認証情報でアクセスできるようにすることが可能

ユースケース 5: オンプレミス AD を AWS クラウドに拡張する

ユーザーは既存の AD ユーザー名とパスワードを使用して、AWS マネジメントコンソール と Amazon WorkSpaces にサインインできます。また、AWS Managed Microsoft AD で SharePoint などの AD 対応アプリケーションを使用すると、ログインした Windows ユーザーは認証情報を再入力せずにこれらのアプリケーションにアクセスできます。

ユースケース 6: ディレクトリを共有して、AWS アカウント間でシームレスに Amazon EC2 インスタンスをドメインに結合する

複数の AWS アカウント間でディレクトリを共有すると、各アカウントや各 VPC で直接作業する必要なく、Amazon EC2 などの AWS サービスを管理することができます。1 つの AWS リージョン内の任意の AWS アカウントおよび任意の Amazon VPC からディレクトリを使用することができます。この機能によって、複数のアカウントと VPC 間で単一のディレクトリのディレクトリ対応型ワークロードを簡単で優れたコスト効果で管理することができます。たとえば、EC2 インスタンスにデプロイした Windows ワークロードを単一の AWS Managed Microsoft AD ディレクトリを使用して複数のアカウントと VPC 間で簡単に管理することができるようになります。

Active Directory Connector

AD Connector は、クラウドの情報をキャッシュせずにディレクトリリクエストをオンプレミスの Microsoft Active Directory へリダイレクトするのに使用するディレクトリゲートウェイ

AD Connector には、スモールとラージの 2 つのサイズがあります。

Active Directory Connector(AD Connector)を試してみた

https://dev.classmethod.jp/articles/try-active-directory-connector/

Simple Active Directory

スモールとラージの 2 つのサイズがあります。

Windowsを一切使わずDirectory ServiceのSimple ADを使ってLinuxユーザーを一元管理する

https://dev.classmethod.jp/articles/linux-simplead-management/

参考文献

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

AWS Certified Security Specialty 合格記録

この記事

AWS Certified Security Specialty を取得したので
どんな学習をしたかを記録します。

about me

インフラエンジニアで、AWS関連のインフラ構築や保守を3年くらい経験しています。

この分野については、業務ではIAMポリシーを作成したり
直近ではCloudFormationを使っていてS3の権限調整したりしていました。

AWS資格は

Solution Architect Associate (7月)
SysOps Administrator Associate (9月)
Solution Architect Professional (11月)
Developer Associate (12月)
DevOps Engineer Professional (3月)
Security Specialty(5月)

という順で取得しました。

Specialtyの資格は初でしたが、Security分野はIAMで悩むことがあった点や、
どんな場合でも必要なので、最優先で学習してみました。

about SCS試験

AWS 認定セキュリティ – 専門知識
https://aws.amazon.com/jp/certification/certified-security-specialty/

試験対策でやったこと

試験ガイドとサンプル問題

「試験ガイドとサンプル問題」はまず目を通します。
https://aws.amazon.com/jp/certification/certification-prep/

模擬試験(公式)

一番はじめに、どんなもんか解いてみます。
模擬試験結果は50%くらいでした。
もしこの時点で全くわからなくてしんどかったら、先にProfessionalを取るべきだと思います。
2つのProfessional資格の学習は、この試験にかなり有効でした。

whizlabs

模擬試験コースがあるので、こちらをメインに取り組みます。
https://www.whizlabs.com/aws-certified-security-specialty/

わからないことがはじめは多いですが、どんどん解いて、AWSドキュメントで覚えていきます。
例えばCMKの話があって1つのAWSドキュメントを読むと、そのドキュメントの知識で他の模擬試験の問題も数問解けたりするイメージなので、意外とモチベーション保てました。

どうしてもイメージが掴めないものは、AWSで検証します。
セキュリティ分野は、暗号化する、復号化するという具体的な作業だけで実践できてしまうので
DevOps等の構築を行う検証に比べて大変ではないと感じました。

udemy

時間と体力の関係で途中まででしたが、こちらも活用しました。
https://www.udemy.com/course/aws-certified-security-specialty-practice-tests/

全体的に学んだサービス

ドキュメントや模擬試験からもわかるかと思いますが、個人的には以下のAWSサービス知識が重要だと感じました。

・KMS(はじめから最後まで一番時間かけた)
・IAM
・AWS WAF
・CloudFront、ELB、SGやACLなど(SAP資格の復習)
・AWS Organizations(復習)
・Systems Manager(復習)
・GuardDuty(復習)
・Secrets Manager
・Macie
・Inspector

・Active DirectoryやSAML関連、コンプライアンス
ホワイトペーパー↓
https://aws.amazon.com/jp/security/security-learning/?whitepapers-main.sort-by=item.additionalFields.sortDate&whitepapers-main.sort-order=desc
https://aws.amazon.com/jp/compliance/resources/

セキュリティサービス全般です。
たくさんあるかと思いますが、それぞれ何に使うのか、どんなケースで有効なのか、どうやって適用するのか、統合サービスはあるのか、など疑問点を必ず解消してから挑むことが必要です。気を抜くと失敗します。
また、もしポリシーを自身で作成したことがない場合は結構きついので、いくつか作成することをおすすめします。

結果&まとめ

無事合格しました。

試験時間ですが、模擬試験を解いたら感じる通り全く心配しなくて良いと思いました。
わかるかわからないかの問題が多いと思うので、冷静に挑みましょう。

今回はProfessionalの資格の知識が有効だったため、試験対策としての学習時間は20-25時間程度でした。

こちらは今までの記事とあまり変わらないですが、AWS試験の感想としては、以下のようになります。

対策すれば取れる
・問題をよく読む。何が求められている問題か?
・ラスト一週間は、問題演習をひたすら行って集中力と文章読解力を鍛える
・日本語の文章だけでは疑問を抱くことがあるので怪しいときは英語問題も読む
・日本語の問題を選択する場合、少々特殊な日本語に事前に慣れる
・今回は特に、選択肢はまず大半が切り捨てられる問題だと感じた
・最後の選択でわからなくても、確率で取れる問題が数問あった

Advanced Networking Specialtyを取ります。
こればかりはずっと取りたかった資格なので、自分の中の一つの大きな通過点です。

この記事が何かのお役に立てられれば幸いです。
ありがとうございました!

Qiitaへの記録

SAA
https://qiita.com/shinon_uk/items/5525178bf98034676b2f

SOP
https://qiita.com/shinon_uk/items/e60bcb946b49bf5cabda

SAP
・合格編
https://qiita.com/shinon_uk/items/c6b599d1cd3000e84d59
・失敗編(資料集め)
https://qiita.com/shinon_uk/items/ba839ba048ba439cc3ff

DVA
https://qiita.com/shinon_uk/items/8015953c792ef4bc7223

DOP
https://qiita.com/shinon_uk/items/5646d536e649b60b962a

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

「SQLSTATE[HY000] [2002] Connection refused」エラーの解決法

sql.png

Cloud9でLaravelを使った開発をしていたら画像のようなエラーが出ました。

初めは何かわからなかったけど、原因と対策は簡単。

コマンドで初めにSQLサーバーを起動していなかったというだけでした。

開発環境

・Windows10
・AWS(Cloud9)
・Larabel

解決法

初めにSQLサーバーを起動することが必要です。

◎SQLサーバ起動

$ sudo service mysqld start

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

Amazon Cognito とは

Amazon Cognito とは

Amazon Cognito は、ウェブアプリケーションやモバイルアプリケーションの認証、許可、ユーザー管理をサポート

Amazon Cognito の主な 2 つのコンポーネントは、ユーザープールと ID プールです。

Amazon Cognito ユーザープールと ID プールを一緒に使用するケース

スクリーンショット 2020-05-18 14.59.50.png

一般的な Amazon Cognito シナリオ

  • ユーザープールによる認証
  • ユーザープールを使用してサーバー側のリソースにアクセスする
  • API Gateway および Lambda でユーザープールを使用してリソースにアクセスする
  • ユーザープールと ID プールを使用して AWS のサービスにアクセスする
  • サードパーティーを使用して認証を行い、ID プールを使用して AWS サービスにアクセスする
  • Amazon Cognito を使用した AWS AppSync リソースへのアクセス

ユーザープールによる認証

スクリーンショット 2020-05-18 15.07.23.png

認証に成功すると、ウェブやモバイルアプリケーションに Amazon Cognito よりユーザープールトークンが送信されます。これらのトークンを使用して、他の AWS のサービスへのアプリによるアクセスを許可する AWS 認証情報を取得したり、サーバー側のリソースへのアクセスや Amazon API Gateway へのアクセスを制御したりすることができます。

WEBIDFederationでトークンと一時認証情報を交換して使います。

ユーザープールを使用してサーバー側のリソースにアクセスする

スクリーンショット 2020-05-18 15.13.50.png

こちらもトークンと一時認証情報を交換して使います。

API Gateway および Lambda でユーザープールを使用してリソースにアクセスする

スクリーンショット 2020-05-18 15.22.58.png

API Gateway を介して API にアクセスすることをユーザーに許可できます。API Gateway は、成功したユーザープール認証からトークンを検証し、Lambda 関数や独自の API などのリソースへのアクセスをユーザーに許可するためにトークンを使用します。

ユーザープールと ID プールを使用して AWS のサービスにアクセスする

スクリーンショット 2020-05-18 15.23.55.png

まずユーザープールで認証を行う。そのあとにIDプールでトークンと一時認証情報を交換。それを使ってAWSリソースにアクセスする。

こちらの記事でフェデレーションについて扱っています。

サードパーティーを使用して認証を行い、ID プールを使用して AWS サービスにアクセスする

スクリーンショット 2020-05-18 15.26.35.png

ユーザープールの代わりに外部Idpを使用。そのあとは一緒です。

Amazon Cognito を使用した AWS AppSync リソースへのアクセス

スクリーンショット 2020-05-18 15.28.28.png

Amazon Cognito のユーザープールと ID プールの違いは何ですか?

ユーザープールでは認証 (アイデンティティの検証) ができます。ユーザープールを使用すると、アプリユーザーはユーザープールからのサインインや、サードパーティーのアイデンティティプロバイダー (IdP) を介した連携ができます。

ID プールでは認可 (アクセスコントロール) ができます。ID プールを使用すると、ユーザーに一意の ID を作成して、他の AWS サービスへのアクセスを許可できます。

参考文献

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

Amazon EventBridge とは?

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

AWS IAM

AWS Identity and Access Management について

まずはじめに用語整理

  • リソース
    • IAM に保存されているユーザー、グループ、ロール、ポリシー、および ID プロバイダー。AWS サービスと同様に、IAM のリソースを追加、編集、削除することができます。
  • ID
    • 識別し、グループ化するために使用される IAM リソースオブジェクト。IAM ユーザーにポリシーをアタッチすることができます。ユーザー、グループ、およびロールなどがあります。
  • エンティティ
    • AWS によって認証に使用される IAM リソースオブジェクト。たとえば、IAM ユーザー、フェデレーションユーザー、引き受ける IAM ロールです。
  • プリンシパル
    • AWS にサインインし、リクエストを作成するために AWS アカウントのルートユーザー、IAM ユーザー、または IAM ロールを使用する人またはアプリケーション。

AWSユーザーに対して AWSのリソースへのアクセスできる範囲やアクセス方法を安全に制御するためのウェブサービスです。IAM により、どのユーザーが AWS リソースを使用できるか(認証)、また、それらのユーザーがどのリソースをどのような方法で使用できるか(認可)を制御できます。

IAM のベストプラクティス

  • AWS アカウントのルートユーザー アクセスキーをロックする
    • MFAを設定すること
  • 個々の IAM ユーザーの作成
  • IAM ユーザーへのアクセス許可を割り当てるためにグループを使用する
  • 最小権限を付与する
    • IAM ポリシーを作成する場合、最小限のアクセス権を付与するという標準的なセキュリティアドバイスに従うか、タスクの実行に必要なアクセス許可のみ付与
  • AWS 管理ポリシーを使用したアクセス許可の使用開始
  • インラインポリシーではなくカスタマー管理ポリシーを使用する
  • ユーザーの強力なパスワードポリシーを設定
  • MFA の有効化
  • Amazon EC2 インスタンスで実行するアプリケーションに対し、ロールを使用する
  • ロールを使用したアクセス許可の委任
    • アカウント間でセキュリティ認証情報を共有しない
  • アクセスキーを共有しない
  • 認証情報を定期的にローテーションする
  • 不要な認証情報を削除する
  • 追加セキュリティに対するポリシー条件を使用する
  • AWS アカウントのアクティビティの監視
    • Cloudfront
    • CloudWatch
    • CloudTrail
    • Config
    • S3

IAM Access Analyzer とは

IAM Access Analyzer は、アカウント内のどのリソースを外部プリンシパルと共有しているかを知らせます

サポートされているリソースタイプ

  • Amazon Simple Storage Service バケット
  • AWS Identity and Access Management ロール
  • AWS Key Management Service キー
  • AWS Lambda の関数とレイヤー
  • Amazon Simple Queue Service キュー

Amazon EventBridge による AWS IAM Access Analyzer のモニタリング

Access Analyzer は、各結果の生成時、既存の結果の状態の変更時、および結果の削除時に EventBridge にイベントに送信します。結果および結果に関する通知を受信するには、Amazon EventBridge でイベントルールを作成する必要があります。イベントルールを作成するときに、ルールに基づいてトリガーするターゲットアクションを指定することもできます。たとえば、新しい結果のイベントが Access Analyzer から返されたときに Amazon SNS トピックをトリガーするイベントルールを作成できます。

EventBridgeについて

参考文献

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

amazon-ssm-agentのバージョン確認方法

AmazonLinux2であれば、以下コマンドで確認できます。

$ sudo yum info amazon-ssm-agent
読み込んだプラグイン:extras_suggestions, langpacks, priorities, update-motd
インストール済みパッケージ
名前                : amazon-ssm-agent
アーキテクチャー    : x86_64
バージョン          : 2.3.662.0
リリース            : 1.amzn2
容量                : 61 M
リポジトリー        : installed
要約                : Manage EC2 Instances using SSM APIs
URL                 : http://docs.aws.amazon.com/ssm/latest/APIReference/Welcome.html
ライセンス          : ASL 2.0
説明                : This package provides Amazon SSM Agent for managing EC2 Instances using SSM APIs

利用可能なパッケージ
名前                : amazon-ssm-agent
アーキテクチャー    : x86_64
バージョン          : 2.3.714.0
リリース            : 1.amzn2
容量                : 15 M
リポジトリー        : amzn2-core/2/x86_64
要約                : Manage EC2 Instances using SSM APIs
URL                 : http://docs.aws.amazon.com/ssm/latest/APIReference/Welcome.html
ライセンス          : ASL 2.0
説明                : This package provides Amazon SSM Agent for managing EC2 Instances using SSM APIs
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWSコンソールでスイッチロール時のセッション時間を増やすCLIツールを作った

皆さんはAWSマネジメントコンソールでスイッチロールをして作業をしていたときにログインセッションが切れて、それまでの設定内容が全て消えて最初からやり直すことになった経験はないでしょうか?

テスト目的で何かを手でポチポチ作成している時にこういったことは個人的によくあり、セッション時間を伸ばすことができればなぁと思っていました。

AWSによるとスイッチロールをした場合のセッション時間は最大で1時間1までとしています。
また、AWSマネジメントコンソール上でスイッチロールを行う限り、このセッション時間は変更することは現状できません。

セッション時間を増やすことはできる

しかしながら、AWSフェデレーションを利用したコンソールURLからログインすると、セッション時間を1時間から最大12時間まで伸ばすことができます2。これは以下の公式ドキュメントで説明されています。

カスタム ID ブローカーに対する AWS コンソールへのアクセスの許可 - AWS Identity and Access Management

このドキュメントによると、AssumeRole APIやGetFederationToken APIから一時的なセキュリティ認証情報を取得し、その情報を使ってさらにAWSフェデレーションエンドポイントからサインイントークンを取得し、そのトークンが入ったコンソールURLを組み立てればOKだよと説明されています。

ただし、このURLを発行するためには簡単なプログラムを書く必要があり、公式ドキュメントでもプログラムの一例が紹介されています3

そこでこのコンソールURLの発行を1コマンド叩くだけでできるCLIツール alug を作成したので紹介します。

alug

今回作ったもの
https://github.com/shirakiya/alug

インストール方法はこちらを参考にしてください。

使い方

説明のために仮にログインしたいIAMロールに関するprofileを hoge とした場合、基本的な使い方は以下のコマンドです。

$ alug -p hoge

https://signin.aws.amazon.com/federation?Action=login&Destination=https%3A%2F%2Fconsole.aws.amazon.com%2F&Issuer=IssuedByAlug&SigninToken=XXXXXXXXXX...

※ この SigninToken の文字数とても多く、長大なURLが出力されます。

ログイン先のIAMロールにMFAが設定されている場合は以下のどちらかの方法でMFAコードを入力する必要があります。(なお、MFAが設定されている場合は後述する mfa_serial がログイン先のprofileに設定されている必要があります)

# インタラクティブに入力する場合
$ alug -p hoge
Input MFA Code: XXXXXX

https://signin.aws.amazon.com/federation?...


# オプションで入力する場合
$ alug -p hoge -t XXXXXX

https://signin.aws.amazon.com/federation?...

設定

alugには二箇所のファイルに設定が記述されている必要があります。

  • ~/.aws/config
  • ~/.aws/credentials

AWSではおなじみのConfigurationファイルたちですね。alugではこれらのAWSの公式設定に準拠する形でデザインしています。

~/.aws/config

~/.aws/config にはログイン先となるIAMロールに関するprofileを設定します。

[profile hoge]
role_arn = arn:aws:iam::000000000000:role/role_name
duration_seconds = 43200
mfa_serial = arn:aws:iam::123456789012:mfa/user
role_session_name = fuga
source_profile = default
  • role_arn
    • ログイン先のIAMロール(設定が必須)
  • duration_seconds
    • これが今回の目的であるログインセッション時間の設定。
    • 最大12時間(秒での設定なので12時間だと43200
  • mfa_serial
    • 前述したMFAが設定されている場合では必須
  • role_session_name
    • ログインした時のsession名
  • source_profile
    • AssumeRole元のprofile名

※これらの項目の説明はalugの文脈での説明です。AWS公式の設定に関しては以下のドキュメントで説明されています。
設定ファイルと認証情報ファイルの設定 - AWS Command Line Interface

duration_seconds に関して最大12時間と記述しましたが、最大時間はログインするIAMロールの「最大CLI/APIセッション期間」の値が最大値となり、この「最大CLI/APIセッション期間」が最大12時間まで、ということに注意です。以下のようにAWSマネジメントコンソールのIAMロール詳細画面から設定値を見ることができます。

image.png

~/.aws/credentials

上記に source_profile で指定しているprofileには正しいcredentialが設定されている必要があります。

前述の通り、今回のコンソールURLの発行に際して、AssumeRole APIを使って一時的に認証情報を取得する必要があり、当然APIを叩くためのcredentialを必要とします。なので、このprofileにはログイン先のIAMロールにAssumeRole可能なIAMポリシーがアタッチされたものである必要があります。

[default]
aws_access_key_id = XXX...
aws_secret_access_key = YYY...

締め

今回はAWSマネジメントコンソールのスイッチロール時のログインセッション時間を増やすためのCLIツール「alug」を紹介しました。
これで途中で消えてやり直すことをほぼ回避できるようになるので、よければご利用くださいませ。

なにかあれば shirakiya831 か issue を上げていただけますと。
それでは。

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

CodeBuildのVPC構成でハマった点をメモ

適当に設定してみたらダメだった

  • CodeBuildプロジェクトを作成
  • パブリックサブネットしかない状態でVPC設定しようとしたら、「プライベートサブネットに配置するべし」とエラーが出る。※CodeBuildの「VPC設定の確認」ボタン押下時
  • プライベートサブネットを作成して再チャレンジしたら「0.0.0.0/0へのルートがない」みたいなエラーになった
  • 困った・・・

Lambdaの時を思い出した

  • LambdaをVPCにのせた時も似たような話があったことを思い出す。
  • `こちらのサイトが物凄く役に立ちました。ありがとうございます。a lot of 感謝。

結論からいうと以下の要件が必要です。

  • CodeBuildからCodeCommitを見るためにはインターネット接続が必須。
  • 接続構成にはPublic SubnetとPrivate Subnetの二つのSubnetが必要。
  • VPCにはInternet-GWがアタッチされていること
  • Public SubnetのルートテーブルにInternet-GWが設定されていること。
  • CodeBuildを実行するSubnetはPrivate Subnetに配置する必要がある。
  • 当該Private SubnetにはNAT GWが接続されている必要がある。
  • ★当該NAT GWは、★★Public Subnet側★★に配置しなければならない。

適当にNAT-GWをPrivate Subnetに作成していたのが原因

  • 適当に作業してはいけない事をひどく反省しました。
  • 多くの時間を浪費した事も反省しました。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

お気に入りpythonモジュール達やバイナリを1つのLambda Layerにまとめるスクリプト

LambdaとLayersは便利ですが、1つの関数につき上限は5つまでと制限があります。
Layersは=1モジュールとして運用しているケースが多いかと思いますが、意外と足りなくなったり1つずつ追加するのは手間です。
お気に入りのモジュールたちはお馴染みのrequirement.txtで管理し、1つのレイヤーにまとめてしまいましょう。

テストで6つのモジュールをインポートするrequirement.txtを作成します。

requirement.txt
selenium
requests
Pillow
lxml
numpy
Flask

そして同階層にて以下のスクリプトを実行します。dockerの
pythonのバージョンや、awsコマンドの引数は必要に応じて編集してください。

mkdir -p python/bin/
docker run --rm -v $(pwd):/var/task -w /var/task lambci/lambda:build-python3.7 pip install -r requirements.txt -t ./python
zip -r layer.zip python
aws lambda publish-layer-version --layer-name favorites --zip-file fileb://layer.zip --compatible-runtimes python3.7 --region ap-northeast-1
rm -rf layer.zip python

Lambdaに登録されたレイヤーを追加できるようになりました。テスト関数はこのレポジトリからServerless Frameworkによるデプロイ・確認を行いました。以上です!

Serverless Frameworkを使うならserverless-python-requirementsを使えばモジュール管理は楽になりますし、レイヤーを使って分離しない方がInfrastructure as Codeの徹底がされていてエレガントだと思います。しかしレイヤー数の上限が障害になったり、モジュールがパッケージに含まれるとデプロイの待ち時間が長くなるので、個人的にはレイヤーで分離するほうが小回りが聞いて好みです。

ちなみにseleniumを使うならバイナリも一緒にあげて管理すると楽です。以下がバイナリも追加するスクリプトです。
余談ですが、私が把握しているlambdaでpythonで動くheadlessなseleniumはこのスクリプトのバージョンとpython3.7のセットです。古いリリースのバージョンを使っているのはそのためです。

mkdir -p python/bin/
+ curl -SL https://github.com/adieuadieu/serverless-chrome/releases/download/v1.0.0-37/stable-+ headless-chromium-amazonlinux-2017-03.zip > headless-chromium.zip
+ unzip headless-chromium.zip -d python/bin/
+ curl -SL https://chromedriver.storage.googleapis.com/2.37/chromedriver_linux64.zip > chromedriver.zip
+ unzip chromedriver.zip -d python/bin/
+ rm -rf chromedriver.zip headless-chromium.zip
docker run --rm -v $(pwd):/var/task -w /var/task lambci/lambda:build-python3.7 pip install selenium -t ./python
zip -r layer.zip python
aws lambda publish-layer-version --layer-name selenium_with_bin --zip-file fileb://layer.zip --compatible-runtimes python3.7 --region ap-northeast-1
rm -rf layer.zip python

seleniumがlambda上で正しく動くためのchromeOptionsやこのレイヤーから得るバイナリのパスを設定したテスト関数はこちらです。

参考
https://github.com/adieuadieu/serverless-chrome/issues/133
https://dev.classmethod.jp/articles/managing-external-modules-with-serverless-framework-plugin/
https://www.npmjs.com/package/serverless-python-requirements
https://hacknote.jp/archives/49974/
https://dev.classmethod.jp/articles/lambda-layer-first-action/

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

EC2にgit cloneする方法

EC2にコードを展開する時、git cloneでやると簡単にDeployできます。
なんとなく手順を覚えているものの、ところどころ忘れていることもあるので、やり方をまとめておきます。

  • Amazon Linux 2でのやり方です。
  • リポジトリは、GitLabを使っています。

SSH Keyの作成

git cloneを実行するには、GitLabとSSHで通信する必要があります。
SSHキー用のディレクトリへ移動し、SSH通信で使用するキーを作成します。

$ cd ~/.ssh
$ ssh-keygen -t rsa -C "[Gitlabで登録したEmail]"

コマンドを実行すると、3つ質問されますが、Enter3回でOKです。

Generating public/private rsa key pair.
Enter file in which to save the key (/Users/(username)/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:

作成されたキーに権限を付与

コマンドが正常に完了すると、id_rsa, id_rsa.pubという2つのファイルができます。
id_rsaは、秘密キーという非常に大切なキーなので、適切な権限が付与されている必要があります。

以下のコマンドで、権限を付与します。

$ sudo chmod 600 id_rsa

GitLabへキーを登録

リポジトリと通信するためには、生成されたキー id_rsa.pub をGitLabへ登録し、有効化する必要があります。

 1. id_rsa.pubを開き、文字列をコピーします。
  (ssh-rsa...のところから全部コピーします)

$ cat id_rsa.pub
ssh-rsa AAA....1yc2EAAAADAQABAA........../j21AEwVC1i/+SBcQgTvccQd......

 2. GitlabのSSH Keysメニューをクリックし、キーを貼り付け、Add Keyをクリックします (SSH Keysは、User Settingsの中にあります)。
Bildschirmfoto_2020-05-17_um_23_07_27.png

SSH通信の確認

ここまでの設定が完了したら、EC2上でGitLabへの通信を確認します。

$ ssh -T git@github.com

Welcome to GitLab, @XXXXXX!と表示されば、通信できています。

git cloneの実行

以下のコマンドを実行し、リポジトリをCloneします。

$ git clone git@gitlab.com:XXX/TTT.git

これで、GitLabのリポジトリからコードを取得できます。

もしうまく行かない時は、、、

上記の設定を行っても、git cloneがうまく行かないことがあります。
こんなエラーが出たり、、、

Cloning into 'Project Name'...
Permission denied (publickey).
fatal: Could not read from remote repository.

この場合、以下の2つの点を確認してみてください。

  1. git clone コマンドは、sudoをつけないで実行しているか?

    • sudo をつけてコマンドを実行すると、rootで実行することになるので、せっかく作成し たキーを利用できていない可能性があります。
  2. Cloneしようとしているディレクトリは、ec2-user:ec2-user になっているか?

    • ec2-userに書き込み権限がないディレクトリには、Clone できないので、そこも意外と盲点だったりします。




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

趣味プロジェクトで簡単に使える双方向通信技術を模索した話

勉強を兼ねて、自分の技術スタックにマッチする範囲で利用できる双方向通信技術を一通り試し、それぞれの長所短所、向き不向きを把握しておきたくなり「いろんな技術でチャットサービスを何個か作ってみる」という活動をしておりました。

結果として、IaaS/ライブラリを変えながら4パターンでチャットサービスを構築し、各IaaS/ライブラリの特性がだいたい把握できたので記事にしたいと思います。

作ったチャットサービスはこんな感じ。
chat-capture03.gif

個人のサービスに導入することをメインに考えてるので、下記を重視しています。

  • 双方向通信部分の実装の難易度
  • 認証との連携
  • インフラの制約

逆に、下記要素は気にしていません。(ゲームとか作るわけじゃないので)

  • 接続数、負荷
  • コスト
  • リアルタイム性(遅延)

※タイトルにある「簡単に使える」というのは技術スタックによって個々人で異なると思いますので、ご参考までに。

なぜ双方向通信なのか?

簡単に言うと、ユーザー同士の操作をリアルタイムに反映するためです。

通常webサービスにおける通信は下記のように、client(ブラウザ)からリクエストをserver(サービス)に送り、そのレスポンスとしてhtmlやjsやcssが返るといった仕組みです。

qiita-chat01.png
※TCPコネクションまわりは省略

ではチャットサービスの例を考えてみましょう。
client1client2がチャットに参加していると仮定します。

単純なREST API等のリクエストのみの場合は下記のようなシーケンスになります。

qiita-chat02.png

①client1が新規にメッセージを投稿し、正常に投稿できた旨のレスポンスを受け取ります。
②client1は①で正常に投稿できたので、全メッセージを取得します。これで最新のメッセージ一覧がclient1の画面に表示されます。
③今度はclient2がメッセージを新たに投稿し、正常に投稿できた旨のレスポンスを受け取ります。
④client2は③で正常に投稿できたので、全メッセージを取得します。この結果には当然client1の①での投稿も含まれるため、全メッセージを見ることができます。

⑤ここで問題が発生します。
(普通のwebサービスの場合)serverからclientへはリクエストを送ることができません。
そのためclient2が新たにメッセージを投稿した瞬間に、それをclient1が知ることはできないのです。

このような課題を解決する一つの方法として、双方向通信技術があげられます。
(ポーリングやPub/Subなど他にも様々な解決方法がありますが、それはまた別のお話)

双方向通信でのclient-server間の通信の様子をシーケンス図で表すと下記のようになります。
qiita-chat03.png

コネクションを確立し、そのコネクション内でclient、serverの双方から任意のタイミングでメッセージを送信することが可能になります。
この技術により、サーバー側から任意のタイミングで確立されたコネクションを通し、クライアントにデータを送信できるようになります。
「双方から」、「任意のタイミングで」という点がキモになります。

チャットサービスをWebSocketで構築した場合の通信のフローを考えてみましょう。
qiita-chat04.png

①と②でclient1とclient2がそれぞれserverへコネクションを確立します。
この時点で、client1-server間、client2-server間で双方向に通信が可能となります。

③でclient1がHelloとメッセージを投稿します。
④でserverは接続している全てのコネクションに対し、client1からHelloというメッセージが投稿されたことを送信します。
この「接続しているコネクション全てに送信する」ことをbroadcastと呼びます。
この送信により、client1、clinet2ともにHelloという新規メッセージが投稿されたことを検知でき、画面に表示することができます。

⑤で今度はclient2がWorldとメッセージを投稿します。
⑥でserverがclient2がWorldというメッセージを投稿したことをbroadcastします。
これにより、各clientが新たに投稿されたメッセージを受信します。

このような仕組みでチャットサービス等でリアルタイムに別ユーザーの操作内容を伝えることができます。

チャットサービス

ということで、チャットサービスを4パターンほど実装してみました。

仕様は共通で、より現実的な課題も体験できるように下記の機能を実装しています。

  • 認証機能
  • チャット部屋作成/取得/削除
  • チャット機能

その他UI等の実装コストを極力減らすため、下記を共通で採用しています。

  • Nuxt.js(フロントエンドフレームワーク)
  • Vuetify.js(マテリアルデザインコンポーネントフレームワーク)
  • Auth0(認証サービス、Firebase以外で利用)

なお、チャット部分のコードを抜粋して掲載していますが、「実装イメージが湧いてくれれば幸い」程度のものになります。
(最終的な完成コードを載せると記事が長くなってしまうので)

socket.io

まずは最もオーソドックスな(?)Node.js用WebSocketライブラリのsocket.ioを利用した実装です。

リポジトリ

reireias/chat-socket.io

アーキテクチャ図

アーキテクチャはこのようになっています。
chat-architecture-socketio.png

  • Node.jsのサーバーライブラリであるExpress上でNuxt.jsを動かす
  • socket.ioをExpress上で動かす
  • Nuxt.js上でsocket.ioのclientを動かし、メッセージの送受信を行う
  • 認証はAuth0を使う
  • roomの管理等はredisを利用する(express-sessionと共通で利用して楽をしただけ)
  • Herokuにデプロイ(Expressを使う都合上、サーバーが必要であるため)

チャット部分コード抜粋

socket.ioの双方向通信は極めてシンプルです。
サーバー側/クライアント側共にイベント駆動になっているので、イベントの送信とイベント種類ごとにハンドラーを定義する形になっています。

サーバー側

// server/socket.js
const io = socketio(http)
const store = {}

// コネクション確立時のハンドラーを定義
io.on('connection', (socket) => {
  const userId = 'express-sessionを利用して取得する'

  // join-roomが送信された場合のハンドラー
  socket.on('join-room', (data) => {
    store[userId] = data
    // socket.ioの機能でroom管理が可能
    socket.join(data.roomId)
  })

  // clientからsend-messageイベントでメッセージが送られてきた際のハンドラー
  socket.on('send-message', (message) => {
    const roomId = store[userId].roomId
    // roomに接続している自分以外にイベントを送信
    socket.broadcast.to(roomId).emit('send-message', message)
    // 自分にも送信
    io.to(socket.id).emit('send-message', message)
    // 必要であればサーバー側でメッセージを永続化
  })
})

クライアント側

// pages/chat.vue ※一部コードは省略
import io from 'socket.io-client'

export default {
  created() {
    this.socket = io()
    // 現在のページに対応したroomへの参加イベントを送信
    this.socket.emit('join-room', {
      id: this.user.id,
      roomId: this.$route.query.roomId,
    })
    // serverから'send-message'イベントを受け取った場合のハンドラーを追加
    this.socket.on('send-message', this.recieveMessage)
  },
  methods: {
    // 新たにメッセージを受け取ったら、ローカル変数に追加し描画する
    recieveMessage(message) {
      this.messages.push(message)
    },
    // メッセージ送信ボタンが押された際のハンドラー
    onPost() {
      if (this.text) {
        const message = {
          text: this.text,
          roomId: this.$route.query.roomId,
        }
        // emitすることでserver側にイベントを送る
        this.socket.emit('send-message', message)
        this.text = null
      }
    },
  },
}

特徴

  • チャット部分のコードをシンプルに実装できる
  • 部屋ごとに送信するような機能をsocket.ioが持っている
  • サーバーが必要
  • 認証はAuth0 + Passport + express-sessionでそこまで難しくない
  • express-sessionを利用することで、WebSocket通信の認証も可能

API Gateway

次はAWSのAPI Gatewayを用いた実装方法です。
API GatewayではWebSocketがサポートされており、WebSocketのbodyの指定した属性に応じて起動するLambda関数を制御できます。
Serverless Frameworkのドキュメントが参考になります。

リポジトリ

reireias/chat-serverless

アーキテクチャ図

chat-architecture-serverless-framework.png

  • インフラ全体の管理にはServerless Frameworkを利用
  • WebSocketはAPI Gatewayを利用し、WebSocketのイベントに合わせて実行されるLambda関数を設定
  • フロント部分のコードをNuxt.jsでビルドし、API Gateway→S3というパスで配信
  • Nuxt.jsのSSR部分やバックエンド(DynamoDB)と接続するAPI部分はwebpackでビルドし、それぞれLambda関数にデプロイし、API Gatewayから呼び出す形式とする
  • 認証にはAPI GatewayのLambda Authorizerを利用し、Auth0で認証

チャット部分コード抜粋

サーバー側

// server/websocket.js

// roomへの参加イベントのハンドラー
// connectionIdとroomIdを紐付けてDynamoDBへ保存する
module.exports.joinHandler = async (event, _context, callback) => {
  const body = JSON.parse(event.body)
  const params = {
    TableName: CONNECTIONS_TABLE,
    Item: {
      roomId: body.roomId,
      id: event.requestContext.connectionId,
    },
  }
  await docClient.put(params).promise()
  callback(null, {
    statusCode: 200,
    body: 'joined',
  })
}

// メッセージ投稿イベントのハンドラー
// DynamoDBからroomに属するconnectionを全て取得し、それぞれに対してメッセージ投稿のイベントを送信する
module.exports.postHandler = async (event, _context, callback) => {
  const body = JSON.parse(event.body)
  const roomId = body.roomId
  const params = {
    TableName: CONNECTIONS_TABLE,
    ExpressionAttributeValues: {
      ':room': roomId,
    },
    ExpressionAttributeNames: {
      '#r': 'roomId',
    },
    KeyConditionExpression: '#r = :room',
  }
  const data = await docClient.query(params).promise()
  const domain = event.requestContext.domainName
  const stage = event.requestContext.stage
  const url = `https://${domain}/${stage}`
  const apigatewaymanagementapi = new AWS.ApiGatewayManagementApi({
    apiVersion: '2018-11-29',
    endpoint: url,
  })
  for (const item of data.Items) {
    const apiParams = {
      ConnectionId: item.id,
      Data: JSON.stringify({
        message: body.message,
        author: body.author,
        authorIcon: body.authorIcon,
      }),
    }
    try {
      await apigatewaymanagementapi.postToConnection(apiParams).promise()
    } catch (err) {
      // 切断済みのコネクションをDynamoDBから削除する
      if (err.statusCode === 410) {
        const params = {
          TableName: CONNECTIONS_TABLE,
          Key: {
            roomId,
            id: item.id,
          },
        }
        await docClient.delete(params).promise()
      }
    }
  }
  callback(null, {
    statusCode: 200,
    body: 'posted',
  })
}

クライアント側

// pages/chat/_id.vue
export default {
  mounted() {
    // API GatewayのWebSocket用エンドポイントを指定して接続
    // 標準APIのWebSocketクラスを利用する
    this.ws = new WebSocket('wss://xxxxxx.execute-api.ap-northeast-1.amazonaws.com/dev')
    // イベント受信時のハンドラーを設定する
    this.ws.onopen = this.onOpen
    this.ws.onmessage = this.onMessage
  },
  methods: {
    // コネクション確立後にroomへの参加イベントをsever側に送信
    onOpen(event) {
      this.ws.send(
        JSON.stringify({
          action: 'join',
          roomId: this.$nuxt.$route.params.id,
        })
      )
    },
    // serverからメッセージ受信時は変数に追加し表示する
    onMessage(event) {
      const data = JSON.parse(event.data)
      this.messages.push({
        text: data.message,
        author: data.author,
        authorIcon: data.authorIcon,
      })
    },
    // メッセージ送信ボタンが押された際のハンドラー
    onPost() {
      this.ws.send(
        JSON.stringify({
          action: 'post',
          roomId: this.$nuxt.$route.params.id,
          message: this.text,
          author: this.user.sub,
          authorIcon: this.user.picture,
        })
      )
      this.text = ''
    },
  },
}

特徴

  • この4つのサンプルサービスの実装の中で最も難易度が高く時間がかかった
    • API GatewayのLambda Authorizer + Auth0による認証
    • API GatewayのWebSocketでLambda Authorizerを使う方法
    • DynamoDBを利用した自前でのWebSocketコネクション管理
    • Nuxt.jsをSSR on Lambdaで動かす部分
  • スケーラビリティはかなり高く、AWSとの連携も柔軟にできるので拡張性は最も高いといえる
  • すくなくとも趣味で軽く作る範囲ではないなという印象

Action Cable

続いてはRuby on RailsのAction Cableでの実装です。
Railsガイドでは「WebSocketとRailsのその他の部分をシームレスに統合するためのもの」と紹介されています。

リポジトリ

reireias/chat-action-cable

アーキテクチャ図

Railsの場合、アーキテクチャはとてもシンプルになります。

chat-architecture-action-cable.png

  • フロントエンドは既存の実装を使いまわすために、WebPacker + Vue.jsで実装
  • 認証はAuth0 + omniouthで実装
  • Herokuへデプロイ
    • DBはHerokuのPostgreSQLを利用

チャット部分コード抜粋

サーバー側

app/controllers/api/v1/messages_controller.rb
class Api::V1::MessagesController < Api::ApplicationController
  include Secured

  def create
    # ActionCableを通し、全clientへメッセージをbroadcastする
    ActionCable.server.broadcast "rooms:#{params[:room_id]}:messages", message
    render json: {}
  end

  private

  def message
    {
      text: params[:text],
      user: current_user
    }
  end
end

その他のファイルはRailsガイドのこのへんを参照

クライアント側

app/javascript/components/pages/rooms/Show.vue
import consumer from '../../../channels/consumer'

// ※もろもろ省略
  created() {
    // イベント受信時のハンドラーを定義
    consumer.subscriptions.create(
      { channel: 'ChatChannel', room_id: this.roomId },
      {
        received: (data) => {
          this.messages.push({
            text: data.text,
            author: data.user.uid,
            authorIcon: data.user.image,
          })
        }
      }
    )
  },
  methods: {
    // client→serverではWebSocketを利用せずに普通にAPIでメッセージをPOST
    async onPost() {
      if (this.text) {
        await axios.post(`/api/v1/rooms/${this.roomId}/messages`, {
          text: this.text,
        })
        this.text = null
      }
    },
  }

特徴

  • なんと言っても「Railsが使える」というのが最大の利点
  • 全てWebSocketで通信するというよりも、一部をWebSocketでbroadcast配信するような用途での利用が多く見られた
  • 「サーバー側の何かの通知をクライアントにリアルタイムに送る」のみであれば比較的簡単に実装が可能である

Firebase

最後はみんな大好き(?)Firebaseでの実装です。
FirebaseにはFirestoreという強力なNoSQLデータベースがあります。
このFirestoreの特徴の一つとして、更新をクライアント側からwatchできるというものがあるので、これを利用して実装します。
ちなみに、FirestoreのwatchはgRPCのBidirectional Streamingを利用して実装されています。

リポジトリ

reireias/chat-firebase

アーキテクチャ図

おそらくFirestore + Vue.jsの鉄板の構成になっていると思います。

chat-architecture-firebase.png

  • チャット部分はFirestoreのデータをvuexfireを利用してVuexのstoreに同期
  • メッセージ投稿はNuxt.jsからFirestoreのclientで登録
  • 認証はFirebase Authentication + firebaseui-webを利用
  • Nuxt.jsで静的サイトとしてgenerateしFirebase Hostingへデプロイ

チャット部分コード抜粋

サーバー側:なし

クライアント側

// store/index.js
import { firestoreAction } from 'vuexfire'
import firebase from '@/plugins/firebase'

export const actions = {
  // vuexfireを利用して、Firestore上のcollectionをstateへbindする
  bindMessages: firestoreAction(({ bindFirestoreRef }, payload) => {
    return bindFirestoreRef(
      'messages',
      db
        .collection('rooms')
        .doc(payload.id)
        .collection('messages')
        .orderBy('createdAt', 'asc')
    )
  }),
  // Firestoreにごく普通の方法でレコードを追加する
  addMessage(_, payload) {
    const message = {
      author: payload.uid,
      authorIcon: payload.authorIcon,
      text: payload.text,
      createdAt: firebase.firestore.FieldValue.serverTimestamp(),
    }
    db.collection('rooms')
      .doc(payload.roomId)
      .collection('messages')
      .add(message)
  },
}

// pages/chat.vue
import { mapActions, mapGetters } from 'vuex'
import moment from 'moment'

export default {
  data() {
    return {
      text: null,
    }
  },
  computed: {
    ...mapGetters(['user', 'messages']),
  },
  created() {
    // ページ描画時にFirestore上のmessagesをlocalのstoreにbindする
    // これにより、computedのmessagesでFirestore上のレコードが取得できる
    this.bindMessages({ id: this.$route.query.roomId })
  },
  methods: {
    onPost() {
      if (this.text) {
        // storeのaddMessageをmapActions経由で呼び出す
        this.addMessage({
          uid: this.user.uid,
          authorIcon: this.user.photoURL,
          text: this.text,
          roomId: this.$route.query.roomId,
        })
        this.text = null
      }
    },
    ...mapActions(['bindMessages', 'addMessage']),
  },
}

特徴

  • 認証、データストア、リアルタイムが組み合わさったFiresotreはかなり便利で洗練されているということを再認識した
    • とくに認証とデータ永続化がお手軽に実装できる点は他にはない強みである
    • 逆に永続化しないで良いデータの送信であればsocket.io等のほうがシンプルでインフラも柔軟である
  • Authentication(認証), Functions(FaaS)、Hosting(静的サイトホスティング)、Messaging(push通知)等一通りの機能がそろっているのでインフラの柔軟性という点でも十分である
    • Firebaseで不足している場合はGCPとも連携が容易なので問題ない
  • Firebase固有の知識がけっこう必要になる
    • Firestoreの設計や認証まわりのコード等

所感

どの実装方法も他と異なる点がいくつかあり、とても勉強になりました。
socket.ioが思っていた以上にシンプルだったことや、いくつかの方法において認証の連携がとても手間であること等様々な発見がありました。

Firebaseが実装難易度、インフラ管理コスト、認証/DBとの連携などかなりの面で優れていることを再認識できたので、今後の個人サービス開発は相変わらずFirebaseを利用していくことになりそうです。

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

EC2にnginxをセットアップする

EC2にnginxをインストールする方法のメモです。
EC2のインスタンスを立ち上げてからの手順をまとめておこうと思います。
(Amazon Linux 2 へのインストール方法です。)

インスタンスのアップデート

yum updateを実行し、インスタンスをアップデートします。

$ sudo yum update

nginxのyumの有効化

EC2インスタンスは、nginxの yum intstallが有効になっていなかったので、以下のコマンドで有効化します。

$ sudo amazon-linux-extras enable nginx1

nginxのインストール

yum コマンドでnginxをインストールします。

$ sudo yum -y install nginx

インストールの確認

以下のコマンドで、インストールされたバージョンを確認します。

$ nginx -v
  nginx version: nginx/1.16.1

自動起動の設定

インストールしただけですと、OSを再起動した際に、nginxが自動で起動してくれないので、自動起動のための設定を行います。

$ sudo systemctl enable nginx

nginxの起動

以下のコマンドで、nginxを起動します。

$ sudo systemctl start nginx.service

nginxの状態確認

以下のコマンドで、nginxの状態を確認します。正常に起動できていると、ログ中にActive: active (running) と表示されます。

$ sudo systemctl status nginx.service
 nginx.service - The nginx HTTP and reverse proxy server
   Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled; vendor preset: disabled)
   Active: active (running) since So 2020-05-17 19:27:25 UTC; 9s ago
   Process: 847 ExecStart=/usr/sbin/nginx (code=exited, status=0/SUCCESS)
   Process: 844 ExecStartPre=/usr/sbin/nginx -t (code=exited, status=0/SUCCESS)
   Process: 843 ExecStartPre=/usr/bin/rm -f /run/nginx.pid (code=exited, status=0/SUCCESS)
   Main PID: 850 (nginx)
   CGroup: /system.slice/nginx.service
           ├─850 nginx: master process /usr/sbin/nginx
           └─851 nginx: worker process

以上で、nginxのセットアップは完了です。




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