Software Developer's Think IT

IT運用に求められる統合フレームワーク - 仮想化時代のデータセンター・ネットワーク

あるべきクラウドを支える運用管理フレームワーク　第1回（http://thinkit.jp/article/1129/1/）では、ITシステム基盤のうち、データセンターを支えるネットワークがどのようなネットワークであるかを解説した。第2回では、IT基盤を運用するためのフレームワークについて説明する。

　図1は、一般的に用いられるサービス・ビジネス管理フレームワークの全体像である。汎用的なフレームワークだが、本記事ではマルチテナント型のクラウドを念頭においていることもあり、クラウド・サービス向けとしても利用できる。

　現在よく利用されている運用フレームワークが「IT Infrastructure Library v3」（ITIL v3）。5つの大カテゴリ（5冊の書籍）で構成しており、ITを使った業務システムの管理によくあてはまる。汎用性が高く、抽象度も高いため、ぜひ一度目を通していただきたい。

　ITILの全容を語るのは本連載の趣旨から外れるが、もともとは、IT導入に伴うコスト効果がじゅうぶんに得られなかったという反省から英国において研究／構成されたベスト・プラクティスである。書籍として実装されている。ITシステムの運用にかかわる者すべてが目を通し理解すべきものである。

　ITILと似たIT関係のフレームワークに、通信事業向けの「Telecom Operation Map」（TOM）や「Enhanced TOM」がある。クラウドを通信サービスとしてとらえた場合、こちらのほうが適した面もある。
「サービス・ビジネス管理」 - 業務視点の運用管理が重要　クラウド・サービスの運用でもっとも重要なフレームワークは、業務の視点に立った、サービス・ビジネス管理というフレームワークである。対象としているのは、IT基盤ではなく、エンドユーザー／顧客サービスのためのヘルプデスクや課金サービス管理といった業務レイヤーである。

　サービス・ビジネス管理の対象は、顧客と接する部分のインタフェース／手順である。この部分はスクラッチから構成するのが困難なため、通常は既存のサービスを利用する。例えば、クラウドの先駆けである米Amazon.comでは、既存のECサイトで使っていたフレームワークを利用できたため、決済システムやカスタマ・サポート／レポーティング機能を開発する必要がなかった。

　現在では、クラウド・サービスを立ち上げる際に別のクラウド・サービスを利用するというやり方も可能である。CRM（顧客関係管理）機能部分に米NetSuiteや米Salesforce.comのサービスを利用することもできる。実際、他社にクラウド・サービスを組み入れて利用してもらうために「クラウドAPI」を積極的に公開している企業が多い。

※蛇足だが、現在ではサービス事業者ごとのクラウドAPIに互換性がないため、標準化の主導権争いが起こっている。米連邦政府一般調達局（GSA: General Services Administration）のプライベート・クラウド調達仕様（RFQ: Request For Quotation）では、米Amazon.comのAPIに似たアーキテクチャーが記述されている。

　次ページからは、IT管理の自動化に着目し、業務とIT基盤をつなぐサービス管理の重要性からIT基盤管理の自律化、FCの優位点までを解説する。

はてな Livedoor Yahoo Google Delicius

]]>

LBによるスケーラブルなネットワーク設計 - ネットワーク設計／構築の最前線

廉価版L7ロード・バランサ　第1回（http://thinkit.jp/article/1125/1/）では、iDC（データセンター）におけるネットワーク接続の冗長化などについて解説しました。今回は、L7SW（レイヤー7スイッチ）と呼ばれるロード・バランサ（負荷分散装置）の導入支援について解説します。

　一般的に、ロード・バランサと言えば米F5 Networksの「BIG-IP」が筆頭であり、“キング”の地位を10年以上も昔から譲っていません。このほかにも、米Brocade Communications Systems（が買収した米Foundry Networks）の「ServerIron」、米Citrix Systems（が買収した米NetScaler）の「NetScaler」など、各ベンダーがL7SWをラインアップしています。

