2013-05-27

EBS: Provisioned IOPSの性能・ベンチマーク

そのものずばりのページが、EC2のドキュメントにあるので、メモ。

Increasing EBS Performance - Amazon Elastic Compute Cloud

性能を出すには

RAID0かRAID1+0 (RAID10) でストライピング
平均キューレングスをチェック
EBSボリューム利用前にプリロード(※)しておく
EBS-Optimized インスタンスを使う

とか。

プリロード

$ dd if=/dev/sdf of=/dev/null

をやっておく。（と上記URLにも書いてある）

ベンチマーク

PIOPSは、ブロックサイズ16KBなので fioをかけるときも --bs=16kをつけている

fio --directory=/media/p_iops_vol0 
--name fio_test_file --direct=1 --rw=randwrite --bs=16k --size=1G 
--numjobs=16 --time_based --runtime=180 --group_reporting

4KBとか8KBのベンチのときは、指定したIOPSとはかけ離れた値が出る場合があるので、適宜、脳内補正が必要となる。

2013-03-28

EC2: GlusterFS in AWS

AWS EC2 訳 S3 MongoDB

GlusterFS on AWSといえば、 #ヤマンのスライドですね。(後述)

こちらの記事では、実際の設定手順等が書かれてある。

GlusterFS in AWS | Celingest Blog – Feel the Cloud

---以下、拾い訳--

事前の考慮点

アベイラビリティゾーン(AZ)を跨いだ2台のサーバで ext4なEBSボリュームを複製する、といった検証(PoC)に入る前に、GlusterFSを使うべきではない場合を列挙した。

複数同時にシーケンシャルにファイル書き込みをする場合：　ログのように複数のサーバから書き込まれる、というようにGlusterFSにログを保存する場合、ロック機構( locking system) が、深刻な問題を引き起こす可能性がある。理想的な解決方法は、ローカルのログに追記書き込みし、S3にアーカイブする方法。必要であれば、S3にログを保存する前か後に複数のサーバログを統合することも出来る。
継続的に変更されるファイル：　PHPセッションファイルやキャッシュなどは、性能に影響する。セッションを統合管理したいのであれば、データベース( RDS, DynamoDB, SimpleDB)や memcached( ElastiCache) を使うべきで、GlusterFSのレプリケーション層に負担をかけることはない。アプリケーションのセッション保持の部分に手を入れられない場合、ローカルフォルダか共有メモリ( shm)を使い、 ELBの stickyセッションで振り分ければ、アプリケーションは透過的になる
キャッシュ無しの複雑なPHP：　アプリのコードをリポジトリに保存すれば、複数台のサーバに簡単にデプロイしてバージョンコントロールできる。GlusterFS上にコードを設置するのが避けられないなら、APCやXCacheといったキャッシュを使って stat()による性能劣化を避けるようにする必要がある。

インストール

Amazon LinuxのメインリポジトリにはGlusterFSパッケージがあるので、外部リポジトリを使う必要はない。各ノードで以下の手順でインストールできる。

yum install fuse fuse-libs glusterfs-server glusterfs-fuse nfs-utils
chkconfig glusterd on
chkconfig glusterfsd on
chkconfig rpcbind on
service glusterd start
service rpcbind start

Fuseとnfsパッケージは GlusterFSのボリュームをマウントするために必要となる。我々は互換性のためNFSモードをオススメしている。

設定

EBSボリューム（エフェメラルストレージでも可）にPOSIX ファイルシステム互換のext4パーティションを用意し、各ノードで以下を実行する。

mkfs.ext4 -m 1 -L gluster /dev/sdg
echo -e "LABEL=gluster\t/export\text4\tnoatime\t0\t2" >> /etc/fstab
mkdir /export
mount /export

GlusterFSボリュームを作成するコマンドを実行するために、複数のノードから1台を選ぶ。インスタンス間の通信はフルアクセスであること。firewallや Security Groupの制限をなくしておく。

gluster peer probe $SERVIDOR2
gluster volume create webs replica 2 transport tcp $SERVIDOR1:/export $SERVIDOR2:/export
gluster volume start webs
gluster volume set webs auth.allow '*'
gluster volume set webs performance.cache-size 256MB

$SERVER1と$SERVER2はインスタンスのDNS名に置き換える。

２つの非標準のオプションを設定する。１つめは、 auth.allowで、全てのIPからのアクセスを受け付けるようにしておく。替わりに、Security Groupでアクセス制御する。２つめは、 performance.cache-sizeで、性能向上のためキャッシュメモリの一部を使えるようにする。

