1. @sawanoboly 2012.09
HiganWorks LLC

2. 1. VIP を使っている物理環境を
2. 使い勝手をあまり変えずに
3. クラウドな IaaS に持っていきたい
そのままはやめたほうが良いので置き換える
クラウド向けデザインパターンの一つ

3.  ハートビート
◦ 堅い疎通経路が必要
 仮想 Mac(VRRP では省略 ) の付け替え
◦ 同じ L2 セグメントで VIP 交換が吉
◦ GARP の届く範囲が吉
IaaS のインスタンスで使っても仕方ない。。

4. 仮想 IP に
アクセス
仮想 IP を付け替える
サーバ B
サーバ A
（バックアッ
（プライマリ）
プ）

5.  そもそもサーバの IP を固定と考えられない
 サーバの稼働率も信用してはいけない
◦ 落ちて当然
 プライマリ・バックアップネットワークが近いと
限らない
◦ 遠くてもよい設計
◦ むしろディザスタ耐性と考えても OK
これらをふまえると次のようなデザインも

6. サービス IP に
アクセス
ロードバランサ的インスタンス
（ AWS なら ELB 、ほかなら HAProxy の導入など）
通常バックエンドに指定 バックアップ
サーバ B
サーバ A
（バックアッ
（プライマリ）
プ）

7.  EC2 などにみられる Elastic という表現
⇒ 丈夫とは取らず、良くも悪くも弾力性、信用す
るな。
◦ 使う側の設計が特に大事
◦ Loose なロードシェアで十分なことは多い
 IP を丸々付け替えが必要か考慮する
◦ IP(NS もあり )+ ポートを１単位ととらえれば、 VIP はや
りすぎ感
◦ もちろん EC2 の EIP 付け替えが有効なケースもある

8. サービスホスト名に
アクセス
LB インスタンス A LB インスタンス B
(A レコードの一つ ) (A レコードの一つ )
クラスタ形成
通常バックエンドに指定 バックアップ
サーバ B
サーバ A
（バックアッ
（プライマリ）
プ）

9.  物理で得られていた安定を、 IaaS のインスタン
スでも適用できると思わない。