　ロード・バランサは、複数のサーバー機にアクセス負荷を分散する負荷分散装置です。事業の拡大などによるトラフィックの増大に対してサーバー機を増強することでシステム全体の処理性能を拡張できます。複数のサーバー機を使うことで、可用性／信頼性も上がります。

　Webアプリケーション向けの機能としては、アクセス元に応じて特定のサーバーへ固定的に接続する機能、サーバーが停止していたり負荷が高い時に作業中のページ（いわゆるSorry page）を表示する機能、サーバー機の代わりにSSL接続を代行（SSLサーバー証明書を代理で返してSSLセッションを確立）するSSLアクセラレータ機能、などを備えます。

　それぞれのロード・バランサ製品には、それぞれの特徴があります。こうした中で、ほとんどのロード・バランサが備えている機能を網羅している製品がBIG-IPです。そのぶん価格は高価ですが、充実した機能や簡単なGUI設定、高い処理性能、1秒以内で終わるフェール・オーバー（縮退運転）など、高価なりの特徴を備えています。

　しかし、BIG-IPを100％使いこなすには、L7（レイヤー7）まで、つまりネットワーク層だけでなくアプリケーション層までを理解する必要があります。価格も、中スペックのものでも、SIベンダーの設置費用、年間保守費用、月額の運用費用などを合計した場合、軽く年間予算1000万円をオーバーします。このため、導入が難しい場合もあるでしょう。

　筆者が所属するスリーセブンワークスでもBIG-IPを取り扱っていますが、小規模から中規模システムを抱える、よりコストを低く抑えたいユーザーに対しては、制約事項について正しく理解してもらったうえで、廉価版のロード・バランサを案内しています。具体的には、価格面と保守面に優れ、スリーセブンワークスが導入を始めてから4年の実績を持つ米Coyote Point Systemsの「Equalizer」を提案しています。

　以下では、この廉価版ロード・バランサ、Equalizerについて解説します。
廉価版と高級機器の主な違い　Equalizerにはいくつかの型番があります。本記事では主に、従来機種「SIシリーズ」の「E450si」と「E550si」、および新機種「GXシリーズ」の「E350GX」を対象に、これらを冗長構成（2台構成）で導入するケースを紹介します。各機器の詳細なスペックは、カタログなどを確認してください。

　以下では、ユーザー企業がロード・バランサを選択する際のポイントを考慮しながら、高級機器であるBIG-IPと、廉価版であるEqualizerの相違点を比較し、Equalizerの特徴を明らかにしていきます。

【BIG-IP（高級ロードバランサ）】の特徴

1） 2台の機器で同じMACアドレス（L2で利用する個体識別子）を利用し、フェール・オーバーします。周辺機器が保持しているARP（Address Resolution Protocol）テーブルのキャッシュ内容に依存しないため（書き変わる／書き換える必要がないため）、実測1秒以下でフェール・オーバーできます。セッション情報も保ったまま切り替えられます。

2）ロード・バランサ自身でVLANを作ることができます。これにより、ロード・バランサの配下に複数のネットワークを収容できます。

3）あるIPアドレスへのアクセスを、Pool（プール）と呼ばれるIPアドレス・グループに対して分散できます。グローバルIPとローカルIPの境界や概念が少ないため、設計の自由度が高まります。外向けのWebサイトではグローバルIPとNAT（Network Address Translation）を組み合わせるケースが一般的ですが、LAN上のサーバーからのアクセスも可能です。

4）セッションに応じて同一サーバーへアクセスを固定するセッション維持機能（Sticky）として、BIG-IPが発行するCookieだけでなく、IPアドレス（ソースIPアドレスやIPレンジ）、SSLセッションID、そのほか多数の方式を用意しています。

【Equalizer（廉価版ロードバランサ）】の特徴

