『DevOps実践ガイド』読書メモ(4)

DevOps実践ガイド

<-前回の記事からの続き->

パート 3 ステップ 1: フローテクノロジーの実践

パート III の目標は、運用環境を中断したり、顧客サービスを中断したりすることなく、開発から運用までの作業の安定的かつ迅速な流れを可能にするために必要な技術的実践とアーキテクチャを作成することです。これは、実稼働環境への変更のデプロイとリリースのリスクを軽減することを意味します。これは、継続的デリバリーと呼ばれる一連の技術的実践を通じて実現されます。

11. 継続的インテグレーションを適用して実践する

バージョン管理システムにおけるブランチの主な役割は、開発者が提出したコードがトランク (マスターまたはメインラインとも呼ばれる) の安定性に影響を与えないようにしながら、開発者がソフトウェアシステムのさまざまなコンポーネントを並行して作業できるようにすることです。、またはエラーが発生します。

ただし、開発者が自分のブランチで一人で作業する時間が長くなるほど、変更をトランクにマージすることが難しくなります。実際、ブランチの数と各ブランチの変更の数が同時に増加すると、マージの難易度は急激に増加します。

統合の問題は、手動マージを通じて競合する変更を解決しなければならないことや、自動テストまたは手動テストが失敗する原因となるマージ問題を解決するために複数の開発者が協力しなければならないことなど、多くの手戻りにつながる可能性があります。従来の開発モデルでは、コードの統合作業は通常、プロジェクトの最後に行われるため、統合作業に時間がかかりすぎると、予定通りにリリースするために手を抜かなければなりません。

これは別の悪循環につながります。コードのマージは非常に面倒なので、マージの頻度が減り、将来のマージがさらに苦痛になります。継続的インテグレーションは、マージを日常業務に組み込むことでこの問題を解決することを目的としています。

11.1 小規模バッチ開発と大規模バッチ統合

バージョン管理システムに送信されたコード変更によってデプロイメントパイプラインが失敗する場合は常に、私たちは協力して問題を解決し、デプロイメントパイプラインをできるだけ早くグリーン状態に復元するよう努めます。ただし、開発者が長期間自分のブランチ (「フィーチャーブランチ」とも呼ばれます) で作業し、コードをトランクにマージすることはたまにしかない場合、マージのたびにトランクに大量の変更が加えられることになり、深刻な問題です。問題です。

分岐戦略にはさまざまな種類がありますが、次の 2 つのカテゴリに分類できます。

個人の生産性の向上: 全員が自分のブランチで作業します。全員が独立して作業し、他の人に干渉することはできませんが、コードのマージは悪夢のようなものになります。コラボレーションは非常に困難になり、システムの最小部分を完成させるために全員が慎重にコードをマージする必要があります。
チームの生産性の向上: 全員が同じエリアで作業します。ブランチはなく、長く中断されないトランクがあるだけです。ルールはないため、コードの送信プロセスはシンプルです。ただし、1 つのコミットによってプロジェクト全体が破壊され、中断される可能性があります。

ウォード・カニンガムは世界初のウィキ・システムを開発し、「技術的負債」という用語を作りました。同氏は技術的負債について説明する際、コードベースを積極的にリファクタリングできない場合、修正や保守が徐々に困難になり、新機能の追加速度も低下すると述べた。継続的インテグレーションとトランクベースの開発手法の主な目的は、これらの問題を解決し、それによって個人の生産性の向上に基づいてチームの生産性を向上させることです。

11.2 トランクベースの開発プラクティスを適用する

一括マージ問題の解決策は、継続的統合とトランクベースの開発手法を適用して、すべての開発者が少なくとも 1 日 1 回はコードをトランクにコミットするようにすることです。そうすることで、開発チームの日々の作業負荷に対するコードコミットの数を減らすことができます。開発者がコミットする頻度が高くなるほど、各コミットが小さくなり、理想的な単一のフロー状態に近づきます。

バックボーンにコードを頻繁に送信するということは、ソフトウェアシステム全体ですべての自動テストを実行でき、アプリケーションやインターフェイスの特定の部分で問題が発生した場合に、アラート情報をタイムリーに受信できることを意味します。マージの問題はすぐに発見されるため、問題もすぐに解決できます。

