AWS Certified Big Data – Specialty 認定試験を受けました

AWSの認定資格でビッグデータの専門知識を問われる試験のAWS Certified Big Data – Specialtyを受験しました。何とか合格できたので、この試験に向けて勉強した内容などを残しておきたいと思います。
 

試験概要

試験の概要は以下参照
AWS 認定ビッグデータ – 専門知識

受験資格

以下のいずれかの試験に合格している必要があります。
AWS 認定クラウドプラクティショナー
AWS 認定ソリューションアーキテクト – アソシエイト
AWS 認定デベロッパー – アソシエイト
AWS 認定 SysOps アドミニストレーター – アソシエイト
 

試験対策

出題範囲の確認

関連するAWSのサービスについては、以下のブログが参考になります。
AWS Certified Big Data – Specialty – Blue Clouds

サンプル問題

サンプル問題は必ず解きましょう。現時点で模擬試験は提供されてないようです。
サンプル問題

参考資料

勉強にあたっては、BlackbeltをはじめにAWSのホワイトペーパーのビッグデータ関連の資料などを読みました。
実際に各サービスを動かして確認していればなおいいと思います。

英語

現時点で日本語の試験は提供されておらず英語での試験しか提供されていません。
これについては、英語のAWSドキュメントを読むことで勉強しました。
また、他の試験の英語のサンプル問題を読むことで問題文に慣れました。

所感

難易度はアソシエイトとプロフェッショナルの間くらいに感じましたが、英語が得意ではないのが一番の難関でした。170分という試験時間はかなり長いのですが、結局見直す時間もないままぎりぎりまでかかってしまいました。
次はAdvanced Networking - Specialtyに挑戦してみたいと思います。

PHPのファイルアップロード機能をサイト別に切り替える

PHPのファイルアップロード機能をサイトごとにhtaccessで切り替えたいというケースがあり、実現方法について調査したので備忘録として残しておきたいと思います。

アップロードするファイルサイズの切り替えはケースとしてはよくあるのでネット上に情報があがってましたが、ファイルのアップロード機能自体を切り替える例は見つからりませんでした。htaccessで同じようにできるか試してみたところうまくいかずしばらくハマりました。
結論としてはhtaccessではできずにhttpd.confに設定することでサイトごとの設定を変更することができました。

設定方法

以下example.comというvirtualhostに設定する場合の記載例です。

<VirtualHost *:80>
  ServerName example.com
  DocumentRoot /var/www/example.com/
  php_admin_flag file_uploads on  ← 追加
</VirtualHost>

htaccessでできなかった理由は、各設定内容がそれぞれモードをもっており、そのモードに応じて設定できる場所が決まっていました。
file_uploadsについてはPHP_INI_SYSTEMというモードになっており、設定可能な箇所はphp.iniかhttpd.confで設定可能となっています。

f:id:cloudfish:20180601135736p:plain
PHPマニュアル抜粋

fish shellでaws-cliのコマンド補完

fish shellでaws cliのコマンド補完を設定してみたので設定方法を紹介したいと思います。

環境

Mac Sierra
fish 2.2.0

設定方法

bashzshについては以下の公式で設定方法が紹介されているのですがfishはありませんでした。
docs.aws.amazon.com

色々調べたところ以下をfishのconfig(~/.config/fish/config.fish)に設定することでコマンド補完ができます。

 complete -c aws -f -a '(begin; set -lx COMP_SHELL fish; set -lx COMP_LINE (commandline); /usr/local/bin/aws_completer; end)'

設定後にテストを行ったところ、以下のように補完候補の末尾に何故かバックスラッシュ(\)がセットされてしまいました。

> ~ aws  acm\                                                         
acm\                       ecs\                            mobile\
alexaforbusiness\          efs\                            mq\
apigateway\                elasticache\                    mturk\
application-autoscaling\   elasticbeanstalk\               opsworks\
appstream\                 elastictranscoder\              opsworks-cm
appsync\                   elb\                            organizations\
athena\                    elbv2\                          pinpoint\
autoscaling\               emr\                            polly\

そのため、補完はされるのですが、このまま実行してもエラーになるので、いちいちバックスラッシュを消す必要があります。
これではせっかく補完されてもあまり嬉しくないので、回避策がないかさらに調べてみました。

以下のとおり補完プログラムを修正することで対応できました。
■修正ファイル
/usr/local/lib/python2.7/site-packages/awscli/completer.py(パスは環境にあわせてください)
■修正箇所

def complete(cmdline, point):
    choices = Completer().complete(cmdline, point)
    #print(' \n'.join(choices)) ← コメントアウト
    print('\n'.join(choices)) ←追加

なぜかスペースをバックスラッシュとして解釈してしまうようなのでスペースを削除します。

再度テストするとバックスラッシュが除去されています。

> ~ aws  acm
acm                       ecs                            mobile
alexaforbusiness          efs                            mq
apigateway                elasticache                    mturk
application-autoscaling   elasticbeanstalk               opsworks
appstream                 elastictranscoder              opsworks-cm
appsync                   elb                            organizations
athena                    elbv2                          pinpoint
autoscaling               emr                            polly