1）フェール・オーバー時には、周辺装置のARPキャッシュを書き換える意図から、Equalizer（または周辺機器）の再起動が必要になる場合があります。Equalizerはフェール・オーバーするとき、別機器でのサービスとなるため、プライマリ機のMACアドレスとIPアドレスが変わります。このため、セッション中の情報を保ったままの切り替えはできません。機器の再起動により、60秒～90秒程度のサービス・ダウンを伴うことになります。

2）自身が所属できるネットワーク数は、基本的にWAN側1ネットワーク、LAN側1ネットワークであり、NAT変換を伴い、複数のネットワークを収容できない形となります（新機種のGXシリーズで2009年から、一部VLANを運用可能になりました）。

3）通常構成の場合、ローカル・サーバーからは、WAN側のクラスタIPを経由したアクセスができない制限があります。

4）サーバーからのOutGoing通信（アウト・ゴーイング通信、サーバーからインターネットへ向かう通信発生時）では、NATされるIPアドレスがロード・バランサの実IPアドレスとなる（裏技を使えば変更できますが、冗長構成の場合に使えないなど、制約があります）。

5）冗長（HA）構成でL7クラスタにSSLサーバー証明書をインストールする場合、A系にセットしてもB系には同期（コピー）されないため、B系にも同様にSSLサーバー証明書を設定しなければなりません。

　ここまで説明してきたように、BIG-IPと比べると、Equalizerには、いくつかの制約があります。次ページからは、実際に、2台のEqualizerを冗長構成で配置するネットワーク設計の具体例を示しつつ、Equalizerの特徴を解説します。

はてな Livedoor Yahoo Google Delicius

]]>

ユニファイド・コミュニケーションへの進化 - ユニファイド・コミュニケーションの現在

Unified Communicationsが登場　本連載では、ただの音声通信にとどまらない、統合されたコミュニケーション・ソリューション（解決策）として、「Unified Communications」（ユニファイド・コミュニケーション）の現状と今後の進化を、4回にわたって解説します。

　IP電話という言葉が一時流行しました。今はどのベンダーもIP電話という言葉を捨てて、Unified Communications（UC）という言葉を使っています。UCは、各ベンダーが使う言葉としては、一定の地位を得たようです。ベンダーによってはUCの次の言葉として、「Collaboration」（コラボレーション）という言葉を使っていますが、今回はUCとして連載を進めます。

　連載第1回の今回は、VoIP（Voice over IP）からUCへの発展を説明するとともに、UC導入への道のりを解説します。まずは、VoIPから発生した技術がどのようにUCへと発達していったのかを解説します。
VoIP技術の発達　1990年代、音声をIP通信に乗せるVoIPを実現するVoIPゲートウエイ製品が各社から発売されました。その以前は、VoFRやVoATMを用いて、FR（フレーム・リレー網）やATM（非同期転送モード）の回線に音声を乗せていました。VoIPは、PBX（構内交換機）同士をIP技術で接続することで電話料金を削減する技術として広まりました。

　VoIPゲートウエイが登場した当時は、音声という遅延が許されないアプリケーションをIPネットワーク上に乗せるということで、音声品質の確保がまずは一番の課題となりました。

　音声品質の課題を解決するため、ネットワーク機器の機能として、優先的に音声を届けるQoS（Quality of Service）機能や、PBXとの接続部分で発生するエコー（反響）を削減するエコー・キャンセラの技術が用いられました。

　さらに、当時はWAN（広域通信網）の帯域が狭かったため、IPのヘッダーを圧縮するCRTP（Compressed Real Time Protocol）や、G.729のような低帯域の音声コーデックが利用されました。また、PBXと物理的に接続するためにE＆MやT1などのインタフェースが、ゲートウエイ間は呼制御のプロトコルとしてH.323が利用されていました。

　ファクス（FAX）も、VoIPゲートウエイに収容して音声と同じようにコスト削減を目指しました。FAXも音声と同様に、狭いWANの帯域を通すため、Fax Relayの機能で圧縮していました。しかしながら、FAX端末メーカーが独自にFAXプロトコルを拡張していることも多く、問題が発生しやすかった印象があります。

