1 .4 アーキテクチャの多重な次元 13 時間 監査可能性 0 「 パフォーマンス セキュリティ 要件 ユニットテスト、機能テスト、統合テスト 合法性 スケーラビリティ ~ アーキテクチャ全体のスコープ 図 1 - 3 アーキテクチャは要件とその他の各次元から構成され、それぞれが適応度関数によって保護 されている 我々はアーキテクチャを包括的に捉える考え方を重視している。しかし、その一方 で、技術アーキテクチャのパターンや結合、凝集などに関連する話題も、アーキテク チャを進化させる要素の大きな部分を占めると認識している。技術アーキテクチャ の結合がどう進化可能性に影響を与えるかは 4 章で、データ結合の影響については 5 章でそれぞれ説明する。 結合は単なるソフトウェアプロジェクトの構造要素を超えた部分にも適用される。 多くのソフトウェア企業は、最近になって、チーム構造がアーキテクチャのような驚 くべきものに影響を与えることを発見した。本書ではソフトウェアでの結合に関する 全ての側面に触れていくが、チームの影響はとても早い段階から頻繁に現れるため、 それについてここでます触れておきたい。
8.2 13 図 8 - 2 人数が増えるにつれ、コネクション数は急速に増加する チーム結合特性 い 85 開発チーム間のコネクション数を減らす努力をすること。 8.2 チーム結合特性 企業が自らの構造をどう整理し管理するかは、ソフトウェアの構築方法やアーキテ ていない。しかし、それは実に大きな影響を持っている。 トは、チーム構造がどのようにアーキテクチャの結合特性に影響を与えるかを考慮し 難にしたりする様々な組織、チームの側面について見ていく。ほとんどのアーキテク クチャに影響を与える。この節では、進化的アーキテクチャの構築を容易にしたり困 文化 ( 名詞 ) : 特定の人々あるいは社会の持っ考え、習慣、社会的行動。 8 念 1 文化 オックスフォード辞書 テクトは、リーダーシップの役割を果たし、技術文化を作り、開発者がシステムを構 フトウェアがどれだけ進化するかに大きな影響を与える。うまく機能しているアーキ テクトがツールを選択し設計を行うために使用する活動及び意思決定プロセスは、ソ なる行動をエンジニアがどう見つけるかについて気に掛けなくてはならない。アーキ アーキテクトは、エンジニアがシステムをどう構築するかや、組織にとって価値に
44 ー 3 章漸進的な変更を支える技術 加える度に、コードの正確さやアーキテクチャ内の全体的な適応度が大量のテ ストにより検査されるようになった。 進化的アーキテクチャのプロジェクトでよく実践されている別のプラクティスに は、継続的デブロイメントがある。継続的デブロイメントは、デブロイメントパイプ ラインを使い、パイプラインの厳しいテストをはじめとする各種検証が通ることを条 件に、変更を本番環境へと組み込む。継続的デブロイメントは理想ではあるものの、 開発者は本番環境にデブロイされた変更がシステムを壊さないようにしなければなら ないため、より高度な調整を必要とする。 この調整問題の解決には、デブロイメントパイプラインのファンアウト操作がよく 使われる。ファンアウトすると、パイプラインは図 3 - 7 に示すように、複数のジョブ を並列に実行する。 、ノーー 1 ス . 管理 アン一 現在の本番環境用ビルド / デブロイ 0 0 将来の環境用ビルド / デブロイ ファン イン 図 3 - 7 テプロイメントパイプラインは複数のシナリオをテストするためにファンアウトする 図 3 - 7 に示すように、変更を行うときには、チームは 2 つのことを検証しなくては ならない。それは、変更が現在の本番環境の状態に悪影響を及ばさないこと ( デブロ イメントパイプラインの実行が成功すると本番環境にコードがデブロイされるため )
8 章 進化的アーキテクチャの実践 目標は、運用上の摩擦を排除することだ。言い換えると、チームは、運用のような従 トにおける全ての役割がチームの誰かによってカバーされる。ドメイン中心チームの ドメイン中心チームは、機能横断型チームとなる傾向がある。つまり、プロジェク 8 工 1 機能横断型チーム の特徴を示す。 チャに関してはいくつかの利点を持つ。そして、そうしたチームは、いくつかの共通 技術的能力ではなくドメインを中心に編成されたチームは、進化的なアーキテク 算編成といった、通常はソフトウェアには関連しない様々な要因へと及ぶ。 ソフトウェアアーキテクチャの影響は驚くほど広範囲であり、チームへの影響や予 8.1 組織的要因 えを受け入れてもらうか、といったことについても示す。 事が含まれる。また、どこから始めるべきかや、どうやってビジネス側にこうした考 を見ていく。これには、組織やチームへの影響を含む、技術的及びビジネス上の関心 最後に、進化的アーキテクチャを中心とした考えを実践するために必要なステップ 割を持っということだ。さらに、この新しい構造に順応するため、 来は分割されていた役割を含む、サービスの設計、実装、デブロイに必要な全ての役 これらの役割は以 下のような形へと変わる必要がある。 ビジネスアナリスト そのサービスの目標と他のサービスの目標を、他のサービスチームを含めて調整
4.3 アーキテクチャスタイルの進化可能性一 93 明確なメリットがあるのであれば、なせ開発者はこのスタイルを採用していないの だろうか。 10 年前、マシンの自動プロビジョニングは不可能だった。オペレーティ ングシステムは商用ライセンスであり、自動化のサポートはほとんどなかった。予算 などの現実の制約もアーキテクチャに影響を与え、開発者がずっとずっと複雑なリ ソースを共有するアーキテクチャを構築し、アーキテクチャが技術レイヤで分離され ていたことの理由の 1 つだ。運用が高くついたり厄介な場合には、 ESB 駆動 S()A の ように、アーキテクトはそれを中心にアーキテクチャを構築する。 継続的デリバリー運動と DevOps 運動は、動的平衡に新たな要素を追加した。現 在では、マシンの定義はバージョン管理され、思い切った自動化をサポートしてい る。デブロイメントパイプラインは、複数のテスト環境を並行でスピンアップし、安 全な継続的デブロイメントをサポートしているソフトウェアスタックの多くがオー プーソーであることから、ライセ = をは一めとする各種 0 懸念事項は、もはや アーキテクチャに影響を与えない。コミュニティはソフトウェア開発工コシステムに 現れた新しい機能に反応して、よりドメイン中心のアーキテクチャスタイルを構築す るようになった。 マイクロサービスアーキテクチャでは、ドメインが技術アーキテクチャをはじめと する各種アーキテクチャをカプセル化することで、ドメインの次元を超えた進化を容 易にする。アーキテクチャに「正しい」視点は 1 つもない。しかし、アーキテクチャ は開発者がプロジェクトの中で作り上げる目標を反映する。技術アーキテクチャが焦 点の全てであれば、次元を超えた変更を加えることは容易だ。しかし、ドメインの視 点を無視すると、次元を超えた進化は巨大な泥団子も同然となる。 アーキテクチャレベルでアプリケーションの進化に影響を与える主な要因の 1 つ に、システムの各部が意図せすに結合されているかどうかという点がある。例えば、 レイヤ化アーキテクチャでは、アーキテクトは意図した方法で明確にレイヤを結合す る。ただし、ドメインの次元は意図せずに結合されることになるため、その次元での 進化は難しくなる。アーキテクチャがドメインではなく技術アーキテクチャのレイヤ を中心に設計されているからだ。したがって、進化可能なアーキテクチャの重要な側 面の 1 つは、次元をまたいだ適切な結合となる。 8 章では、実践的な目的で量子の境 界を特定して利用する方法を説明する。
8.3 CFO と予算い 89 解し、ツールや方法について実際の制約を見つけることができる。効果的なセッ トべース開発の鍵は、短い期間 ( 数日未満で ) でより具体的なデータや経験を作 るためにいくつかのアプローチをプロトタイプすることだ。いくつかの競合する 解決策を考慮した後で、より堅牢な解決策が現れることはよくある。 工ンジニアとエンドユーサーをつなげる 実験は、チームが仕事の影響を理解した場合にのみうまくいく。実験の精神を持 つ多くの企業では、チームとプロダクト側の人間は、最終顧客に対する意思決 定の影響を直接確認し、この影響を探る実験を行うことが奨励されている。 A/B テストす 3 は、企業がこの実験の精神に基づいて行うプラクティスの 1 つだ。企業 が実施する別の方法には、ユーザーがソフトウェアとどう相互作用して特定の仕 事を達成するかの観察行為に、チームやエンジニアを送り込む方法がある。ユー ザビリティのコミュニテイから出てきたこのプラクティスは、エンドユーザーへ の共感を築くものだ。このプラクティスを実践することで、エンジニアはしばし ばユーザーのニーズをより良く理解し、それをよりうまく満たす新しいアイデア を持ち帰る。 8.3 CFO と予算 予算編成などのエンタープライズアーキテクチャにある多くの伝統的な働きは、優 先事項が進化的アーキテクチャに変わったことを反映しなくてはならない。過去、予 算編成はソフトウェア開発ェコシステムの長期トレンドを予測する能力に基づいて行 われていた。しかし、本書を通して提示してきたように、動的平衡の基本的性質は予 測可能性を破壊する。 実際、アーキテクチャの量子とコストの間には興味深い関係が存在する。量子当た りのコストは、量子の数が増えると下がることになる。その傾向はアーキテクチャが スイートスポットに達するまで見られる。図 8 - 3 を見てほしい。 図 8 - 3 では、アーキテクチャ量子の増加に伴って、それぞれのコストは減少してい る。要因はいくつかある。ます、アーキテクチャがより小さい部分から構成されるた め、関心の分離はより離散的、定義的になることが挙げられる。第二に、物理的な量 子数が増加すると、運用面での自動化が必要になるということが挙げられる。特定の 時点を超えると、人が雑用を手作業で処理することはもはや現実的でないからだ。 https://ja.wikipedia.org/wiki/A/B テスト す 3
84 ー 4 章アーキテクチャ上の結合 メッセージ拡張と変換 統合ハプの利点の 1 つは、アプリケーションに代わってプロトコルや他の変換 を処理できることだ。例えば、サービス A は HTTP を「話し」、そしてサービス B を呼び出す必要があるとする。しかし、サービス B は RMI / IIOP だけしか「話せ ない」。こうした場合には、必要なときはいつでも目に見えない形でこの変換を 処理できるよう、サービスパスを構成できる。 ESB 駆動 SOA のアーキテクチャ量子はとてつもなく莫大だ。それはモノリスのよ うにシステム全体を包括するが、分散アーキテクチャであるため、モノリスよりもは るかに複雑なものとなる。分類は再利用を助けるものの、通常の変更に悪影響を与え る。そのため、 ESB 駆動 SOA では 1 つだけの進化的変更を行うことが並外れて難し い。例えば、 SOA 内でドメイン概念 Cata10gCheckout を考えると、それは技術アーキ テクチャ全体にしみわたっている。朝 taIogCheckout だけを変更するには、アーキテ クチャの部品間 ( 異なるチームで共有しているもの ) の調整が必要となり、それは膨 大な量の調整摩擦を発生させることになる。 この catalog 〔 he ( kout の表現を、マイクロサービスの境界づけられたコンテキスト による分割と対比しよう。マイクロサービスアーキテクチャでは、それぞれの境界づ けられたコンテキストは、ビジネスプロセスかワークフローを表現する。したがっ て、開発者は CatalogChe ( kout のようなものを中心に境界づけられたコンテキストを 構築する。 cataIogCheckout が customer についての詳細を必要とするが、それぞれの 境界づけられたコンテキストはそれぞれにエンティティを「所有」する可能性が高 い。もし他の境界づけられたコンテキストが customer の概念を持っていたとしても、 開発者は 1 つの共通的な custome てクラスへと統一しようとはしない (ESB 駆動 SOA こうした場合に 1 つの共通クラスへ統一することは好ましいアプローチだ ) 。 では、 境界づけられたコンテキストである CatalogCheckout と Ship0 て der が顧客に関する情 報を共有する必要がある場合には、 1 つの表現へと統一しようとはせすに、メッセー ジングを介して情報の共有を実現する。 ESB 駆動 SOA は、進化の性質を示すようには決して設計されていなかった。した がって、進化的アーキテクチャの側面のどれもが以下のように高い度合いを示さなく ても、それは驚くことではない。
ー 4 章アーキテクチャ上の結合 これらのアーキテクチャには、開発者が主要なアーキテクチャ特性を維持してい ることを保証するためにホリスティックな適応度関数を含める必要もある。例えば、 76 各パターンには異なるコア能力がある。こからは、パターンの詳細と進化への影響 には、 Broker バターンと Mediator バターンというよく知られた 2 つの実現方式がある。 セージキューを使い、複数の異なるシステムを統合する。この種類のアーキテクチャ イベント駆動アーキテクチャ ( E 肥ⅳ - 〃行肥月℃ん c res : EDA) は通常、メッ 生 3 イベント駆動アーキテクチャ 備える必要がある。 には、開発者は契約とメッセージの一貫性を保証するホリスティックな適応度関数も トスイートを持っことを計画する必要がある。依存プラグインを持つシステムの場合 がある。したがって、開発者はホリスティックな適応度関数として動作する統合テス 個々のプラグインはスケーラビリティのようなシステムの性質に影響を与える可能性 をそれぞれ個別に見ていく。 Broker 型 EDA では、 Broker ( プローカー ) ァーキテクチャコンポーネントは次の要素から構成される。 初期化イベント れる。 メッセージキュー メッセージキューは JMS (Java Messaging Service) などの様々な技術で実装さ ビジネスプロセスを満たすためにイベントプロセッサ間でやり取りされるイベン プロセス内イベント ビジネスプロセスを開始するイベント。 り取りする。 つのプロセッサが連携する必要がある場合には、 実際のビジネスプロセスを行うアクテイプなアーキテクチャコンポーネント。 2 イベントプロセッサ キューを介してメッセージをや
4.3 適応度関数による誘導的な変更 アーキテクチャスタイルの進化可能性 81 Broker よりも Mediator の方が適応度関数の構築は容易だ。個々のイベント プロセッサのテストは、 Broker 型と大きく違わない。 Broker 型と異なるの は、ホリスティックな適応度関数を容易に構築できることだ。調整を扱うた めに Mediator に依存できるからだ。例えば、保険のワークフローであれば、 Mediator が調整を行っているため、開発者は全体のプロセスがうまくいったか どうかのテストと識別を容易に行える。 適切な結合 多くのテストシナリオは Mediator によって容易になるものの、結合は増加し、 進化を妨げる。 Mediator は重要なドメインのロジックを含み、それを取り囲む ようにアーキテクチャ量子の大きさを増やし、各サービスを互いに結合する。 のアーキテクチャでは、開発者が変更を加えるたびに、結合を増やすことになる。 そして他の開発者はワークフロー内で他のサービスへの副作用を考慮する必要が ある。 進化的な観点では、 Broker アーキテクチャは結合を減らすことから明らかな利点 がある。 Mediator パターンでは、調整役が影響を受ける全てのサービスを結びつけ る結合点として機能する。 Broker パターンでは、既存のメッセージキューに新しい プロセッサを追加することで、他に影響を与えることなく動作を進化させることが可 能だ ( トラフィックによってキューが過負荷になる場合を除く。この問題は様々な アーキテクチャパターンと適応度関数によって解決可能なものだ ) 。 Broker パターン は本質的に疎結合化されているので、進化は容易となる。 これはアーキテクチャによるトレードオフの古典的な例だ。 Broker 型 EDA は、 進化可能性、非同期性、スケール、その他望ましい特性の大きさに関して、多くの利 点を提供する。しかし、トランザクションの調整のようなよくあるタスクをより難し いものにする。 4.3.4 サービス指向アーキテクチャ 多くのハイプリッドを含む、様々なサービス指向アーキテクチャ (Service-Oriented ℃ hitectures:SOA) が存在する。こではいくつかの代表的なアーキテクチャパ ターンを紹介する。
3. ] 構成要素ー 45 と、それらの変更がうまくいくこと ( 将来の環境に影響を与えるため ) だ。デブロイ メントパイプラインのファンアウトは、タスク ( テスト、デブロイなど ) を並列に実 行し、時間を節約できるようにする。図 3 - 7 に書かれている一連の並行ジョブが完了 すると、パイプラインは結果を評価する。そして、全てがうまくいっていたら、デブ ロイなどのタスクを実行するための単一のスレッドにファンインする。チームが複数 のコンテキストで変更を評価する必要がある場合には、この広がって狭まる組み合わ せをデブロイメントパイプラインが何度も行う可能性があることに注意してほしい。 継続的デブロイメントに関するもう 1 つのよくある問題は、ビジネスへの影響だ。 ユーザーは定期的に現れる新機能の弾幕を望んでいない。むしろ、「ビックバン」デ プロイのような、より従来型の方式で段階的にリリースすることを望んでいる。継続 的デブロイメントと段階的なリリースの両方に対応する一般的なやり方に、機能トグ ルを使用するというものがある。新しい機能を機能トグルの下に隠して実装すること で、ユーザーが早期にそれに気が付くことを心配することなく、開発者は機能を安全 に本番環境へデブロイできる。 本番環境における QA 新しい機能を構築するのに習慣的に機能トグルを使うようになると、本番環 境で QA タスクを実行できるという有益な副次的効果が得られる。多くの企業 は、探索的テストに本番環境を使えるということを認識していない。機能トグ ルを使うことに慣れてくると、チームは変更を本番環境へとデブロイできるよ うになる。だいたいの機能トグルをサポートするフレームワークは、ユーザー を様々な基準 ( 旧アドレスやアクセス制御リストなど ) に基づいてルーティン グすることを可能にするからだ。そうして、 QA 部門だけがアクセスできる機 能トグル内に新しい機能を導入することで、 QA 部門は本番環境でそれをテス トできるようになる。 デブロイメントパイプラインを使うことで、アーキテクトはプロジェクトの適応度 関数を容易に適用することが可能になる。必要なステージを把握することは、デブロ イメントパイプラインを設計する開発者によって共通の課題だ。プロジェクトにおけ