これで快適にコマンド補完できました。
ただし、残念なことにawscliのアップデートの度に修正が必要になりそうです。

ec2-scheduleでEC2のインスタンスタイプの自動変更

ec2-scheduleではインスタンスタイプの変更も可能です。
今回はインスタンスタイプを自動で変更する方法を紹介したいと思います。

設定方法

DynamoDBのConfigTableに以下を設定

テーブル名はスタック名+ConfigTableになっています。
ex)
月曜から金曜までの9:00 - 20:00(日本時間)t2.micro
月曜から金曜までの20:00 - 9:00(日本時間)t2.nano

scheduleレコード
type name description periods timezone
schedule ec2_type_change ec2 type change { "down-period@t2.nano", "up-period@t2.micro" } Asia/Tokyo
periodレコード
type name description timezone weekdays begintime endtime
period up-period Office hours Asia/Tokyo {"mon-fri"} 9:00 19:59
period down-period Office hours Asia/Tokyo {"mon-fri"} 20:00 08:59

EC2の設定

以下のとおりタグを付与します
f:id:cloudfish:20180413103933p:plain

動作確認

インスタンスタイプがt2.nanoの状態です。
f:id:cloudfish:20180413103747p:plain

設定時間がすぎるとt2.microに変更されて起動されました。
f:id:cloudfish:20180413105224p:plain

変更の動きとしては、9:00に動くLambdaで一旦EC2が停止されます。
その後、9:05のLambdaでインスタンスタイプが変更されて起動されます。
停止に時間がかかる場合は、変更されるタイミングももう少し遅くなるかと思います。

インスタンスタイプを自動で変更してくれるのはすごく便利な機能ですね。
平日は大きめのインスタンスタイプとし、週末はタイプを落とすなどしたいユースケースなどで使えそうです。
ただし、稀に変更するインスタンスタイプが枯渇しているため起動できないなどのケースも想定されるので、本番での利用についてはそのあたりの考慮が必要になりますがぜひ利用を検討してみてください

ec2-schedulerでRDSを定期的に起動・停止する

前回、ec2-schedulerでEC2の定期起動・停止を試してみましたが、今回はRDSで実行してみたいと思います。RDSについてもほぼEC2と同様の設定になります

設定方法

DynamoDBのConfigTableに以下を設定
テーブル名はスタック名+ConfigTableになっています。
ex)
月曜から金曜までの9:00 - 20:00(日本時間)の間だけRDSを起動する設定

configレコード
type name use_metrics default_timezone regions schedule_lambda_account scheduled_services tagname trace
config scheduler true Asia/Tokyo { "ap-northeast-1" } true { "ec2", "rds" } Schedule false

scheduled_servicesにrdsを追加します

scheduleレコード
type name description periods timezone
schedule rds_stopstart rds stop start {"weekday_9to20"} Asia/Tokyo
periodレコード
type name description timezone weekdays begintime endtime
period weekday_9to20 Office hours Asia/Tokyo {"mon-fri"} 9:00 20:00

RDS側にタグを付与

対象のRDSに以下のタグを付与します
f:id:cloudfish:20180413083308p:plain

動作確認

まず停止状態にしておき、時間が来るまで待ちます
f:id:cloudfish:20180413083333p:plain

設定した時間内になれば自動的に起動されました
f:id:cloudfish:20180413084842p:plain

注意点

  • RDSクラスターの一部もしくはAuroraはec2-schedulerでは自動起動・停止はできません。
  • EC2でも同様ですが、設定時間から起動が開始されているためインスタンスが利用可能となっているわけではないので、利用可能としたい時間にあわせて事前に起動しておく必要があります。
  • メンテナンスウィンドウを考慮したスケジュールも可能となっています。詳しくはドキュメントを参照してください。
  • 本番で利用する場合は、正常に起動しない場合も想定して監視をするなどの考慮してください。

RDSも停止することが可能になったので、定期的な停止をしてコスト削減を検討してみてはいかがでしょうか。

ec2-schedulerでEC2を定期的に停止してコストを節約しよう

AWS Answerで公開されているec2-schedulerを使ってみました。
EC2の自動起動、停止についてはLambdaを使って色々と工夫されているかと思いますが、このec2-schedulerはかなり高機能なソリューションになっていますのでぜひ利用を検討してもらえればと思います。
aws.amazon.com

ec2-schedulerでできること

構成

以下のような構成で提供されています。
https://d1.awsstatic.com/aws-answers/answers-images/instance-scheduler-architecture.727e008ced5a4b1b656b5c22afb4a2dfc32d7c33.png
デフォルトでは5分毎にLambdaが起動されて特定のタグが付与されているEC2、RDSの自動起動、停止を行っています。

デプロイ方法

以下のリンクからCloudFormationを該当リージョンから実行します。
リージョンごとに設定が必要になります。
Launch CloudFormation