　次ページからは、VoIPからIP電話、UCまでの発展の経緯を解説します。

はてな Livedoor Yahoo Google Delicius

]]>

ネットワーク全体から見る「スイッチ超入門」 - ネットワーク全体から見る「ネットワーク超入門」

まずはネットワーク全体を見る　本連載では、ネットワークの根本技術であるスイッチとルーター、そしてVoIP（IP電話）のそれぞれの基礎技術を、ネットワーク全体を俯瞰（ふかん）しながら分かりやすく解説します。

　昨今のネットワーク環境は、多種多様なベンダー製品を組み合わせて構築するのが一般的です。さらに、ルーター、スイッチ、ファイアウォールなど、さまざまな役割を果たすネットワーク機器が混在しています。全体を見渡すのが難しい状況にあると言えます。

　「木を見て森を見ず」ということわざがあります。ネットワークの世界でも同じです。個々の技術に心を奪われてネットワーク全体を見ないがゆえに、結果としてトラブルの復旧に時間がかかってしまう。実際の現場ではよくあるケースです。読者の皆さんの中にも経験がある方がいることでしょう。

　ここで、提案があります。読者の皆さんには、「個々の技術をひとつひとつ極める」という従来の考え方を、いったん脳裏からすべて捨てていただきたいのです。まずは、ネットワーク全体を俯瞰（ふかん）してネットワークの全体像を把握したうえで、個々の技術を学んでほしいのです。

　以上のような筆者の身勝手な願いも込めて、今回の連載をはじめさせていただきたいと思います。

■ネットワーク全体におけるスイッチの位置づけ

　スイッチは、図1-1のようにLAN（ローカル・エリア・ネットワーク）の中心的な機器として位置づけられており、イーサネット（Ethernet）技術を利用しています。実際のネットワークは、レイヤー2スイッチやレイヤー3スイッチと呼ばれる機器を中心に構築します。

　今回は、その基礎である「レイヤー2スイッチ」に焦点をあて、解説します。レイヤー2スイッチの用途　レイヤー2スイッチとは、ネットワーク機器の1つで、OSI参照モデルの第2層にあたるデータリンク層（TCP/IPではネットワーク・インタフェース層）においてデータの行き先を判断／転送する中継装置です。イーサネットを前提としており、イーサネット・フレームに含まれるMACアドレスを見て、データの行き先を決定します。

　また、レイヤー2スイッチは、多くのネットワーク機器の中で、ユーザーにとっては最も身近なものです。なぜなら、各種のネットワーク端末やサーバー機はもちろんのこと、現在ではテレビ・カメラや電話までもがケーブルを介してレイヤー2スイッチに接続されているからです。LANを構築するにあたり、レイヤー2スイッチは無くてはならない存在です。

　このように、レイヤー2スイッチは、オフィスのフロアにある端末や無線LANアクセス・ポイントなどを接続するエッジ（境界）に位置するネットワーク機器（エッジ・スイッチ）です。こうした特徴から、レイヤー2スイッチは、フロア・スイッチやアクセス・スイッチなどとも呼ばれます。

　レイヤー2スイッチはまた、コンシューマ製品から企業向け製品まで、さらに通信事業者向けにさまざまなプロトコルに対応した製品まで、用途に応じてさまざまです。しかし、規模の大小や使用場所に関係なく、イーサネット・フレームを転送するという基本的な仕組みは同じです。

　次ページからは、レイヤー2スイッチの基本動作について解説します。

はてな Livedoor Yahoo Google Delicius

]]>

アプライアンスの動向とWebサイトの最適化 - ネットワーク・アプライアンス最新動向

