モノリシックからセルベースへ次世代のアプリケーションアーキテクチャを解説

近年、アプリケーションアーキテクチャの領域において「セルベースアーキテクチャ」という言葉を聞く機会が増えました。セルベースアーキテクチャはAWSやSlackなど、主要なテック企業が採用したということで話題となっています。

セルベースアーキテクチャとはどのような仕組みであり、どのようなメリットがあるのでしょうか。今回は、注目のセルベースアーキテクチャについて、詳しく解説します。

セルベースアーキテクチャとは

セルベースアーキテクチャは、モノリシックアーキテクチャやマイクロサービスアーキテクチャの進化形として登場した、次世代のアーキテクチャスタイルです。個々の「セル」が独立したユニットとして機能し、サービス間の疎結合を保ちながらも高い信頼性とスケーラビリティを実現します。

セルベースアーキテクチャの仕組み

セルベースアーキテクチャでは、「セル」と呼ばれる独立したコンポーネントでシステムを構成します。これらのセルは、特定の機能やサービスを提供するために設計されており、単一のセルが障害を起こした場合でも、全体のシステムには影響を与えないように設計されています。また、セルは自己修復機能を持ち、異常が検出された場合には自動的に修復されます。

セルは分散システムの一部として、「セルコントローラー」と呼ばれるルーティングの仕組みにより他のセルと通信しながら協力して動作します。また、各セルは独自のデータストレージを持ち、必要に応じて他のセルとデータを共有します。

独立したセルをベースとした構成により、障害発生時にはセル内のみに影響範囲が限定されます。また、セルの追加や削除は容易であり、スケーラビリティの向上やシステムの柔軟性担保に寄与します。

セルベースアーキテクチャのメリット

セルベースアーキテクチャを採用するメリットは以下のとおりです。

〇レジリエンスの向上

セルベースアーキテクチャの大きな特徴の一つは、高いレジリエンス（耐障害性）です。各セルは独立して動作するため、システム全体が一つの障害で停止することはありません。たとえば、一部のセルに障害が発生しても、他のセルは正常に機能し続けることができます。

これにより、システム全体の可用性が向上し、ユーザーに安定したサービスを提供することができます。

〇スケーリングのしやすさ

セルベースアーキテクチャでは、特定のセルのみをスケールアップまたはスケールダウンすることが可能です。これにより、リソースを効率的に利用でき、必要な部分に必要なだけのリソースを割り当てやすくなります。

また、セルごとに異なるスケーリング戦略を採用することができるため、たとえば特定の機能のみを拡張するなど、柔軟な対応も可能です。

〇テスト・デプロイ範囲の限定

セルベースアーキテクチャのもう一つのメリットは、テストやデプロイの範囲を限定できることです。各セルが独立してデプロイできるため、新機能のリリースやバグ修正を迅速に行えます。

これにより、デプロイのリスクを軽減しつつ、開発サイクルを短縮できます。さらに、特定のセルだけに変更を加えることで、他の部分に影響を与えずに機能改善を進めることができます。

AWSやAmazonでの採用

セルベースアーキテクチャは、クラウド環境やコンテナ技術と相性が良く、AWSやAmazonなどのクラウドサービスプロバイダーでの採用が進んでいます。

2024年に実施されたAWS Summit Japanでは、AWSの取り組みとしてセルベースアーキテクチャの採用事例も紹介されています。

※参考：AWS Summit Japan 2024 に見る Resilience at AWS

アプリケーションアーキテクチャの変遷

セルベースアーキテクチャが登場した背景を理解するために、以下では従来型のモノリシックアーキテクチャからマイクロサービスアーキテクチャまで、一連のアプリケーションアーキテクチャの変遷についてご紹介します。

モノリシックアーキテクチャの時代