システムをデプロイ可能な状態から外すコミット (コード変更や環境変更など) の受け入れを拒否するようにデプロイメントパイプラインを構成することもできます。このアプローチはゲート送信と呼ばれます。つまり、デプロイメントパイプラインは、送信された変更が正常にマージされ、正常にビルドできること、およびトランクにマージされる前にすべての自動テストに合格したことを確認する必要があります。テストが失敗した場合は、開発者に通知が届くため、バリューストリーム内の他のユーザーに影響を与えることなく、開発者自身が問題を解決できます。

これらのプラクティスを適用した後、「完了」の定義を修正します (太字のテキストは新しい内容です)。「各反復サイクルの終わりに、実用的なコードが統合され、運用環境に似た環境でテストされます。コードはワンクリックプロセスを通じてトランク上に作成され、自動テストに合格しています。」

11.3 概要

トランクベースの開発は、おそらくこの本の中で最も物議を醸している実践です。多くのエンジニアは、それは機能しないと考えており、他の開発者と協力せずに自分のブランチで作業することを好みます。しかし、Puppet Labs の 2015 State of DevOps Report では、トランクベースの開発が生産性の向上、安定性の向上、さらには仕事の満足度の向上と燃え尽き症候群の低下につながる可能性があることを示しています。

最初は開発者を説得するのは難しいですが、開発者が大きな利点を理解すれば、完全に変わります。継続的インテグレーションの実践は、低リスクで自動化された展開プロセスに向けた次のステップへの道を開きます。

12. 自動化された低リスクのリリース

この章の目的は、運用および保守チームまたは開発チームが、実稼働環境の導入の手間を軽減することで、頻繁かつ簡単に導入できるようにすることです。これは、デプロイメントパイプラインをスケーリングすることで実現します。

コードを運用環境に似た環境に継続的に統合するだけでなく、テストと検証をオンデマンド (つまり、ワンクリックでリリース) または自動的に (つまり、ビルドとテストが成功した直後に自動デプロイ) プロセスのあらゆるビルドで自動化できるようになります。本番環境にリリースされます。

12.1 自動展開プロセス

現在の展開プロセスを完全に文書化したら、次のステップは、手動の手順を可能な限り簡素化および自動化することです。次に例を示します。

コードをデプロイしやすい形式にパッケージ化します。
事前構成された仮想マシンのイメージまたはコンテナを作成します。
ミドルウェアの展開と構成を自動化します。
インストールパッケージまたはファイルを運用サーバーにコピーします。
サーバー、アプリケーション、またはサービスを再起動します。
テンプレートに基づいて構成ファイルを生成します。
自動スモークテストを実行して、システムが適切に機能し、正しく構成されていることを確認します。
さまざまなテストプログラムを実行します。
データベース移行作業をスクリプト化して自動化します。

継続的な統合およびテスト機能を備えたほとんどのツールには、展開パイプラインを拡張する機能もあります。これらのツールは、通常、本番環境の受け入れテストが実行された後に、検証済みのビルドを本番環境にリリースできます (このようなツールには、Jenkins Build Pipeline プラグイン、ThoughtWorks の GoCD および Snap CI、Microsoft Visual Studio Team Services、Pivotal Concourse が含まれます)。

デプロイメントパイプラインには次の要件があります。

すべての環境へのデプロイメントを同じ方法で処理する: すべての環境 (開発、テスト、本番環境など) で同じデプロイメントメカニズムを使用することで、パイプラインに正常にデプロイされているため、本番環境へのデプロイメントの成功率を高めることができます。回。
デプロイメントでスモークテストを実行する: デプロイメントプロセス中に、すべての依存システム (データベース、メッセージバス、外部サービスなど) に正常にアクセスできるかどうかをテストし、1 回のテストでシステムが適切に動作するかどうかを確認する必要があります。上記のテストのいずれかが失敗すると、展開は失敗します。
環境の一貫性を維持する: 上記の手順により、ワンステップの環境構築プロセスが作成され、開発環境、テスト環境、実稼働環境に共通の構築メカニズムが適用されます。これらの環境が一貫した方法で構築されていることを継続的に確認する必要があります。