多様化するアプライアンス製品　企業ネットワークやデータセンターにおいて各種のネットワーク・サービスを提供しているのがアプライアンス製品です。このアプライアンス製品の世界では、日々革新が続いています。本連載では4回にわたり、各種アプライアンス製品の最新動向を紹介します。

　ネットワークにおけるアプライアンスの考え方は、おそらくルーターのソフトウエアをUNIX系のサーバーから取り出し、専用の機器として開発したことが始まりでしょう。その後インターネットの普及に伴ってファイアウォールがアプライアンス化されるなど、機能が多様化し、続々と新しい製品が開発されています。

　アプライアンス化の基本的な流れは、サーバー上で実行していた機能をネットワーク上に移動し、専用機器として実装する、というものです。これにより、処理の高速化やサーバー上の処理負荷の軽減、ネットワーク環境の拡大に応じたスケーラビリティ、アプリケーションと運用／管理／セキュリティ機能の分離、インストールや設定／運用の負荷軽減、といったメリットが生まれます。

　このため、ルーターやファイアウォールといったネットワーク固有の機能だけでなく、本来であればアプリケーションやサーバーの機能だったものまでがアプライアンスとして開発されるようになったのです。

　アプライアンスの製品形態としても、標準的なサーバー・プラットフォームにアプリケーションとして機能を搭載したものから、専用OSに機能を統合したもの、独自開発した専用のハードウエアを備えるものまで、多様化しています。
アプライアンス製品の全体動向 - 仮想化とクラウド化による進化　アプライアンスの全体的な動向としては、1990年代後半から始まったアプライアンスの多様化が継続しており、今後も続いていくでしょう。多様化の背景には、主に4種類の要因があるようです。

（1）ソフトウエアとして提供されていた機能を専用機器化
　例えば最近では、DNSやDHCPなどのネットワーク基盤サービスがアプライアンス化されています。

（2）複数のアプライアンス機能の統合
　異なる種類の製品で提供されていた機能を1台で提供するケースです。ファイアウォールにウイルス検知などを統合したUTM（統合脅威管理）が良い例です。

（3）ネットワークの進化に対応
　通信の高速化などに伴い、新しいサービスをネットワークで提供します。データ・バックアップなどが挙げられます。

（4）アプリケーション機能の取り込み
　もともとアプリケーションに実装されていた機能をネットワークで提供します。負荷分散やアプリケーションの高速化などが行われています。

　より最近の動向としては、もちろん仮想化とクラウド化による影響を無視するわけにはいきません。これらの要因によって、アプライアンスには以下のような動きが起こっています。

（a）仮想化に必要なネットワーク機能を搭載
　仮想サーバー上のアプリケーションが要求するネットワーク・サービスに対応するため、仮想化に特有の機能を搭載したり、仮想化ソフトウエア（ハイパーバイザ）との連携機能を提供するようになってきています。

（b）仮想ネットワークへの対応
　サーバー上に作られた仮想ネットワークも、運用管理やセキュリティ管理の対象です。このため、ネットワーク・サービスを提供するアプライアンスも、こうした仮想ネットワークを管理できるよう、対応を始めています。

（c）アプライアンスの仮想化
　仮想化環境では、ネットワーク・サービスもサーバー機と同様、より柔軟な対応が求められるケースがあります。このため、仮想アプライアンスの形でサーバーに搭載できるアプライアンス製品が出始めています。

　それでは、以上のような動向を踏まえて、アプライアンスの動向を紹介していきましょう。この連載では、製品分野ごとにアプライアンス製品の動向と最新の製品技術を紹介します。

　第1回の今回は、Webサイト・ネットワークでアプリケーションの最適化を行う「アプリケーション・デリバリー・コントローラ」（ADC）を紹介します。以降、第2回はネットワーク基盤サービス、第3回はストレージ、第4回はセキュリティと、アプライアンスが重要な役割を果たしている分野を順に紹介していきます。

はてな Livedoor Yahoo Google Delicius

]]>

ネットワーク機器がクラウドを支える - 仮想化時代のデータセンター・ネットワーク

