この記事について
システムのリファクタリングはタダでできるモノではありません。利害関係者にリファクタリングのメリットと必要性を訴える必要があります。 そのためにはシステムのモジュール化/リファクタリングのメリットをエンジニア自身が納得しなければなりません。 リファクタリングをするべき5つの理由を解説します。
つまり、今回の記事の内容としては以下の通りです
大規模作業向けの良い提案資料を用意する方法
アーキテクチャのモジュール化のメリットを理解する
メリットを現在直面している課題に対応づける話し方
アプリケーションを分解することでトレードオフを分析し、文書化する方法
それではシステムのリファクタリングが必要なケースと、どうすればリファクタリングが可能になるかを見ていきましょう。
アーキテクチャのモジュール化・リファクタリングのメリット
リファクタリングやモジュール化を行う際には、当然ながら費用が発生します。 また、その費用を承認してもらう際にビジネスサイドと折り合いがつかない時もあるでしょう。
リファクタリングやモジュール化などは保守業務の一種であると言われますので、 よくやる経費の取り方としてこの保守業務を新規案件の時に組み込む方法はあります。 ですが、そうでない場合はアーキテクチャのモジュール化やリファクタリングを行うことのメリットを説明しなければなりません。
まずは、「そもそもシステムが変化するモノである」という大前提を有識者に共有しておかなければならないでしょう。
そもそもシステムは常に変化するものである
ITは常に進化している。 計算システムが置かれている技術環境も同様であり、その都度アーキテクチャも進化してきた。 例えば、コンテナ化、クラウドベースのインフラへの移行、DevOpsの採用、CI/CDなどなど。 これらの技術全てがアーキテクチャに影響を与える。
from https://reorganization.nihon-ma.co.jp/report/743/
ところが、絶え間無く急速に進化しているのは、ITだけではなく、ビジネスだけではない。 今日の市場では、M&Aが盛んに行われているため、ある企業を別の企業が買収することも発生する。 企業の買収が発生した場合、企業の物理的な側面(人、建物、在庫)だけでなく、顧客もより増えることになる。 両者の既存システムは、合併による結合がうまくいくだろうか。
このように、ビジネスでの進化やイベントは、アーキテクチャ上の関心事として大きな意味を持つ。
リファクタリングが必要となる具体例
1.システムのパフォーマンスを改善するためにリファクタリングを行う
例えば、モノシリックなアーキテクチャとマイクロサービスなアーキテクチャではどちらが合併や買収をサポートしやすいだろうか。 これは当然マイクロサービスなアーキテクチャである。
- モノシリックなアーキテクチャは一つのサーバーで全てのシステムの機能を賄うため、「サーバーの限界値=システムが提供できる機能の限界値」となる。
- マイクロサービスなアーキテクチャは複数のサーバーでシステムの機能を賄うため、サーバーを増築することでシステムが提供できる機能の限界は無限である。
このように、マイクロサービスには事業の成長に合わせたスケーラビリティを持ち合わせるのである。
これらの材料を利害関係者に説明するとこのようなる
「最近のシステムはマイクロサービスを採用することもあるが、それはごくごく最近のことです。このシステムは10年前に作られたシステムでものシリックなサービスでしたが、当時はユーザー数もそれほどではなかったので十分で耐えられていました。ですが今回のM&Aでユーザー数が10倍に膨れ上がることが予測されます。ビジネスの変化とともにシステムも変化させて柔軟な対応ができるようにマイクロサービスを採用しましょう」
2.アジャイルなビジネスに対応するためにアジャイルなシステムへリファクタリングを行う
先ほど説明したように企業の業績が良ければ良いほど、その企業はサイズも含めて成長する
そうすると
ユーザーアクティビティの増加をサポートするのにより高いスケーラビリティが必要になる
また、アプリケーションの一部に障害が発生しても、他の部分は通常通り機能したままとし、エンドユーザーへの全体的な影響を最小限にする耐障害性が必要になる
今日のように急速に変化し続ける市場で生き残るにはビジネスは当然アジャイルでなければならないが、それは基盤となるアーキテクチャもアジャイル出なければならない。
リファクタリングをするべき5つの理由
耐障害性
スケーラビリティ
デプロイ性
テスト性
保守性
システムがアジャイルな変化に対応できるモノであるためには、上の5つが条件となる。
このうち、「デプロイ性」と「テスト性」と「保守性」のみはマイクロサービスでなくとも通常のリファクタリングで十分対応可能だ。 ユーザーが大幅に増えるとか、大規模な改修が入る以外ではモノシリックサービスのリファクタリングで良い。
しかし、耐障害性やスケーラビリティはモノシリックアーキテクチャでは対応できない。 前述の通り、モノシリックなアーキテクチャは一つのサーバーで全てのシステムの機能を賄うため、「サーバーの限界値=システムが提供できる機能の限界値」となるためである。
No1,2. スケーラビリティ/保守性
スケーラビリティと保守性についての詳しい内容は別のページに記載した。 内容が複雑で入り組んでいるためだ。
詳しい内容はこちらを参照していただき、メリットとデメリットを経営陣に説明できるようにしてほしい。
No3,4. 耐障害性/可用性
耐障害性を「システムのある部分が故障しても、他の部分は応答性/可溶性を持続する能力」と定義する。 例えば、ECサイトであれば商品の購入はできなくとも商品の閲覧は持続的に利用できる能力とする。
モノシリックなアーキテクチャでは耐障害性は低い。 なぜなら、アーキテクチャを構成する単位は一つしかなく、ビジネス上のある機能のダウンは全機能のダウンを意味するからだ。
from https://techblog.short-tips.info/inhouse_se/2001layerd_arch.md
上はモノシリックで耐障害性の低いレイヤードアーキテクチャである。
ビジネスレベルや機能単位での耐障害性を実現するためには、アーキテクチャをモジュール化する以外の選択肢はない。
システムを複数のデプロイメントユニットに分割することで、壊滅的な障害を対象のデプロイメントユニットのみに限定し、残りの部分を正常に起動させる必要がある。
No5. デプロイ性
デプロイ性は、
デプロイのしやすさ
デプロイの高頻度
デプロイのリスクの低さ
の3つの要素がある。これらの要素を満たすことで、2週間に一回以上のデプロイを行うことができる。 デプロイ性を損なった場合、複数の変更をまとめて行い、リリースする必要が発生し、リリース自体が高リスクなものになってしまう
モノシリックアーキテクチャはこれらのデプロイ性の要件をほぼ全て満たしていない。
アプリケーションは一つの塊となっているため、アプリケーションのリリースに伴う作業や変更範囲が多く
デプロイ後に別の機能が壊れることが発生し
デプロイ感覚は長くなり、よりリリースが高リスクなものになる
逆に、高度にモジュール化されたアプリケーションであれば、モノシリックなアーキテクチャよりもデプロイの作業は少なく、リスクも低く、頻度も高くなる。
補足:マイクロサービスは結合度に注意がいる
たとえ分散システムであっても結合の粒度が細かすぎる場合、デプロイ性にも支障が出ることがある。
事業のシステム上の手続きを完了するために、多くの通信が必要になる場合は結合度が強くなる。
マイクロサービス – 分散された大きな泥だんごサービスの数が多ければ多いほど、通信の数も多くなる。
from https://postd.cc/distributed_big_balls_of_mud/
もし、マイクロサービスアーキテクチャのサービス群を必ず特定の順序でデプロイしなければならないのであれば、モノリスに戻してしまった方がいい
まとめ:なぜリファクタリングが必要なのか
リファクタリングをする目的は、次の5つに分類される。
耐障害性
スケーラビリティ
デプロイ性
テスト性
保守性
そして、時代とともにアーキテクチャは変化するものであり、開発者側の責任というよりは時代の流れでリファクタリングせざるを得ないのである。
備考
title:リファクタリングをするべき5つの理由
description:システムのリファクタリングはタダでできるモノではありません。利害関係者にリファクタリングのメリットと必要性を訴える必要があります。そのためにはシステムのモジュール化/リファクタリングのメリットをエンジニア自身が納得しなければなりません。リファクタリングをするべき5つの理由を解説します。
img:https://github.com/kawadasatoshi/techblog/blob/main/0/inhouse_se/3045/five.png?raw=true
from https://www.pakutaso.com/20190249044post-18819.html
category_script:page_name.startswith("3")