12.1.1 アプリケーション自動化のセルフサービス展開

作業をより容易にするためには、開発者または運用担当者が実行できるコードリリースプロセスが必要であり、理想的には手動操作や作業の引き継ぎを必要としない必要があります。このプロセスの手順は次のとおりです。

ビルド: 運用環境を含むあらゆる環境にデプロイできるパッケージをビルドするには、デプロイメントパイプラインはバージョン管理システムに基づいている必要があります。
テスト: 誰でもワークステーションまたはテストシステム上で自動テストスイートを実行できる必要があります。
導入: スクリプト (バージョン管理システムにコミット) を実行することで、誰でもアクセスできる環境にこれらのパッケージを導入できる必要があります。

上記の実践は、デプロイメントを正常に実行するのに役立ちます。誰が実行するかは関係ありません。

12.1.2 コードのデプロイメントをデプロイメントパイプラインに統合する

コード展開プロセスが自動化されている場合、それを展開パイプラインの一部にすることができます。したがって、自動展開には次の機能が必要です。

継続的統合フェーズで構築されたソフトウェアパッケージが運用環境に展開できることを確認します。
実稼働環境の準備状況が一目で明確になります。
運用環境にデプロイできるコードに対して、ワンクリックおよびセルフサービスのリリースメカニズムを確立します。
コマンドが実行されたマシン、実行されたコマンド、承認者、結果など、監査とコンプライアンス管理に必要な関連コンテンツを自動的に記録します。
スモークテストを通じてシステムが適切に動作していること、データベース接続文字列およびその他の構成が正しいことを確認します。
開発者に迅速なフィードバックを提供して、デプロイメントの結果 (デプロイメントが成功したかどうか、アプリケーションが運用環境で正常に実行できるかどうかなど) をできるだけ早く理解できるようにします。

私たちの目標は、迅速にデプロイすることです。デプロイが成功したかどうかを確認するために何時間も待ったり、コードの修正に何時間も費やす必要はありません。Docker などのコンテナーテクノロジーを使用すると、非常に複雑なアプリケーションのデプロイメントを数秒または数分で完了できます。

ここに画像の説明を挿入します
上記の機能を構築することで、ワンクリックでコードをデプロイでき、コードと環境の変更をデプロイメントパイプラインを通じて安全かつ迅速に実稼働環境にリリースできます。

12.2 導入とリリースの分離

実際には、「デプロイ」と「リリース」という言葉を同じ意味で使用することがよくあります。ただし、実際にはこれらは異なるアクションであり、目的も大きく異なります。

デプロイメントとは、特定のバージョンのソフトウェアを特定の環境にインストールすることを指します (たとえば、コードを統合テスト環境や運用環境にデプロイするなど)。具体的には、デプロイメントは機能のリリースに関連する場合もあれば、関連しない場合もあります。
リリースとは、ある機能 (または一連の機能) をすべての顧客または一部の顧客が利用できるようにすることを指します (たとえば、ある機能を顧客ベースの 5% に公開する)。コードと環境のアーキテクチャは、機能リリースでアプリケーションのコードを変更する必要がないようなものである必要があります。

言い換えれば、デプロイメントとリリースを混同すると、結果に対して誰が責任を負うのかを定義することが難しくなります。これら 2 つのアクティビティを分離することで、開発者と運用スタッフの迅速かつ頻繁なデプロイ能力が向上すると同時に、製品所有者にはリリースの成功に対する責任が課せられます (つまり、機能の構築とリリースに費やした時間が貴重であることが保証されます)。

導入サイクルが長すぎると、新機能を頻繁に市場にリリースする能力が制限されます。ただし、オンデマンドで導入できる場合、新機能をいつ顧客にリリースするかは、技術的な決定ではなく、ビジネスおよび市場の決定になります。一般的に使用される公開モードは 2 つあります。

