とあるエンジニアの作業ブログ

DevOps System Architecture コンサル ビジネス書要約 マネジメント

システムにおける適応度関数 〜進化的アーキテクチャを読んで〜

投稿日:2019年2月16日 更新日:

オライリーの進化的アーキテクチャを読んで、重要そうなポイント、特に適応度関数について自分用まとめ。

はじめに断っておくと、この本は「システムアーキテクチャを変更する際にこういう風にしておけば容易に変更できる」ということを書いてあるわけではない。
「アーキテクチャは極力変更したくないものの、現実世界の変化のスピードや多様性を受けて自然と変化してしまう/変化せざるをえない。それを是として受け入れ、アーキテクチャが変化したとしてもシステムとして重要な特性(わかりやすい例でパフォーマンスや耐障害性)、品質をどうやって継続的に担保していくか」を説明している。
この本を読んだからといって、「今までフロントはAngularを使っていたけども、明日からReactに変更できる」となるわけではないので悪しからず。。。

進化的アーキテクチャって要はなんだ!?

アーキテクチャはコードを書き始める前までに完成させるべきものである
[···中略···]
開発中に変更の必要がないことが、優れたソフトウェアアーキテクチャの証であると捉えられてきた。

上の文章からもわかるように、システムアーキテクチャは開発が始まる前に設計・構築され、一度開発が始まったらそうそう容易には変更できないとみなされてきた。
しかし、昨今のアジャイルな世界では、ビジネス要件が定常的に変化するだけでなく、それを実現するアーキテクチャまでもが管理された変化を受け入れるべきと考え、定常的変化を受け入れた継続的なアーキクチャを、本書では「進化的アーキテクチャ(Evolutionary Architectures)」と呼んでいる。

まぁコンセプトはわからんでもない···

適応度関数

適応度関数とは···

遺伝的アルゴリズムで成功の定義に使われる評価関数。進化的アーキテクチャではその概念を拝借している。
進化的アーキテクチャにおける適応度関数は、アーキテクチャが進化(変化)するにしたがって、変更がアーキテクチャの重要な特性にどのように影響するかを評価する。アーキテクチャとしての特性が経年劣化するのを防ぐ仕組みとして活用される。本書中では以下のように定義されている。

アーキテクチャの適応度関数は、あるアーキテクチャ特性がどの程度満たされているかを評価する客観的な指標を与える。

ここでいうアーキテクチャの特性とは、互換性、信頼性、完全性、稼働性、可搬性、スケーラビリティ、性能etc···などのアーキテクチャにより決定されるシステム特性である。

適応度関数の具体的な正体

適応度関数とは、、、極端な話、要はただのテストである。

  • 適応度関数としてアーキテクチャに求められる要件を定量化し、
  • それを評価するテストコード(これが関数。つまりプログラミングにおけるfunctionである。)を書き、
  • テストして目標を満たしているか評価する(DevOps Pipelineへの組み込みが前提)

というただそれだけ。
ただ注意すべきは、「それを評価するテストコード」の部分が、一概にテストコード書いてDevOps Pipelineで自動化できるという類のものではないという点と、全てのテストが適応度関数なのではなく、あくまでもアーキテクチャ特性を検証するテストのみが適応度関数に分類されるという点。

随分概念的だし、もはや哲学的な雰囲気さえ感じる。実はただの言葉遊びなんじゃないのと思わなくもない。。。
本文中にある以下のような内容が、疑念を更に深いものにする。。。

  • 全ての適応度関数を自動化できるプロジェクトばかりではない
  • パフォーマンス要件には特に有効に活用できる。全てのサービス要求実行していずれも基準値内にレスポンス返って来れば評価OKとすれば良い(ただのパフォテやんけ!!)
  • 制約があり、完全自動よりも手動が推奨されるものもある(HW障害テストにおけるDBフェールオーバーの評価など)
  • 必ずしも単一スクリプトとして実行できない

適応度関数を実践的な内容として理解する

適応度関数とテストの違い

適応度関数が普通のテストと違うのはどんな点だろうか?
それは、適応度関数はアーキテクチャの検証という点にフォーカスが当てられているという点だ。
例えば、静的解析で一般的に望ましくないと思われるコーディングを摘出したりすることは適応度関数とは言えない。
適応度関数とは、例えばアーキテクチャとしてモジュールの変更可能性を検証するためにJDependというツールでモジュール間の循環参照をチェックしたりするものを指す。

適応度関数の導入手順

