PHPでEC2が使ってるIPアドレス帯を取得する
EC2の東京リージョンが使ってるIPを取得する必要があった時のメモ。
https://ip-ranges.amazonaws.com/ip-ranges.json
上記のURLでAWSが使ってるIPアドレス帯を取得できる。
$json = file_get_contents('https://ip-ranges.amazonaws.com/ip-ranges.json'); var_dump($json);
こんな感じで取得すると
string(41372) "{ "syncToken": "1429628708", "createDate": "2015-04-21-15-07-01", "prefixes": [ { "ip_prefix": "23.20.0.0/14", "region": "us-east-1", "service": "AMAZON" }, { "ip_prefix": "27.0.0.0/22", "region": "ap-northeast-1", "service": "AMAZON" }, { "ip_prefix": "43.250.192.0/24", "region": "ap-southeast-1", "service": "AMAZON" }, ......
こんな感じでいっぱい出てくる。
ただこれは海外とかも含めAWS全体のサービスで使ってるIPなので、東京リージョンのEC2だけ抜き出します
$json = file_get_contents('https://ip-ranges.amazonaws.com/ip-ranges.json'); $json = json_decode($json, true); $ec2_ips = array(); foreach ($json['prefixes'] as $line) { if ('EC2' === $line['service'] && 'ap-northeast-1' === $line['region']) { $ec2_ips[] = $line['ip_prefix']; } } var_dump($ec2_ips);
これを実行すると
array(17) { [0]=> string(14) "46.51.224.0/19" [1]=> string(12) "52.68.0.0/15" [2]=> string(12) "54.64.0.0/15" [3]=> string(12) "54.92.0.0/17" [4]=> string(12) "54.95.0.0/16" [5]=> string(13) "54.150.0.0/16" [6]=> string(13) "54.168.0.0/16" [7]=> string(13) "54.178.0.0/16" [8]=> string(13) "54.199.0.0/16" [9]=> string(13) "54.238.0.0/16" [10]=> string(13) "54.248.0.0/15" [11]=> string(13) "54.250.0.0/16" [12]=> string(12) "103.4.8.0/21" [13]=> string(15) "175.41.192.0/18" [14]=> string(14) "176.32.64.0/19" [15]=> string(13) "176.34.0.0/19" [16]=> string(14) "176.34.32.0/19" }
東京リージョンのEC2のIP帯だけ取れました!
あとは保存するなりなんなり
ある要素が画面内に入ったらGoogleAnalyticsにイベントを送信する
同僚から聞きましたが、今の広告業界では1インプレッションは画面内に表示された回数らしいです。
PV=インプレッションの時代は終わってたんですね。。
そんな感じで動作するものを実装しなくてはいけなくなったのでメモ。
いつも通りjQuery使います。
宗教でDOMの直接操作を禁止されてる方には申し訳ないですがここで終わりです。
jquery.inview
要素が画面内にあったときにイベントを発生させてくれるjqueryプラグインです。
使い方とかは以下の記事が大変詳しく、参考になりました。
この記事でほぼ終わってるんですが、ハマるポイントがありました。
このプラグインでは画面内に入った時も出た時もイベントが発生しますし、画面内に既に入ってる状態でも更にイベントが発生したりします。
$('target_dom').on('inview', function(e, isInView, visiblePartX, visiblePartY) { // GoogleAnalyticsに通知する処理 ga('send', 'event', {'eventCategory':'category', 'eventAction':'action', 'eventLabel': 'event'}); });
例えばこんな書き方をして、上からスクロールしていった場合
1. 要素の上辺が画面内に入った時
2. 要素全てが画面内に入った時
3. 要素の上辺が画面外に出た時
4. 要素の下辺が画面外に出た時
という感じで4つイベントが発生する可能性があります。
今回は
・画面内に要素が入ったら1カウントし、画面外に出るまでカウントしない
・画面外に出てから再度画面内に入った場合は再度カウントする
という仕様にしたいので以下のようにします。
inviewFlag = false; // 画面内に入ってるかどうかのフラグ $('target_dom').on('inview', function(e, isInView, visiblePartX, visiblePartY) { if (isInView) { if (!inviewFlag) { // GoogleAnalyticsに通知する処理 ga('send', 'event', {'eventCategory':'category', 'eventAction':'action', 'eventLabel': 'event'}); } inviewFlag = true; } else { inviewFlag = false; } });
これで画面内に入ったらGoogleAnalyticsに通知できます。
GoogleAnalyticsでイベントをトラッキングする場合は以下のURLを参考に設定します。
analytics.js のフィールドに関するリファレンス - Google アナリティクス — Google Developers
僕はイベントが発生したページとか、DOMを取得したいので以下のようにしてます。
ga('send', 'event', {'eventCategory':'category', 'eventAction':location.href, 'eventLabel': e.target.id || e.target.className});
これでインプレッションを出せるようになりました。
リダイレクトするときにfile descriptor out of range: Permission denied
crontabにタスク書いたのに実行されなかったときのメモ。
エラー内容をコピペしてググっても全く出てこないので。
PHPで作ったタスクに
*/5 * * * /usr/bin/php test.php 12345>>/var/log/test.log 2>>/var/log/test_error.log
みたいな感じでcrontabに書いたんですが全く実行されませんでした。
ログとか確認しても何も出ないので何でかなーと思ってたんですが、これをこのままコピペして貼り付けたらエラーが出ました
$ /usr/bin/php test.php 12345>>/var/log/test.log 2>>/var/log/test_error.log file descriptor out of range: Permission denied
直訳すると範囲外の数字です的なエラーですね。
原因
標準ストリームのファイル記述子として認識された。
標準出力は1、標準エラー出力は2みたいな感じで12345もストリームと認識されたんだと思います。
解決法
引数とリダイレクトの間にスペースを入れる。
$ /usr/bin/php test.php 12345>>/var/log/test.log 2>>/var/log/test_error.log
これを
$ /usr/bin/php test.php 12345 >>/var/log/test.log 2>>/var/log/test_error.log
こうする。わかりづらいですね。
もしくは文字列とする
$ /usr/bin/php test.php "12345">>/var/log/test.log 2>>/var/log/test_error.log
文字列の場合はストリームのファイル記述子とは認識されませんでした。
9ヶ月で月間1000万PVにスケールするまでに躓いたこと
2月にベータ版を公開してから、9ヶ月(2014年11月)でPVが1000万を超えた記念。
サービスがスケールするにつれて、ググっても同じ悩みを持つ人が少なくなっていって問題解決に時間がかかった。
参考になるかは分からないけどメモ。
そんなの当たり前だろ!ってことも多いですが初めはそういうもんだということで。
お仕事で作ったサービスなのでサービス名は伏せときます。
時系列で躓いた点を上げていきます。まずはスペック
スペック
・クラウド : AWS, さくらクラウド
・言語 : PHP, javascript
・フレームワーク : FulePHP
・Webサーバー : Apache(EC2)
・DBサーバー : Mysql(RDS)
・キャッシュサーバー: Redis(EC2)
俺スペック
・PHPer歴2年
・Linux歴2年
躓いたところ
画像の動的作成は非常に重い処理(2014年3月ごろ)
そんなに重い処理だとはつゆ知らず、URLに幅を指定してやれば動的に画像をリサイズする処理を入れてたんですが、すぐサーバー落ちました。
同時アクセス5くらいで落ちてましたw
対策:画像をアップロードするときにリサイズするようにした。
デザインが毎週コロコロ変わるとかで無ければアップロード時にリサイズした方がいいです。
計測してみたらHTMLをレンダリングするまでの時間が300ms位だったのに対し、画像1枚に300〜500ms(デカイ画像だと1秒)とかかかってた。
画像1枚の処理に、URLパースしてDB接続して色々計算してみたいな処理を全部終えるのと同じかそれ以上かかるわけです。
20枚画像あったら20倍ですよ、やばい。
webサーバー1台の限界(2014年4月ごろ)
この頃からグノシーさんとかに補足され始めてちらほらアクセスが集まって来ました。
それまではwebサーバー1台DBサーバー1台でやってて、アクセスが上がるたびに一回サービス止めてインスタンスを良い奴にして再起動みたいな事してました。
ですがある程度のスペックまで上げると、それ以上良いインスタンス使ってもアクセスが捌けなくなりました。
対策:負荷分散しました
このへんは4回に分けて記事書きました。
ネットワーク素人が、さくらクラウドで負荷分散構築した時のメモ1【準備編】 - なりせなるてず
転送量が多すぎる(2014年9月ごろ)
PHPなどの処理はAWSで、画像などの静的ファイルは転送量課金が無いさくらクラウドから配信していたのですが、アクセスが集まると画像だけ非常に遅く表示されるようになりました。
ISDNの古き良き時代を思い出させるサービスとして、これはこれでいいかという気の持ちようで居たのですが上司からダメ出しをくらいました。
さくらクラウドの標準ネットワーク速度は100Mbpsなのでそれをぶっちぎってたわけです。
対策:サーバーの追加と静的ファイルの圧縮
単純に1台サーバーを追加すれば200Mbpsになるので、サーバーを追加しました。
それでは根本的な解決ではないので、静的ファイルを圧縮しました。
javascriptとcssはGruntを使いminifyします。
静的な画像はPNGならtinypngで、JPEGはoptimizillaで極限まで圧縮しました。
転送量が3分の1位まで減りました。サーバー費も浮きますね。
瞬間的アクセスで落ちる(2014年11月ごろから現在)
これはまだ解決しきれてない問題ですが一応。
iPhoneアプリのユーザーが増えてきてアプリでPUSHを送ると瞬間的(5秒間位)に秒間100アクセス以上あり、いつもは秒間5〜10アクセス位なので当然捌ききれず2,3分サービスがほぼ停止状態に陥る。
対策:データの持たせ方の変更と、サーバーの追加
この問題には複数の原因がありました。
・原因1
瞬間的アクセスがあるとすぐにDBが息しなくなるので原因調査したらデータの持たせ方に問題がありました。
アクセス数をページ毎に持たせていたのですが、1ページ1レコードでした。
Update文を発行すると対象行はロックされます。秒間100アクセスなのでロック待ちの処理が大量発生しレスポンスが返ってこなかったのです。
アクセス数を1ページ30レコード位に増やし、ランダムでインクリメントし、表示時は足して表示するようにしました。
これでロック待ちの処理は30分の1になりました。
・原因2
タイムアウトまでの時間が短すぎました。
タイムアウトを5秒に設定していたので高負荷時はレスポンスを返せませんでした。
・原因3
単純にWebサーバーの力不足。
平常時の秒間5アクセス位に合わせてサーバーを建ててるので瞬間的なアクセスには耐えられません。
オートスケールでは秒単位のアクセス増加には間に合いません。
サーバーをずっと建てとけばいいんですが、サーバー費がガッツリかかるのでそれも出来ません。
ここの折り合いがつかず、まだ解決しきれてません。
おわりに
元々プログラマとしてしか仕事してなかったのでサーバー構築・管理は未だに分からない事だらけです。
月間1000万PVとか昔は信じられなかったですが、意外と一人でもなんとかなるもんですね
3ヶ月AWS使ってでハマったこと
EC2とRDSとElastiCache位しか使ってないのでそんなにありませんけども、一応メモ。
RDS
Storage TypeにGeneral Purpose (SSD)というのがあるが、これは気をつけたい。
これを選択した状態でAllocated Storageを100GB未満の数値にすると性能が著しく落ちる時があります。
青文字で書いてある部分に詳細が載っているですけどね。
英語分からないし、青文字で重要そうじゃないので読まずにハマっただけです、ハイ。
Redis on ElastiCache
リクエスト毎の性能差が凄いです。
これはRedisのせいみたいなんですが、EC2から同じデータをGETするのに早い時で10msec位、遅い時で200msec位でした。
AWS Redis on Elastic Cache のBenchmark をしてみた - tech.guitarrapc.cóm
上記の記事で非常に詳しくベンチマークされてて、とても参考になりました。