zuntan02のはてなブログ

備忘録的なものです。時々職場の技術者ブログにも転記してますが、メインはこちらで。

【Route53+CloudFront+S3+ACM】転送設定:http(s)://hoge.jp/をhttps://sub.hoge.jpにリダイレクト

【作業メモ】

1)Amazon S3 コンソールで、hoge.jp(転送元) の正確な名前を使用して S3 バケットを作成します。

ドメイン名外は全てデフォルトで作成

2)作成したバケットを選択し、[プロパティ] -[Static website hosting]

[リクエストをリダイレクトする]
ターゲットバケットまたはドメイン:sub.hoge.jp
プロトコルhttps

3)Route 53 コンソールで、Aliasにhoge.jp のホストゾーンを選択します。

以下の様に設定

Name:hoge.jp
Type:A
Alias:s3-website-ap-northeast-1.amazonaws.com
Routing Policy:Simple
Evaluate Target Health:No
4)確認

http://hoge.jp → https://sub.hoge.jp
http://hoge.jp/aaa → https://sub.hoge.jp/aaa

★注意★
このままでは、http://hoge.jp(非SSL)からのリダイレクトは対応できてますが、https://hoge.jp(SSL)からはリダイレクトされません。
SSL側も対応する場合は引き続き下記の作業を実施

5)Certificate Managerで証明書を作る

[Certificate Manager]→「hoge.jp」の証明書を取得しておきます(手順は汎用的なものなので省略)

6)CloudFrontのDistributionを新しく作りOriginをS3にし証明書を設定します

[CloudFront]-[Create Distribution]-[GetStarted]

[Origin Domain Name]
→先ほどのS3の設定の時に出てきた{バケット名}.s3-website-{リージョン名}.amazonaws.comを指定します。
(サジェストで出るバケットは指定しちゃダメ)
hoge.jp.s3-website-ap-northeast-1.amazonaws.com

[Alternate Domain Names(CNAMEs)]
hoge.jp(自分のリダイレクト元にしたいドメイン名を指定)

[SSL Certificate]
→Custom SSL Certificateで先ほどのACMhoge.jp)を指定

後はすべてDefaultでCreate

7)Route53でCloudFrontに向くようにRecordを追加する

Alias:s3-website-ap-northeast-1.amazonaws.com

Alias:XXXXXXXXXXXXXX.cloudfront.net

【AWS】Wordpress冗長化をALBとEFSだけでやってみたら遅すぎて無理だったけどCloudFrontとOPcacheでなんとかなったログ

【概要】

EFSが東京に来た時、Wordpress冗長化の決定打では!?とか思ってたんだけど、事例が全然出てこない。遅い…遅い…という怨嗟の声は聞こえたりするので実際にどれくらい遅いのかやってみたら画像が「ぱら・・・ぱら・・ぱ・・・(止まる」みたいな感じでホントに遅かった。CloudFrontで静的ファイルをキャッシュしてみたけど、WordpressだとまずPHPそのものの処理が重い。
対策として静的ファイルをCloudFrontで、phpはOPCacheでさばくことでEBS単体の時と遜色ない性能となった。

【参考】

https://hacknote.jp/archives/38521/
ランダムリードがEBS汎用SSDで18MB/sのところ、EFSは108 KB/sとのこと。なるほどそんな感じだった。

https://postd.cc/wordpress-on-aws-smooth-and-pain-free/
EFSとOPcacheとCloudFrontを利用した解決。これがおそらく現状の正答。

【OPcache有無での差異テスト】

1)全部EBS+CloudFrontで画像およびcss/jsをキャッシュ
2)EFSにWordpress全部入り+CloudFrontで画像およびcss/jsをキャッシュ
3)EFSにWordpress全部入り+CloudFrontで画像およびcss/jsをキャッシュ、にPHPをOPcacheでキャッシュを追加

種別 PageSpeed InsightsのTTFB(※)値
1)EBS+CF 0.18s
2)EFS+CF 7.46s
3)EFS+CF+OPcache 0.33s

※TTFB:Time To First Byte、最初の1バイトが到着するまでの時間

という訳で、WordpressをEFSに全部突っ込んで冗長化しても性能が……という向きにはOPcache+CloudFrontで。

構築メモ

【参考】
https://www.sodo-shed.com/archives/12629
→東京リージョンで使えるようになったAmazon EFSを使って手軽なWordPress冗長化

https://docs.aws.amazon.com/ja_jp/efs/latest/ug/mount-fs-auto-mount-onreboot.html
Amazon EFS ファイルシステムの自動マウント

https://hacknote.jp/archives/38406/
→キャッシュヒット率を上げつつ管理画面に影響を出さない

