ソフトウェアアーキテクチャ・ハードパーツ

アーキテクチャの諸問題で、トレードオフを発見し、判断するテクニックを学ぶ!
ソフトウェアアーキテクチャには、難しい問題やベストプラクティスが存在しない問題など、妥協点の中から選択しなければならない事柄が数多くあります。本書は、分散型アーキテクチャのそうしたトレードオフについて考える方法を学びます。
本書は、適切なアーキテクチャを選択するための戦略から、サービスの粒度の決定方法、契約の管理と切り離し、分散トランザクションの管理から、スケーラビリティ、弾力性、パフォーマンスなどの運用特性の最適化までを扱います。

分散システムの設計では、サービスをどの粒度で切るか、どのサービスがデータを所有するか、サービスをまたぐ更新をどう整合させるかといった問いに、万人に通用する答えがありません。『ソフトウェアアーキテクチャ・ハードパーツ』 (Neal Ford、Mark Richards、Pramod Sadalage、Zhamak Dehghani 著、島田浩二 訳、オライリー・ジャパン発行、オーム社発売、2022 年 10 月刊) は、そうした妥協点の中から選択を強いる難題を「ハードパーツ」と呼び、読者が自分のアーキテクチャ上の難題に対して効果的なトレードオフ分析を行えるようになることを目的とした書籍です。原書は "Software Architecture: The Hard Parts" で、副題は「分散アーキテクチャのためのトレードオフ分析」、版元は『ソフトウェアアーキテクチャの基礎』の著者らによる一冊と紹介しています。

全 15 章の構成、分解する第 I 部とつなぎ合わせる第 II 部

構成は全 15 章と付録 A から C です。1 章では、ベストプラクティスが存在しない問題にどう向き合うかという本書の問題設定に加え、アーキテクチャデシジョンレコードとアーキテクチャ適応度関数という本書を貫く道具を導入し、題材となる Sysops Squad サーガを紹介します。第 I 部「分解する」 (2 章から 7 章) は、アーキテクチャ量子の概念を使った結合の見分け方、モジュール化の推進要因、コンポーネントベース分解パターン、業務データの分解、サービスの粒度を扱い、モノリス をどこで切るかを判断する材料を積み上げます。第 II 部「つなぎ合わせる」 (8 章から 15 章) は、分解したサービスを再び協調させる側で、再利用パターン、データの所有権と分散トランザクション、分散データアクセス、分散ワークフローの管理、トランザクショナルサーガ、コントラクト、分析データの管理を順に取り上げ、15 章「独自のトレードオフ分析を構築する」で締めます。

著者陣について、書店掲載の書誌 (出版社提供) の著者紹介は、刊行当時の Ford を Thoughtworks のディレクターでソフトウェアアーキテクト、Sadalage を同社のデータおよび DevOps 担当ディレクター、Dehghani を同社の先端技術担当ディレクターとし、Richards は 1983 年からソフトウェア業界に身を置き、分散システムの構築、設計、実装に携わってきたソフトウェアアーキテクトと紹介しています。訳者の島田浩二は 2009 年に株式会社えにしテックを設立し、2011 年からは一般社団法人日本 Ruby の会の理事も務めるとあります。

トレードオフ分析が分散アーキテクチャで難しい理由

モノリスを分割して マイクロサービスアーキテクチャ へ移ると、1 つのプロセスと 1 つのデータベースが暗黙に保証していたものが、すべて設計上の選択肢に変わります。関数呼び出しはネットワーク越しの通信になり、1 本のトランザクションで済んでいた更新は複数のサービスにまたがるため、強い整合性を保ち続けるか 結果整合性 を受け入れるかを決めなければなりません。共通コードをライブラリとして配るか共有サービスに寄せるか、ワークフローを中央のオーケストレーションに任せるか各サービスのコレオグラフィに委ねるか、サービス間のコントラクトを厳格にするか緩くするかも、それぞれ変更のしやすさ、性能、耐障害性、運用負荷の間で引き換えが生じます。個々の選択肢は単独では良し悪しを言えず、他の選択と絡み合って効くため、経験則を暗記しても現場の判断には使えません。本書が「ベストプラクティス」の代わりに提示するのは、絡み合う次元を発見し、結合点を分析し、定性的分析と定量的分析を組み合わせて比較するという、分析の手順そのものです。

Sysops Squad サーガで追うモノリス分解の意思決定

本書の特徴は、Sysops Squad サーガと名付けられた題材が 2 章から 15 章までのすべての章に置かれ、モノリスを分解しマイクロサービスアーキテクチャに再構築する例を通して各章の議論が具体化される点です。2 章で量子を理解し、4 章で分解アプローチを選択し、6 章でデータベース分解の根拠を検討し、7 章でチケット割り当てと顧客登録の粒度を決め、9 章でチケット処理のデータ所有権を割り当て、12 章でアトミックトランザクションと補償トランザクションを比べ、14 章でデータメッシュを検討するというように、抽象的なパターンの説明が一貫した題材の上での意思決定として読めます。12 章のエピックサーガからアンソロジーサーガまで 8 つのトランザクショナルサーガパターン、14 章のデータウェアハウスやデータレイクとデータメッシュの対比のように、パターンを名前と特性で整理してから題材に当てる進め方が全体を通して貫かれています。

前提知識と、この本が向かない読者

版元は本書を、現代のソフトウェアアーキテクチャに関わるソフトウェア開発者にとって必携の一冊と位置づけています。ただし入門書ではなく、マイクロサービスやデータベース、分散トランザクションといった用語を既に知っていて、自分のシステムで分割や統合の判断を迫られている読者を想定した議論が続きます。目次に個別のフレームワークやクラウドサービス、特定言語の実装手順を扱う章はないため、実装のハウツーを求める人には向きません。これから初めてアーキテクチャを学ぶ段階なら、同じ著者らによる『ソフトウェアアーキテクチャの基礎』のような基礎から読み始める方が、本書のトレードオフの議論を消化しやすくなります。

元が取れるのは、モノリスの肥大化に悩みながら「分けるべきか、分けるならどこで」を議論しているチームのアーキテクトやテックリード、マイクロサービスへ移行したものの分散トランザクションやサービス間の結合に苦しんでいる開発者です。統制のための適応度関数で分解を保つ手法、データの所有権を単独所有 / 全体共有 / 共同所有のシナリオで整理する枠組み、8 つのサーガパターンの整理といった道具は、設計レビューでそのまま議論の土台に使えます。判断の根拠をアーキテクチャデシジョンレコードとして残す習慣も含め、正解を教わるのではなく判断の仕方を身につけたい読者にとって、長く手元に置く価値のある一冊です。