マイクロサービスとモノリシック アーキテクチャの比較

組織は多数のさまざまな要因に応じて、モノリシックとマイクロサービスの各アーキテクチャのどちらからでもメリットを得られます。モノリシック アーキテクチャによって開発する際は、1 つのコード ベースに基づくアプリケーションの作成が簡単なために開発速度が速いことが第一のメリットとなります。

モノリシック アーキテクチャには、次のようなメリットがあります。

デプロイが簡単 – 実行可能ファイルまたはディレクトリが 1 つであるため、デプロイが簡単です。

開発 – アプリケーションを 1 つのコード ベースで構築すると、開発が容易になります。

パフォーマンス – 多くの場合、一元化されたコード ベースとリポジトリでは、多数の API がマイクロサービスによって実行するのと同じ機能を 1 つの API で実行できます。

簡素化されたテスト – モノリシック アプリケーションは一元化された単一のユニットであるため、分散アプリケーションを使用するよりも高速にエンドツーエンドのテストを実行できます。

デバッグが簡単 – すべてのコードが 1 か所に配置されているため、リクエストに従いやすく問題を見つけやすくなります。

Netflix の場合と同様に、モノリシック アプリケーションは非常に効果的である可能性がありますが、それは大きくなりすぎてスケーリングが困難になるまでの話です。1 つの機能に小さな変更を加えるために、プラットフォーム全体をコンパイルしてテストする必要があります。これは、今日の開発者が好むアジャイル アプローチに反しています。

モノリスのデメリットは次のとおりです。

開発速度の遅さ – 大規模なモノリシック アプリケーションでは、開発がより複雑になって速度が低下します。

スケーラビリティ – 個々のコンポーネントはスケーリングできません。

信頼性 – いずれかのモジュールにエラーがあると、アプリケーション全体の可用性に影響する可能性があります。

テクノロジー導入の障壁 – フレームワークや言語の変更はアプリケーション全体に影響し、変更にはコストと時間がかかることがよくあります。

柔軟性の欠如 – モノリスは、モノリスですでに使用されているテクノロジーによる制約を受けます。

デプロイ – モノリシック アプリケーションを少し変更するために、モノリス全体を再デプロイする必要があります。

単にマイクロサービスとも呼ばれるマイクロサービス アーキテクチャは、独立してデプロイ可能な一連のサービスに依存するアーキテクチャ手法です。これらのサービスには、特定の目標を持つ独自のビジネス ロジックとデータベースがあります。更新、テスト、デプロイ、スケーリングは各サービス内で行われます。マイクロサービスはドメイン固有の考慮事項である主要なビジネスを、別々の独立したコード ベースに分離します。マイクロサービスは複雑さを軽減するものではありませんが、タスクを互いに独立して機能し全体に貢献する小さなプロセスに分けることで、複雑さを可視化して管理しやすくします。

マイクロサービスはチームがユーザーの要件に迅速に適応できるようにする継続的なデリバリーを実践する基盤であるため、多くの場合、マイクロサービスの採用は DevOps と密接に関係しています。

アトラシアンは、Jira と Confluence で拡大と拡張の課題に直面した後、2018 年にマイクロサービスへの道をたどりました。オンプレミスで稼働しているシングルテナントのモノリシック アーキテクチャでは、将来のニーズに合わせて拡張できないことがわかりました。

Jira と Confluence を再構築して、ステートフルなシングルテナントのモノリシック システムから、Amazon Web Services (AWS) がホストするマルチテナントのステートレス クラウド アプリケーションに移行することを決定しました。その後、時間をかけてこれらをマイクロサービスに分解しました。このプロジェクトは、ある上級エンジニアが「このアイデアは本当に気に入っているが、めまい (vertigo) がする」と言ったことにちなんで、「Vertigo」と名付けられました。これは、これまでで最大のインフラストラクチャ プロジェクトであり、AWS への移行には 2 年かかり、わずか 10 か月余りで 10 万人を超えるお客様をサービスの中断なく移行しました。また、サービスをマイクロサービスに分解することにも取り組みました。

マイクロサービスは決して特効薬ではありませんが、成長するソフトウェアや企業の多くの問題を解決します。マイクロサービス アーキテクチャは独立して実行されるユニットで構成されているため、他のサービスに影響を与えずに各サービスを開発、更新、デプロイ、スケーリングできます。ソフトウェアの更新をより頻繁に実行しながら、信頼性、アップタイム、パフォーマンスを向上させられます。アトラシアンは週に 1 回のアップデートのプッシュから、1 日に 2 - 3 回のプッシュへと改善できました。

アトラシアンが成長するに伴い、マイクロサービスによってチームや地理的な場所をサービスの所有権に沿って分割することで、より確実にスケーリングできるようになります。Vertigo を始める前、アトラシアンには世界中に 5 つの異なる開発センターがありました。このような分散したチームは一元化されたモノリスに制約されていたため、自律的な方法でチームをサポートする必要がありました。マイクロサービスによってこれが実現します。

Vertigo のメリットには、デプロイ速度の向上、ディザスター リカバリ、コストの削減、パフォーマンスの向上などがあります。これによって目標をより早く達成しながら、その過程で顧客により大きな価値を提供できます。

さらに、より一般的には、マイクロサービスによってチームは継続的なインテグレーションと継続的なデリバリー (CI/CD) で、コードを更新したりリリース サイクルを加速したりしやすくなります。チームはコードを試して、何か問題が起きた場合はロールバックできます。

