ぼくのかんがえたさいきょうの高ディスクI/Oマシン
ようやくトラウマから覚め、まとめる気になりました（その話はまた後日）。
数ヶ月前の事を当時のメモを参考にしつつ、思い出しながら書きます。
ここ数年、某所に旅行に行く度にサーバがぶっ飛んで（多分ヤンデレ）、復旧作業が発生します。
（最近は旅行先からsshで入って構ってあげるようにしてます。やれやれだぜ）
今年は、合計600GB強のデータ（今回のプロダクトで利用しているデータストア8台分）をマージしなければならないという事態になりました。
さすがに震えた。
今回のマージ作業の性質として、
- データストア数台分のデータの中から、ユニークな部分を検索し、1つのファイルに書き出し
- 過去同様の作業経験より、ボトルネックは書き出し部分（ディスクI/Oの書き込み性能）
- マージ作業でメモリはほとんど使わない
という点があげられます。
どうやら勤め先のサーバのスペックだとマージだけで1週間以上かかりそうで、とにかく高速なディスクI/Oを持つマシンが必要に。
- 最終的にマージ結果のファイルサイズは100GBぐらいに落ち着く
- gzで圧縮すれば、元データは1ファイルあたり約15GB、合計120GB程度になる
- 作業用ファイルだけ解凍すれば良いので、同時に必要となるストレージサイズは最低400GB程度（約120+約80*2+約100GB）
以上の点を頭におきつつ、amazon Web services（AWS）のインスタンス一覧を見ていた所、あるではないですか、素敵なインスタンスが！
最終的に利用したのはストレージに特化したインスタンスではなく、メモリに特化したインスタンスである
High Memory Cluster Eight Extra Large (cr1.8xlarge) instance
米国西海岸（オレゴン）リージョン（us-west-2）
（毎時$3.500かかる…！）
です。
※当時東京リージョンで使えませんでした
これは
「単一ディスクならメモリをマウントしてRAMディスクとして使うのが一番速いんや！」
という思想だった為です。
※無検証
このcr1.8xlargeインスタンス、スペックとしては
244GBメモリ
となっております。うーんメモリお化け。
どうせインスタンスは揮発性、SSD2つはなりふり構わずRAID 0で組みます。
結果
18GBメモリ
226GB RAMディスク
という構成に。ひいっ化物！
※18GB残したのは適当です（なんで16GBにしなかったんだろう…記憶なし）。
このスペックなら、東京->西海岸、西海岸->東京と、ファイルの転送に多少時間がかかっても、十分お釣りが来る、と読みました。
トータル466GBあるので、うまくやれば（gzファイルとマージ先ファイルをRAMディスク上に、gzファイルを解凍した元データをSSDに）手間がかかりますがなんとかなりますし。
結果、1週間かかりそうだった作業が、作業自体は1日程度で終わりました…
（途中、高速転送ツールであるTsunami UDPを使用しようとしてうまく動かず、普通にrsyncで送ったり、OSのバージョン違いでデータストアのインストールに手間取ったりして、結局2日近くかかった）
2ファイルマージするのに40分かからなかったのを見て、ブヒィィィってなりましたもんね。
ちなみにTsunami UDPについては下記参照。使ってみたいんですよねーこれ。
リージョン間高速データ転送
http://ijin.github.io/blog/2013/04/03/accelerating-cross-region-data-transfer/
cr1.8xlargeを単一インスタンスでこんな使い方したのは珍しいんじゃないかなーと…
ありがとう、そしてありがとうAWS！
以下作業手順です。
今回一般的に配布されているイメージを利用しました。
AMIはCentOS 6.4の「ami-503bae60」を使用。
CentOS 6.4 AMI available
インスタンスの立ちあげ、セットアップは省略。
Instance Store(Ephemeral Store)を全て付けるのを忘れずに。
まずは必要となるものをインストール
$ sudo yum update -y $ sudo yum install mdadm xfsprogs -y
マウントを外す
$ umount /dev/xvdb $ sudo blockdev --setra 65536 /dev/xvdb $ sudo mkfs.xfs -f -l version=2 -l size=64m -l lazy-count=1 /dev/xvdb $ umount /dev/xvdc $ sudo blockdev --setra 65536 /dev/xvdc $ sudo mkfs.xfs -f -l version=2 -l size=64m -l lazy-count=1 /dev/xvdc
RAID 0作成
$ yes | sudo mdadm --create --verbose /dev/md0 --level=0 -c256 --raid-devices=2 /dev/xvdb /dev/xvdc $ sudo echo 'DEVICE /dev/xvdb /dev/xvdc' > /etc/mdadm.conf $ sudo mdadm --detail --scan >> /etc/mdadm.conf
ファイルシステムを作成
$ sudo blockdev --setra 65536 /dev/md0 $ sudo mkfs.xfs -f -l version=2 -l size=64m -l lazy-count=1 /dev/md0 $ sudo mkdir -p /mnt/md0 $ sudo mount -t xfs -o discard,nobarrier,relatime /dev/md0 /mnt/md0 $ cd /mnt/md0
以上参照）
訳：エフェメラルディスクでRAID0
http://understeer.hatenablog.com/entry/2012/03/22/080938
Amazon EC2でEphemeral StoreをRAID0構成にしてディスクI/O性能を上げる
http://dev.classmethod.jp/cloud/amazon-ec2-ephemeral-store-raid0/
メモリマウント（/zなのは趣味）
umount /dev/shm mount -t tmpfs -o size=226G tmpfs /z df -ih /z
参照）
tmpfs は本当に容量が動的なのか
http://d.hatena.ne.jp/naoya/20060217/1140176470
これで環境完成！