上記のように適応度関数の実践的な使い方として、まずはアーキテクチャとしてどんな特性を有していなければならないかと、その特性が十分なレベルで実現されているかを検証し評価する手段を定義する必要がある。
適応度関数の具体的な導入手順は以下。

  1. ビジネスケースや要件からそのシステムが必要とする特性を論理的に洗い出す
    例)金融システムの場合
    • ストレスのないレスポンス=Performance
    • 24/365の可用性=Availability
    • 情報漏洩や外部アタックに対する万全のセキュリティ=Security
  2. 洗い出したシステム特性に対してどのような検証を行えばその特性が評価できるかを考え、適応度関数として定義する
  3. その適応度関数を実現する手段を具体化し、自動/手動・実施タイミングなどを定義する(テストコードを書く/ツールを使う、レビューで担保する、DevOps Pipelineに組み込む/アドホックに手動で実行する etc…)
  4. 実装する

上記の流れに沿って洗い出した適応度関数の例は以下。

特性 適応度関数 手段 自動/手動
Performance GatlingやLocustなどの負荷試験ツールで本番相当のMIXモデル負荷を与えて検証 データボリューム増大・アクセス数増大という負荷に対してパフォーマンスが担保されることを検証 ●●sec以内のTAT、●●件/sec以上のスループット等 自動
Availability 24/365稼働を前提とした耐障害性が担保されていることを検証 Chaos MonkeyやPumbaなどのChaos Engineeringの実現ツールでランダムなインスタンス、コンテナ障害を引き起こし評価 自動
Security ホワイトボックスとしてOSやSW、コンテナイメージの脆弱性がないことを検証 vuls等の脆弱性検知ツールでスコアリング・評価 自動
第三者(LAC社など)によるアプリケーションセキュリティ診断を実施し外部に対するセキュリティホールが存在しないことを評価 手動

あとはこの一つ一つの適応度関数について、自動のものについては実装&DevOps Pipelineへの組み込みを行い、手動のものについては適切なタイミングでの実施の準備を進めれば良い。(ただし見てわかる通りどれも口で言うほど簡単なものではないので、1つ実現するだけでもそれ相応の工数がかかる。)
また、この洗い出しまではなるべく早く実施される必要がある。見てわかる通り、適応度関数とはそのアーキテクチャで担保する特性だ。つまりアーキテクチャのつくりそのものに影響するということだ。

もう一つ私自身の経験に基づいた理由を挙げるなら、適応度関数を実装するのは上述の通り大変手間がかかる。これを事後で実施するのは、通常のプロジェクトであれば予算的にも工数的にも期間的にもかなり難しいだろう。適応度関数はアーキテクチャ構築・開発・テストの中で同時並行的に実装され、リリースまでのプロセスに取り込まれることが最もオーバーヘッドのかからない方法と思われる。

適応度関数のレビュー

適応度関数はそれ自体が陳腐化してしまわぬよう定期的にレビューされるべきだある。レビューでは新たな適応度関数の追加や、すでに構築した適応度関数の変更が行われる。
以下に適応度関数がレビューされるべき代表的なタイミングと、私自身の経験を踏まえて適応度関数の変更例をまとめた。(このような明らかなタイミングがなくても、最低でも年に1回はレビューされるべき)

  • 市場や顧客の成長といったビジネス背景の変化や拡大
    →ユーザー数の増加に伴い当初目標としていたPerformanceが満たせなくなる可能性がある。そういった場合には適応度関数を満たせるようにアーキテクチャを変更するのがべき論だが、費用対効果の関係などで即座に変更が行えない可能性がある。その場合には適応度関数を細分化し、平常時に満たすべき目標値とピーク時に満たすべき目標値を定め、それぞれを評価する検証を行う
  • 新領域の機能追加
    →新たなビジネス的なコンテキストを受け、新領域の機能が追加される場合は、それを実現するためにアーキテクチャが変更される代表的なケースだ。アーキテクチャが変更された際に新たな特性が付加されていない場合は既存の適応度関数で評価可能だが、アーキテクチャの変更により新しい特性が生まれる場合にはそれを検証する内容を適応度関数に盛り込むべきである

「未知の未知」と適応度関数の限界

未知の未知とは、何がわからないのかわからないということである。反対に既知の未知という言葉もあり、これは何がわからないのかはわかっている(つまり何を明らかにすれば良いかがわかっている)という状態だ。
本書中の下記の文章に表現されるように、わかっていないことがわからなければそれに対する対策は打てない。

アーキテクトは未知の未知を設計できない。

私が実際に経験した事例として、それまでは自社で提供しているだけだったサービスに新たなパートナー企業が参加したとき、そのパートナー企業のAPIレスポンスが劣化するとシステム全体がスローダウンするというものがある。
これは、システムとしてサービス独立性が担保されておらず(要はサーキットブレーカーの仕組みが実装されておらず)、一つのサービスが停止すると他のサービスも影響を受けるアーキテクチャになっていたことが原因だ。
自社だけでサービス提供しいてる時にはそれでもよかったかもしれないが、外部パートナー企業が参加したときに新たにサービス独立性という特性が必要なことに気づけなかったために起きた障害である。

