ITアーキテクチャ構築の勘所
第1回 アーキテクチャ設計の手順

日本IBM
ICP-エクゼクティブＩ/Ｔアーキテクト
河野紀昭
2005/10/26

　 ITアーキテクトの役割は「ビジネスの要求に応える良いアーキテクチャを構築すること」だが、どのようにしたら良いアーキテクチャを構築できるのだろうか。本連載では、標準的なアーキテクチャ設計手順を提示したうえで、各ステップごとに良いアーキテクチャ設計を行うためのポイントを、例示していきたい。

　連載1回目に当たり、まずアーキテクチャ不在のシステムがどうなるか、簡単な例で紹介しよう。インターネット・ショッピングのWebサイトを思い浮かべていただこう。インターネット上で商品のカタログを見せてオーダーを受け付けるということであれば、次のようなシステム構成でも一応可能である。

図1 インターネット・ショッピングのWebサイトのアーキテクチャ

　さて、このようなシステムで販売を開始後、商品に人気が出て注文が殺到したらどうなるだろうか。マシンの能力が追いつかず、注文がさばき切れなくなって、今度は苦情が殺到することになりかねない。

　CPUやメモリの能力を増強して対応しようとしても、マシンを増強している間は、システムの停止を余儀なくされるし、増強しても、1台のマシンでは物理的に搭載できるCPUとメモリの限界がある。

　また、このシステム構成はセキュリティ的にも問題がある。一応ファイアウォールは設置しているが、さまざまなテクニックを駆使されてセキュリティが破られ、サーバマシンでOSコマンドなどが実行されてしまうと、顧客情報などの個人情報がネットワークに流出という事件につながりかねない。

　上記のような問題を避けるためには、例えば、次のようなアーキテクチャにすればよい。

図2 変更後のアーキテクチャ （クリックすると拡大）

　このアーキテクチャは、次の点を配慮して設計されている。

• スケーラビリティー：処理量の増加には、サーバーの台数を増やすことによって対応できる
  
  
• 可用性：基本的にハードウェアが2重化されているので、1台のマシンの故障ではユーザーに対するサービスが停止しない。また、ハードウェアやソフトウェアの保守に際しても、2重化しているサーバーを順次停止しながら行うことにより、サービス全体は停止せずに行うことができる
  
  
• セキュリティ：ファイアウォールを2重に設置し、個人情報など保護すべきデータを安全な場所に保管している。

　さて、このようなアーキテクチャはどのように設計／構築していったらよいのだろうか。昔は優秀なエンジニアが、システム構成を「えいやっと」設計するということがよくあった気がするが、ITアーキテクトの仕事のスタイルとしてはまずいだろう。また、うまくいった設計を「パクる」ことも行われてきたが、盲目的にまねをするだけでは、実情に合わないシステムとなってしまう危険がある。

　ITアーキテクトとしては、手順を追って設計したうえで、なぜ、そのようなアーキテクチャになったか、きちんと説明できるようにする必要がある。私の場合、次のような手順でITアーキテクチャの設計を行っている。

図3 ITアーキテクチャ設計の手順

　 （1）では、業務上実現したいことに合わせて、アーキテクチャの要件を洗い出す。（2）から（6）は反復して行うステップであり、要件に合わせて、システムを構成するコンポーネントを抽出し、配置し、製品を当てはめて、性能とセキュリティを吟味していく。

　（4'）は、（4）を補完するステップで、使用実績のない製品を設計に組み込む場合などに、期待どおりに機能するかどうか、必要に応じてプロトタイプなどを作成して検証する。（5'）は（5）を補完するステップで、性能見積もりに必要な原単位が不明な場合に測定を行ったり、期待どおりの性能が得られるかプロトタイプを作成して測定を行ったりする。

　この手順を実施するうえで重要なのは、ステップ間で論理的につながりを持って設計を進めること（トレーサビリティーがあること）と、その結果、アーキテクチャ決定理由を明確に説明できること（アカウンタビリティーがあること）である。

　上記の例でいうと、「トランザクションの増加に対応できること」「高い可用性を実現できること」という要件に対応して、Webアプリケーション・サーバーのクラスタリングというアーキテクチャを採用していることを明確にする必要がある。

勘所：アーキテクチャ決定理由を明確にせよ

　アーキテクチャ決定理由が明確になっていれば、状況が変わった場合に、これに合わせてITアーキテクチャを変更すべきかどうかを客観的に判断することが可能になる。また、ITアーキテクチャを再利用する場合でも、元のアーキテクチャが新しい状況に合うかどうかを分析することができる。例えば、社内向けの小規模の販売システムで、トランザクション量やサービス時間が限られている場合であれば、要件が違うので、ここまで費用の掛かる構成を必要としないといった判断が客観的にできるわけだ。

　次回から、この手順に従ってITアーキテクチャ設計を行う場合のステップごとの勘所を述べていこう。

【プロフィール】

河野紀昭（こうの のりあき） 日本IBMにてITアーキテクトとしてさまざまなプロジェクトでアーキテクチャ設計を10年以上にわたって実施してきた。現在、エクゼクティブITアーキテクトとして、システムのアークテクチャ設計を担当するとともに、後進の指導にも当たっている。

IT Architect 連載記事一覧

＠IT情報マネジメント メールマガジン　情報マネージャのための情報源（無料）

情報マネージャのための「今日のひと言」 - 2010/3/19 『仕事の順序』　仕事の順序を決めるに当たっては「緊急性と重要性」が2大要素です。仕事ではつい目先の緊急課題が気になりますが、実は…… >>続きはクリック

IFRSが経営、業務、ITに与える影響とは？ 導入に必要な「4つのフェイズ」を紹介 New！

仮想化すればコストは削減できるか？ 仮想化に必要な「3つの視点」を解説する

運用管理の課題を“2つの観点”から分析 ユーザー満足度の高い「仮想環境」とは？

その数、なんと400台以上！ グループ内 サーバの「統合管理」によるメリットは？

＠IT Specialヘ