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

バックアップデータベースやバックアップサーバに戻すといった従来のフェイルオーバー手法は、設計、テスト、保守にコストがかかる。セルベースアーキテクチャは、この問題を解決を目指す新しいアプローチだ。

[Matt Heusser，TechTarget]

　従来のフェイルオーバー手法（バックアップデータベースやバックアップサーバに戻す手法など）は、設計、テスト、保守にコストがかかる。また、一部の障害がシステム全体に連鎖するリスクがある場合も、復旧にコストがかかる。

　セルベースアーキテクチャ（CBA：Cell-based architecture）とは、単一障害点を取り除くことで、これらの問題の解決を目指す新しいアプローチを指す。SlackやAmazon.comのAmazon Prime Videoは、サービス停止インシデントや、トラフィック／データ増加への対策として、セルベースのアプローチに移行している。

　ただし、アーキテクチャの変更する決定にはトレードオフが伴う。高可用性とスケーラビリティのメリットと、セルベースアプローチが大規模アプリケーションシステムにもたらす複雑さとコストを比較検討することが重要になる。

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

　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ユーザーは、影響を感じることはなくなった。