#概要
以前、オンプレからAWSへWEBアプリを移行した際に行ったことです。

##ELBを挟んだ
以前はCDN（Akamai）からWebサーバーを直接見るようにしていましたが、間にELBをはさみました

以前： Akamai -> Apache -> アプリ(php)
今　： Akamai -> ELB -> Apache -> アプリ(php)

SSL証明書は、ApacheからELBに移しました。
##ELBが挟まったことによる影響
通信がSSLかそうでないかを判断している部分に影響がありました。
インターネットからELBの間はSSL通信ですが、
ELBからEC2の間は80番での通信なので、下記のようなコードだと正常に動作しません。

ssl通信かどうか

if($_SERVER["SERVER_PORT"] == 443){
	echo "SSL通信です";
}

同じような判別をするなら下記のようなコードを記述する必要があります。

ssl通信かどうか。ELB経由

if($_SERVER["HTTP_X_FORWARDED_PORT"] == 443){
	echo "SSL通信です";
}

改修範囲が多い場合、下記のコードでも可能です。

強引に解決

$_SERVER['SERVER_PORT'] = $_SERVER["HTTP_X_FORWARDED_PORT"];
if($_SERVER["SERVER_PORT"] == 443){
	echo "SSL通信です";
}

##リソースのIPをprivateドメインで管理
セッションサーバーをElasticacheにした際、IPの管理方法を見直しました。
今まではphp.iniに直接キャッシュサーバーのエンドポイントを書いていましたが、route53のprivateドメインを使用するように変更しました。
これをすることで、セッションサーバーのエンドポイントが変更になってもRoute53の設定を変更するのみで済み、アプリやサーバーの設定を変更する必要がなくなります。

以下のようにHosted zonesにレコードを追加する。

追加したレコード

prd-web-redis.private.XXX.jp
CNAME
prd-redis.XXXXX.cache.amazonaws.com　（redisのプライマリエンドポイント）

エンドポイントをRoute53のprivateドメインにする運用方法は、RDSでも有効です。
エンドポイントの変更は本番稼働中の場合には、そう多くあることではありませんが、開発中は頻繁にあります。

##sessionの保存先をredisに変更
phpのセッションの保存先にelasticache を使用する。
当初、elasticacheのmemcachedを使用していたが、レプリケーション機能が付いていなかったためRedisに変更した。

phpのredisモジュールをインストール

sudo yum --enablerepo=epel install php-pecl-redis

sessionの保存先をredisに変更

sudo vi /etc/php.ini

; session.save_handler = files
; session.save_path = "/var/lib/php/session"
----------------------------------------

sudo vi /etc/php.d/redis.ini

session.save_handler = redis
session.save_path = "tcp://prd-web-redis.private.XXX.jp:6379"

##redisに値が保存されているか確認
redis cliを用いてelasticacheに値が保存されているか確認する。
※telnet等、他の手段を使って確認する方法もある。

redisインストール。値が保存されているか確認する

sudo yum --enablerepo=epel install redis

#以下のコマンドで値が保存されていることを確認した
redis-cli -c -h prd-web-redis.private.XXX.jp -p 6379
keys *
get キー名