Amazon Prime VideoやSlackが採用するセルベースアーキテクチャ　そのメリットと実装上のリスクとは？：テストの分離やダウンタイム低減に寄与

　CBAは、1つのソフトウェアシステムを、さまざまなアプリケーションサービスとデータコンポーネントを部分的または完全なコピーの集合体に分解する。マイクロサービスベースのアプリケーションの場合、各セルには、定義済みビジネスロジックに従って動作する1つ以上のマイクロサービスが含まれる。

　セルは、相互に分離され、独立したソフトウェアシステムユニットだ。各セルには、論理的に結び付きのある一連のサービスが含まれる。例えば、データベースに保存されたプロファイルと、そのプロファイルに関連する作成サービス、編集サービス、読み取りサービスがあるとする。この場合、セルには、プロファイル内のユーザー情報を含むデータベースをはじめ、各種サービスを実行するのに必要な依存関係も全て含められる。

　各セルは、個別にバックアップ、デプロイ、作成する必要がある。セルには、APIゲートウェイのようなゲートウェイを介したアクセスポイントが1つある。各セルは独立しており、サービスのデプロイに必要な要素が全て含まれるため、需要のピーク時に複製して再利用できる。負荷に対応する際、ルーティングレイヤーがトラフィックを新しいセルに再ルーティングする。ルーティングレイヤーには次の要素が含まれる。

• コントロールプレーン：セルをプロビジョニングおよびアップデートするための管理APIを提供する
• データプレーン：トラフィックを転送する
• 管理プレーン：構成と監視をする

　ルーティングレイヤーには、管理プレーンと連動して高負荷を監視し、動作しなくなったシステムを置き換えるロードバランサーが含まれる場合もある。

セルの主な特徴と設計

　セルベースアプローチでは、管理機能とルーティング機能が分離され、両機能が連携することで、新たな可能性が生み出される。例えば、冗長セルを複数用意して高可用性を実現し、地理的なリージョンやアベイラビリティゾーン（AZ）の間でデータを分離することも考えられる。大企業の場合、パブリッククラウドのさまざまなリージョンにセルを配置して、顧客へのレスポンスを向上することもできる。

　回復力の点では、ロードバランサーと管理プレーンにより、セルが失われた場合でもサービスを維持できる。セルの独立性により、別のサービスがダウンしてもアプリケーションの稼働を継続することも可能だ。

　セルベースアーキテクチャでは、クラウドコンピューティングと自動スケーリングを統合するのが最も一般的な運用方法で、この場合、セルは1つ以上のRESTfulサービスを実装するのが一般的だ。

　ただし、セルベースアーキテクチャを構築する方法は他にもある。セルは、個別に稼働する物理サーバ、あるいは同一マシン上の仮想サーバに複数作成することもできる。この場合、既存ネットワークは、ルーター、ファイアウォール、IPセキュリティを使って分離される。あるいは、同一のマシン上で動く複数のセルに、それぞれ異なる権限、プロセス、ユーザーIDを使用して分離を実現することもできる。

　これらの例は、セルベースアーキテクチャが、多種多様な方法でセルの分離を実現できることを示している。

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

　セルベースアーキテクチャは、信頼性の高い大規模アプリケーションを構築するための次のようなメリットを提供する。

障害の分離

　データストレージが分離されるため、個別のセルのクラッシュやメモリエラーによりダウンするのは単一の要素だけになる。重要なサービス（認証、広告配信、購入プロセスなど）には冗長性を持たせるために多くのリソースを配置し、重要度の低いサービスに配置するリソースを減らすことも可能になる。

テストの分離

　セルは自律的で、担う役割も異なるため、テスト用に簡単に作り直すことができる。1つのセルに欠陥が生じても、他のセルに影響を及ぼす可能性は低い。

　セルのテストやデプロイを個別にできるため、必ずしもシステムの広範な回帰テストは必要にならない。「Docker」やKubernetesのようなプラットフォームとCI/CDツールでは、セルのエクスポート、インポート、読み込み、実行が数回の操作で済み、セルごとに異なるデプロイパイプラインの作成も可能になる。

ダウンタイムの低減

