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で設定可能となっています。

※PHPマニュアル抜粋

参考

PHP: Where a configuration setting may be set - Manual

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

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

環境

Mac Sierra
fish 2.2.0

設定方法

bashやzshについては以下の公式で設定方法が紹介されているのですが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の設定

以下のとおりタグを付与します

動作確認

インスタンスタイプがt2.nanoの状態です。

設定時間がすぎるとt2.microに変更されて起動されました。

変更の動きとしては、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に以下のタグを付与します

動作確認

まず停止状態にしておき、時間が来るまで待ちます

設定した時間内になれば自動的に起動されました

注意点

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

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

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

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

ec2-schedulerでできること

• EC2の自動起動・停止
• RDSの自動起動・停止
• EC2のインスタンスタイプ変更

構成

以下のような構成で提供されています。

デフォルトでは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に以下のタグを付与します

動作確認

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

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

注意点

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

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

参考

AWS Instance Scheduler - AWS Instance Scheduler

SecurityGroup設定のポイント

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

環境

以下のようなWebシステムを前提に考えてみます。

※赤枠がアタッチするセキュリティグループになります。

基本的な設定ポイント

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

AWS GlueのJob Bookmarkの使い方

実際にETLで処理するケースとしては、1日1回定期的に処理するなどのケースが多いと思います。
この場合、追加分のみを抽出してETL処理をする必要があります。
Glueには、前回どこまで処理したかを管理するJob Bookmarksという機能があります。
今回はこのJob Bookmarksを使ってみたいと思います。

確認用のETL処理

S3に配置したapacheのアクセスログをparquet形式に変換します。

手順概要

①S3にapacheのアクセスログを配置

②Crawler設定、実行

③Job作成、実行

④変換データ確認

⑤S3に追加のログをアップロード

⑥Job再実行

⑦変換データ確認

準備

以下のようなフォーマットのapacheログをそれぞれ10行程度ずつ2ファイル用意します。

200.69.224.58 - - [16/Jan/2018:18:34:42 +0900] "GET /item/computers/2216 HTTP/1.1" 200 65 "/item/games/643" "Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)"
40.66.156.206 - - [16/Jan/2018:18:34:42 +0900] "GET /item/games/4918 HTTP/1.1" 200 73 "/item/games/2145" "Mozilla/5.0 (iPad; CPU OS 5_0_1 like Mac OS X) AppleWebKit/534.46 (KHTML, like Gecko) Version/5.1 Mobile/9A405 Safari/7534.48.3"
48.201.76.35 - - [16/Jan/2018:18:34:42 +0900] "GET /category/toys HTTP/1.1" 200 85 "-" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; YTB730; GTB7.2; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; .NET4.0C; .NET4.0E; Media Center PC 6.0)"

①S3にapacheのアクセスログを配置

S3にbucketを作成し、準備で作成したファイルの一つ目をアップロードします。

②Crawler設定、実行

①で作成したS3用のクローラーを設定して実行します。

③Job作成、実行

左ペインのJobsを選択し「Add Job」をクリックしてJobを追加します。
この時、Job BookmarkをEnableに変更します。それ以外については環境に応じて設定してください。

Job bookmarkについては、以下の設定値があります。
デフォルトはDisableになります。

Job bookmark	説明
Enable	前回実行した以降のデータを処理
Disable	常に全データを処理
Pause	前回実行した以降のデータを処理するが、状態を更新しない

※Pauseはどういう時に使えばいいかが分かっていません。

Jobの設定が完了したら、実行してください。

④変換データ確認

上記でJobが正常に実行されたら、変換後のデータを確認します。
まずは、変換先のS3用のクローラーを設定します。
以下のようにクロール対象から_common_metadataと_metadataを除外するようにセットします。

クローラーを実行後、AthenaからSQLを実行してデータが変換されていることを確認します。
今回は1つ目のファイルにはアクセスログを10行用意しました。

⑤S3に追加のログをアップロード

準備で作成したapacheログファイルの二つ目をソースとなるS3にアップロードします。

⑥Job再実行

再度、同一Jobを実行します。

⑦変換データ確認

上記Jobが正常終了したら、Athenaから④で確認したの同様のSQLを実行して増分のみ追加されていることを確認してください。Job BookmarkがDisableの場合は、再実行時に全件処理されてしまいます。
もし想定通りの結果とならないようであればJob Bookmarkの設定値を再確認してください。
2つ目のファイルにはアクセスログを11行用意しているので、以下のとおり全部で21行となり増分データのみ追加されました

現状、このJob Bookmarkについては、ソースがS3のときのみ利用可能となっています。
RDSなどのDBの場合については、処理のなかでフィルタする必要があります。

実際にBookmarkを本番で使うには、ジョブがエラーとなった場合などどのようにリトライするかをしっかり想定しておく必要がありそうですね。