Posted at

AWS移行 - アプリケーション側の改修ポイント


概要

以前、オンプレから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 キー名