1) EFS用のSecurityGroupを作成する
[EC2]-[セキュリティグループ]-[セキュリティグループの作成]
→VPCからのアクセスのみすべて許可
2) EFSを作成する
[EFS]-[ファイルシステム]-[ファイルシステムの作成]
ステップ 1: ファイルシステムアクセスの設定
→VPCとマウントターゲットを指定

ステップ 2: オプション設定の構成
パフォーマンスモードの選択:汎用
スループットモードの選択:バースト★
暗号化の有効化:チェック無し

★注意★
BackWPupでデイリーバックアップしてたらEFSのバーストクレジットが枯渇してベースライン(50KB/秒)になって499多発を招いたので、環境作ってからしばらくはCloudWatchのBurstCreditBalanceを見守ることをお勧めします!以下のようにバランスしていない場合場合は諦めてプロビジョンドスループット(10MB/秒で$76)とかにしましょう。自戒を込めて……
f:id:zuntan02:20181229104437p:plain

3)マウント
# マウントポイント作成
mkdir /srv/hoge

# マウント実行
mount -t efs <EFSのファイルシステムID>:/ /srv/hoge

# 再起動後のマウント対応
vi /etc/fstab
# 以下を追記
------------------------------
<EFSのファイルシステムID>:/ /srv/hoge efs defaults,_netdev 0 0
------------------------------

上記のマウントポイントにWordpressを配置、インストールします(通常の作業なので省略)

4)OPCache導入と有効化(以下はnginxの例)
yum -y install php-opcache
systemctl restart php-fpm
systemctl restart nginx
5)CloudFrontで静的ファイル(画像/js/css)キャッシュ対応
[CloudFront]-[Behaviors]-[Create Behavior]

# 以下のパスパターンについてキャッシュを有効化
Path Pattern:*.jpg
Path Pattern:*.png
Path Pattern:*.css
Path Pattern:*.js

# Behavior設定
Origin:ELB
Viewer Protocol Policy:Redirect HTTP to HTTPS
Allowed HTTP Methods:[GET, HEAD]
Cache Based on Selected Request Headers:Whitelist

Whitelist Headers
=====
Authorization	# 管理画面にベーシック認証を入れる時などに必要です。
CloudFront-Forwarded-Proto	# Origin側へプロトコルを通知します。
Host	# Origin側へアクセス先ホスト名を通知します。
=====

Object Caching:Customize
	Minimum TTL:0
	Maximum TTL:31536000	デフォルト1年 ※要調整
	Default TTL:86400		デフォルト1日 ※要調整

Forward Cookies:Whitelist

Whitelist Cookies:(管理画面では画像キャッシュさせない)
	wordpress_logged_in*
	wp-settings*

Query String Forwarding and Caching:None(Improves Caching)

以下デフォルトのままで[Create]
6)CloudFrontで残りのファイルはキャッシュしない対応(Behaviorルールの下端)
[Behaviors]-[Create Behavior]

パスパターン:Defaultについてキャッシュを無効化(TTLを0にするパス、条件を追加)
Path Pattern:Default (*)

# Behavior設定
Origin:ELB
Viewer Protocol Policy:HTTP and HTTPS
Allowed HTTP Methods:[GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE]
Cache Based on Selected Request Headers:Whitelist

Whitelist Headers
=====
Authorization
CloudFront-Forwarded-Proto
Host
=====

Object Caching:Customize
	Minimum TTL:0
	Maximum TTL:0
	Default TTL:0

Forward Cookies:All
Query String Forwarding and Caching:Forward all, cache based on all

以下デフォルトのままで[Create]

f:id:zuntan02:20181211194820p:plain

※その他簡単な検証
丁度Wordpressの4→5化の時期だったので、この構成でWPを4→5に上げたが、特に問題なく終了した。

既存のAWS CodeCommitに接続するアカウントを追加で作成したメモ

【サマリ】

既に存在するAWS CodeCommitリポジトリにIAMアカウントベースで接続する。
(筆者はCodeCommitはおろかGitにも明るくないので誤りがあるかもしれませんが何かの足しになれば)

【作業メモ】

gitのURLをhttpsでやるかsshでやるかで方法が異なります。

HTTPS

手順

1)マネージドコンソールより利用者のIAMを作成(共通)
2)マネージドコンソールより[IAM]-[ユーザー]-対象のIAM詳細-[認証情報]を選択(共通)
3)[AWS CodeCommit の HTTPS Git 認証情報] で、[生成] を選択します。
→CodeCommitにHTTPS接続する際のBasic認証情報が生成されるので保存・連絡

