連載
» 2006年04月12日 12時00分 公開

28歳から挑戦するITアーキテクト(9)〜実践編〜:システム全体を連続稼働に持ち込め!

ソフトウェアとハードウェア。前回「基盤技術にロック・オンされていないか?」で詳しく述べたとおり、本来は切っても切れない間柄にある関係だが、意外にも開発現場ではポッカリと抜けていることが多く散見されるようになっている。

[岩崎浩文(株式会社豆蔵 BS事業部 エンタープライズビジネスグループ ),@IT]

 ほとんどのエンタープライズ系システムの場合、連続稼働を期待されている。これを限られた予算内で達成するためには、予算超過の元凶である余計な手戻りを発生させず、最初から入念に整合性を持ってハードウェア構成とソフトウェア構成を決めなければならなくなる。

 とはいっても、ソフトウェア開発をメインで行ってきた本連載が想定する若手プログラマからすると、いきなりいわれても何のことやらさっぱり、というのが実際だ。よほどのマニアか実務で鍛えられていない限り、この辺りの話は難しくて……と避けられてしまう。しかし、ITアーキテクトを目指すならば、ここを把握していないとお話にならない。まずはプログラマでも理解できる水準で、基本の基本を押さえておこう。

停止しないハードウェア構成

 コンピュータとはそもそも停止するものだ。こういってしまえば元も子もないのだが、現実問題としてどんな機械も壊れる可能性がある。自然故障もあればケーブルを引っこ抜かれる、ソフトウェアを壊されるなどの人災も含めると、連続で動くことを期待する方がどうかしている、と極端な話みることもできるだろう。ただ、そんなことをいったが最後、システムを利用する側から「何寝ぼけたこといってんだ! いいから動かせ!」とののしられること間違いなしだ。

ALT 図1 危険な単純構成

 つまり、最初からどこかが壊れる前提で、1カ所どこか壊れても動き続けられるようにした形、つまり多重化で機器を構成するのが、ハードウェアおよびネットワーク構成の「定石」となっている。機器構成の仕様書などに、single point of failure、fault tolerance(FT構成、耐障害性)、 high availability(HA構成、高可用性)うんぬんと記述してある個所は、この多重化に関する個所とみて間違いないだろう(これらの細かな内容はITSSでの「ITスペシャリスト」の担当範囲となるため、ほかの@ITの詳しい記事を参考にしてほしい)。

多重化構成で動くソフトウェア

 さて、この多重化構成のハードウェア、単純に機器を選定し、買ってきてつなぎ合わせるだけで動くのであれば問題ないのだが、ソフトウェアがないと動かない。それは当然として、多重構成を何も考えずに作ったソフトウェアがこの上で動くか、といえば、「Yes」の場合もあるが、多分に「No」の場合が多い。

 ソフトウェアデベロップメント(プログラマ)が自らの環境での作業が完了した後、実際の運用に持っていくまで(多くの開発プロセスでは「移行フェーズ」などと呼んでいる)というのは、意外にもプログラミング作業より大変だったりすることが多い。一度中規模から大規模のシステムを運用まで持ち込んだ経験があれば、ある程度想像がつくと思うが、運用に至るまでの開発現場は一般にてんてこ舞いである。それが難度の高い多重化構成であれば、失敗するとプロジェクト全体が崩壊してしまうことも多々ある。

 なぜこのようなことが起きてしまうのか。運用の肝である多重化構成をITスペシャリストに任せ切りにし、自らはソフトウェアの開発に没頭してしまう(あるいは全く手が回らなくなる)ソフトウェアデベロップメント側に問題がある、というのが筆者の結論だ。

 業界の現状分析はさておき、この「そのままで動く場合」と「そのままでは動かない場合」をさらに詳しく見ていこう。

そのままで動く場合の典型例

 特に何もせず多重構成でそのままで動く場合、というのは、限りなく「単一のコンピュータ」で動作しているように機器を構成した場合、または特殊なハードウェアやOSを利用した場合に限られる。

 その典型例だが、Webアプリケーションを構成するシステムの場合を見てみよう。

