Fundamentals of Software Architecture: An Engineering Approach 読書メモ
ソフトウェアアーキテクトという仕事についての入門書です。ソフトウェアアーキテクトはまだ歴史の浅い職業なので、体系だった入門書が多くはありません。この本では、アーキテクトが身に付けるべき知識、スキルを
に大別して、それぞれ解説しています。
アーキテクチャ特徴
Architecture characteristicsのことです。邦訳はこれといったものが見当たらなかったので、直訳して使うことにします。
各種アーキテクチャへの要求のうち、個々のソフトウェア固有ではない一般的なもの、のような定義でしょうか。もっとハマりのいい定義があるかもしれません。
アーキテクチャ特徴は沢山あるのですが、この本では下記リストの特徴について、各アーキテクチャスタイルを採点しています。
Partitioning type
Number of quanta
Deployability
Elasticity
Evolutionary
Fault tolerance
Modularity
Overall cost
Performance
Reliability
Scalability
Simplicity
Testability
見ていただければ分かりますように、このリストはアーキテクチャ特徴を網羅している訳ではなく、意味が重複している項目もあります。それでも分析の出発点には十分なります。
詳細な定義は原著を読んでもらうのがいいですが、それぞれ簡単に紹介します。
Partitioning type
何を元にコンポーネントを切り分けるか、です。TechnicalとDomainの二種類あります。
プレゼンテーション層、サービス層など技術的な関心を元にして切り分ける場合はTechnicalで、ユーザーや商品など、ドメインを元にして切り分ける場合はDomainです。
原著にわかりやすい画像を載せてくれていたので、転載します。
Chapter 8. Component-Based Thinking
Number of quanta
デプロイの単位がいくつあるか、です。例えばフロントエンドとバックエンドを分離していて別々にデプロイできる場合、Number of quantaは2となります。
Deployability
デプロイのしやすさです。小さな単位でデプロイできたり、自動化が進んでいる場合は高くなります。逆に、コンポーネントが密結合になっていたり、デプロイ手順に手動の項目が多かったりすると低くなります。
Elasticity
アクセスが急上昇しても耐えられるか、です。Scalabilityとの違いがよく分かっていなかったのですが、
Scalability → アクセスが徐々に増えていっても対応できるか
Elasticity → アクセスの急な増減に対応できるか
と説明してあって分かりやすかったです。
こちらも原著のイラストで、
Scalability
Elasticity
こうして見ると違いがよく分かります。
Evolutionary
新たなコンポーネント、機能を追加するのが容易かを表します。拡張性ですね。
Fault tolerance
一部のコンポーネントが異常でも、システム全体としては正常に動作する能力です。耐障害性が近い？
Modularity
アーキテクチャが、どの程度パーツ毎に分離されているかを表します。モノリシックなアーキテクチャに近付くほど、Modularityは低くなります。
Overall cost
そのアーキテクチャを採用するコストです。サーバーなどの計算リソースだけではなく、実装するエンジニアの作業量や、学習コストなども入ります。そのアーキテクチャに関する経験の薄い組織の場合、アーキテクチャ採用の許可をマネジメント層から得るための説得にかかる労力なども、コスト計算に入れなければならないかもしれません。
Performance
どれだけ多くのリクエストを捌けるか、レスポンスを返すまでにどの程度の時間がかかるのか、などです。
Reliability
信頼性。どれだけ長い時間、システムダウンせずに稼働し続けられるかを表します。
Scalability
継続的なアクセス増加にどの程度対応可能かを表します。Elasicityの項目と比較すると違いがわかりやすいです。
Simplicity
アーキテクチャの単純さを表します。単純なほど理解、実装が容易です。
Testability
テストのしやすさです。細かい粒度でモジュール分けしてある方がテストがしやすく、テスト自動化もしやすいです。
アーキテクチャスタイル
プログラミングにおけるデザインパターンと同じように、アーキテクチャにも定番のパターンが存在します。新たに誕生したり、使われなくなるものもあるので普遍的なものではありませんが、この本では下記のアーキテクチャパターンを取り上げています。
モノリシックアーキテクチャ
Layered Architecture Style
Pipeline Architecture Style
Microkernel Architecture Style
分散アーキテクチャ
Service-Based Architecture Style
Event-Driven Architecture Style
Space-Based Architecture Style
Orchestration-Driven Service-Oriented Architecture
Microservices Architecture
詳細に解説すると分量が多くなるので、要点のみ簡潔に記載します。
Layered Architecture Style
プレゼンテーション層やサービス層など、層ごとに役割を割り当てて切り分けるアーキテクチャです。
層をスキップしたアクセスはしないのが基本です。↓のイメージだとPresentation LayerはBusiness Layerのみにアクセスできて、Persistence Layer以下へのアクセスはできません。
しかし何らかの事情でスキップしたい場合もあります。その場合、スキップが可能な層をopen、スキップできない層をcloseと呼びます。
シンプルで分かりやすいのが最大の特徴で、特にプロジェクトの初期に土台として選択するのに適したアーキテクチャです。
Pipeline Architecture Style
独立したFunction同士を繋いでいくアーキテクチャです。シェルのワンライナーなどが代表的です。
シンプルさが特徴で、機能の追加なども容易です。パイプラインの途中で異常が発生するとシステム全体が正常に動作しなくなってしまうので、耐障害性は低いです。
Microkernel Architecture Style
コアとなるコンポーネントを用意しておいて、必要に応じて機能をPlug-inするアーキテクチャです。WordPressとかがイメージ近いのかな？と思っています。
機能の追加、削除が容易なのが特徴です。
Service-Based Architecture Style
独立したサービスがいくつか(4 ~ 12程度)存在していて、UIとDBを共有しているアーキテクチャです。UIとDBはサービス毎に分離することもあります。
非常にバランスが良く柔軟なアーキテクチャなので、分散アーキテクチャの基本として使うことができます。
Event-Driven Architecture Style
特定の条件でイベントを発生させて、各サービスは必要に応じてそのイベントに反応するアーキテクチャです。
イベントを中央で管理するMediator Topologyと、
中央管理をしないBroker Topologyが存在します。
Mediator Topologyではワークフローやトランザクションの管理がやりやすいですが、複雑さが増すことになります。
機能の追加がしやすく、パフォーマンスも高いですが、どうしても複雑になります。
Space-Based Architecture Style
スケールアウトを試みる際、webサーバー、アプリケーションサーバー、DBの順に難しくなります。DBのボトルネックを解消するために使われるのがこのアーキテクチャです。
DBへ直接アクセスするのではなく、インスタンス毎にキャッシュを保持する構成です。データに変更があった場合はDB Reader, Writerへmessageを送信します。
データ不整合が発生する確率の計算式なども記載してあったので、パフォーマンスと信頼性のバランスを検討する際に使えるかと思います。
パフォーマンスを非常に高くできますが、その分だけ複雑で、テストも難しいです。また、データ不整合の可能性をどうしても含んでしまうので、それを許容できないケースもあるかと思います。
Orchestration-Driven Service-Oriented Architecture
計算リソースやソフトウェアのライセンスが、今よりはるかに高価だった頃の遺産のようなアーキテクチャです。ライセンスを購入しなければならないソフトウェアの機能を、全く関係のないサービス同士で共有してコストカットすることができます。
スケーラビリティは比較的高いですが、極端に複雑な構成になります。現在では、新規でこのアーキテクチャを採用する理由は無いと思います。しかし歴史のあるサービスなどではまだ現役で動いているかもしれないので、知っておく意義はあります。
Microservices Architecture
各サービスが独自のDBを持っていて、相互にやり取りをするアーキテクチャです。
柔軟でパフォーマンスが高く、テストもしやすいです。その代わり極めて複雑なため、育てるのが大変なアーキテクチャです。
ソフトスキル
技術的な知識が必要なのは当然ですが、この本では関係者との交渉、チームマネジメント、日々の学習など、ソフトスキルにも重きを置いていました。
アーキテクチャを図解する際の記号の用法
開発者と生産的な関係を築く方法
毎日の勉強にあてるべき時間
などなど、具体的なtipsが多かったです。
所感
著者が一貫して強く主張していたのは、「アーキテクトが抱える問題に問題に一般解は無い」ということです。どんなプロジェクトでも最適なアーキテクチャはありませんし、これさえやればプロジェクトは必ずうまくいく！ようなものもありません。
市場やチームの状況、各関係者の思惑などを見ながら、その状況に合った特殊解を考え続けるのがアーキテクトの仕事です。アーキテクチャ特徴やアーキテクチャスタイルを理解するのは前提として必要だと思いますが、それだけではなく開発者や経営層といい関係でいられるように努力し続けるのが肝心だと思いました。
アーキテクチャ特徴やアーキテクチャスタイルは、リファレンスとしても使いやすいのではないでしょうか。プロジェクトの立ち上げ時などに、ざっと目を通し直すといいかもしれません。