モノリシックアーキテクチャは、従来のソフトウェア開発において広く採用されてきたアーキテクチャスタイルです。モノリシックアーキテクチャでは、アプリケーションの全ての機能が一つのコードに統合され、全ての機能が一体としてデプロイされます。

モノリシックアーキテクチャはコードの管理が一元化されるため、小規模なプロジェクトやリソースが限られた環境では現在でも有効なアプローチです。

しかし、モノリシックアーキテクチャにはデメリットも存在します。アプリケーションが大規模になるにつれてコードは複雑化し、少しの修正が多くの範囲に影響してしまうため、変更や修正は難しくなります。また、一部の機能に不具合が発生した場合、アプリケーション全体が影響を受けるリスクもあります。

スケーラビリティに関しても、特定の機能だけをスケールアップすることが難しく、全体としてパフォーマンスを向上させなければなりません。

こうした課題を克服するために、モノリシックアーキテクチャからマイクロサービスアーキテクチャへの移行が進められるようになりました。

マイクロサービスの登場

マイクロサービスアーキテクチャは、モノリシックアーキテクチャの制約を克服するために考えだされた仕組みです。このアプローチでは、アプリケーションを複数の独立したサービスに分割し、各サービスが特定の機能を担当します。

スケールアップを行いたい場合、特定の機能のみを拡張することで、柔軟な対応が可能となります。また、各サービスが独立しているため、異なるチームが同時に開発を進めることができ、開発速度が向上するというメリットもあります。

一方で、マイクロサービスアーキテクチャには複雑性の増加や運用コストの上昇といった課題もあります。サービス間の通信やデータの一貫性を確保するための仕組みが必要となり、開発や運用において高度な技術力が求められます。

以上のように、マイクロサービスアーキテクチャは柔軟性とスケーラビリティの面で大きな利点を持ちながらも、適切な設計と運用が求められるアーキテクチャスタイルです。

マイクロサービスの究極系セルベースアーキテクチャ

セルベースアーキテクチャは、マイクロサービスアーキテクチャの進化形として、さらに高い柔軟性とスケーラビリティを提供します。上述した通り、セルベースアーキテクチャではアプリケーション全体を複数の「セル」に分割します。各セルは独立しており、セル同士は疎結合となっています。

各セルが独立して動作するため、一部のセルに障害が発生しても他のセルには影響が及びません。これにより、システム全体の耐障害性が向上します。

また、各セルが独立してデプロイできるため、新機能のリリースやバグ修正も行いやすくなります。

セルベースアーキテクチャの注意点

一方で、セルベースアーキテクチャはどのようなシステムにおいても有効な仕組みであるとは言えません。以下では、セルベースアーキテクチャ採用における注意点を整理します。

複雑さ

セルベースアーキテクチャの採用において、複雑さは避けられない要素の一つです。システム全体を複数のセルに分割することで、各セルが独立して機能するメリットを得られる一方、セル間の通信やデータの一貫性を保つための仕組みが必要となります。

セルベースアーキテクチャを実現するためには、設計や開発、運用の各フェーズにおいて、高度な技術力が求められるようになります。さらに、セルごとに異なる技術スタックやツールを使用する場合には、それぞれの管理が複雑化するリスクもあります。

異なるセル間でのデータの一貫性を維持するためのプロトコルや、監視・ロギングシステムの導入が不可欠です。

コスト

セルベースアーキテクチャは、初期導入や運用においてコストが増加する傾向があります。

各セルが独立して動作するためには、個別のインフラが必要となり、そのぶんの費用がかかります。

さらに、高度な技術を持つ人材の確保や、トレーニングなどの人件費も増加する可能性があります。セルごとに異なる技術スタックを使用する場合、それぞれのライセンス費用や保守費用も考慮しなければなりません。

単一障害の増加

多数のセルを用意するためには、多数のハードウェアを用意する必要があります。よって、ハードウェアの単一障害の可能性は増加します。

ただし、セルベースアーキテクチャでは自然回復の仕組みを用意しますので、単一障害がそのままシステムの停止につながるわけではありません。