IT資源のネットワーク・サービスが急伸　ITにかかわる者にとって、2010年がクラウド・コンピューティング元年であることに疑いの余地はないだろう。このコンピューティングの概念をどのように価値創造／価値競争の戦いに生かしていくのかは、各人に考えていただきたい。本連載では、クラウド・コンピューティングという概念が立脚するIT技術について、ネットワークの側面から解説する。

　インターネットや雑誌などでも取り上げられているが、クラウド・コンピューティングの本質は、ビジネス・ロジック（SaaS）やコンピューティング・リソース（PaaS/IaaS）を、準動的に利用できることである。

・SaaS = ビジネス・ロジックそのものを提供するサービス
・PaaS = ビジネス・ロジックを構成するためのプラットフォーム・サービス
・IaaS = ビジネス・ロジックを処理するためのハードウエア・リソース・サービス

　異論もあるかもしれないが、クラウド・コンピューティングをビジネスの側面から見ると、2つに大別できる（図1）。1つは、アプリケーションなどのソフトウエアをIaaS上の「仮想アプライアンス」で提供する形態である。もう1つは、スケール・アウトが可能なデータ・ストアやネットワーク・サービスのAPIを使う形態である。後者では、ユーザー独自のソフトウエアを動作させることができる。
XaaSは用途に応じて使い分ける　SaaSやPaaSの特徴は、Webベースのアプリケーションを想定した機能として、スケール・アウトのための特別な仕組みを持っている点である。昨今、雑誌でもよく取り上げられるKey-Value Store（キー・バリュー・ストア、以下、KVS）技術は、その一例である。

　KVSのようなフレームワーク（特定用途のソフトウエア・ライブラリ群）は、複数システムにまたがるグローバルなアトミック操作（複数の操作を組み合わせた一連の操作）を犠牲にすることでスケーラビリティを得ている。アーキテクチャー上、既存のアプリケーションとは異なる制約がある。

　一方、IaaSと仮想アプライアンスの組み合わせ、つまり、分散処理用フレームワークなどのミドルウエアの提供を前提とせずに素の仮想サーバー環境の上で仮想アプライアンスを利用するケースでは、スケーラビリティの制約こそあるものの、KVSに見られるようなアーキテクチャー上の制約はない。

　XaaS（SaaS/PaaS/IaaS）は、いずれの形態を採用したとしても、ITに大きな変革をもたらす。例えば、ビジネス・ロジックをPaaSのフレームワークで構成すれば、最低限のIT基盤を保有するだけで済む。一方、IaaSと仮想アプライアンスを導入する場合であっても、カスタマイズを施すことで利用できる。

　XaaSと従来のASP（Application Service Provider）との大きな違いは、ASPがアプリケーション層のマルチテナント機能を要求するのに対して、XaaSはアプリケーション層についてはシングルテナントを意識した構造でよい、という点である。

　次ページ以降では、クラウド時代のデータセンターを構成するネットワークとインターコネクトのアーキテクチャーを示し、システムのボトルネックを回避するポイントを解説する。

はてな Livedoor Yahoo Google Delicius

]]>

iDCの鉄板ネットワーク設計 - ネットワーク設計／構築の最前線

“落ちないIP”を実現するために　現在では、冗長化や仮想化などの技術を用いてITシステムの可用性を高める試みが、数多く提供されています。特に、日本のインターネット環境においては、サーバー機の冗長化に加えてネットワークの冗長化に取り組むことによって、サービスが停止している時間が格段に少なくなりました。日本は、この数年間で世界でトップ・クラスのネットワーク・インフラを持つまでになりました。

　国内では、誰もがその最高峰のネットワーク・インフラを使っています。さまざまな企業が、メールやWebサイトの用途にとどまらず、販売／宣伝や動画配信などの業務用途で利用しています。さらに、業務アプリケーション・ソフトや携帯端末の進化もあいまって、現在のネットワークはあらゆる業務ニーズに応えられるようになっています。

