ITアーキテクトの役割は「ビジネスの要求に応える良いアーキテクチャを構築すること」だが、どのようにしたら良いアーキテクチャを構築できるのだろうか。本連載では、標準的なアーキテクチャ設計手順を提示したうえで、各ステップごとに良いアーキテクチャ設計を行うためのポイントを、例示していきたい。
連載1回目に当たり、まずアーキテクチャ不在のシステムがどうなるか、簡単な例で紹介しよう。インターネット・ショッピングのWebサイトを思い浮かべていただこう。インターネット上で商品のカタログを見せてオーダーを受け付けるということであれば、次のようなシステム構成でも一応可能である。
さて、このようなシステムで販売を開始後、商品に人気が出て注文が殺到したらどうなるだろうか。マシンの能力が追いつかず、注文がさばき切れなくなって、今度は苦情が殺到することになりかねない。
CPUやメモリの能力を増強して対応しようとしても、マシンを増強している間は、システムの停止を余儀なくされるし、増強しても、1台のマシンでは物理的に搭載できるCPUとメモリの限界がある。
また、このシステム構成はセキュリティ的にも問題がある。一応ファイアウォールは設置しているが、さまざまなテクニックを駆使されてセキュリティが破られ、サーバマシンでOSコマンドなどが実行されてしまうと、顧客情報などの個人情報がネットワークに流出という事件につながりかねない。
上記のような問題を避けるためには、例えば、次のようなアーキテクチャにすればよい。
このアーキテクチャは、次の点を配慮して設計されている。
さて、このようなアーキテクチャはどのように設計/構築していったらよいのだろうか。昔は優秀なエンジニアが、システム構成を「えいやっと」設計するということがよくあった気がするが、ITアーキテクトの仕事のスタイルとしてはまずいだろう。また、うまくいった設計を「パクる」ことも行われてきたが、むやみにまねをするだけでは、実情に合わないシステムとなってしまう危険がある。
ITアーキテクトとしては、手順を追って設計したうえで、なぜ、そのようなアーキテクチャになったか、きちんと説明できるようにする必要がある。私の場合、次のような手順でITアーキテクチャの設計を行っている。
(1)では、業務上実現したいことに合わせて、アーキテクチャの要件を洗い出す。(2)から(6)は反復して行うステップであり、要件に合わせて、システムを構成するコンポーネントを抽出し、配置し、製品を当てはめて、性能とセキュリティを吟味していく。
(4')は、(4)を補完するステップで、使用実績のない製品を設計に組み込む場合などに、期待どおりに機能するかどうか、必要に応じてプロトタイプなどを作成して検証する。(5')は(5)を補完するステップで、性能見積もりに必要な原単位が不明な場合に測定を行ったり、期待どおりの性能が得られるかプロトタイプを作成して測定を行ったりする。
この手順を実施するうえで重要なのは、ステップ間で論理的につながりを持って設計を進めること(トレーサビリティーがあること)と、その結果、アーキテクチャ決定理由を明確に説明できること(アカウンタビリティーがあること)である。
上記の例でいうと、「トランザクションの増加に対応できること」「高い可用性を実現できること」という要件に対応して、Webアプリケーション・サーバーのクラスタリングというアーキテクチャを採用していることを明確にする必要がある。
勘所:アーキテクチャ決定理由を明確にせよ | |
---|---|
アーキテクチャ決定理由が明確になっていれば、状況が変わった場合に、これに合わせてITアーキテクチャを変更すべきかどうかを客観的に判断することが可能になる。また、ITアーキテクチャを再利用する場合でも、元のアーキテクチャが新しい状況に合うかどうかを分析することができる。例えば、社内向けの小規模の販売システムで、トランザクション量やサービス時間が限られている場合であれば、要件が違うので、ここまで費用の掛かる構成を必要としないといった判断が客観的にできるわけだ。
次回から、この手順に従ってITアーキテクチャ設計を行う場合のステップごとの勘所を述べていこう。
河野紀昭(こうの のりあき)
日本IBMにてITアーキテクトとしてさまざまなプロジェクトでアーキテクチャ設計を10年以上にわたって実施してきた。現在、エクゼクティブITアーキテクトとして、システムのアークテクチャ設計を担当するとともに、後進の指導にも当たっている。
Copyright © ITmedia, Inc. All Rights Reserved.