（前回の記事の続きです）
クラウドとの親和性
さて、IIJ広域負荷分散サービスがどんなものかが分かったところで、このブログは「GIOろぐ」です。IIJ GIOとどんな組み合わせができるのかを構成例を交えてご紹介します。
IIJ広域負荷分散サービスはサーバ（サイト）が自社構築（オンプレミス）でもクラウド（IIJ GIOや他社のクラウド）でも問題なく利用できますので、一般的な組み合わせはこんな感じです。
DRサイト構成
メインサイトにオンプレミス、DRサイトにクラウドを組み合わせた例
昨今のBCPやDRといったキーワードで連想される構成パターンです。
DRサイト側にIIJ GIOを利用した構成とすることで、新たな設備を「所有する」のではなくDRサイトを「利用」できます。
IIJ GIOコンポーネントサービスならオンプレミスに近い構成がDRサイトに構築できますし、IIJ GIOホスティングパッケージサービスなら迅速かつリーズナブルなDRサイトが構築できます。
マルチクラウド構成
上記のDRサイトの応用として、IIJ GIOに万が一の障害があった場合のリスク対策として、別のクラウドサービスでDRサイトを契約しておきたいなんていうわがままな要望も、IIJ広域負荷分散サービスを使うことで簡単に実現できます。
IIJ広域負荷分散サービスではCNAMEのレコード登録に対応しているので、IIJ GIOと他社クラウドとの併用もバッチリです。
メインサイトにIIJ GIO、DRサイトに他社クラウドを組み合わせたマルチクラウド構成
また、複数のクラウドベンダーからリソースを調達し、システムリソースに合わせて負荷の分散を図る構成もできたりします。こういった点は「所有」ではなく「利用」することができるクラウドならではの発想だと思います。
複数のクラウドベンダーのリソースに負荷分散
事例(1)：IIJ GIOホスティングパッケージサービスによるキャンペーンサイト構成
ここからは、実事例をベースとした構成イメージや使い方をご紹介します。
IIJ GIOホスティングパッケージサービスの「日割り課金」「即時利用開始」「クローン機能」の長所とIIJ広域負荷分散サービスの「冗長化」「負荷分散機能」を活かした構成です。
IIJ GIOホスティングパッケージサービスを利用したキャンペーンサイト構成例
一見なんてことない構成なのですが、キャンペーンサイトのように、
- 一定期間だけ利用したい
- アクセス数の予測ができない（多いかもしれないし、まったく来ないかもしれない）
といった要望に対して柔軟に対応できる構成となっています。
1時間以内でのサーバ増設・削減、日割での課金調整ができますので、アクセス状況や利用時期に合わせて最適な台数で管理することができます。繁忙期と閑散期で適切なリソースを必要なだけ利用することができ、「平日は少ないけど、土日は集中するから増設」なんてことも可能です。
必要なリソースを必要なだけ契約
また、この構成だと、Webサーバ1台当たりの処理性能（どのくらいアクセスをさばけるか？）を設計すればアクセス数に合わせて台数を増やすだけですので、アクセス負荷が大きい時にパラメータチューニング→テスト→構成変更という工程そのものをなくすことができます。
サーバの知識のあまりないホームページ担当やキャンペーンサイト担当の方でもお手軽に「Webサーバの増設（削減）作業」ができてしまいます。
さらに、この構成では副次的なメリットとして、IIJ GIOホスティングパッケージサービスの制約を一部クリアできます。IIJ GIOホスティングパッケージサービスでWebサーバを複数台配置してFW/LBを付けて…と構成を組んでみると、インターネット接続の性能がFW/LBの性能（MAX：100Mbps）に依存してしまいます。
＜注意＞もちろんFW/LBを複数契約することでトータル100Mbps以上出すこともできますが、FW/LBの台数分コストがかかるため採用しづらい構成になります。
IIJ GIOホスティングパッケージサービスのFW/LBありの場合、インターネット接続の性能＝FW/LBの帯域上限となる
「キャンペーンだし、アクセス集中など考えるとやっぱり100Mbps以上出したい」なんて要望を手軽に実現するために、FW/LBの替わりにIIJ広域負荷分散サービスによる負荷分散構成を作ることで、キャンペーンサイトのインターネット接続性能を100Mbps以上にすることが可能です。
IIJ広域負荷分散サービスでLBを代替すれば、インターネット接続の性能＝サーバの帯域上限×台数に
サーバ自体は単体で最大で200Mbpsのトラフィックを出すことができます。
オプションメニューをあえて外すことで
インターネット接続＝サーバの出せるトラフィック×台数
というパフォーマンス設計を考えることができます。
もちろん、Webサーバが直接インターネットにさらされてしまうので、サーバ側にFWの設定をすることを忘れずに。
各サーバにFWの設定が面倒という問題もクローニング機能でコピーしますので、構築・設定は実質1台で済みます。
事例(2)：アプリケーションサーバのAPIを簡易的に冗長化
Webサイト閲覧不可を防止するだけでなく、システム間連携のAPIの冗長化にもIIJ広域負荷分散サービスを利用できるといった事例です。
＜注意＞
この内容は実際に使用例がありますが必ずどの構成でもできるというものではありません。「こんなやり方もあるんだね」という温かい目で読んでください。
既にIIJ GIOホスティングパッケージサービスとIIJ広域負荷分散サービスでWebサイトを構築されているお客様が、アプリケーションサーバのAPIで他社システムからデータを受け取っていた構成があります。IIJ GIO内のAPIには、FQDNベースでデータをPOSTしていました。
※FQDN：Fully Qualified Domain Name。ドメイン名、サブドメイン名、ホスト名をすべて記述する形式のこと
変更前の構成
変更前の構成では、アプリケーションサーバのAPIは冗長化されていない
APIがダウンすると情報を受け取れないためになんとか冗長化したいということになりましたが、APIだけのために今更LBを入れるのも大変ですし、VIP（Virtual IPアドレス：仮想IPアドレス）を使ってHA（High Availability：高可用性）な構成に変更する手間も時間もないという時に、IIJ広域負荷分散サービスを使ってこんな解決をしました。
解決策（変更後の構成）
IIJ広域負荷分散サービスのFQDN設定を利用して、APIを冗長化
元々、FQDNベースでデータをポストしていたことから以下の流れで構成を追加しました。
- FQDNをIIJ広域負荷分散サービスで契約
- APIのポートで監視（ヘルスチェック）をかけるためにカスタム監視オプションを追加
- アプリケーションサーバ（Active）をクローニング機能でコピーしてStandby機を作成
- IIJ広域負荷分散サービスの構成をActive-Standby構成にして、アプリケーションサーバ（Active）のIPをActiveグループに登録、アプリケーションサーバ（Standby）のIPをStandbyグループに登録
- Active→Standbyに切り替えるための監視をAPIで利用しているポートで設定
実際にどのくらい手間がかかったかというと、サービスの契約申し込みに2週間をいただきましたが、設定作業と切り替え確認テストで1時間程度の作業時間で冗長化構成を作ることができました。
この構成変更では、他社システムやWebサーバ群には一切影響を与えずに実現していますし、両サービスはIIJサービスオンラインのWeb UIで操作できるので、設定作業はサーバのログインなしで実施できました。
IIJ広域負荷分散サービスは、カスタム監視オプションを契約することで任意のTCPポートも監視（ヘルスチェック）の対象にできるため、こういった応用例の実現もできるのです。
最後に。
長々と書いてしまいましたが、いかがでしたでしょうか？IIJ GIOは単体サービスとしても柔軟性の高いクラウドサービスですが、他のIIJサービスと組み合わせることでより柔軟にご利用いただけます。
ちょっとクラウドサービスだけではダメかな？と思ってあきらめている方は一度弊社までご連絡ください。きっと最適な構成を提案できると思います。
なお、本サービスはF5社のBIG-IP Global Traffic Managerを利用したサービスということで、F5社のサイトでも紹介していただいております。もっと深い技術情報が知りたいという方は、こちらもぜひご覧ください。
（ソリューションインテグレーション部 菱木）
IIJは、2012年3月23日に開催された「GREE Platform Conference 2012」にスポンサーとして参加しました。ブース出展と講演のレポートをお届けします！
今回は、赤ずきんがいるのでこんなノベルティも用意しました。予想以上の反響でお客様にも喜んでいただけました。用意していた在庫もなくなってしまい、増産の予定もないのでプレミアが付くかもしれませんね。
講演では、IIJ GIOがソーシャルアプリに選ばれている理由を始め、実績や事例をご紹介しました。また、多くのSAP事業者とのお付き合いや、インフラサービスを提供・運用する中で得たノウハウから、5秒ルール対策、海外でのクラウドサービス利用時の留意点等、5つのポイントをお伝えしました。
