Zenn
🦔

Software Architecture and Decision-Makingから学ぶ設計判断

2024/07/13に公開
デザイン
performance
book
architecture
idea

Software Architecture and Decision-Makingという本を読んで面白かったので、一部をかかいつまんで紹介します。

作者はApacheプロジェクトで20年ほどアーキテクチャ設計をしてきた人で、Axis2、Airavata、WSO2 CEP、WSO2 Choreoなどにかかわっています。作者は、リーダーシップとアーキテクチャ上の意思決定の間の溝を埋めたいと考えてこの本を書いたそうです。アーキテクチャの欠陥やミスは知識と決断のギャップからくることが多いので、そこを埋めようということです。

概要

Book cover

本としては、基本的にテクニカル寄りの内容です。
UX、パフォーマンス、セキュリティ、HA、各種アーキテクチャなどさまざまな話題を説明しながら、各章の最後で「リーダーシップ検討事項」として、次に紹介する5つの質問と7つの原則に絡めたポイントを説明するというスタイルになっています。

5つの質問と7つの原則

この本のキーとなるのが5つの質問と7つの原則です。5つの質問を使ってビジネスコンテキストや自分たちの環境の制約を理解し、7つの原則をトレードオフ判断の指標として使います。

5つの質問

まずは5つの質問を簡単に紹介します。

  1. 市場に出す最適なタイミングは？
    時間制約が厳しいことはよくありますが、時間問題はスキルとお金では解決できません。なので作り直しを前提にしたり、スコープ調整するしかありません
  2. チームのスキルレベルは？
    理想のメンバーを高望みをしても意味はありません。身の丈に応じた設計判断をすること。でもセキュリティーなど大事なポイントは人を雇うことも検討すること
  3. システムパフォーマンスへの感度は？
    ほんっっとうにそのパフォーマンス要件は必要かよく考えてください
  4. システムはいつ作り直せますか？
    作ったシステムをずっと維持するつもりで考えず、作り直す時期を考えてください
  5. 難しい問題は？
    その「難しい問題」はあなたに競争優位をもたしますか？もたらさないなら誰かが対応済みなので、そこから学びましょう。もたらすならシステムから切り離して早くから取り組みましょう

7つの原則

7つの原則も紹介します。

  1. すべてをユーザージャーニー駆動で進める
    UXはとても大事で、使ってもらえるシステムにするだけでなく、使われない機能や価値のない機能の導入を抑えられ、システムをシンプルに保つのにも役立ちます
  2. イテレーティブな薄いスライス戦略を使用する
    要求された機能を全部作ってから統合するのではなく、1つの機能を端から端まで作ることを繰り返しましょう。この時、アーキテクチャは必要最低限のシンプルさに保ちましょう
  3. 各イテレーションでは、最小労力で最大価値をより多くのユーザーに届ける
    本当に価値がある機能は一握り。いきなり作り始めるのではなく、価値を定義し、それを得るためにリソースを使いましょう
  4. 決定を下す。リスクを受け入れる
    非機能要件だって「必要な要件は間違いなくこうです」といえることはありません。ユーザーだって知りません。決めるしかないのです。そして、決めればみんなその方向に動き出します
  5. 変更が難しいものはじっくり設計し、ゆっくり実装する
    他者に公開する部分など、設計の中には一度決めると変えにくいものがあります。こういうものは深くじっくり設計し、ちゃんと理解をし、将来変更のリスクを避ける必要があります
  6. 困難な問題に早くから取り組むことで、未知の排除とエビデンスからの学習を行う
    実験や試行錯誤は重要な「ツール」であり、これを使って未知に気づき、排除していきます。問題に気づけるよう、モニタリングへの投資も大事です
  7. ソフトウェアアーキテクチャにおける凝集性と柔軟性のトレードオフを理解する
    柔軟性は変更力を高めますが、高くつきます。凝集性は部品の再利性に関係しますが、再利用すればいいというものでもないことに注意が必要です

オーバーエンジニアリングを避ける

個人的に特に興味深かったのは5つの質問の#3と#4です。

