ソフトウェアアーキテクチャとは？ソフトウェアアーキテクチャの基本を解説！
目次
はじめに
ソフトウェア開発のプロセスは、家を建てることに似ています。基礎が頑丈であれば、時の試練に耐え、その存続期間中、クライアントの要求を満たせます。
では、どうすれば開発者は自分のプログラムの土台がしっかりしていることを確認できるのでしょうか？その解決策は、プログラムのアーキテクチャにあります。
家を建てる際には、建設プロセスの早い段階でいくつかの決定を下さなければなりません。その中には、使用する材料、家のデザイン、内部の建築様式などが含まれます。これらの選択は、家の耐久性、強度、品質を検討するために非常に重要です。さらに、ベースがしっかりしていれば、その上に階層を追加することも簡単です。
同様に、ソフトウェアアーキテクチャは、長期的にソフトウェアの内部品質を定義する重要な特性について判断を下します。これは、その後の開発がこれに依存するため、ソフトウェア開発工程の初期（要求定義）に行われます。
今回は、ソフトウェアアーキテクチャの基本をご紹介します。
ソフトウェアアーキテクチャとは？
システムのソフトウェアアーキテクチャは、システムの組織または構造を示し、それがどのように機能するかを説明するものです。システムは、与えられた機能または機能の集合を実行する要因の集合体です。言い換えれば、ソフトウェアアーキテクチャは、ソフトウェアを構築するための強固な基礎を提供します。一連のアーキテクチャ上の考慮事項と交換は、システムの品質、性能、保守性、および全体的な成功に影響を与えます。基本的な困難や長期的な影響を考慮しないと、システムを危うくする恐れがあります。
現代のシステムにおいては、いくつかの上級なアーキテクチャパターンや考え方が広く採用されています。これを表現するために一般的に使われているのが「アーキテクチャスタイル」です。ソフトウェアシステムのアーキテクチャが、特定のアーキテクチャスタイルに制約されることはほとんどありません。むしろ、システム全体を作るためにさまざまなスタイルが使われることもよくあります。
お問い合わせください！
なぜソフトウェアアーキテクチャが重要なのか？
構造化されたソフトウェアアーキテクチャは、ソフトウェア開発工程の内部品質を保証するのに役立ちます。2つの比較可能な製品を考えてみましょう。どちらも1ヵ月以内にリリースされ、3ヵ月後に新機能を追加する予定です。
シナリオは2つあります。
製品Aは2021年1月に発売される予定です。開発チームは一刻も早く発売して市場を独占することを目指しているため、この製品はソースコードがずさんになっています。
製品Bは2021年3月に発売予定です。このプロジェクトの特徴は、きちんと構造化され、秩序立ったソフトウェアアーキテクチャを採用しています。開発チームはプロセスの早い段階でデザインとアーキテクチャの決定に取り組み、急いで発売することよりも品質を優先しています。
AとBのうち、どちらの製品がより成功すると思いますか？
製品Aは、当初は市場を独占し、コンバージョンも良くなるかもしれません。しかし、不器用なコードの結果、製品の普及は最終的に遅くなり、技術的負債が蓄積されることになります。このようなバックログがあると、新しいアップグレードやバグ修正を即座に展開することが難しくなります。
製品Bは、市場参入のギャップに直面するかもしれませんが、より速い納期の維持が容易になります。ユーザー体験を損なうことなく、顧客の要求を満たせ、結果として大きな勝利を得ることができます。
最もよく使われる5つのソフトウェアアーキテクチャ
最もよく使われる5つのソフトウェアアーキテクチャをご紹介いたします。
レイヤー（N層）アーキテクチャ
レイヤー（N層）アーキテクチャは、一般にデータベースを中心に構築されます。多くの商用アプリケーションが表に自然に情報を格納するのに適しているため、おそらく最もよく使われる戦略です。
レイヤー（N層）アーキテクチャは、ほとんど自己実現的な予言です。Java EE、Drupal、Expressなど、最も人気があり優れたソフトウェアフレームワークの多くは、この構造を念頭に置いて設計されています。その結果、それらを使って作成されたアプリケーションは、自然にレイヤー（N層）アーキテクチャを持つようになります。
コードは、データが最上層に入り、各層を下っていき、一般にデータベースである最下層に到達するような構造になっています。各層は、データが正しいかどうかを検証したり、数値の整合性を保つために再フォーマットしたりなど、ルートに沿って明確な義務を負っています。複数のプログラマーが独立してさまざまな階層を担当するのが一般的です。
MVC（モデル・ビュー・コントローラ）構造は、一般的なWebフレームワークの大半が提供する標準的なソフトウェア開発手法であり、紛れもなくレイヤー（N層）デザインです。モデル層はデータベースのすぐ上に位置し、ビジネス論理とデータベース内のデータの種類に関する情報を含みます。
ビュー層は一番上にあり、多くの場合、CSS、JavaScript、HTMLで構成され、動的なコードが埋め込まれています。コントローラは中間に位置し、表示とモデルの間を移動するデータを変更するための多数のルールと技巧を備えています。
レイヤー（N層）アーキテクチャの利点は分離であり、各レイヤーはその役割のみに集中することができます。
レイヤー（N層）アーキテクチャのメリット
レイヤー（N層）アーキテクチャには、次のようなメリットがあります。
・テスト可能性
・メンテナンスの柔軟性
・個別の 「役割 」を安易に割り当てる
・レイヤーを個別に更新・改善することが簡単
適切に設計されたレイヤー（N層）アーキテクチャは、ほかのレベルの変更の影響を受けないようにレイヤーが分離されており、よりシンプルなリファクタリングを可能にします。
この設計では、サービスレイヤーなどのオープンレイヤーを追加できます。サービスレイヤーは、ビジネスレイヤー専用の共有サービスにアクセスするために使用され、同時にスピードアップのためにスキップされることもあります。
アーキテクトの最大の課題は、職務分担と各階層の設計です。要件がパターンに密接に一致する場合、レイヤーを分割してさまざまなプログラマーに簡単に割り当てることができます。
レイヤー（N層）アーキテクチャのデメリット
レイヤー（N層）アーキテクチャには、次のようなデメリットがあります。
・ソースコードが乱雑で、モジュールの責任や関係が定義されていないと、大きな混乱になってしまうかもしれない。
・一部の開発者が、シンクホール・アンチパターン※と呼ばれるもののために、コードがゆるくなる。コードの多くは、ロジックを伴わないレベル間のデータの受け渡しに費やされる可能性がある。
・レイヤーの分離は設計上重要ですが、すべてのモジュールを理解しないとアーキテクチャを把握することが難しくなるかもしれない。
・開発者は、緊密な結合や複雑な相互依存関係を持つ論理的な混乱を発生させるために、レベルをスキップできる。
・個別なデプロイメントが頻繁に必要なため、ちょっとした修正でプログラムの完全な再デプロイメントが必要になることがある。
※シンクホール・アンチパターン：このアンチパターンは、リクエストがアーキテクチャの複数の層を通過する際に、各層でほとんど論理的に実行されず、単純な通過処理として流れる状況を説明する。
レイヤー（N層）アーキテクチャを利用すべきケース
レイヤー（N層）アーキテクチャは、次のようなケースで利用すべきです。
・新しいアプリを早く開発しなければならない時。
・一般的なIT組織や運用を反映させる必要がある企業や法人向けアプリケーションの開発時。
・開発チームに、さまざまなアーキテクチャに不慣れな初心者が多い時。
・保守性やテスト性の要求が厳しいアプリケーションの開発時。
イベント駆動型アーキテクチャ
多くのプログラムは、その時間の大半を、何かが起こるのを待つためだけに費やしています。これは、ネットワークのような領域でも広く見られますが、特に人間と対話するコンピュータに当てはまります。処理しなければならないデータがある時とない時があるのです。
イベント駆動型アーキテクチャは、すべてのデータを受け取る中央ユニットを構築し、そのデータを特定の種類を扱う個々のモジュールに委譲することでこれを支援します。このハンドオフは「イベント」と呼ばれ、その種類に関連するコードに委ねられます。
JavaScriptを使ってWebページをプログラミングする場合、クリックやキー入力などのイベントに反応する小さなモジュールを書く必要があります。ブラウザはすべての入力を制御し、正しいコードだけが正しいイベントを表示します。ブラウザでは、さまざまな種類のイベントが普及していますが、モジュールは自分に関係するイベントとしか対話しません。これは、すべてのデータが通常すべてのレベルを通過するレイヤードデザインとは対照的です。
イベント駆動型アーキテクチャのメリット
イベント駆動型アーキテクチャには、次のようなメリットがあります。
・複雑で、しばしば混沌とした環境にも容易に適応できる。
・新しいイベントタイプの出現時に拡張可能。
・簡単にスケールアップできる。
イベント駆動型アーキテクチャのデメリット
イベント駆動型アーキテクチャには、次のようなデメリットがあります。
・要因が相互に影響し合うと、テストが複雑になることがあります。個々のモジュールは個別に評価できますが、モジュール間の相互作用は、完全に動作するシステムでなければ検証できない。
・特に、多くのモジュールが同じイベントを処理しなければならない場合、エラー処理を整理するのは難しいかもしれない。
・モジュールが故障した場合、中央装置はバックアップ計画を立てておく必要がある。
・メッセージングオーバーヘッドは、特に中央装置がバースト的に到着するメッセージをバッファリングする必要がある場合、処理性能を低下させる可能性がある。
・イベントに対するシステム全体のデータ構造を作成することは、イベントの要件が極めて異なる場合、困難な場合がある。
・モジュールが分離・自律しているため、一貫性を保つためにトランザクションベースのアプローチを維持することは難しい。
イベント駆動型アーキテクチャを利用すべきケース
イベント駆動型アーキテクチャは、次のようなケースで利用すべきです。
・非同期システムにおける非同期データフロー
・個々のデータブロックが複数の要因のサブセットとしか通信しないようなアプリ
・ユーザーとの交流
マイクロカーネルアーキテクチャ
多くのアプリには、入力や作業に応じてさまざまなパターンで繰り返される行動の核となるセットが含まれています。たとえば、人気のある開発ツールであるEclipse（エクリプス）は、ファイルを開き、注釈を付け、編集し、バックグラウンドのプロセッサを起動しないといけません。このツールは、これらの作業をすべてJava言語で行い、ボタンが押されるとコードを集め、実行することで知られています。
このシナリオでは、マイクロカーネルには、ファイルの閲覧や編集のための基本的な手順が含まれています。Javaコンパイラーは、マイクロカーネルの基本的な機能をサポートするために使用される単なるアドオン要因です。さまざまなプログラマーがEclipseを改造し、異なるコンパイラーを使用してほかの言語でコードを記述しています。多くはJavaコンパイラーを利用していませんが、いずれも同じ基本的なファイル編集と注釈の手順を使っています。
上に載せる追加機能は、一般にプラグインと呼ばれます。むしろ、この拡張可能な方式をプラグインアーキテクチャと呼ぶ人が多いです。この方法は、名前を尋ねる、支払いを確認するなど、特定の基本的な業務をマイクロカーネルの内部に置きます。そして、さまざまなビジネスユニットが、カーネルのコア機能への呼び出しでルールを接続し、さまざまな種類のプラグインを開発できます。
マイクロカーネルアーキテクチャのデメリット
マイクロカーネルアーキテクチャには、次のようなデメリットがあります。
・何がマイクロカーネルに属するかを選択することは、しばしば科学というよりむしろ芸術である。柔軟な対応が必要で、よく使われるコードは残しておくべき。
・プラグインは、マイクロカーネルにプラグインがインストールされ、使用できる状態にあることを通知するよう、相当量のハンドシェイク※コードを含む必要がある。
・多くのプラグインがマイクロカーネルに依存している場合、それを変更することは不可能ではないにしろ、困難な場合がある。これを解決する唯一の方法は、プラグインも同様に変更することである。
・カーネル関数の適切な粒度を選択することは、準備段階では難しいが、後々、調整することは、ほぼ困難である。
※ハンドシェイク：電気通信において、ハンドシェイクとは、通信の開始時に、完全な通信を開始する前に、通信リンクのプロトコルを確立するための情報交換を通じて、2つの参加者の間で行われる自動的な交渉のこと。
マイクロカーネルアーキテクチャを利用すべきケース
マイクロカーネルアーキテクチャは、次のようなケースで利用すべきです。
・幅広い層で使われるツール
・アプリケーションの基本的なルーチンと高次のルールが明確に分かれている場合
・固定されたコアの手順と、定期的に更新する必要がある動的なルールの集合を持つアプリ
マイクロサービスアーキテクチャ
ソフトウェアは子象のようなもので、小さいうちは愛嬌がありますが、大きくなると制御が難しく、変化に対して抵抗があります。マイクロサービスアーキテクチャは、開発者が自分の製品が大きく、柔軟性に欠けるものにならないように支援することを目的としています。一つの大きなプログラムを作るのではなく、小さなプログラムをたくさん構築し、新しい機能が追加されるたびに新しい小さなプログラムを作っていくという考え方です。
iPadでNetflixのUIを見ると、そのインターフェイスにあるものはすべて別のソースから送られてきていることに気づくでしょう。お気に入りのリストも、特定の映画に対する評価も、会計情報も、すべて異なるプロバイダーから個別に送られてくるのです。まるで、Netflixが何十もの小さなWebサイトのネットワークであり、それがたまたま1つのサービスとして表示されているようなものです。
この戦略は、イベント駆動型やマイクロカーネルのアプローチに匹敵しますが、さまざまなタスクが容易に分離できる場合に使用されます。多くの場合、異なるタスクはさまざまな量の処理を必要とし、異なる方法で使用される可能性があります。金曜と土曜の夕方には、Netflixのコンテンツを配信するサーバーの負荷が大きくなるため、スケールアップの準備が必要です。Netflixのクラウドでは、これらを異なるサービスとして確立することで、需要の変化に応じて個別にスケールアップとスケールダウンを行っています。
マイクロサービスアーキテクチャのデメリット
マイクロサービスアーキテクチャには、次のようなデメリットがあります。
・サービスはほとんど自己完結していないと、接触によってクラウドのバランスが崩れてしまう。
・すべてのアプリが単純に分割できるわけではない。
・タスクが複数のマイクロサービスに分散している場合、パフォーマンスが低下しない。通信にかかる費用は相当なものになる。
・マイクロサービスの数が多すぎると、ウェブページのある部分の表示がほかの部分よりずっと遅れるため、ユーザーが混乱する可能がある。
マイクロサービスアーキテクチャを利用すべきケース
マイクロサービスアーキテクチャは、次のようなケースで利用すべきです。
・小さな要素で構成されたWebサイトやアプリ
・境界線が明確に定義された企業のデータセンター
・世界中に分散している開発チーム
空間ベースアーキテクチャ
多くのWebサイトは、データベースを中心に構築されており、データベースがトラフィックを処理できる限り、うまく機能します。しかし、利用が急増し、データベースがトランザクションの記録を作成するという継続的なタスクに追いつけなくなると、Webサイト全体がクラッシュしてしまう可能性があります。空間系アーキテクチャは、処理とストレージを多数のサーバーに分散させることで、高負荷時の機能破綻の回避を目的としています。
データはノード全体に分散されています。建築家の中には、より平易な表現である 「クラウドアーキテクチャ」を好む人もいるかもしれません。空間ベースとは、ユーザーの「タプル空間」を指しており、これを分割してノード間で作業を分担します。すべてメモリ内で行うものです。データベースを取り除くことで、空間ベースのデザインは、予期せぬ急増を伴う項目に対応します。
RAMに情報を格納すれば、活動を高速化し、処理とストレージを分散させることで、多くの単純作業を簡素化できます。しかし、分散アーキテクチャは、ある種の分析を難しくすることがあります。平均値の計算や統計解析など、データセット全体に分散しないといけない計算は、サブタスクに分割し、すべてのノードに分散させ、完了したら集計する必要があります。
空間ベースアーキテクチャのデメリット
空間ベースアーキテクチャには、次のようなデメリットがあります。
・RAMデータベースの場合、トランザクションのサポートはより困難である。
・システムをテストするために十分な負荷を発生させることは難しいかもしれないが、個々のノードを独立してチェックすることは可能。
・多数のコピーを破損することなく、データをキャッシュして高速化するためのスキルを身につけるのは難しい。
空間ベースアーキテクチャを利用すべきケース
空間ベースアーキテクチャは、次のようなケースで利用すべきです。
・クリックストリームやユーザーログは大容量データの一例
・価値の低いデータで、紛失しても大きな影響がないもの、つまり、銀行取引ではないもの
・ソーシャルメディアネットワーク
まとめ
ソフトウェアアーキテクチャの概念は本当に難しいものですが、ソフトウェア開発でよく使われます。外見から左右されないように、まず、基本から理解し、自分の意見と見方を発展させることをおすすめします。
ソフトウェア開発の工程は一人では担当できません。社内と社外の両方からの援助が必要になる場合もあります。さらに相談したいことがある場合は、IT専門家からのアドバイスを求めると良いでしょう。
CMC Japanについて
本記事の読者の中で、システム開発パートナーをお探しの企業様がいらっしゃいましたら、是非CMC Japanをご検討ください。弊社は、30年の開発実績と2500名以上のITリソースを擁するベトナム大手オフショア開発企業の日本法人です。ベトナム人材によるコストメリットを活かしたシステム開発をご提供いたしますので、お気軽にお問合せください。
中長期的なリソース計画や開発コストの最適化をご検討の企業様は、お問い合わせフォームよりご連絡ください。
当社は日本のお客様に「止まらない、持続可能な開発」をベトナムオフショア開発で支援しています。
【動画】【2022年版】2分でわかる！オフショア開発とは？
ベトナムオフショア開発の活用で、コスト「60%」削減!! & 開発期間「1/2」短縮を実現できた事例をご紹介！
高品質なオフショア開発なら当社にお任せ！
【お役立ち資料】 ベトナムオフショア開発入門書
資料ダウンロード
資料は下記のフォームを送信して頂くと完了画面またはメールにてダウン口一ドできます