設定方法

DynamoDBのConfigTableに以下のレコードを追加します。
テーブル名はスタック名+ConfigTableになっています。
ex)
月曜から金曜までの9:00 - 20:00(日本時間)の間だけEC2を起動する設定

scheduleレコード
type name description periods timezone
schedule ec2_stopstart ec2 stop start {"weekday_9to20"} Asia/Tokyo
periodレコード
type name description timezone weekdays begintime endtime
period weekday_9to20 Office hours Asia/Tokyo {"mon-fri"} 9:00 20:00

ちなみにconfigレコードはデフォルトタイムゾーンの設定やタグ名の設定など実行時の設定内容を保存しています。

また、レコードの登録については、DynamoDBをコンソールから直接変更してもいいですが、scheduler-cliという専用のCLIも用意されています。
docs.aws.amazon.com

EC2側にタグを付与

対象のEC2に以下のタグを付与します
f:id:cloudfish:20180413090128p:plain

動作確認

正しく設定されていれば、上記の時間以降に対象EC2が停止されます。
f:id:cloudfish:20180412145758p:plain

また、上記の時間設定であれば、9:00になれば対象EC2が起動されています。

注意点

設定した時間にEC2が停止もしくは起動されているわけではないので、例えば必ず9:00から使いたいのであれば、起動時間を考慮して早めに起動しておく必要があります。

このLambda自体のコストとしては、月額約5$程度となります。
起動・停止スケジュールを複数作ることもできますし、クロスアカウントでの実行や実行結果をCloudWatchのカスタムメトリクスに書き込むといったこともできるようです。かなり使いやすいと思うので導入を検討してみてはいかがでしょうか?

SecurityGroup設定のポイント

AWSのインフラ設計にあたって、セキュリティグループの設計は結構重要だと思うのですが、あまり意識して設計されていないケースも見受けられます。
メンテナンス性が考慮されていないと、後々かなり変更しづらくなりますし、誤って設定してしまい障害を発生させてしまうことも起こりえます。
そこで今回は一般的なWebシステム構成をベースにSecurityGroupの設定のポイントを紹介したいと思います。

環境

以下のようなWebシステムを前提に考えてみます。
f:id:cloudfish:20180221210403p:plain
※赤枠がアタッチするセキュリティグループになります。

基本的な設定ポイント

サービスのRole(役割)ごとにSecurityGroupを作成する
内部通信の許可はSourceにSecurityGroupを定義する(IPで定義しない。VPNやDXなどで外部と接続するようなケースはこの限りではないです)
管理用通信(ssh、監視)などは扱うグループ(開発者、インフラなど)ごとにSecurityGroupを分けて管理する。ただし、デフォルトで付与できるSGは5つまでなので分けすぎにも気をつけてください

具体的な設定内容は以下に記載します。
以下は全てInBound通信の設定となります。

サービスの役割ごとに応じたセキュリティグループ

ELB、Webサーバ、RDSがあるためそれぞれにセキュリティグループを作成します

ELB-SG(sg-elbsg)
Type Protocol Port Range Source Description
HTTP TCP 80 0.0.0.0/0 webアクセス用
HTTPS TCP 443 0.0.0.0/0 webアクセス用
WEB-SG(sg-websg)
Type Protocol Port Range Source Description
HTTP TCP 80 sg-elbsg elb→web通信用
HTTPS TCP 443 sg-elbsg elb→web通信用

※sourceにELBのセキュリティグループをセット

DB-SG(sg-dbsg)
Type Protocol Port Range Source Description
MYSQL/Aurora TCP 3306 sg-websg web→db通信用

※DBの種類に応じてポートは変更してください

管理用通信(ssh、監視)のセキュリティグループ

開発者とインフラ担当という想定で2つのセキュリティグループを作成しました。
ここは関係者に応じて作ってください。

DEV-SG(sg-devsg)
Type Protocol Port Range Source Description
SSH TCP 22 xxx.xxx.xxx.xxx/32
SSH TCP 22 xxx.xxx.xxx.xxx/32
INFRA-SG(sg-infrasg)
Type Protocol Port Range Source Description
SSH TCP 22 xxx.xxx.xxx.xxx/32
Custom TCP Rule TCP 1234 xxx.xxx.xxx.xxx/32 監視用

セキュリティグループについては送信元をIPではなくSGを指定することができます。
そうすることで通信経路が分かりやすくなるので、メンテナンス性も向上します。
また、例えばDBへの通信をWebサーバのIPで許可していたりすると、何かしらでIPが変更されたもしくはオートスケールでサーバが増えた際に、接続できなくなるトラブルも発生します。
こうしたことからもできるだけIPやCIDRで設定しない方向で設計してもらえればと思います。

また、OutBoundの通信の制限については、所属している組織のセキュリティポリシーにもよるかと思いますが、セキュアになる反面、トラブル時に原因が分かりにくくなる場合もあるのでその点を注意して使用するかどうかを判断してもらえればと思います。