環境ベースのリリースモデル: システムを 2 つ以上の環境にデプロイしますが、実際に顧客のトラフィックを処理する環境は 1 つだけです (たとえば、トラフィックを切り替えるようにロードバランサーを構成することによって)。新しいコードを非実稼働環境にデプロイし、実稼働トラフィックをこの環境に切り替えます。このパターンは、通常、アプリケーションへの変更をほとんどまたはまったく必要としないため、非常に強力です。このモデルには、Blue-Green 導入、カナリアリリース、および集団免疫システムが含まれています。これらのパターンについては後で説明します。
アプリケーションベースのリリースモデル: 小規模な構成変更により、アプリケーション機能を選択的にリリースまたはオープンするようにアプリケーションを変更します。たとえば、機能の切り替えを通じて、最初に開発チーム、次に社内の全従業員、次に 1% の顧客に新機能を段階的に公開したり、機能が設計に完全に準拠していることを確認した後、すべての従業員に直接リリースしたりすることができます。顧客。これは、いわゆるブラックスタートテクノロジです。すべての機能を運用環境にデプロイし、リリース前に運用環境のトラフィックでテストします。たとえば、リリースまでの数週間で実稼働トラフィックを使用して新機能をテストし、正式リリース前に問題を発見して解決できるようにします。

12.2.1 環境ベースのリリースモデル

デプロイメントとリリースを分離すると、私たちの仕事のやり方が劇的に変わります。お客様への悪影響を軽減するために、深夜や週末に導入する必要はなくなりました。代わりに、通常の営業時間内にデプロイできます。運用担当者と保守担当者は、ようやく他の人たちと同じように通常通り仕事を終えることができるようになりました。

環境ベースのリリースモデル。アプリケーションコードを変更する必要はありません。導入には複数の環境を使用しますが、実際に顧客のトラフィックを処理する環境は 1 つだけです。このアプローチにより、実稼働リリースのリスクが大幅に軽減され、展開時間が短縮されます。

Blue-Green デプロイメントモード
Blue-Green デプロイメントは、3 つのモードの中で最も単純です。このモードには、Blue 環境と Green 環境という 2 つの実稼働環境があります。常に、これらの環境のうち 1 つだけが顧客トラフィックを処理します。図 12-5 では、顧客のトラフィックを処理するのはグリーン環境です。

サービスの新しいバージョンをリリースするときは、ユーザーエクスペリエンスに影響を与えずにテストを実行できるように、まずオフライン環境にサービスをデプロイします。すべてが正常であることを確認したら、顧客のトラフィックを青色の環境に切り替え、この方法を使用して新しいバージョンを配信します。その後、青の環境が実稼働環境になり、緑の環境が実稼働前環境になります。ロールバックは、顧客トラフィックをグリーン環境にリダイレクトすることによっても実現できます。

Blue-Green 導入モデルは比較的シンプルで、既存のシステムに実装するのが非常に簡単です。これには、チームが通常の営業時間中にデプロイメントを実行でき、オフピーク時間中にバージョンの切り替え (ルーティング構成やシンボリックリンクの変更など) を簡単に実装できるなど、多くの利点があります。これらだけでも、導入チームの作業状況を大幅に改善できます。
データベース変更の処理
2 つのバージョンのアプリケーションが同じデータベースに依存している場合、問題が発生する可能性があります。デプロイ操作でデータベーススキーマの変更、またはテーブルや列の追加、変更、削除が必要な場合、データベースはアプリの両方のバージョンを同時にサポートできません。一般に、この問題は次の 2 つの方法で解決されます。
- 2 つのデータベース(青のデータベースと緑のデータベース) を作成します。アプリケーションの各バージョン (青 (古いバージョン) と緑 (新バージョン)) には独自のデータベースがあります。リリース中は、青色のデータベースを読み取り専用モードに設定し、バックアップを実行して緑色のデータベースに復元し、最後にトラフィックを緑色の環境に切り替えます。このモデルの問題は、青色のバージョンにロールバックする必要がある場合、まずトランザクションデータを緑色のデータベースから青色のデータベースに手動で移行しなければならないことです。そうしないと、データが失われる可能性があります。
- データベースの変更とアプリケーションの変更の分離: 2 つのバージョンをサポートするデータベースとは異なり、データベースへの変更のリリースとアプリケーションへの変更のリリースは、次の 2 つの操作を実行することによって分離されます。まず、データベースには増分変更のみが行われます。既存のデータベースオブジェクトを変更しないでください。第 2 に、アプリケーションロジックは運用環境のデータベースバージョンについて何も想定しません。これは、私たちがデータベースについて常に考える方法とは大きく異なり、重複データの生成を回避します。
カナリアリリースモードとクラスター免疫システムリリースモード
Blue-Green デプロイメントモードは実装が比較的簡単で、ソフトウェアリリースのセキュリティを大幅に向上させることができます。自動化によってセキュリティをさらに向上させ、展開時間を短縮できるバリエーションもありますが、同時に複雑さが生じる可能性があります。

