システムアーキテクチャを明確化するには

システムアーキテクチャを明確化するには

システム開発のアーキテクチャ分類としてシステムアーキテクチャを明確化について、その説明とその手順を紹介します。

基本的なシステムアーキテクチャの枠組み

まず、基本的なシステムアーキテクチャの枠組みを検討します。枠組みとして最初に検討すべきは「システム形態」です。検討の候補には以下があります。

・ホスト中心 ― 昔ながらのメインレームを使用するシステムです。

・2層クライアント/サーバー型 ― オープン系のサーバーとクライアント PCで処理を分担するシステムです。

・3層クライアント/サーバー型 ― データベースサーバー、アプリケーションサーバー、クライアントで処理を分担します。

・Web システム(PCブラウザ·モバイル) ― クライアントとしてPCまたはモバイルのWebブラウザを使用するシステムです。

・Web システム(リッチクライアント) ― クライアントとして「リッチクライアント」と呼ばれる特殊なブラウザを使用するシステムです。スマートフォン専用アプリケーションもこの分類に含めます。

・その他のシステム ― IoTデバイスを使用するシステムや、サーバーレスのP2P(ピアツーピア)、エッジコンピューティング等が提唱されています。上記形態とともに、サーバーの置き場所も検討する必要があります。置き場所の分類には以下があります。

・オンプレミス ― ハードウエアからOS、データベースまで全てを自前で構築します。昨今の仮想化技術により、OSの配下に仮想OSとコンテナを配備することで、ハードウェアを意識する必要が低下しつつあります。

・クラウドサービス ― 以下の4種類の形態があり、どれを選択して構築するか検討する必要があります。

  • IaaS: インフラまでをクラウドで調達。具体的にはOS、サーバー、ネットワーク機器、ファイアーウオール、DNS、SDN、SSD環境が提供されます。インフラに関する設定を管理する必要があります。
  • PaaS:ミドルウエアまでをクラウドで調達。RDBMSなど、ミドルウエアの設定を管理する必要があります。
  • SaaS:アプリケーションをクラウドで調達。ハードウエアミドルウェアを意識せず使用可能です。アプリケーションそのものの設定は管理する必要があります。
  • FaaS:粒度の小さいサービスをクラウドで調達。組み合わせて処理を行う。サービス呼び出しごとの課金は、サーバーを時間レンタルするより低コストになる。自然とマイクロサービスの組み合わせとなることが特徴です。サーバーレスアーキテクチャを指向することになります。

クラウドサービスを使用する場合は、①〜④の組み合わせを含め検討します。この組み合わせの中で、集中·分散等の処理方式を検討し、最適な形態を選択もしくは併用すべく、方針を固めていきます。

分散方針

集中と分散を検討するに当たっての方針を検討します。昨今は「疎結合」がキーワードになるほど「適度な分散」が主流になっています。そうした背景から、主に「分散」に対する方針を優先して検討することになります。

  • 業務による分散 ― 業務単位に分散するか、集中管理を行うかを検討します。
  • インフラによる分散 ― アプリケーションとデータを、どのように分散配置して管理するか、を検討します。
  • 水平分散 ― 処理のボリュームに応じて、各アプリケーションやデータの分散をどのように(場合によっては動的に)行うか検討します。

マイクロサービスを使用する場合は、業務に注目し、それぞれが独立性を備え、更新が容易になるように分散配置を意識して設計を行います。要件定義段階においても設計方針を考慮する必要があります。

システムアーキテクチャを明確化する際、非機能要件をどこまで、どのようにアーキテクチャとして落とし込むかを熟考します。

運用要件

システムアーキテクチャの方向性がある程度固まった時点で、運用要件についても検討します。運用に関する要件は後回しになりがちですが、情報システムは動き続けてこそ価値を持ちます。アーキテクチャ検討の際に併行して検討しましょう。

移行要件

運用要件同様に、移行要件についても検討します。現行システムが存在する場合は、非機能要件で検討した内容を基に、新システムのアーキテクチャの方向性が固まった時点で、さらに検討を加えます。

「システムアーキテクチャ明確化」の手順

システムアーキテクチャ明確化の具体的な手順は以下のとおりです。

Step1 方向性の決定

本節の冒頭に挙げた6種のシステム形態、およびオンプレミスまたは4種のクラウドサービスについて、非機能要件を満たす最適な組み合わせを検討し、複数の組み合わせを含め、方向性を決定します。

Step2 具体的な設定

決定したシステム形態の各種設定(インフラ、OS、ミドルウエア)を検討し、方向性を決定します。具体的に決めるべきは以下の事項です。

・インフラ:PCやサーバー等の機種、DBサーバーやAPサーバー等の用途、ストレージ·周辺機器·メモリ、仮想化、クライアント選定(モバイル等)

・OS,ミドルウエア:サーバーやクライアントの0S、ブラウザソフト、DBMS等のデータ管理、APサーバー等のミドルウエア

・その他ツール等:開発支援ソフトウエア、運用支援ツール、エンドユーザー支援ツール等クラウドサービスを使用する場合、サービス形態の選択により定まることがあります。

Step3 ネットワーク環境の決定

ネットワーク環境を検討し、方向性を決定します。回線の準備、通信サービスの選定、機器選定、エ事計画等これに関してもStep2同様に、クラウドサービスを使用する場合、サービス形態の選択に応じて定まることになります。

Step4 アーキテクチャ定義書の作成

決定したシステムアーキテクチャの方向性を「アーキテクチャ定義書」にまとめます。システム形態の大枠と、現時点での設定内容が把握できるように、一覧表とイメージ図があればよいでしょう

Step5 運用要件の追記

上記の方向性に基づく運用要件をまとめて、「アーキテクチャ定義書」に追記します。

Step6 移行要件の追記

新システムへの移行要件に関する検討を行い、方向性を決定します。決定内容を「アーキテクチャ定義書」に追記します。

テックカテゴリの最新記事