ALT 図2 そのままで動く場合の典型例

 この構成は現在、非常に多くのシステムで採用されている。利点は管理が楽、かつアプリケーションの修正がほとんど必要ない、機器を増設(スケールアウト)すればリニアに処理能力が向上する、などが挙げられる。

 というような難しいことはさておき、要するに、リクエスト一発目に入り口で振り分けて、後は延々と振り分け先で処理を継続する、という単純構成だと考えてもらえば間違いない。セッションが継続する限り、振り分け先を利用するわけだ。振り分けは入り口のルータで制御するため、振り分けられた先のソフトウェアは、そのリクエストがどこから来たのか、全く関知せずとも処理を行うことができる、という具合になる。

 弱点は簡単で、一発目で振り分けられたが最後、振り分け先が落ちた場合にその利用者のセッション情報も巻き込んで落ちてしまうという点だ。このため、お金を扱う系の絶対落ちてはいけないWebサイトでは、この構成は採用できない(設定次第ではいくらでも回避策はあるが、典型例ということで理解していただきたい)。

そのままで動かない場合の典型例

 では次に、多くの場合そのままでは動かない典型例を見てみよう。これは上記の例の弱点を克服したものになる。つまり、どこが停止しても処理を継続できる構成だ。

ALT 図3 そのままで動かない場合の典型例

 より具体的には、アプリケーションサーバのクラスター (房、Cluster)機能を用いたタイプ、つまりクラスタリング機能を用いたフェイルオーバー(fail over)構成であるわけだ。

 これらの用語を聞いただけで及び腰になる向きが多いのだが、要するに、毎回のリクエストのたびにランダムに処理を振り分け、状態をそれぞれのクラスターがコピーし合って持っておく構成になる。これならどれか1つが落っこちても隣が自動的に状態を継続して持ってくれるのだ。

 Java EEに準拠したアプリケーションサーバの場合であれば一般的に、標準として持っているクラスタリング機能を利用する。この場合、サーバ側のWebセッション情報や、ビジネスロジックで状態を保持している個所をServletやEJB SessionBeanでJava EE規約に従いコーディング、EARとしてビルドしておく必要がある。

 .NETの場合であれば、Windows Server 2003の上位版に搭載されているNLBを用い、ASP.NETなどのセッション情報を一元的に永続化してフェイルオーバーする形、ということになる。

なぜ動かないのか?

 さて、ではなぜそのままでは動かないか、というと、Java EEサーバにしても、.NETにしても、完全に規約に従った形でコーディングしていない限り動作しない、という厳然たる事実があるからだ。

 Java系のプログラマの多くはEJBを使いたがらないし(正確には使ったことがない、という場合が多いのだろうか)、多重構成を考慮していない独自フレームワークやオープンソースの多用などでがんじがらめになっていることが多くある。それは.NETにしても同じことで、ASP.NETのセッション状態に関して厳密に規約を守っている必要(例えばApplicationオブジェクトは読み取り専用で利用するなど)がある。

 そうした規約を守らず、不正な状態に依存した構成でアプリケーションが構築されていれば、大規模な作り替えが発生するのは当然だ。このような個所は筆者の経験上、現場のプログラマ1人1人が正確に把握していることはほとんどの場合期待できない。多くのプログラマは仕様どおりプログラミングすることで精いっぱいだ。

 つまり、ITアーキテクトが、最初から機器構成を考慮に入れ、ソフトウェアアーキテクチャを厳密に設計し、規約を現場に周知徹底して初めて、手戻りなく運用まで持ち込める、ということになる。

 今回取り扱った多重化の例はあくまで一例にすぎない。システム規模や機器構成・ソフトウェア構成によって、ITアーキテクトが先陣を切って全体の設計を主導する必要がある点はいうまでもないだろう。

真正面から取り組もう!!

 本連載読者の大半の方は、すでにソフトウェア開発に関してある程度の経験を持った方だと思う。最前線で活躍する技術者でも、ハードウェア構成まで想定したソフトウェアアーキテクチャを想定していることは実に少ない。

 この現象は開発の分担が細分化されてきたなど諸説あるが、筆者としてはソフトウェア開発があまりにアカデミックな抽象化への方向性を取り過ぎたことが原因ではないかと考えている。いかに机上で美しく設計をできたところで、最終的に実際に十分な能力を持って確実に動かすことができなければ、現実の開発現場では「未熟者」としてあしらわれるだけだ。

 ITアーキテクトよ、リアルなビジネスと併走するエンタープライズ系開発から逃げずに、現実と正面から戦おうではないか。

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