カナリアリリースという用語は、炭鉱夫が檻に入れられたカナリアを鉱山に持ち込む伝統に由来しています。鉱山労働者はカナリアを使用して鉱山内の一酸化炭素濃度を学習します。一酸化炭素の濃度が高くなりすぎると、カナリアは中毒になり、鉱山労働者にすぐに避難する必要があることを知らせます。

カナリアリリースモデルでは、各環境でソフトウェアがどのように実行されているかを監視します。問題が発生した場合はロールバックし、問題が発生した場合は次の環境にデプロイします。
- グループ A1: 社内従業員のみにサービスを提供する運用サーバー。
- グループ A2: 少数の顧客のみにサービスを提供し、ソフトウェアが特定の受け入れ基準を満たした後に展開される運用サーバー (自動または手動)。
- グループ A3: 残りの実稼働環境サーバーでは、グループ A2 で特定の受け入れ基準に達した後にソフトウェアが展開されます。
Cluster Immune System リリースモデルは、運用環境の監視システムとリリースプロセスをリンクすることにより、カナリアリリースモデルを拡張します。20%)、コードが自動的にロールバックされます。この保護には 2 つの明らかな利点があります。1 つは、特定の主要なページ要素が非表示になるページ変更 (CSS コードの変更など) など、自動テストでは発見するのが難しい欠陥を回避することです。2 つ目は、トラブルシューティングと解決にかかる時間を短縮します。変更パフォーマンス低下の問題が発生するまでに必要な時間。

12.2.2 アプリケーションベースの公開モデルはより安全です

前のセクションでは、環境ベースの公開モデルを紹介しました。複数の環境を使用し、それらの間でトラフィックを切り替えることにより、デプロイメントとリリースを分離することが特徴です。これはインフラストラクチャレベルで完全に可能です

このセクションでは、コードを使用して新しい機能をより柔軟かつ安全に顧客にリリースするアプリケーションベースのリリースモデルを紹介します (通常、機能は 1 つずつリリースされます)。アプリケーションベースの公開モデルはアプリケーションコードに実装されるため、開発チームの参加が必要です。

機能スイッチの実装
アプリケーションベースの公開モデルは、主に機能スイッチを通じて実装されます。機能切り替えメカニズムを使用すると、実稼働コードをデプロイすることなく、機能を選択的に有効または無効にすることができます。機能スイッチを使用すると、アプリケーションの機能を社内従業員や特定の顧客グループなどの特定のユーザーに公開できます。

機能スイッチの実装メカニズムは通常、条件ステートメントを使用してアプリケーションロジックまたはユーザーインターフェイス要素をカプセル化し、どこかに保存された構成情報に基づいて機能を有効または無効にします。構成情報は、単純なアプリケーション構成ファイル (JSON または XML 形式の構成ファイルなど) を使用して保存できます。また、サービスカタログや、機能の切り替えを管理するために特別に設計された Web サービスを通じて構成することもできます。

特性スイッチには次の利点もあります。
- 簡単にロールバック
- パフォーマンスのプレッシャーを軽減する
- サービス指向アーキテクチャによる復元力の向上
- 機能スイッチは、コードのデプロイメントを機能リリースから切り離します。
ブラックスタートの実装
機能切り替えの効果は、機能を運用環境にデプロイしますが、一時的に使用できなくなります。これにより、すべての機能を実稼働環境にデプロイしてから、顧客には表示されない機能のテストを実行する、ブラックブート手法が可能になります。大規模な変更やリスクの高い変更の場合、ブラックブートプロセスは多くの場合数週間かかるため、正式リリース前に本番環境のようなワークロードで安全にテストできます。