mkdir -p /home/webs
mount -t nfs -o _netdev,noatime,vers=3 localhost:/webs /home/webs
# If we want to mount it automatically, we need to modify /etc/fstab
echo -e "localhost:/webs\t/home/webs\tnfs\t_netdev,noatime,vers=3\t0\t0" >> /etc/fstab
chkconfig netfs on

これで、 /home/webs にコンテンツを保存出来るようになった。保存したコンテンツは自動的にもう片方のインスタンスに複製される。stat() がGlusterFSのヘルスチェックを矯正するので、ls -l をフォルダで実行することで複製を強制実行できる。

--以下、 #ヤマンによるGlusterFS on AWSのスライド--

Awsではじめるgluster fs 20120726-public from Akio Katayama

2012-09-21

訳：どのようにしてVimeoはEC2の費用を50%削減したか

AWS EC2 訳

これは面白い記事。

High Scalability - High Scalability - How Vimeo Saves 50% on EC2 by Playing a Smarter Game

＝＝

ビデオトランスコーディング処理用のEC2インスタンス費用を、スポットインスタンス、オンデマンドインスタンス、リザーブドインスタンスを賢く組み合わせることで50%も費用を削減している。 Vimeo on EC2 を見るとその考え方がわかる。この資料は2011年のものだが、リザーブドインスタンスマーケットができたので、彼らの戦略も変わってくるだろう。

Vimeoのアプローチは

閾値以上にbidしない。閾値はオンデマンド価格の80%に設定
いかなるときも、 10以上のスポットリクエストを出さない
１時間前の平均価格より10%高くbidする
非ピーク時の負荷に必要なぶんだけリザーブを買う
優先度が低く急ぎではないジョブに対してスポットインスタンスを使う
スポットインスタンスをterminateしない。Amazonがやってくれる
スポット上で動いているジョブは、リトライする仕掛けを。
オープンなスポットリクエストに注意。リクエストの期限を伸ばすこと。
長いジョブには、より高くbidしたスポットかオンデマンドを使う
スポットが飽和したらオンデマンドにフェイルオーバーしろ

＝＝

2012-08-15

リーンスタートアップとDevOps

訳 Develop Ops

ビジネスとシステムという少し距離のある２つだが、共通点が非常に多いし、ゴールは実は同じという点で、リーンスタートアップとDevOpsを組み合わせることは非常に効果的だろう。

つまり、常に計測可能な数字をもって仮説とし、それを測定する仕組みも必ず一緒に組み入れその結果を検証し次のサイクルを回す。素早いサイクルで回すには、DevOps(特に自動化)は欠かせない要素になるし、ビジネスサイドとシステムサイド（とくにDevelopmentとOperation)が協業する文化が一番大事になってくる、ということ。

Devops and The Lean Startup | Agile Zone

===

リーンスタートアップは、我々が顧客に本当に意味のあることに注力すべきである、と説いている。データに基づいた試みを短いサイクルでまわす科学的な手法を使うことを進めている。しかし、自社ビジネスのすべての領域を網羅して試みを継続的に行うには、全社の協力が必要になる。まさに、DevOpsのゴールの一つとされている、クロスファンクションなチームが必要である。リーンスタートアップとDevOpsの考えがどのように相互作用して、製品開発フローを成功に導くかを見てみよう。

データ駆動試験

リーンスタートアップの手法では、新機能に対するビジネス的な評価軸に対する明確な仮説を立てることで、製品開発を開始する。もしホームページに”購読”ボタンを加えようとするなら、まず最初に期待値を明確化する（例えば「購読率は0.5%である」)。仮説が用意できたら、どのように結果を計測するかを考える。DevOpsの強みでもある、何をどのように計測するか？を知ることがアイディアの初期段階である。また、データに基づいた試験として機能開発を進めることは、早期に社内でフィードバックを得ることになる。

DevOps : 協業の文化

DevOpsは、クロスファンクションチームの全メンバー間で協業する文化である。開発フローの運用サイドから発生したDevOpsは、すべてのフローを最適化することを狙っている。そしてDevOpsは、できる限り速く顧客について知るための試験を実行する際に必要となることでもある。引き継ぎや遅延といったすべての無駄は、顧客について学ぶスピードを遅くし、そして邪魔をする。

すごい力を組み合わせる

革新的な製品を作ろうとしているなら、できる限りの助けを使うべきだ。リーンスタートアップのテクニックを適用することで、本当に価値のあるものを確実に作れるだろう。 DevOpsの文化を取り入れることで、クロスファンクションチーム全体が、フィードバック・ループに入ることができる。素早く製品を見直す( "rinse & repeat")なら、自動化を使うことでそのスピードを早くすることができる。そして、製品の変更が現実のビジネスに与えた影響の測定ができるようになる。これが、あたなと、あなたの顧客にとっての、成功のためのキーである。