ソフトウェアアーキテクチャの基礎

ソフトウェアアーキテクチャには明確な定義がなく、専門家によって定義が異なることも少なくない。本記事では、以下を包括するものをアーキテクチャと呼ぶことにする。

同期通信か非同期通信か、モジュラーモノリスかマイクロサービスか、データベースを分割するかしないかなどの判断は、システムが動作する環境、企業の予算や期間、開発者のスキルセット、その他多くの要因に依存する。つまり、あらゆるアーキテクチャに関わる問題の答えは「場合による」である。

また、最初からうまくゆくアーキテクチャは存在せず、絶えず分析と改善を繰り返していく必要がある。

ソフトウェアアーキテクチャの範囲は広く、こうすれば良いという統一的な法則はないが、以下の要素は共通している。

アーキテクチャ特性に普遍的な標準リストは存在しない。急速に進化するソフトウェアに合わせて、常に新たな概念が生まれている。以下にいくつかの分類とアーキテクチャ特性を示す。

アーキテクチャ特性

出典：ソフトウェアアーキテクチャの基礎（表4-1~4-3）

あらゆるアーキテクチャ特性を同時に満足させるアーキテクチャは存在しない。そのため、状況に応じてトレードオフを分析し、「少なくとも最悪でないアーキテクチャ」を選択をするしかない。

マイクロサービスのような分散アーキテクチャは、パフォーマンス、スケーラビリティ、可用性の点でモノリシックアーキテクチャよりも強力だが、決して「銀の弾丸」などではなく、当然大きなトレードオフが存在する。ここでは、分散コンピューティングの８つの誤信（正しいと信じられているが実際には誤っていること）を紹介する。

時代とともに向上してはいるが、ネットワークの信頼性は依然として低いままである。分散アーキテクチャでは、すべてのサービス間通信がネットワークに依存するため、ネットワークの問題でレスボンスが得られなくなるなど、信頼性が低下する。

ローカルでメソッドを呼び出すときにかかる時間はナノ秒またはマイクロ秒単位だが、リモートアクセスでかかる時間はミリ秒単位になる。1回のリクエストの平均レイテンシーが100ミリ秒だとして、特定の機能を実行するのに10回のリクエストが必要になる場合、平均レイテンシーは1000ミリ秒となる。「ロングテール」のレイテンシーを引かされたら、パフォーマンスはさらに低下する。

分散アーキテクチャでは、すべてのサービス間通信がネットワークに依存する。もし、ユーザー情報を取得する際に、不要な情報を含めてまるごと取得するような仕様になっている場合、すぐにネットワーク帯域を圧迫して、ネットワークの速度低下や信頼性の低下につながる。

VPNや信頼できるネットワーク、ファイアウォールを使うことに慣れて忘れがちだが、ネットワークは安全ではない。分散アーキテクチャの全ユニットのエンドポイントを悪質なリクエストから保護しなくてはならず、これはパフォーマンスの低下にもつながる。

トポロジー（ネットワークの接続形態）には、ルーター、ハブ、スイッチ、ファイアウォール、ネットワーク、アプライアンスすべてが含まれていて、これらは常に変化している。ネットワークの軽微なアップグレードによって、パフォーマンスの低下や信頼性の低下につながる可能性もある。

古典的な大企業には、ネットワーク管理者が数十人いることもある。今扱っている分散アーキテクチャが正しく動作するようにするために、誰に何を（一体全体何人と）相談し、調整すればよいのだろうか。

ネットワークを経由したサービス間通信にも当然コスト（費用）が発生する。さらに、分散アーキテクチャの構築には、モノリシックアーキテクチャより余分に、ハードウェア、サーバー、ゲートウェイ、ファイアーウォール、サブネット、プロキシなどを用意する必要がある。

ほとんどの企業は、複数のネットワークハードウェアベンダーを使ってインフラを構築している。そしてそれらのハードウェアベンダーはすべてがうまく連携しているわけではない。ときには、ネットワークの信頼性やレイテンシー、帯域幅に影響を与えることもある。

アーキテクチャスタイルは、様々なアーキテクチャ特性をカバーするアーキテクチャの構造を表現するパターンの名前。現在一般的になっているいくつかのアーキテクチャスタイルを紹介する。

アーキテクチャ特性の評価表

上記のアーキテクチャスタイルは、様々なアーキテクチャ特性をカバーしているが、「銀の弾丸」などというものはなく、状況に合わせて選択する必要がある。