AWSでインスタンスを停止し、再起動した時にパブリックIPが割り振られない場合

AWS特訓中の宮里です。

AWSでインスタンスを作成したときに、少し困った現象があったため情報共有したいと思います。

AWSで作成したインスタンスを一旦停止後、ネットワークインターフェイスを追加し、再起動した後にパブリックIPが割り振られない現象が発生しました。

?????となりながら、再起動を何度か試すもパブリックIPは復活せず。
作成したばかりのインスタンスだったので、インスタンスを一から作成し直し、特に問題は起こりませんでした。
その後、気になったので原因を調べてみると、AWS公式のドキュメントに今回の現象の解答がありました。

下記、公式のドキュメントから一部引用します。

手動でパブリック IP アドレスをインスタンスに関連付けること、また、手動でインスタンスから割り当て解除することはできません。場合によって、パブリック IP アドレスはインスタンスから解放されたり、新しいインスタンスに割り当てられたりします。
インスタンスが停止または終了されると、インスタンスのパブリック IP アドレスは解放されます。停止していたインスタンスが再起動されると、そのインスタンスには新しいパブリック IP アドレスが送信されます。
VPC 内のインスタンスのパブリック IP アドレスが既に解放されている場合には、複数のネットワークインターフェイスがインスタンスにアタッチされていると、インスタンスに新しいパブリック IP アドレスは送信されません。

出典:
AWS ドキュメント「パブリック IPv4 アドレスと外部 DNS ホスト名」

インスタンスを再起動するときは、プライマリENI以外はインスタンスにアタッチしてはいけないということでした。。。

少しづつ身につけていきたいと思います。

AWSのタイムゾーン設定でハマった件

福岡拠点の宮里です。
先日、アパッチのアクセスログをアーカイブして一定期間保存する作業を行っていたのですが、

apache-loggenでダミーアクセスログの生成

ログを確認していると、何か違和感が…

|02/May/2018:09:24:59 +0000|

私「あれ?もう出社して9時間は経ってて、もう今日も終わっちまうのかなぁって気がしていたけど」

心の中の金子賢「バカヤロー、まだ始まってもいねーよ」


サーバー時刻をUTCからJSTへ変更

あれあれあれと心を鎮めながら、サーバーに設定されているタイムゾーンを確認してみると、

このサーバーのタイムゾーンはUTC。
このままだとなにかと不都合です。
心臓にもわるいので、JST時間帯へ変更したいと思います。

sysconfigディレクトリの設定ファイル(clock)からタイムゾーンを修正します。
ひとまずバックアップ取って、

シンボリックリンクの向き先Asia/Tokyoへ変更します。

サーバーのタイムゾーンがUTCからJSTに変わりました。

これでひと安心かと思いきや、
この作業を行う前にすでに記録されているログの時刻をJSTに修正しないと何かと収まりがわるいです。
なので、USTで記録されているログをJSTへと変換するスクリプトを作りたいと思います。


既に出力されているログの時刻をJSTへ修正

スクリプトは、サーバーに標準でインストールされているpythonで作成してライブラリをひとつだけ追加します。

pytzの取得

JSTへ変換するスクリプト
changeJst.py

粗いスクリプトですが、ひとまず期待通りに動くことが確認できましたので、作業するサーバーのhttpdを停止してスクリプトを実行しました。ちなみにAWSのELBがunhealthyを認識して振り分けを開始するまで約1分~2分ほどかかるようです。認識する前にhttpdを止めると502で振り分けもされなくなるので注意が必要です。

処理するディレクトリのバックアップを取って実行。

なんとか完了です。
サーバー時刻もUTCからJSTへ変更します。
その後、httpdを再起動。
無事に現在時刻が18時に修正されました。
やっと終わっちまえます。


あれ、cronの実行がおかしい

それから様子をみること数日。
dateコマンドやログに出力される時刻はしっかりUTCからJSTに変更がされているけど、cronに設定したタスクの実行時間がおかしい!どうにも9時間遅れて実行されている!と気づきました。
調べてみるとサーバーのタイムゾーンを変更しただけではcronの実行時刻への反映がされないようです。crondを再起動してJSTタイムゾーンの反映が必要でした。。。

crontabの設定ファイルへtimezoneを記述して、crondの再起動。

これでcronの実行時間にもJSTが反映されました。

VPSサーバーのリソース不足を回避する方法

福岡拠点の野田です。もうすぐ花見の季節ですね。来週か再来週あたり、お昼休みの合間を縫って花見に行きたいと思っています。

さて、今日は、仮想サーバーのリソース状況について話をしようと思います。
皆さんは、VPS環境で以下のような画面を見たことがありますでしょうか。開発用だったり、低予算の貧弱な環境では、結構こういう場面に遭遇することもあります。

The following exception is caused by a lack of memory or swap, or not having swap configured
Check https://getcomposer.org/doc/articles/troubleshooting.md#proc-open-fork-failed-errors for details
[ErrorException]
proc_open(): fork failed - Cannot allocate memory

上記は、composer を実行した際に発生したエラーです。このエラーがでたあと、httpd をいったん停止してから実行すると普通に実行できたりします。これは、仮想サーバーのリソースが不足するために発生しているエラーになります。こういうときは、都度、エラーが出るたび、httpdを止めて、ということをしなければいけないのでしょうか。

仮想サーバのリソース状況をチェックするには以下のようなコマンドがあります。
cat /proc/user_beancounters

この中のprivvmpagesという値に注目します。これは、プライベート仮想メモリサイズです。リソースを解放するためには、httpd など消費リソースが大きいサービスを再起動するとリソースが解放されます。

以下は、リソース情報をチェックし、閾値を越えてリソースが足りない状態になると httpd サーバーを再起動するスクリプトになります。

/root/bin/restart.sh

シェルを毎分 cron 実行したら、リソースがないときは、httpdを再起動して、適宜、リソースが解放されるという仕組みです。

ちなみに800 というのはなんとなくの感覚値です(・ω<) 。某VPSサーバーでは、httpd を再起動すると 3000 くらいまで回復します。300 とか切るとセグメンテーションエラーとかメモリ関連のエラーがよく発生します。

これでサーバーのリソース不足でエラーとなるイライラも収まるでしょう。それでは、Have a nice server life!