私たちはよくイケてるビジネスプランを立てて、プランに書かれている「将来のたくさんのユーザー」を想定してアーキテクチャを設計してしまいます。ユーザーに快適な体験を届けたいという思いでかっこいいテクニックを導入してシステムを複雑化させますが、実際にはそのユーザーはまだ存在しません。

そこで、システムを作り直すポイントを決めておく(#4システムはいつ作り直せますか？)ことで、シンプルに始めても大丈夫という気持ちになります。実際にユーザー数が増えてきた場合、それはビジネス上の成功を意味しますので、お金も入るようになってきているはずです。それをシステムの作り直しに使えばいいのです。

もう一つ大事なのがパフォーマンス対策です。これはシステムの複雑化に大きく貢献します。想定ユーザー数や処理リクエスト数が一線を越えるごとに大幅に複雑になっていくということが紹介されています。そのため、本当にそれが必要なのか、重要なのかを問うのが#3システムパフォーマンスへの感度は？という質問です。

#4を決め、最小限なシステムを作り、#3のパフォーマンス感度が低いようならこれへの投資も押さえます。実際には、Request per threadのようなシンプルなモデルでも長くにわたって十分に稼働することが多いそうです。なので、オーバーエンジニアリングへの不安や欲望を抑えるこれらの質問が大事になってきます。

パフォーマンス関連では、予期せぬ負荷対策としてこんな対策も紹介されています。
「サービスへの入場制限を行いし、不便を被ったユーザーの1ヶ月のサブスク料金をタダにする」
CAC(顧客獲得コスト)に比べればサブスク料金なんて安いものといえる場合にはこういった手段も有効です。

マクロアーキテクチャのビルディングブロックたち

沢山の話題をカバーした本ですが、ここではビルディングブロックについてのセクションを紹介します。
既にあるものを利用できるなら利用できる方がいいですよね。そのためにはどんなビルディングブロック(構築要素)があるか、カタログを知っておくことが大事です。

  • データ管理
    • データベース: MySQL、PostgreSQL、MSSQL、Oracleなど
    • 分散キャッシュ: 複数のノードにまたがる仮想キャッシュ。Hazelcast、Apache Igniteなど
    • レジストリ: パーツ同士が情報共有するためのもので、何を共有したいかでいろいろある。etcdなど
  • ルーターとメッセージング
    • ロードバランサー: ハードウェアタイプとソフトウェアタイプがある。H5、NGINXなど
    • APIマネージャー: 安全に外部公開するためのもので、セキュリティやサブスク管理などを行う。WSO2 API Manager、Google Apigeeなど
    • エンタープライズサービスバス (ESB): 異なるシステム間の統合とメッセージ変換を行う。WSO2 ESB、Mule ESBなど
    • メッセージブローカー: 非同期メッセージング。ActiveMQ、RabbitMQ、IBM MQ、TIBCO、Apache Kafkaなど
  • エグゼキューター
    • ワークフローシステム: 長時間実行されるタスク(数年レベルでも)を管理する。ストレージ保存や回復なども。Apache Ode、Kamundaなど
    • MapReduceシステム: 大規模データの並列処理を実現する。Apache Sparkなど
    • コンテナ/VM管理: 仮想化環境やコンテナの管理とオーケストレーション。Kubernetes、VMwareなど
  • セキュリティ
    • IAMサーバー: ユーザー管理、認証、認可などを実現する。WSO2 Identity Server、Centrify、Asgardeo、Auth0など
  • コミュニケーション
    • 分散ハッシュテーブル (DHT): 効率的なデータ分散と検索を実現する
    • ゴシップアーキテクチャ: 大規模なノード間でのデータ同期を可能にする
    • 責任のツリーパターン: 階層的なタスク分散と結果収集を実現する
    • 分散コーディネーションシステム: 複数ノード間の協調動作を支援する。Apache ZooKeeper、Redisなど
  • その他
    • トランザクションマネージャー: 分散環境でのトランザクションを実現する。Atomikoなど。WebLogic、IBM WebSphere、JBossにも含まれる

クラウドプロバイダーが提供する機能との統合についての話もあります。
浅い統合と深い統合のトレードオフなどについて説明されています。

面白い本だと思いますので気になる方はぜひ読んでみてください👋

Discussion