■[統計] 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 によるハイパフォーマンス・コンピューティング」に取り組んでいます。
並列対応したアプリケーションのリリースを待つのも良いのですが、自らも低消費電力環境を運用することで、満足にコンピュータ・パフォーマンスの成功談（体験談）を広めることが自分に課せられた使命であるように感じています。
■まとめ
計算処理が遅いからマシンパワーを増強するという考えは、もう終わりにしましょう。
何故計算処理が遅いのか、その計算手法で本当に合っているのか。コンピュータを使った商売をなさっている方は、一緒に考えていきませんか？
以上