このように、セルベースアーキテクチャの導入にあたっては複雑さやコスト管理、単一障害の増加などが課題となります。よって、基本的にセルベースアーキテクチャは大規模システム向きだと考えられます。

Slackの導入事例

以下では、セルベースアーキテクチャの具体的な適用事例として、Slackのケースをご紹介します。

※参考：Slack engineering「Slack’s Migration to a Cellular Architecture」

想定通りとならなかったインシデント

以下は、Slackで発生したインシデントの概要です。

日時	インシデントの内容
2021年6月30日午前11時45分	Slackが利用するクラウドプロバイダーのうち、米国東海岸地域のアベイラビリティゾーンでネットワーク障害が発生。各サーバー間の接続速度が低下し、サービスが低下。
2021年6月30日午後12時33分	ネットワークリンクがクラウドプロバイダーによって自動的にサービスから削除され、Slackのお客様へのサービスが完全に回復。
2021年6月30日午後5時22分	同じネットワークリンクで断続的な障害が再発。
2021年6月30日午後5時31分	クラウドプロバイダーがネットワークリンクをサービスから永久に削除し、お客様への完全なサービスを回復。

Slackはグローバルでマルチリージョンのネットワークを運用していますが、主なインフラストラクチャの大部分は、単一リージョン内の複数のアベイラビリティゾーンに配置されています。

アベイラビリティゾーンは、単一のリージョン内の独立したデータセンターであり、物理的に分離されています。Slackでは、クラウドサービスの仮想化OS、ストレージ、ネットワークなどの影響範囲が制限されており、複数のアベイラビリティゾーンで同時に障害が発生しないよう設計されています。これにより、リージョン全体の可用性を高める構成を採用していました。

しかし、上述した障害事例では、この構成がうまく機能せず、1つのアベイラビリティゾーンの障害によりシステムがダウンしてしまいました。

なぜシステムはダウンしたのか

Slackでは、当時マイクロサービスアーキテクチャを採用していました。

マイクロサービスアーキテクチャのような分散システムにおいて、障害の検出は困難です。ユーザーから送られたリクエストは、バックエンドにある多数のRPC（Remote Procedure Call）に分散され、それぞれが正しい応答を返す必要があります。

このインシデントでは、障害の影響を受けたアベイラビリティゾーン内のサービスはバックエンドのRPCを利用可能と認識したものの、実際には利用不可な状態でした。一方で、障害の影響を受けなかったアベイラビリティゾーン内のサービスは、影響を受けたRPCを利用不可と適切に認識しました。

つまり、アベイラビリティゾーン間での連携がうまく取れず、バックエンドのステータスに対する認識が異なってしまったのがサービス停止の原因でした。

セルベースアーキテクチャへの移行

Slackでは、このような事態を再発させないために、セルベースアーキテクチャへの移行を実施しました。

基本的な方針としては、以下の通りです。

各サービスはアベイラビリティゾーン内からのトラフィックのみを受信する。
各サービスはアベイラビリティゾーン内のみにトラフィックを送信する。

つまり、各アベイラビリティゾーンを「一つのセル」と見なし、アベイラビリティ内に影響範囲を限定するという戦略を採用しました。

すべてのサービスはすべてのアベイラビリティゾーンに存在しますが、各サービスはそのアベイラビリティゾーン内のサービスとのみ通信します。結果として、1つのアベイラビリティゾーン内のシステムの障害はその内部に限定されます。もしいずれかのアベイラビリティゾーンで障害が発生した場合、そのアベイラビリティゾーンに送られたトラフィックは、フロントエンドで他のアベイラビリティゾーンへとリダイレクトします。

このような仕組みにより、トラフィックを動的にルーティングして障害を回避できます。結果としてユーザーには障害が発生しているように見えず、サービスを継続的に利用してもらうことができます。