セルベースアーキテクチャとは、プロビジョニングと監視を自動化し、需要に応じてコンピューティングリソースをスケーリングするアーキテクチャだ。一般的にコンテナオーケストレーションツール「Kubernetes」を使って実装され、論理的に関連するサービス群を「セル」というまとまりに分離する構造を持つ。各セルは相互に通信するための仕組みがある。

　各セルは設定情報管理、製品データ管理、画像処理、テキストデータ処理、従業員データ管理など、システム全体における特定領域の機能を担当する。セルベースアーキテクチャのシステムは、新機能を単一の独立したセルに展開できるため、あるセルで障害が発生してもシステム全体が停止するリスクを軽減可能だ。複数のセルを使ってシングルテナント（専有型）のシステムを構築すれば、冗長性を高め、連鎖障害を防ぐことにつながる。監視システムが停止または不適切に動作しているセルを検出すると、他のセルが処理を引き継ぎ、その間に障害が起きたセルを停止させてから再起動できる。

マイクロサービスアーキテクチャとは

　マイクロサービスアーキテクチャは、異なるサービスを組み合わせてシステムを構築する「サービス指向アーキテクチャ」（SOA）の考え方を基にした分散アーキテクチャだ。特定の業務機能に特化した、小規模で独立したサービスの構築を可能にする。開発チームは通常、マイクロサービス群とそれらを動作させるために必要なインフラ、アプリケーション、ソースコード、データベースを管理することになる。

　各マイクロサービスはデータベースを持ち、API（アプリケーションプログラミングインタフェース）を通じて他のマイクロサービスと通信する。マイクロサービス同士のインタフェースが標準化されていれば、それぞれのマイクロサービスを異なるプログラミング言語で実装することも可能だ。マイクロサービス間の依存関係が限られるため疎結合（依存関係の少ない連携）な状態を実現でき、適切に実装されていれば1つのマイクロサービスに障害が発生してもシステム全体は稼働し続ける。

両者の違い

　セルベースアーキテクチャは、業務プロセスの拡張性を高め、システム障害の影響を抑える仕組みを提供する。具体的には、コンピューティングリソースの需要増加に対処するための層を設けて、その層で個々のマイクロサービスではなくセル単位で独立してスケーリングできるようにする。

　マイクロサービスアーキテクチャは、業務プロセスを分割・分離し、連携を可能にする方法を提供する。ただしスケーリングには計画が必要で、需要に応じてマイクロサービスのリソースをスケーリングできても、データベースがそれに追い付かない場合がある点に注意が必要だ。

いつ使うべきか

　セルベースアーキテクチャは、可用性と回復力に優れたシステムの構築に役立つ。分散システムへの切り替えやクラウドサービスへの移行を検討している場合、セルベースアーキテクチャを導入することで、システムに先進技術を取り入れるための新たなステップとなる可能性がある。

　ただしセルベースアーキテクチャのシステムは、CPU、メモリ、ネットワークといったリソースの使用量が増えてコストがかさむだけではなく、デバッグなどの技術的課題も生じる恐れがある。こうした課題は、システムを監視する層（オブザーバビリティ層）によって解決できる可能性があるが、その分リソースの使用量がさらに増加することにもなりかねない。

　特に既存のレガシーシステムをセルベースアーキテクチャに切り替える場合、新たにセルベースアーキテクチャのシステムを開発するよりも多くの障壁に直面しやすい。小規模アプリケーションやスタートアップ（新興企業）にとっては、セルベースアーキテクチャに関する初期投資が導入のメリットを上回る可能性がある。

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

　業務プロセスを独立させつつ、可用性スケーラビリティを確保する方法として、マイクロサービスを1つのセルとして扱う「セルベースのマイクロサービスアーキテクチャ」というアプローチがある。コストがかかりやすく、開発も複雑になりやすいデメリットはあるが、適切な場面で利用すれば、両アーキテクチャの長所を組み合わせたシステムを構築可能だ。これによって、ビジネスプロセスを細分化しつつ迅速な開発と継続的デリバリーを実現できる。

　インターネットに公開する大規模アプリケーションにおいて、スケーラビリティや可用性、障害耐性を求めるのであれば、セルベースのマイクロサービスアーキテクチャのメリットを享受できる見込みがある。ただし従来型のシステムでは、得られるメリットが少なく、コストが高くなる可能性がある。