■[統計] Alexa に見る東日本大震災後のトラフィック推移（fxfrog.com)

・今年の東日本大震災直後に節電することは当たり前の行動と感じ、自宅サーバはすべてシャットダウン（仮想インスタンスを多数起動していたが大幅に縮小）、Web サーバも一時的に amazon EC2, S3 へ待避させてからレンタルサーバへ移行。

その行動模様が Alexa トラフィック統計で確認できるのでご紹介します。

—

■震災直後に fxfrog.com 完全停止したグラフ。 Time on Site (minutes) / fxfrog.com

震災までは、各種クローラや bot が常時稼働していました。

—

■netcraft で Web Server 稼働状況を振り返ると、震災後は 21-Mar-2011 に、取りあえず確保した NEC BIGLOBE に一時設置し、その後 現在使用している ExpressWeb / DataJapan 　へ移設しました。

//　Broadgate は旧 UCOM (USEN FTTH CIDR /29) の自宅サーバで激安 SSL 証明書も乗せ、それなりに面白い検証も実施していました。 ExpressWeb は SSL 使えないのと、時々意味不明な挙動で笑わせてくれますが、安いほうだと思います。

ーーー

■現在、Alexa トラフィックランクが向上する施策を展開中。

デイリーペイジビュー（ユーザ単位）で見ても判明する通り、震災直後は本当に運用停止していました。

ーーー

■自宅の物理サーバと運用変更。

これまで電力消費をするだけのハイパワーマシンから、低消費電力で効率良いマシンを真剣にデザインし、ビックリするほどの運用効率へ転換することに成功しました。

これには意識変化が伴っています。

具体的には intel meny cores （メニーコア）で運用するのではなく、並列化できるものは並列環境で計算する。当社では震災を機に「NVIDIA CUDA によるハイパフォーマンス・コンピューティング」に取り組んでいます。

並列対応したアプリケーションのリリースを待つのも良いのですが、自らも低消費電力環境を運用することで、満足にコンピュータ・パフォーマンスの成功談（体験談）を広めることが自分に課せられた使命であるように感じています。

■まとめ

計算処理が遅いからマシンパワーを増強するという考えは、もう終わりにしましょう。

何故計算処理が遅いのか、その計算手法で本当に合っているのか。コンピュータを使った商売をなさっている方は、一緒に考えていきませんか？

以上