@sawanoboly 2012.09HiganWorks LLC

1. VIP を使っている物理環境を2. 使い勝手をあまり変えずに3. クラウドな IaaS に持っていきたい

そのままはやめたほうが良いので置き換えるクラウド向けデザインパターンの一つ

ハートビート◦ 堅い疎通経路が必要

仮想 Mac(VRRP では省略 ) の付け替え◦ 同じ L2 セグメントで VIP 交換が吉◦ GARP の届く範囲が吉

IaaS のインスタンスで使っても仕方ない。。

サーバ A（プライマ

リ）

仮想 IP を付け替える

仮想 IP にアクセス

サーバ B（バックアッ

プ）

そもそもサーバの IP を固定と考えられない サーバの稼働率も信用してはいけない

◦ 落ちて当然 プライマリ・バックアップネットワークが近い

と限らない◦ 遠くてもよい設計◦ むしろディザスタ耐性と考えても OK

これらをふまえると次のようなデザインも

サーバ A（プライマ

リ）

通常バックエンドに指定

サービス IP にアクセス

サーバ B（バックアッ

プ）

ロードバランサ的インスタンス（ AWS なら ELB 、ほかなら HAProxy の導入など）

バックアップ

EC2 などにみられる Elastic という表現⇒ 丈夫とは取らず、良くも悪くも弾力性、信用するな。◦ 使う側の設計が特に大事◦ Loose なロードシェアで十分なことは多い

IP を丸々付け替えが必要か考慮する◦ IP(NS もあり )+ ポートを１単位ととらえれば、 VIP は

やりすぎ感◦ もちろん EC2 の EIP 付け替えが有効なケースもある

クラスタ形成

サーバ A（プライマ

リ）

通常バックエンドに指定

サービスホスト名にアクセス

サーバ B（バックアッ

プ）

LB インスタンス A(A レコードの一つ )

バックアップ

LB インスタンス B(A レコードの一つ )

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