要するに、マイクロサービスのメリットは次のとおりです。

アジリティ — 頻繁にデプロイする小規模なチームでアジャイルな作業方法を促進します。

柔軟なスケーリング – マイクロサービスの負荷容量が最大に達した場合は、そのサービスの新しいインスタンスを付随するクラスターに迅速にデプロイして、負担を軽減できます。現在、アトラシアンはマルチテナントでステートレスであり、お客様は複数のインスタンスにまたがっています。今では、さらに大きなインスタンス サイズをサポートできるようになりました。

継続的なデプロイ – リリース サイクルが頻繁かつ迅速になりました。以前は 1 週間に 1 回アップデートをプッシュしていましたが、現在は 1 日に 2 - 3 回程度プッシュできます。

高い保守性とテスト性 – チームは新機能を試すことができるうえに、何かがうまくいかない場合はロールバックできます。これによって、コードの更新が容易になり、新機能の市場投入までの時間が短縮されます。さらに、個々のサービスの障害やバグを簡単に特定して修正できます。

独立したデプロイが可能 – マイクロサービスは個別のユニットであるため、個々の機能を迅速かつ簡単に独立してデプロイできます。

テクノロジーの柔軟性 –マイクロサービス アーキテクチャによって、チームは希望するツールを自由に選択できます。

高い信頼性 – アプリケーション全体が停止する恐れなしに、特定のサービスに対する変更をデプロイできます。

チーム満足度の向上 – マイクロサービスを扱うアトラシアン チームは自律性が高まり、プル リクエストが承認されるまで数週間待たずに自らビルドしてデプロイできるため、満足度が向上します。

少数のモノリシック コードベースから製品を支える多くの分散型システムやサービスに移行すると、意図しない複雑性が生じました。当初、以前と同じベロシティと自信を持って新機能を追加するのに苦労していました。マイクロサービスによって複雑さが増して、それが開発の無秩序な増加や急速で管理不能な成長につながる可能性があります。異なるコンポーネントが互いにどのように関係しているか、特定のソフトウェア コンポーネントを所有しているのは誰か、依存するコンポーネントに干渉しないようにするにはどうすればよいかを判断するのは、難しい可能性があります。

このため、アトラシアンは Vertigo によって、既存の製品と購入して構築する将来の製品を強化する共通の機能を構築しました。単一の製品を扱う会社であれば、マイクロサービスは不要かもしれません。

マイクロサービスのデメリットには、次のようなものがあります。

開発の無秩序な増加 – マイクロサービスの方がモノリス アーキテクチャより複雑になります。なぜなら、複数のチームによってより多くの場所でより多くのサービスが作成されるからです。開発の無秩序な増加を適切に管理しないと、開発速度が遅くなって運用パフォーマンスが低下します。

指数関数的なインフラストラクチャ コスト – 新しいマイクロサービスごとに、テスト スイート、デプロイ ガイド、ホスティング インフラストラクチャ、監視ツール、その他に関する独自のコストがかかる可能性があります。

組織的なオーバーヘッドの増加 – チームはアップデートとインターフェイスを調整するために、コミュニケーションとコラボレーションのレベルをさらに高める必要があります。

デバッグの課題 — 各マイクロサービスには独自のログ セットがあるため、デバッグがより複雑になります。さらに、1 つのビジネス プロセスを複数のマシン全体で実行できるため、デバッグがさらに複雑になります。

標準化の欠如 – 共通のプラットフォームがない場合は、言語、ロギング標準、監視が急増する可能性があります。

明確な所有権の欠如 – 導入されるサービスの数が増えるにつれて、それらのサービスを実行するチームの数も増加します。時間が経つにつれて、チームが利用できるサービスやサポートの問い合わせ先を把握することが難しくなります。

多くのプロジェクトは最初はモノリスとして始まり、その後マイクロサービス アーキテクチャに進化します。モノリスに新機能が追加されると、多くの開発者を特異なコードベースに取り組ませるのは面倒になってくるかもしれません。コードの競合がより頻繁になって、ある機能を更新することで無関係な機能にバグが入るリスクが増加します。このような望ましくないパターンが発生した際は、マイクロサービスへの移行をご検討ください。

移行から学んだベスト プラクティスを次に紹介します。

2016 年 1 月には、合計で約 15 のマイクロサービスがありました。現在、この数は 1300 を超えています。10 万のお客様をクラウドに移行させてその過程で新しいプラットフォームを構築し、私たちの文化を変革して最後に新しいツールを導入しました。私たちには、より満足度が高い自律的なチームとより優れた DevOps 文化があります。

マイクロサービスは万人向けではないかもしれません。従来のモノリスが完璧に機能するかもしれませんし、これを分解しても苦労に見合わないかもしれません。しかし、組織が成長してアプリケーションに対する要求が高まるにつれ、マイクロサービス アーキテクチャは価値あるものになり得ます。

多くの組織にとってのトレンドは分散型アーキテクチャを備えたマイクロサービスであるため、アトラシアンは Compass を開発して、企業が分散型アーキテクチャの複雑さを拡張に合わせて管理できるようにしました。Compass は拡張可能な開発者エクスペリエンス プラットフォームで、すべてのエンジニアリング成果とチーム コラボレーションに関する分断された情報を一元化された検索可能な場所にまとめます。