適応度関数を使ったところで、上記のような未知の未知の罠を完全に防止することはできないだろう。
ビジネスの拡大に伴い新たなシステム特性が必要になることをわかっていなければ、それを実現するためのアーキテクチャの設計も、評価するための適応度関数の変更もできないからだ。

しかし、だからといって適応度関数による進化可能なアーキテクチャを否定する理由にはならない。
未知の未知の罠は完全には防止できないが故に、アジャイルなプロセスと適応度関数による進化可能なアーキテクチャを構築しておくことで、実害が顕在化したときにアジリティをもって対処することが重要だからだ。(要は高レジリエンスを維持することが重要ということ。)

まとめ

最終的にまとめると以下。

  • アーキテクチャは変化させたくなくても時勢の影響で変化してしまう/変化せざるをえないという現実
  • それを是として受け入れ、アーキテクチャが変化したとしてもシステムとして重要な特性(わかりやすい例でパフォーマンスや耐障害性)、品質をどうやって継続的に担保していくかが重要
  • そのためには適応度関数というアーキテクチャの特性を検証するテストを実施し、アーキテクチャの特性が経年劣化していないことを常々評価することが効果的
  • 適応度関数はDevOps Pipelineに組み込まれ自動で実行されることが望ましいが、評価する特性によっては手動で実施されるほうが良いものもある
  • 適応度関数の実践的手順として、まずはアーキテクチャとしての特性とそれをどうやって検証・評価するかを論理的に洗い出す
  • 洗い出しができたら、その適応度関数は自動で実行されるべきか手動で実行されるべきかをそれぞれ定義し、物理的な実装に落とし込んでいく
  • こうやって実装された適応度関数は、それ自体が陳腐化してしまわぬよう定期的にレビューを行う。市場や顧客の成長といったビジネス背景の変化や拡大、新領域の機能追加等は代表的なレビュー実施タイミング
  • 適応度関数を使おうが「未知の未知」は防止できない。だからこそ、アジャイルなプロセスと進化可能なアーキテクチャ(適応度関数も含む)を構築し変更に対するアジリティを持つことが重要

その他:コンウェイの法則と逆コンウェイの戦略

コンウェイの法則
システムを設計するあらゆる組織は、必ずその組織のコミュニケーション構造に倣った構造を持つ設計を生み出す。

システムアーキテクチャは組織構造の写像であると言っている。開発チームをフロント、バック、データの3層チームに分け、バックに関しては4つの業務ドメインのチームに分けたとすると、アーキテクチャもその通りに分割される。
当り前じゃね!?と思ってしまうのは私だけ・・・?

逆コンウェイの戦略

理想的には「技術的アーキテクチャ」が「ビジネスアーキテクチャ」の同形写像になるようにチームを組織すること。
その名の通りコンウェイの法則の逆で、実現するための技術アーキが先にあってそれを写像したチームを作るという戦略。
具体的に言えば、DevOpsするなら開発と運用は混成一体チームであるべきだし、AgileやるならBizとSys混成のスクラムチームを組むべき、マイクロサービスアーキテクチャを採用するなら技術アーキによる分割ではなくサービス単位でのチームを組織するべしというもの。

 

-DevOps, System Architecture, コンサル, ビジネス書要約, マネジメント
-, ,

執筆者:


comment

メールアドレスが公開されることはありません。

関連記事

改めてリーンスタートアップの要点まとめ(1/3) 全体概要&第1部

ここ2、3年の仕事はプロジェクトをアジャイルで進めることが多く、かつ今度リーンスタートアップで提唱されているプロセスを採用するということで改めてリーンスタートアップを読んでみた。 以前読んだときは自分 …

AML(Anti Money Laundering)入門

仕事でAMLの知識が必要になったので勉強した内容のメモ。 目次 マネーロンダリングとAML/CFTとは マネーロンダリング/テロ資金供与の実例 AML/CFTの仕組み 全体概要(KYC、経済制裁対応、 …

リスクベースドテストにおけるリスク定義方法

リスクベースドテストにおけるリスク定義方法のメモ。 主に、リスク定義する上でのリスク算出要因(影響度(Damage), 発生確率(Probability of Failure))と重みづけ方法、及びリ …

銀行システムのセキュリティ要件整理

銀行システム/組織のセキュリティ要件を整理する機会がありました。セキュリティはあんまり詳しくないので自分の勉強がてらメモ。 目次 ざっくり結論 各評価項目の定義 セキュリティ要件解説 前提の整理 セキ …

改めてリーンスタートアップの要点まとめ(2/3) 第2部

リーンスタートアップの第2部のまとめ。 第1部のまとめはこちら。 目次 構築→計測→学びのサイクルと事業拡大/転換 :本書 5、6、7、8章に対応 構築・検証プロセスにおける特記 :本書 6章に対応 …