ブラックブート技術を使用して、新しい検索機能、アカウント作成プロセス、データベースクエリなどの潜在的にリスクのある新機能をリリースするとします。すべてのコードが運用環境にデプロイされたら、新しい機能を無効にし、ユーザーセッションコードを変更して新しい関数を呼び出します。呼び出しの結果はユーザーに表示せず、テスト結果のみをログに記録または破棄します。

これにより、製品に対する顧客の満足度を確認するために大規模な発売を待つ必要がなくなりました。その代わり、大規模な発売を発表するまでに、当社はビジネス前提の検証を完了し、実際の顧客を対象に無数の改良実験を実施し、製品と顧客のニーズの適合性を向上させてきました。

12.3 継続的デリバリーおよび継続的デプロイメントの実践に関する調査

継続的デリバリーと継続的デプロイメントの新しい定義は次のとおりです。

継続的デリバリーとは、すべての開発者が小さなバッチでトランク上で作業するか、または有効期間が短い機能ブランチ上で作業し、トランクを常にリリース可能に保ち、通常のスケジュールで実行できるようにしながら、定期的にトランクにマージすることを意味します。勤務時間中の要求。開発者は、バグ、パフォーマンスの問題、セキュリティの問題、ユーザビリティの問題などの回帰エラーが発生したときに、迅速なフィードバックを得ることができます。このような問題が発見されたらすぐに対処し、バックボーンを展開できる状態に保ちます。継続的デリバリーでは、検証されたコードを企業独自のリポジトリに自動的にリリースできます。
継続的デプロイメントとは、継続的デリバリに基づいて、開発者または運用および保守担当者がセルフサービスベースで実稼働環境に高品質のビルドを定期的にデプロイすることを意味します。これは通常、全員が少なくとも 1 日に 1 回実稼働環境にデプロイすることを意味します。あるいは、開発者がコード変更を送信するたびに、自動化されたデプロイメントがトリガーされます。

継続的インテグレーションが継続的デリバリーの前提条件であるのと同様に、継続的デリバリーは継続的デプロイメントの前提条件です。継続的デプロイメントは、オンライン Web サービスの配信に適していますが、継続的デリバリーは、組み込みシステム、市販の既製製品、組み込みシステム、商用製品など、品質、配信速度、結果の予測可能性を必要とするほぼすべての低リスクのデプロイメントおよびリリースシナリオに適しています。そしてモバイルアプリケーション。

12.4 概要

リリースとデプロイメントは、高リスクで高状況のタスクである必要はありません。また、完了するために数十人、さらには数百人のエンジニアが残業する必要もありません。むしろ、それらはあなたの日常の一部になることができます。リリースと展開を日常業務に統合することで、展開時間を数か月から数分に短縮でき、組織は予期せぬインシデントやサービスの中断を回避しながら顧客に迅速に価値を提供できるようになります。さらに、開発者と運用保守担当者との緊密な協力により、運用保守作業がより人間味のあるものになります。

13. リリースリスクを軽減するアーキテクチャ

この章では、上で説明した悪循環を逆転できる対策を紹介し、いくつかの主要なアーキテクチャの原型をレビューし、開発生産性、テスト容易性、展開可能性、セキュリティの向上に役立つアーキテクチャの機能を検討するとともに、既存のアーキテクチャを安全に移行するための関連アーキテクチャの移行戦略について説明します。組織の目標をより適切に満たすアーキテクチャへの変更

13.1 生産性、テスト容易性、セキュリティを向上させるアーキテクチャ

密結合したアーキテクチャは生産性を低下させるだけでなく、安全に変更を加える能力にも影響を与えます。対照的に、明確に定義されたインターフェイスを備えた疎結合アーキテクチャは、モジュール間の依存関係を最適化し、生産性とセキュリティを向上させ、小規模で生産性の高い「ダブルピザ」チームが小さな変更を安全かつ独立して実行できるようにします。各サービスには明確に定義された API があるため、テストが容易になり、チーム間のサービスレベル契約の条件を決定するのも簡単になります。

Google Cloud Datastor は世界最大の NoSQL サービスですが、そのサポートチームは約 8 人しかいません。これは主に信頼性の高い基本サービスのレイヤーの上に構築されているためです。サービス指向アーキテクチャにより、小規模なチームが小規模で単純な開発タスクに取り組むことができ、各チームが独立して迅速かつ安全に展開できます。
ここに画像の説明を挿入します