　ネットワーク基盤に対して100％に限りなく近い稼働率を求めるのであれば、事業者が運営するデータセンター（iDC）を利用するのが普通です。本記事の第1回では、“落ちないIP”（停止時間がほとんどないIPネットワーク）の実現を目的に掲げ、iDCが採用しているネットワーク冗長化の仕組み、VLAN（仮想LAN）設計、具体的なラック内の機器設計方法について解説します。
ルーター冗長化プロトコルで2重化する　iDC各社のサービス・メニューを利用者の立場で見てみると、さまざまな回線を低コストで利用できることが分かります。比較的安価なサービスでも、上流に位置するネットワークとの接続回線部分は2重化されているのが普通です。

　大手の主要iDCでは、ルーター冗長化プロトコルのVRRP（Virtual Router Redundancy Protocol、RFC2338）やHSRP（Hot Standby Routing Protocol、米Cisco Systems仕様）を用いて、ルーターとネットワーク回線を2重化しています（ルーター同士は通常、「/30」（IPアドレス4個）などの小さなネットワークで結びます）。

　冗長回線を利用するためには、iDCからの冗長回線を接続するための設備を用意し、ラックに設置しなければなりません。基本的には、レイヤー3スイッチ（L3SW）と呼ばれるIPルーティング機能を持ったスイッチ機器を2台用意し、この2台でVRRP/HSRP構成を作り、仮想IP（VIP）で運用する必要があります。

　図1-Aを参照してください。ラックとiDCは、このように接続されます。実際の結線は図1-Bの通りです。ラック側とiDC側で合計4台のL3SWを、2本の結線で結びます。

　iDC側では、冗長化する「iDCSW-A」と「iDCSW-B」の2台のルーターにおいて、実IP-Aと実IP-Bのインタフェース上で仮想IP（iDC-VIP）を作ります（図1-C）。こうすることで、iDCSW-Aに障害が発生してスタンバイ・ルーターのiDCSW-Bに切り替わっても、同一の仮想IP（iDC-VIP）のまま通信を継続できます。

　こうして作ったiDC側の“落ちないIP”に対応して、ラック側（顧客ネットワークの最上位）に用意するL3SWも、同じように“落ちないIP”を用意します（Cust-VIP）。iDC側とラック側で互いに仮想IP（iDC-VIPとCust-VIP）を使って経路交換を行うことで、通信を実現しています。

　物理的には、ルーターと回線が2系統あるため2本の結線となりますが、論理ネットワーク的には、それぞれの仮想IPアドレスであるiDC-VIPとCust-VIPが1対1で、互いをデフォルト・ゲートウエイとして通信することになります。

　ここまで説明してきた“落ちないIP”とは、2台の冗長化されたL3SWによって作り出される仮想IP（VIP）のことを指します。

　次ページからは、iDCでラックを運用する際の必須事項とも言えるVLAN構成について簡単に紹介するとともに、ファイア・ウォール（FW）機器や負荷分散装置（ロード・バランサ、LB）による冗長構成について解説します。

はてな Livedoor Yahoo Google Delicius

]]>

ObjectWorks＋によるアプリケーション開発 - 進化するWeb開発フレームワーク

アプリケーション情報の定義シートを作成する（1）　前回（http://thinkit.jp/article/1123/1/）は、野村総合研究所（NRI）のSIフレームワーク「ObjectWorks＋（オブジェクトワークスプラス）」の概要を解説しました。最終回の今回は、ObjectWorks＋によるWebアプリケーション開発の流れに沿って、もう少し詳細な特長を解説していきます。

　ObjectWorks＋による開発の流れは、「定義シート作成」→「ソースコード自動生成」→「コーディング」→「単体テスト」と4つの作業に大別されます。まずは、アプリケーション開発支援ツールObjectWorks＋/STUDIO（以下、STUDIO）での「定義シート作成」から、開発がスタートします。