※CentOS6などでgit cloneする場合、basic認証が通らずエラーとなるため、AWS CLI認証情報ヘルパー(未検証)を用いるか、或いは以下のようにして自動的にbasic認証をパスしてみてください

vi ~/.netrc

machine git-codecommit.ap-northeast-1.amazonaws.com
login 認証ID
password 認証パスコード

AWS CLI認証情報ヘルパー
https://docs.aws.amazon.com/ja_jp/codecommit/latest/userguide/setting-up-https-unixes.html

SSH

手順

1)利用者はあらかじめ

cd ~/.ssh
~/.ssh$ ssh-keygen -t rsa -b 2048 -f codecommit

の様にして鍵ファイルを生成し、公開鍵(上記のコマンドであればcodecommit.pub)を確認します
2)マネージドコンソールより利用者のIAMを作成(共通)
3)マネージドコンソールより[IAM]-[ユーザー]-対象のIAM詳細-[認証情報]を選択(共通)
4)「AWS CodeCommit の SSH キー」で公開鍵の中身を貼り付ける
 →成功すると「SSHキーID]が発行されるのでこれを連絡
5)利用者は以下のようにしてsshのConfigを設定し、git clone可能となる
vi ~/.ssh/config

Host git-codecommit.*.amazonaws.com
  User APK*****************
  IdentityFile ~/.ssh/codecommit(秘密鍵名)

Windows10でHostsFileManagerを利用する(.Net Framework 3.5の導入)

【概要】

WindowsPCでhosts書き換えを行いながら現行サイト・構築中のサイトを比較していると結構手間。特にPCに詳しくないお客様はhosts切り替えの説明だけで結構な時間を取ることがある。
(過去にこんな記事も書いた)
これまでもお客様にhosts書き換えを依頼するときに、定番のツール
Hosts File Manager
を紹介してきた(※)が、Win10での導入に当たって.NET Framework 3.5が必要だったため下記のメモを残す
※ブラウザのHosts書き換えプラグインも試してみたけど権限の問題でhostsファイルが書き換えられないことが多くてダメ。

【導入手順】

1)ダウンロード

Vector
https://www.vector.co.jp/soft/winnt/net/se406523.html
よりHFM_2.00_x86_ja.zipをダウンロード

2)インストール

HFM_2.00_x86_ja.zip を展開し、Setup.exeをダブルクリックしてインストール
→「.NET frameworkの3.5を必要とします」と出る場合は
Windows 8、Windows 8.1、および Windows 10 への .NET Framework 3.5 のインストール | Microsoft Docs
より

キーボードの Windows キー Windows ロゴ を押し、「Windows の機能」と入力して、Enter キーを押します。 [Windows 機能の有効化または無効化] ダイアログ ボックスが表示されます。
[.NET Framework 3.5 (.NET 2.0 および 3.0 を含む)] チェック ボックスをオンにして [OK] を選択し、メッセージが表示された場合はコンピューターを再起動します。

を実施して有効化。

3)起動

[スタート]-[Hosts File Manager]-[Hosts File Manager]で起動
※UI自体は非常にシンプルなので迷うことはないかと思います。

■詳細な利用手順はこちら

beyondjapan.com

【AWS】東京リージョンで[t3.medium]を立てようとしたら制限数エラー

【概要】

東京リージョンでt3.mediumのEC2インスタンスを立てようとしたら以下の制限数エラーが出た。

作成失敗
You have requested more instances (1) than your current instance limit of 0 allows for the specified instance type. Please visit http://aws.amazon.com/contact-us/ec2-request to request an adjustment to this limit.

→参考
oreout.hatenablog.com
東京リージョンだと初期値0台とかひどい

【上限緩和申請】

サービス制限の緩和
http://aws.amazon.com/contact-us/ec2-request

f:id:zuntan02:20181019152032p:plain

→一時間くらいで以下のメールが返ってきた

ご依頼いただきましたとおり、 以下のように上限値を設定いたしました。

                      • -

サービス: EC2 インスタンス
リージョン: アジアパシフィック(東京)
プライマリインスタンスタイプ: t3.medium
制限の名前: インスタンス上限
申請する上限数: 5

                      • -

早い!

以上。

【AWS】EIPを付与しているのにパブリックDNSが出ない

【原因】

  • VPCの設定で有効にしてない
  • EIPかパブリックIPが割り当てられてない

VPCの設定】

EIPは割り当ててるのにパブリックDNSが出ない!っていう感じだったのでメモ。
[アクション]-[DNSホスト名の編集]-[DNSホスト名]が「いいえ」の場合は「はい」に。
f:id:zuntan02:20180831194316p:plain
f:id:zuntan02:20180831194322p:plain
以上