7.2 漸進的な変更いハ がって、プロジェクトのサイクルタイムは、アーキテクチャの進化速度を決定する。 言い換えると、進化速度はサイクルタイムに比例するということだ。これは次の式に よって表される。 Ⅸ C v は変化のべロシティ (velocity) を表し、 c はサイクルタイム (cycletime) を表 す。開発者はプロジェクトのサイクルタイムより速くシステムを進化させることはで きない。言い換えると、チームがソフトウェアをより速くリリースできれば、チーム はシステムの一部をより速く進化させることができるということだ。 サイクルタイムは、したがって進化的アーキテクチャの重要なメトリクスだ。サイ クルタイムが速ければ速いほど、進化速度が速いことを意味する。実際、サイクルタ イムはプロセスペースのアトミックな適応度関数の優れた候補となる。例えば、開発 者は自動化されたデブロイメントパイプラインを使ってプロジェクトをセットアップ し、 3 時間のサイクルタイムを達成する。時間が経ち、開発者が検証や統合点をデブ ロイメントパイプラインにより増やすにしたがって、サイクルタイムが徐々に増えて いく。市場投入時間はこのプロジェクトにとって重要なメトリクスなため、チームは サイクルタイムが 4 時間を超えると警告を出す適応度関数を確立する。適応度関数 がしきい値に達すると、開発者はデブロイメントパイプラインの仕組みを再構築した り、 4 時間のサイクルタイムが許容できるかどうかを判断したりする。適応度関数は、 プロジェクトメトリクスを含め、プロジェクトを監視したい開発者のあらゆる行動に 対応付けられる。プロジェクトの関心事を適応度関数として統一することで、開発者 は、最終責任時点として知られる将来の判断点を設けることができる。先ほどの例で は、開発者はその時点で 3 時間のサイクルタイムと彼らが作成したテストの集合の どちらがより重要かを判断する必要がある。ほとんどのプロジェクトでは、開発者は 徐々に上昇するサイクルタイムに気付くことはない。したがって、競合する目標に優 先順位をつけることもないため、こうした決定を暗黙的に行っている。適応度関数を 使用すると、将来の判断点を中心にしきい値を設定できる。
170 ー 7 章進化的アーキテクチャの落とし穴とアンチパター 7 念 3 落とし穴 : リリース速度の欠如 ン 継続的デリバリーの開発プラクティスは、ソフトウェアのリリースを遅くする要因 に対処している。それらの開発プラクティスは、進化的アーキテクチャを成功させる の変更がデブロイメントパイプラインによって配置された難所を通過した場合に限り 企業が継続的デブロイメントを中心にエンジニアリング文化を構築するなら、全て はない。しかし、ソフトウェアをリリースする能力とソフトウェアの設計を進化させ 中の極端な意見については、進化的アーキテクチャを成功させるために必須なわけで ための公理的なものだと考えるべきだ。継続的デリバリーや継続的デブロイメントの る能力の間には強い相関が存在する。 が速いということは、アーキテクチャがより速く進化できることを意味する。した すいからだ。進化的アーキテクチャにおいても同様のことが言える。サイクルタイム サイクルが短く、新しい世代がすぐに現れるので、遺伝特性の顕著な結果を確認しや な遺伝特性を説明するための実験にミバエ ( 実蠅 ) がよく使われる。ミバエはライフ 進化的アーキテクチャにおいても、サイクルタイムは重要だ。生物学では、部分的 目標の 1 っとなる。 測定することであり、サイクルタイムを短縮することは、継続的デリバリーの重要な で実行されると計測を終了する。サイクルタイムの目標は、エンジニアリング効率を は、開発者が新しい機能に対する作業を始めると計測を開始し、その機能が本番環境 す。作業の単位は、この場合はソフトウェア開発となる。サイクルタイムの計測で る。サイクルタイムとは、作業の単位あたりの開始から終了にかかる経過時間を指 スは貧弱になる。そこで、継続的デリバリーでは代わりに、サイクルタイムを追跡す 付けといった主観的な活動が多く含まれるため、エンジニアリングに関するメトリク ウェアの中に現れるまでの時間のことだ。しかし、リードタイムには見積や優先順位 連するメトリクスだ。リードタイムとは、アイデアの始動からそのアイデアがソフト なメトリクスの 1 つにサイクルタイムがある。サイクルタイムとは、リードタイムに関 するために、物事を計測できなくてはならない。継続的デリバリーが追跡する主要 を学ぶためにメトリクスを採用する。開発者はメトリクスをより良くする方法を理解 継続的デリバリーはデータ駆動の成果を追い求め、プロジェクトを最適化する方法 れば、進化的アーキテクチャを活用できる可能性は低くなる。 一方で、もしリリースが多くの専門的な作業を必要とする形式的なプロセスなのであ 本番環境へ進むことが当たり前となり、開発者は絶えす変更していくことに慣れる。
120 ー ある。 6 章進化可能なアーキテクチャの構築 これには、技術アーキテクチャと、データ設計やセキュリティ、スケーラビリ ティといったアーキテクトが一般に重要だと考える各種の「 ~ 性」が常に含まれる。 特定に際しては、ビジネス、運用、セキュリティなどの影響を受けるグループを含 む、組織内でそれに関心を示すチームが関与している必要がある。そのためには、機 能横断型チームを後押しする逆コンウェイ戦略 ( 「 1.5 コンウェイの法則」参照 ) が 役立つ。基本的に、これはプロジェクトの開始時、支援したいアーキテクチャ特性を 特定する際にアーキテクトが行う一般的な行動だ。 6 2 ②それそれの次元に対して適応度関数を定義する 1 つの次元が複数の適応度関数を含むのはよくあることだ。例えば、コンポーネン トの循環依存を防止するというような、コードベースのアーキテクチャ特性を保証す る際は、コードメトリクス群をデブロイメントパイプラインへと組み込むのが一般的 だ。アーキテクトは、どの次元を継続的に注視するかを決定し、それを Wiki などの 軽量フォーマットで文書化する。そして、それぞれの次元に対して、進化にあたって 望ましくない動作を示す可能性のある対象を決定し、最終的に適応度関数を定義す る。適応度関数は自動化されていても手動でもよい。しかし、定義に際しては、工夫 を要する可能性がある。 6. れ 3 ③デブロイメントバイプラインを使って適応度関数を そして最後に、デブロイメントパイプラインに適応度関数を適用するステージ群 を定義し、マシンプロビジョニングといったデブロイメントの実践やテストなどの DevOps の関心事を管理しながら、プロジェクトの漸進的な変更を促進する必要があ る。漸進的な変更は進化的アーキテクチャのエンジンとして、デブロイメントパイプ ラインを介した適応度関数の積極的な検証と、デブロイメントなどの日常的な作業を 見えなくする高度な自動化を可能にする。プロジェクトで進化的アーキテクチャを支 える開発者の責務の一つは、サイクルタイムを良い状態に維持することがある。サイ クルタイムとは、継続的デリバリーのエンジニアリング効率を測定する値のことだ。 他の多くのメトリクスがそこから派生するため、サイクルタイムは漸進的な変更にお いて重要な意味を持つ。例えば、新しい世代がアーキテクチャに現れる速度は、サイ クルタイムに比例する。つまり、もしプロジェクトのサイクルタイムが長くなれば、 自動化する
190 ー 8 章 進化的アーキテクチャの実践 コスト / 量子 数 子 アーキテクチャ量子とコストの関係 図 8 - 3 しかし、量子をとても小さくすると、せん断数はより重いコストとなる可能性があ る。例えば、マイクロサービスアーキテクチャでは、フォームの 1 つのフィールド の粒度でサービスを構築することが可能だ。そのレベルでは、それぞれの小さな部品 間の調整コストがアーキテクチャの他の要素を支配し始める。したがって、極端なグ ラフでは、量子のせん断数が量子当たりの利点を減らすことになる。 進化的アーキテクチャでは、アーキテクトは適切な量子サイズと対応する調整コス トの間のスイートスポットを見つけようと努力する。このスイートスポットは、全て の企業で異なっている。例えば、積極的な市場の中にいる企業であれば、より速く動 く必要があり、したがって、より小さな量子サイズを望む可能性がある。新しい世代 が出現する速度はサイクルタイムに比例するため、より小さい量子サイズはより短い サイクルタイムとなる傾向があることを覚えておいてほしい。 他の企業は、共通の変更をより詳細にモデル化することから、より大きな「アプリ ケーションの一部」を量子サイズとするサービスペースアーキテクチャ ( 4 章参照 ) を構築することが現実的だと考えるかもしれない。 計画を無視するエコシステムと対峙している中では、多くの要因がアーキテクチャ とコストの最適な釣り合いを決定する。これは、アーキテクトの役割が拡大したとい う我々の見解を反映している。アーキテクチャ上の選択は今まで以上に影響を持つよ うになったのだ。 現代のアーキテクトは、エンタープライズアーキテクチャについての数十年前の
172 ー ーン 7 章 進化的アーキテクチャの落とし穴とアンチバタ 進化の速度はサイクルタイムの関数だ。サイクルタイムを速めることで、進化を 速めることができる。 場合、ビジネス担当者は、開発者にとって難しいことをしようとする悪人ではない。 最後に、ビジネス上の関心事からくる不適切な結合について説明する。ほとんどの 7.3 ビジネス上の関心事 しい能力を実現することができる。 ト、リリースの実践が不可欠だ。それによって、仮説駆動開発を用いてビジネスの新 進化的アーキテクチャを成功させるには、優れたエンジニアリングやデブロイメン ス 3.1 落とし穴 : 製品のカスタマイズ ビジネス上の落とし穴やアンチパターンについて紹介する。 ーでは、 判断に至らせる優先順位を持っているだけのことがほとんどだ むしろ、アーキテクチャの観点から不意に未来の選択肢を制約するような、不適切な 一握りの でプレミアム機能を解除できる無料バージョン ) を作成したりする。 バージョンを構築したり、製品の「フリーミアム」バージョン ( 料金を払うこと 戦略的に使われることがある。開発者は機能トグルを使って、顧客ごとに異なる 3 章で紹介した機能トグルは、しばしば永続的なカスタマイズを作成するために 永続的な機能トグル プランチやタグなどを駆使することを強制する。 東する。それは開発者にバージョンを追跡するためにバージョン管理システムの このシナリオでは、営業は厳しい時間スケールの上で機能の固有バージョンを約 顧客ごとの個別ビルド のコストと引き換えだ。 フトウェアを欲しがる。しかし、そのカスタマイズ可能性は、実装技術が要する相応 くらいだ。すなわち、営業は製品を売りたいがために、無限にカスタマイズ可能なソ かが決まる前に、要求された機能を何でも売ってしまうという営業の風刺漫画がある 営業は販売のための選択肢を望んでいる。実際にその機能が製品に含まれるかどう
8.7 なぜやるか ( あるいは、なせやらないか ) ー 201 トウェアを競争上の優位性とみなす。例えば、もし Acme 、 Vigets がサイクルタイム が 3 時間のアーキテクチャを作成し、 PenultimateWidgets が依然として 6 週間のサ イクルタイムだったとすると、 AcmeWigets は有効に使える利点を持っことになる。 主に競争の激しい市場にいる多くの企業が、サイクルタイムを第一級のビジネス メトリクスとしている。全ての市場は、最終的にここが競争の場となる。例えば、 1990 年代初めには、いくつかの大企業が手動ワークフローをソフトウェアを介した 自動化に積極的に取り組み大きな利点を得て、全ての企業が最終的にその必要性を認 0 量子レベルでアーキテクチャ特性を分離する 伝統的な非機能要件を適応度関数として考え、十分にカプセル化されたアーキテク チャ量子を構築することで、アーキテクトは量子ごとに異なる特性をサポートでき る。これは、マイクロサービスアーキテクチャが持っ利点の 1 つだ。各量子の技術 アーキテクチャが他の量子と疎結合になっているため、アーキテクトは異なるユース ケースに対して異なるアーキテクチャを選択できる。例えば、小さなサービスの開発 者は、漸進的な追加を許容する小さなコアをサポートしたいために、サービスにマイ クロカーネルアーキテクチャを選択するかもしれない。別のチームの開発者は、ス ケーラビリティに関心があることから、サービスにイベント駆動アーキテクチャを選 択するかもしれない。もし両方のサービスがモノリスの一部だったとしたら、アーキ テクトは両方の要件を満たすためにトレードオフを行わなくてはならない。小さな量 子レベルで技術アーキテクチャを分離することによって、アーキテクトは、競合する 優先順位のトレードオフを分析するのではなく、 1 つの量子の主要な特性に自由に集 中することができる。 8. ス 2 ケーススタディ : PenuItimateWidgets における 選択的なスケール PenuItimateWidgets には、スケールの必要がないために単純な技術スタックで 書かれているいくっかのサービスがある。しかし、数個のサービスは突出していた。 lmport サービスは、会計システムのために毎晩、実際の店舗から在庫金額をインポー トする必要がある。したがって、開発者が lmport サービスに構築したアーキテクチャ 特性や適応度関数にはスケーラビリテイや回復性が含まれており、サービスの技術アー
200 ー 8 章進化的アーキテクチャの実践 た設計になっていた。 スが低下し、全てのページ読み込みが遅くなった。 てきた。ある時点でデータベースのスケールは限界へと達し、サイトはパフォーマン トラフィックが増加すると、データベースを拡張する必要が出 Amazon は全てを 1 つのもの ( リレーショナルデータベース、エンタープライズ て捉え、コストを最小限に抑えようとする。対照的に、イノベーテイプな企業はソフ るからだ。いくつかの大規模で保守的な組織は、ソフトウェアをオーバーヘッドとし その理由は、サイクルタイムがいくつかの市場でビジネスの差別化要因となってい なる。なぜ企業はそれほどまで遠くに行くのだろうか。 続的デブロイメントを実現するには、かなりの量のエンジニアリングの洗練が必要と テージが自動的に次のステージへ昇格する継続的デブロイメントの区別を行った。継 くとも 1 つのステージでは手動プルを行う継続的デリバリーと、成功すると全てのス 「 3.1.2 デブロイメントパイプライン」では、デブロイメントパイプラインの少な ビジネスメトリクスとしてのサイクルタイム 企業に与える。 化的アーキテクチャは予測不能で避けられない変化に対するより良い技術的応答性を B テストを実行することは難しく、それは関心の分離をより難しくする。一般に、進 要素は、進化可能なアーキテクチャだ。例えば、コンポーネントの結合が高いと A/ を組み込むことに憧れている。高度な DevOps の多くを実践するための主要な構成 る。多くの企業では、多変量テストによって彼らのフィードバックループにユーザー 更は、仮説駆動開発やデータ駆動開発といったよく知られたプラクティスを可能にす 羨望を感じている。そうした企業は洗練された機能を持っているからだ。漸進的な変 多くの企業は、 Facebook や Netflix をはじめとする最先端のテクノロジー企業に 高度なビジネス機能 テムを構築することは、進化可能なシステムにも対応する傾向がある。 てきたように、不適切な結合は進化にとって最大の難題となる。スケーラブルなシス そうした疎結合水準の副次的な利点は、進化可能性の向上だ。本書を通して説明し なスタイルに再設計することで、全体的なエコシステムをスケール可能にした。 が付いた。彼らは、アーキテクチャを不適切な結合を排除するよりマイクロサービス サービスパスなど ) に結合することが最終的にスケーラビリティを制約することに気
2.3 なってしまうだろう。 早い段階で適応度関数を特定する 29 適応度関数は、以下に示す 3 つの単純なカテゴリに分類できる。 主要なもの https ://en.wikipedia.org/wiki/Flexib1e_product development プラクティスだ。 並行的に複数の解決策を設計するためにリーンやアジャイルのプロセスで用いられる して、将来の意思決定のための選択肢を手に入れるだろう。セットべース開発とは、 チームはセットべース開発す 3 を適応し、複数の解決策を構築するコストと引き換えに な開発プロジェクト ) の実施に時間と労力をかけることには価値がある。いくつかの るアーキテクチャ上の側面を検証するためにスパイク ( タイムボックスで行う実験的 つ。選択した設計が主要な適応度関数に明確な意味合いを持つ場合には、設計におけ 適応度関数をカテゴリに分類することは、設計判断に優先順位を付けるのに役立 者は忘れすに日々の開発作業の中でそれらを考慮できるようになる。 度関数と関連性のある適応度関数の知識を保ち続けよう。そうすることで、開発 適応度関数を実行した結果を共有スペースなどで可視化することで、主要な適応 関数は必要ない。 ものではあるかもしれないが、アーキテクチャとは無関係だ。そのため、適応度 ( 設計から実装までにかかった時間の総量 ) などのプロセスメトリクスは重要な 設計と技術の選択は、この種の次元に影響を受けない。例えば、サイクルタイム 関連性のないもの リクスは重要だが、主要な次元ではない。 の選択を誘導することはない。例えば、コードベースの品質に関するコードメト これらの次元は、機能レベルで考慮する必要があるものだが、アーキテクチャ上 関連性のあるもの ンスと回復力が主要な次元となる。 を割かなくてはならない。例えば、銀行アプリケーションであれば、パフォーマ とした変更を容易に行えるようにする設計上の選択を探ることにより多くの労力 これらの次元は、技術や設計を選択する上で重要なものだ。これらの要素を中心
214 ー スケール . データベース開発者… 索引 コンサルティング柔道 .. コンシューマ駆動契約 .. コンポーネント . コンポーネント結合 . コンポーネント循環 .. サービス .. サーヒ、ス . サーバーレスアーキテクチャ .. サードバーティのコード . さ行 コンポーネント . サーヒ、スディスカバリ . サービス指向アーキテクチャ サーピス境界… サービスペースアーキテクチャ .. サービスに分離 .. サービステンプレート .. ... 205 ... 90 , 183 … 59 , 64 … 96 … 146 … 199 … 201 .. 104 … 103 … 124 … 141 … 145 … 12 … 187 .. 161 … 33 ... 124 … 131 .. 133 … 81 … 130 … 60 … 60 … 100 … 122 .. 162 , 164 … 140 , 141 … 170 , 171 , 200 … 94 , 128 ... 92 , 142 , 143 選択的スケー スナップショットビルド . スノーフレーク .. 危険性 .. スノーフレ ル . ーークヨガ、一ノヾーー 組織… セットべース開発 .. 説得… セカンドシステムシンドローム .. 生成的テスト .. 請求書発行サーヒ、ス .. スプレッドシート . スパイクソリューショ ン . ソフトウェアアーキテクチャ .. サイクルタイム .. 再構築… 最終責任時点… 再利用 .. 漸進的な変更… 開発と運用… た行 ー間の結びつき .. メンノヾ 抽象化 .. 欠如 .. 乱れ… 作業するのをやめて、それを成功と呼ほう原則 .. 156 … 8 , 66 , 68 , 69 , 72 , 75 , 78 , 80 85 , 91 , 95 , 98 , 125 , 166 , 206 サンフランシスコプロジェクト .. 次元 .. 実験の文化… 実装ビュー 実用最小限の製品 . ジャストインタイム .. 順応… 商用オフザシェルフ .. 進化… 進化可能… 進化的アーキテクチャ .. 進化的データベース設計… スケーラピリティ スキーマの進化 .. … 10 , 11 , 13 , 119 , 120 ... 7 , 139 , 199 ... 17 , 202 … 18 , 202 … 3 , 8 , 17 , 207 データベー 適応度関数… ツールチェイン . データ駆動開発… データ結合 . データの年齢と質… データベース .. 共有データベース統合 .. データベーストランザクション .. ス設計 .. データベーススコープ .. … 201 .. 150 … 135 … 137 … 135 ... 189 … 30 … 3 , 11 … 115 … 112 … 55 … 112 … 140 … 157 … 184 … 114 ... 94 .. 15 … 106 … 177 … 189 … 205 .. 145 … 198 … 52 … 177 , 185 … 103 , 104 … .9 , 19-23 , 28 , 52 , 120 , 123 AI を使った . アーキテクチャ上の関心事… 一時的な… カテゴリ . 企業規模… … 198 … 46 … 24 … 27 … 29 … 191
202 ー 8 章進化的アーキテクチャの実践 キテクチャはとても複雑になっていた。 MarketingFeed という別のサービスは、通常、 毎日の売上とマーケティング情報の更新を取得するために開店時に各店舗から呼び出 される。 MarketingFeed は運用の観点では、店舗がタイムゾーンを超えて開店するた めに、集中的な要求を処理できる弾力性が必要だった。 高度に結合されたサービスに共通する問題は、不用意な過剰性能だ。より結合され たアーキテクチャでは、開発者はスケーラビリテイや回復性、弾力性を全てのサー ビスに構築する必要があり、それはそれらの能力を必要としないものも複雑にする。 ァーキテクトは、様々なトレードオフからアーキテクチャを選択することに慣れてい る。明確に定義された量子境界を持つアーキテクチャを構築することは、必要なアー キテクチャ特性の仕様を要求することを可能にする。 順応 vs 進化 多くの組織は徐々に技術的負債の増加という罠に陥り、必要な変更箇所の再構成を 躊躇し、システムと統合点をますます脆弱にする。企業はサービスパスのような接続 ツールを使ってこの脆さを解消しようとする。サービスパスを使うことは、既存のシ ステムを別の設定で使用するよう順応する例だ。しかし、これまで強調してきたよう に、順応の副作用は技術的負債の増加だ。何かを順応させる際には、開発者は元の振 る舞いと並んで新しい振る舞いのレイヤを保持する。コンポーネントの順応サイクル が長くなるほど、並行的な振る舞いが増え、より複雑さがまし、戦略性は絶望的にな る。 機能トグルの利用は、順応の利点の良い例を示す。開発者は仮説駆動開発を介して いくっかの代替案を試すときにトグルを使用して、ユーザーに最も支持されるものを テストする。この場合、トグルによって課せられる技術的負債は、目的のある、望ま しいものだ。もちろん、これらの類のトグルに関するエンジニアリングのベストプラ クティスは、判断が解決したらすぐにそのトグルを削除するというものだ。 それに対し、進化することは根本的な変化を意味する。進化可能なアーキテクチャ の構築では、適応度関数によって破壊から保護されたその場所で、アーキテクチャを 変更することを伴う。最終的な成果は、内部に潜んでいる時代遅れの解決策を増やす ことなく、有用な方法で進化し続けるシステムだ。