Strangler Fig

現代のソフトウェア エンジニアリングでは、レガシーのモノリシック アプリケーションが共通の課題となっています。時間が経つにつれて、成功したコードベースは非常に大きくなり相互接続されるため、単純な変更を行うのは危険になり、デプロイには数時間かかり、個々の機能を拡張することは事実上不可能になります。 チームがマイクロサービスに移行してシステムを最新化することを決定したとき、現在のビジネスを中断することなくシステムを書き直すにはどうすればよいですか? という一か八かの質問に直面します。 選択肢の 1 つは、「ビッグバン」書き換えです。つまり、密室で新しいシステムをゼロから構築し、1 日ですべてを切り替えることです。ただし、これは非常に危険であり、多くの場合失敗につながります。 幸いなことに、より安全で信頼性の高い代替手段、ストラングラー フィグ パターンがあります。このガイドでは、ストラングラー フィグ パターンとは何なのか、なぜ機能するのか、そして明確な図と実際のコードを使用してそれを段階的に適用する方法を説明します。 現実世界のたとえ: ストラングラー イチジクの植物 このパターンは、熱帯雨林に自生する植物であるストラングラー イチジクにちなんで名付けられました。 ストラングラー イチジクの種子は、既存の「宿主」の木の上部の枝で発芽します。イチジクは地面から上に成長するのではなく、下に向かって成長します。 根を宿主の木の幹に送り込み、林床に到達して土壌に固定します。 時間の経過とともに、より多くの根が成長し、宿主の周りを包み込み、融合します。 イチジクは、宿主の木に届く光を遮る葉を生やします。 最終的に、宿主の木は枯れて腐り、中空のストラングラー イチジクの木がその場所にしっかりと立っています。 ソフトウェア アーキテクチャでは、従来のモノリス がホスト ツリーであり、新しいマイクロサービス が絞殺図です。私たちはモノリスのエッジの周りに新しいサービスを構築し、モノリスが完全にシャットダウンできるまでトラフィックをレガシー システムから徐々に移行させます。 「ビッグバン」書き換えが失敗する理由 ストラングラー フィグ パターンの仕組みに入る前に、代替案 (完全な書き換え) がなぜ非常に危険なのかを理解しましょう。 数か月 (または数年) では価値がありません: 開発者はコードの作成に長い時間を費やしますが、プロジェクト全体が完了するまではコードが実際に公開されることはありません。 スコープ クリープ: 2 年間の書き換え中に、ビジネス ニーズが変化します。ターゲットは移動し、新しいシステムは書き換え開始時には存在しなかった機能をサポートする必要があります。 暗黙的な動作の欠落: Monoliths には、文書化されていないバグ修正とエッジケースの処理が何年にもわたって含まれています。白紙の状態で書き直すと、これらの詳細が忘れられることがよくあります。 導入リスクが高い: 大規模なレガシー システムをオフにして新しいシステムを一度にオンにすると、何か問題が発生した場合に大きな爆発範囲が発生します。 ストラングラーフィグパターンの仕組み Strangler Fig パターンの中心となるアイデアは 増分移行 です。システム全体を移行するのではなく、一度に 1 つの小さな機能、つまり「スライス」を移行します。