　この工程では、画面遷移設計やデータ項目の定義など、アプリケーションの基本設計の中でも、「内部設計」に相当する設計を行います。その前段には、前回解説したようにサイト構成図の「Conversation分割」が完了し、STUDIOの定義シートの設計範囲が切り分けられていることが必要です。

　STUDIOでは、「画面遷移定義」「データ定義」「アクション定義」「サービス定義」と、Excelをベースとした4つの定義シートを準備します（図1）。

■画面遷移定義

　まず始めに、「画面遷移定義シート」を作成します。画面遷移定義シートは、大きく分けると「遷移元画面」「遷移時のアクション」「遷移先の画面」の3つの領域があります。アプリケーション内（Conversation内）のすべての画面について、その中で発生するアクションを書き出し、その処理結果に応じて遷移先の画面を定義します。

■データ定義

　次に、「データ定義シート」を作成します。データ定義シートは、「データ項目と属性の定義部」と「DTO（Data Transfer Object）設計部」の2つの領域に分かれます。まず、シートの左端に、そのアプリケーション内に登場するすべてのデータ項目を列挙します。

　データ項目を列挙した後、それぞれについて属性情報を記入していきます。属性情報としては、データ型や日本語名称、デフォルト値などのほかに、バリデーション属性があります。ここで「必須」や「全角」といった欄にチェックを入れておくことで、後ほど自動生成されるDTOにこれらのバリデーションを実装するアノテーションが付与されます。

　続いて、シートの右端に、任意のデータ項目をフィールドとして持つDTOを設計します。DTOをどの程度細かく分割して定義するかは、プロジェクトの標準化ルールによります。画面（XHTML）とアクション・クラスとの間でデータのやり取りに用いる「Web層DTO」を、サービス／ロジック・クラスの入出力にもそのまま用いるように単純化するケースもあれば、サービス／ロジックの種類に応じて最低限必要なデータ項目だけを持たせた入力DTO、出力DTOを用意する場合もあります。DTOは、後述する「アクション定義シート」、「サービス定義シート」とも同時並行的に設計していくことになります。
アプリケーション情報の定義シートを作成する（2）■アクション定義

　次に、「アクション定義シート」を作成します。アクション定義シートは、「画面遷移定義シート」で記述した、遷移時に呼び出されるアクションを設計します。画面遷移定義シートで記述したアクションのコンポーネントID（＝アクションID）に対して、そのアクションが呼び出すサービスのコンポーネントID（＝サービスID）を記述していきます。

　また、アクション・クラスと画面（XHTML）との間でデータをやり取りするためのDTOを指定します。ここには、先ほどの「データ定義シート」で設計したDTOの名前を指定します。

■サービス定義

　最後に、「サービス定義シート」を作成します。「アクション定義シート」で記述したサービスIDに対して、そのサービスが呼び出すロジック（ビジネス・ロジックの実装部の本体）を記述していきます。

　また、サービス・クラスの入出力に用いるDTO、およびロジック・クラスの入出力に用いるDTOも、ここに定義します。この入出力DTOを、サービスやロジックごとに適切に設計することで、サービスやロジックといったBL（ビジネス・ロジック）層のクラスがPL（プレゼンテーション・ロジック）層の画面やアクションと切り離されて管理しやすくなります。

　以上で、最初のステップとなる「定義シート作成」の工程は完了です。STUDIOの定義シートは、アプリケーションのクラス構造に、理解しやすい単純なアーキテクチャーを導入して標準化する役割を果たしていますが、役割はそれだけではありません。

　アプリケーションの設計情報を、これらのスプレッド・シート上に一元化することで、アプリケーション全体の構造を俯瞰（ふかん）したり、サービスの入出力のようなインターフェースが、個々の開発者によって変更されないよう管理を集約するなどの役割も担っています。

はてな Livedoor Yahoo Google Delicius

]]>