はじめに
これまでは新規開発などを通じて「新しいシステムを創る」ということに強い関心がありました。その反面で短サイクルでの開発により技術的負債が後回しになるケースも少なくないと思います。
そこで、「今あるシステムをどう活かして、どう育てていくか？」という運用・保守などの観点を意識するようになりました。
そんな経緯もあり、追求しているうちにモノリスやマイクロサービスという設計思想に行き着いたので、その違いについてまとめてみました。
モノリスとマイクロサービスの違い
モノリスとマイクロサービスは、アプリケーションの設計思想の大きな違いがあります。
-
モノリス： 1つの巨大なアプリケーションであり、すべての機能（UI、ビジネスロジック、データアクセスなど）が1つの大きな塊として構築されています
-
マイクロサービス: 独立した小さなサービス群であり、ユーザー管理、決済、商品管理など機能ごとに小さなサービスに分割されています。これらのサービスはAPIなどを通じて連携します
引用：アプリケーション・モダナイゼーション： マイクロサービスのメリットって？
モノリスの特徴
メリット
- 開発・運用のシンプルさ: 一つのアプリケーションとして管理するため、開発の開始が簡単で、小規模なプロジェクトやスタートアップには最適です
- デプロイの容易さ: 一度でアプリケーション全体をデプロイできるため、プロセスがシンプルです
- パフォーマンス: アプリケーション内の機能間の通信がプロセス内で完結するため、マイクロサービスに比べて通信のオーバーヘッドが少なく、パフォーマンスが高い傾向にあります
- テストのしやすさ: 単一のアプリケーションなので、エンドツーエンドのテストが比較的容易です
デメリット
- 柔軟性の低さ: 一部の機能を変更する場合でも、アプリケーション全体を再コンパイル・再デプロイする必要があり、開発スピードが遅くなることがあります
- スケーラビリティの課題: 負荷が増えた場合、アプリケーション全体をスケールさせるしかなく、リソースが非効率的になることがあります
- 障害耐性の低さ: 1つの機能にバグや障害が発生すると、アプリケーション全体が停止するリスクがあります
- 技術のロックイン: 一度採用した言語やフレームワークから変更するのが非常に困難です。
マイクロサービスの特徴
メリット
- 柔軟性とアジリティ: サービスごとに独立して開発・デプロイができるため、迅速な機能追加やバグ修正が可能です
- 高いスケーラビリティ: 負荷が高い特定のサービスだけを個別にスケールできるため、リソースを効率的に利用できます
- 高い障害耐性: あるサービスで障害が発生しても、他のサービスに影響が及ぶことは少なく、システム全体の可用性が向上します
- 技術選択の自由: サービスごとに最適なプログラミング言語、フレームワーク、データベースを選択できます
デメリット
- 運用管理の複雑性: 多数の小さなサービスを管理・監視する必要があるため、運用が複雑化し、コストが増加する可能性があります
- 通信のオーバーヘッド: サービス間の通信にネットワークを介したAPIコールなどが必要となり、モノリスに比べてパフォーマンスが低下することがあります
- データの一貫性: 各サービスが独自のデータベースを持つことが多いため、サービス間でデータの一貫性を保つのが難しく、複雑な設計が必要になります
- 設計の難しさ: アプリケーションをどのようにサービスに分割するかという設計が非常に重要で、初期段階での設計ミスが後々の大きな問題につながることがあります
マイクロサービス化すると何が良いのか？？
-
安定した事業運営の継続
既存のシステムを適切に運用保守することで、日々の業務が滞りなく進み、売上の機会損失やビジネスの停止リスクを防ぐことができます -
無駄なコストとリスクの回避
既存システムを安易にリプレイスしようとすると、莫大なコスト（開発費用、移行費用）と膨大な時間、そして移行に失敗するリスクが伴います。運用保守を続けることで、これらの大きな投資を回避し、既存システムを延命させながら、より重要な新規事業や技術革新に経営資源を集中させることができます。 -
段階的な改善と技術的負債の解消
既存システムの専門家が社内にいることで、一度にすべてを刷新するのではなく、段階的かつ計画的にシステムのモダナイズ（近代化）を進めることができます。例えば、部分的に新しい技術に置き換える「マイクロサービス化」や、パフォーマンス改善、セキュリティ強化などを継続的に行うことで、技術的負債を少しずつ解消し、システムをより健全な状態に保てます。
4. 属人化リスクの軽減
既存のシステムは、開発者が退職すると運用が困難になる「属人化」のリスクを抱えています。これを運用保守する人材を育成し、チームで取り組むことで、技術やノウハウの継承が進み、特定の個人に依存しない安定した運用体制を構築することができます。
ストラングラーパターン
上記のようなアプローチは「ストラングラーパターン（Strangler Fig Pattern）」とも呼ばれ、レガシーシステム全体を一度に刷新するのではなく、徐々に新しいシステムに置き換えていく方法です。
ストラングラーパターンの概念
この名前は、絞め殺しのイチジク（strangler fig）が他の木に巻きつき、徐々に宿主を覆い尽くして枯死させていく様子に由来しています。ITの世界では、この「イチジク」が新しいサービス、「宿主」がレガシーシステムです。
ストラングラーパターンのメリット
- リスクの低減: 一気にシステム全体を刷新するよりも、小さな単位で変更を進めるため、失敗した際の影響範囲が限定されます
- 継続的な価値提供: 開発チームは、レガシーシステムを維持しながら、顧客に新しい価値を提供し続けることができます
- コストの最適化: 全面的なリプレイスに比べて初期投資が抑えられ、段階的にコストを分散させることができます
具体的な手順
1. 新しいマイクロサービスを構築
レガシーシステムが提供している機能の一部を、新しい技術を使ってマイクロサービスとして独立して構築します。
2. トラフィックを徐々に移行
外部からのリクエストを、レガシーシステムから新しいマイクロサービスへと少しずつ切り替えていきます。
3. レガシー機能の削除
新しいマイクロサービスが安定稼働したら、レガシーシステム内の古い機能を削除します。
このプロセスを繰り返すことで、最終的にはレガシーシステム全体を新しいアーキテクチャに置き換えることができます。
モダナイゼーション
モダナイゼーション（Modernization）とは、企業が保有する古くなったシステム（レガシーシステム）を、最新の技術や環境に合わせて最適化・刷新する取り組みのことです。
モダナイゼーションすることのメリット
システムのモダナイズは以下の点から、単なる技術的なリファクタリングではなく、企業の競争力を高め、将来の成長を実現するための戦略的な投資と言えます。
1. 開発スピードの向上と市場への迅速な対応
古いシステムは、複雑な構造や技術的制約から、新しい機能の追加や変更に時間がかかります。モダナイズによって、マイクロサービス化や新しい開発手法（DevOpsなど）を取り入れることで、開発サイクルが短縮され、市場や顧客のニーズに素早く応えることができます。これは、競合他社に先んじて新しいサービスや機能を投入する上で不可欠です。
2. 採用力の強化と人材の定着
レガシー技術を扱えるエンジニアは限られており、新たな人材を確保するのが困難です。システムをモダン化することで、より多くの技術者が興味を持つ最新の技術スタックに移行でき、優秀な人材の採用がしやすくなります。 また、エンジニア自身も新しい技術に触れる機会が増えるため、モチベーションが向上し、離職率の低下にもつながります。
3. 保守・運用コストの削減
一見するとモダナイズには費用がかかるように見えますが、長期的にはコスト削減につながります。
古い技術や属人化されたシステムは、バグ修正や障害対応に多くの工数を要します。モダンなシステムは、自動化や監視ツールなどを活用することで、運用コストを削減できます。
4. セキュリティとコンプライアンスの強化
レガシーシステムは、最新のセキュリティ脅威に対応できていないことが多く、情報漏洩や不正アクセスのリスクを抱えています。モダナイズは、最新のセキュリティ技術やアーキテクチャを導入する絶好の機会であり、企業の信頼性を高める上で非常に重要です。
5. ビジネスの拡張性（スケーラビリティ）の確保
古いシステムは、大量のデータ処理や急激なユーザー増加に耐えられない場合があります。モダンなシステムは、クラウド上でスケールアップ・アウトが容易な設計にすることで、ビジネスの急成長にも柔軟に対応できるようになります。これにより、新しい事業機会を逃さずに済むようになります。
おわりに
既存のシステムを運用保守する仕事は、こうした戦略を立て、実行していく「システムの外科医」のような役割を担うことだと思いました。
単にコードを直すだけでなく、ビジネスの安定性を保ちながら、未来に向けたアーキテクチャの再構築に貢献すると考えると、よりエンジニアとして仕事をする意義が見出せそうです。