　セルの冗長性により、1つのセルが停止してもロードバランサーによりトラフィックがリダイレクトされるため、ダウンタイムはほぼゼロになる。

スケーラビリティ

　需要の増加に応じて、冗長セルを作成して負荷分散したり、セルを分割したりできる。セルにデータが含まれていない場合（他のAPIにアクセスするだけの場合など）、管理レイヤーは新しいセルを作成し、セル間で負荷を分散できる。セルにデータが含まれている場合は、データを分離してルーティングするか、ライトスルーキャッシュを実装することもできる。

デプロイメントの分離

　セルをそれぞれ独自のCI/CDパイプラインを通じて運用環境にデプロイすることもできる。

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

　セルベースアーキテクチャを実装するに当たって、インフラに新たなレイヤーを追加することで生じる課題を認識しておくことも重要だ。次のようなリスクが想定される。

• 複雑さ：セルベースの作業では、必要な帯域幅、処理能力、メモリ、プロセス間通信が増える。個別のセルにログを保持する可観測性レイヤーを追加しなければ、デバッグは難しい。だが、可観測性レイヤーを追加すると、必要な帯域幅が倍増する可能性がある
• コスト：可観測性レイヤーにより、データストレージのコストが大幅に増加し、CPUとメモリのコストによってクラウドコンピューティングの費用も増加する。セルアーキテクチャの開発には全く新しいチームが必要になる可能性があり、サポート用に別途チームが必要になることもある
• 規律の欠如：セルベースアーキテクチャに移行するには、ビジョン、規律、優れたコミュニケーションが必要になる。主導者がいなければ、真のセルベースアーキテクチャによって必要な分離を実現できず、メリットを享受できない可能性がある
• システム障害：一般的に、セルベースアーキテクチャは、レガシーシステムからのアーキテクチャ変更ではなく、システムの新規開発で成功の実績がある。適切なパフォーマンステストを大掛かりに行わないと、セルベースにアプローチを変えることで、回復困難なシステム障害が発生する可能性がある

セルベースアーキテクチャを検討すべきシステムとは

　セルベースアーキテクチャは、本来複雑なアプリケーションシステム内で連鎖して発生するエラーやフェイルオーバーの問題に対処する手法として登場した。グローバル規模やインターネット規模で運用されるシステムは、その規模の大きさから冗長性とスケーラビリティが求められるため、セルベースアーキテクチャが特に適している。

　セルベースアーキテクチャは、ビジネスとインターネットサービスを連携させようとする企業や、クラウドでWebサービスを構築してデプロイしようとしている企業に適している。コンポーネントやCI/CDパイプラインの設定は、最初にかなりの作業が必要になるものの、企業の成長に応じて規模が拡大したとしても、デプロイをクリーンかつシンプルに保つことができ、新しいセルの開発速度も向上する。

　成長中の企業がセルベースアーキテクチャに移行するには、バックドア、サイドチェック、冗長性、手作業で作成したSQLのクリーンアップに取り組む必要がある。チームはセル内に残る問題への対処が続く可能性があると同時に、その問題を解決するための完全な権限を持つことになる。

SlackやAmazon.comはどうセルベースアーキテクチャを活用しているのか

　Amazon.comは、Amazon Prime Videoでの動画配信にセルベースアーキテクチャを使用し、需要が高ければ新しいセルを作成し、パフォーマンスの低いセルをローテーションから外すようセルルーティングを調整して、負荷分散を実現させている。

　各セルは状態を保持しないで動画を配信するため、セルが無限ループに陥ると、システムにより自動的にそのセルが削除される。その後、新しいセルが作成され、トラフィックが検出されて再ルーティングされる。

　Slackでは、2021年に起きたサービス停止のインシデントを受け、セルベースアーキテクチャに移行した。Slackは、AZはサービス停止のリスクがあると見なし、それぞれのAZをセルとして扱うことで、セルのダウン時にフェイルオーバーとルーティングを可能にするソフトウェアを構築することを決めた。そのために、各AZ内のコードを分離して、サイロ（セル）を作成する必要があった。この取り組みの結果として、もしAZに障害が発生しても、Slackユーザーは、影響を感じることはなくなった。