13.2 アーキテクチャプロトタイプ: モノリシックアーキテクチャとマイクロサービス

モノリシックアーキテクチャは本質的に悪いものではありません。実際、製品ライフサイクルの初期段階では、多くの場合、モノリシックアーキテクチャが最良の選択となります。

スタートアップ企業に適したモノリシックアーキテクチャ (たとえば、新機能のプロトタイプを迅速に作成する必要がある場合、または会社の戦略目標が大幅に変更される可能性がある場合) は、数百の開発チームを擁する企業が使用するアーキテクチャとは完全に異なります。独自に顧客に価値を提供できなければなりません。時代に合わせて進化するアーキテクチャを採用することで、組織の現在のニーズを確実に満たすことができます。
ここに画像の説明を挿入します

13.3 エンタープライズアーキテクチャを安全に進化させる

既存のアーキテクチャが密結合すぎると思われる場合は、その上の一部の機能を安全に分離できます。このようにして、これらの機能を担当する開発チームは、アーキテクチャ上のエントロピーを削減しながら、独立して安全に開発、テスト、デプロイを行うことができます。

前述したように、Strangler アプリケーションモデルでは、既存の機能を API でカプセル化し、新しいアーキテクチャに従って新しい機能を実装し、必要な場合にのみ古いシステムを呼び出します。Strangler アプリケーションパターンでは、すべてのサービスはバージョン付き API (バージョン付きサービスまたは不変サービスとも呼ばれる) を通じてアクセスされます。

バージョン管理された API により、呼び出し元に影響を与えることなくサービスを変更できるため、システムの結合が軽減されます。パラメーターを変更する必要がある場合は、新しい API バージョンを作成し、サービスに依存するチームを新しいバージョンに移行します。新しいアプリケーションが他のサービスと密接に結合されることを許可すると (別のサービスのデータベースに直接接続するなど)、再設計という目標を達成できなくなります。

既存の密結合システムから機能を継続的に切り離すことで、作業は徐々に安全で活気のあるエコシステムに移行され、開発者の生産性が大幅に向上する一方で、既存のアプリケーションの機能は徐々に縮小します。すべてのビジネス機能が新しいアーキテクチャに移行されると、古いアプリケーションが完全に消えることさえあります。

ストラングラーはこの用語に当てはまります。これは、彼がオーストラリアを旅行中に自生するラタンストラングラー植物からインスピレーションを得たものです。彼は次のように書いています。「種子はイチジクの木のてっぺんに落ち、その後蔓が徐々に幹を下って成長し、最終的には土に根を張ります。長い年月を経て蔓は素晴らしく美しい形を形成しますが、同時に絞め殺されてしまいます」彼らの宿主の木です。」

Strangler アプリケーションを作成すると、新しいアーキテクチャや新しいテクノロジーで既存の機能が重複するのを避けることができます。既存のシステムの特性により、ビジネスプロセスが複雑になりすぎるため、既存のプロセスをコピーすることはお勧めできません (ユーザーを調査することで、ビジネスプロセスを再設計し、よりシンプルなプロセスを使用してビジネス目標を達成できることがよくあります)。

他の変革と同様に、私たちは迅速な成功を目指して努力し、反復的に価値を提供し続ける必要があります。予備分析は、新しいアーキテクチャがビジネス目標の達成に効果的に役立つように、最小のブレークスルーを特定するのに役立ちます。

13.4 概要

大部分は、サービスのベースとなるアーキテクチャによって、コードのテスト方法とデプロイ方法が決まります。これは、Puppet Labs の 2015 State of DevOps Report で検証されています。このレポートは、アーキテクチャがエンジニアの生産性に影響を与える最大の要因であり、変更を迅速かつ安全に実装できるかどうかを決定することを示しています。

私たちは、異なる方向性を追求する組織の目標や長年のレガシーアーキテクチャによって制約されることが多いため、アーキテクチャの進化は安全に行われなければなりません。この章で紹介する事例では、Strangler アプリケーションパターンなどのテクノロジについて説明します。これは、組織のニーズの変化に対応するためにアーキテクチャの変革を段階的に推進するのに役立ちます。