バックアップデータベースやバックアップサーバに戻すといった従来のフェイルオーバー手法は、設計、テスト、保守にコストがかかる。セルベースアーキテクチャは、この問題を解決を目指す新しいアプローチだ。
この記事は会員限定です。会員登録(無料)すると全てご覧いただけます。
従来のフェイルオーバー手法(バックアップデータベースやバックアップサーバに戻す手法など)は、設計、テスト、保守にコストがかかる。また、一部の障害がシステム全体に連鎖するリスクがある場合も、復旧にコストがかかる。
セルベースアーキテクチャ(CBA:Cell-based architecture)とは、単一障害点を取り除くことで、これらの問題の解決を目指す新しいアプローチを指す。SlackやAmazon.comのAmazon Prime Videoは、サービス停止インシデントや、トラフィック/データ増加への対策として、セルベースのアプローチに移行している。
ただし、アーキテクチャの変更する決定にはトレードオフが伴う。高可用性とスケーラビリティのメリットと、セルベースアプローチが大規模アプリケーションシステムにもたらす複雑さとコストを比較検討することが重要になる。
CBAは、1つのソフトウェアシステムを、さまざまなアプリケーションサービスとデータコンポーネントを部分的または完全なコピーの集合体に分解する。マイクロサービスベースのアプリケーションの場合、各セルには、定義済みビジネスロジックに従って動作する1つ以上のマイクロサービスが含まれる。
セルは、相互に分離され、独立したソフトウェアシステムユニットだ。各セルには、論理的に結び付きのある一連のサービスが含まれる。例えば、データベースに保存されたプロファイルと、そのプロファイルに関連する作成サービス、編集サービス、読み取りサービスがあるとする。この場合、セルには、プロファイル内のユーザー情報を含むデータベースをはじめ、各種サービスを実行するのに必要な依存関係も全て含められる。
各セルは、個別にバックアップ、デプロイ、作成する必要がある。セルには、APIゲートウェイのようなゲートウェイを介したアクセスポイントが1つある。各セルは独立しており、サービスのデプロイに必要な要素が全て含まれるため、需要のピーク時に複製して再利用できる。負荷に対応する際、ルーティングレイヤーがトラフィックを新しいセルに再ルーティングする。ルーティングレイヤーには次の要素が含まれる。
ルーティングレイヤーには、管理プレーンと連動して高負荷を監視し、動作しなくなったシステムを置き換えるロードバランサーが含まれる場合もある。
セルベースアプローチでは、管理機能とルーティング機能が分離され、両機能が連携することで、新たな可能性が生み出される。例えば、冗長セルを複数用意して高可用性を実現し、地理的なリージョンやアベイラビリティゾーン(AZ)の間でデータを分離することも考えられる。大企業の場合、パブリッククラウドのさまざまなリージョンにセルを配置して、顧客へのレスポンスを向上することもできる。
回復力の点では、ロードバランサーと管理プレーンにより、セルが失われた場合でもサービスを維持できる。セルの独立性により、別のサービスがダウンしてもアプリケーションの稼働を継続することも可能だ。
セルベースアーキテクチャでは、クラウドコンピューティングと自動スケーリングを統合するのが最も一般的な運用方法で、この場合、セルは1つ以上のRESTfulサービスを実装するのが一般的だ。
ただし、セルベースアーキテクチャを構築する方法は他にもある。セルは、個別に稼働する物理サーバ、あるいは同一マシン上の仮想サーバに複数作成することもできる。この場合、既存ネットワークは、ルーター、ファイアウォール、IPセキュリティを使って分離される。あるいは、同一のマシン上で動く複数のセルに、それぞれ異なる権限、プロセス、ユーザーIDを使用して分離を実現することもできる。
これらの例は、セルベースアーキテクチャが、多種多様な方法でセルの分離を実現できることを示している。
セルベースアーキテクチャは、信頼性の高い大規模アプリケーションを構築するための次のようなメリットを提供する。
データストレージが分離されるため、個別のセルのクラッシュやメモリエラーによりダウンするのは単一の要素だけになる。重要なサービス(認証、広告配信、購入プロセスなど)には冗長性を持たせるために多くのリソースを配置し、重要度の低いサービスに配置するリソースを減らすことも可能になる。
セルは自律的で、担う役割も異なるため、テスト用に簡単に作り直すことができる。1つのセルに欠陥が生じても、他のセルに影響を及ぼす可能性は低い。
セルのテストやデプロイを個別にできるため、必ずしもシステムの広範な回帰テストは必要にならない。「Docker」やKubernetesのようなプラットフォームとCI/CDツールでは、セルのエクスポート、インポート、読み込み、実行が数回の操作で済み、セルごとに異なるデプロイパイプラインの作成も可能になる。
セルの冗長性により、1つのセルが停止してもロードバランサーによりトラフィックがリダイレクトされるため、ダウンタイムはほぼゼロになる。
需要の増加に応じて、冗長セルを作成して負荷分散したり、セルを分割したりできる。セルにデータが含まれていない場合(他のAPIにアクセスするだけの場合など)、管理レイヤーは新しいセルを作成し、セル間で負荷を分散できる。セルにデータが含まれている場合は、データを分離してルーティングするか、ライトスルーキャッシュを実装することもできる。
セルをそれぞれ独自のCI/CDパイプラインを通じて運用環境にデプロイすることもできる。
セルベースアーキテクチャを実装するに当たって、インフラに新たなレイヤーを追加することで生じる課題を認識しておくことも重要だ。次のようなリスクが想定される。
セルベースアーキテクチャは、本来複雑なアプリケーションシステム内で連鎖して発生するエラーやフェイルオーバーの問題に対処する手法として登場した。グローバル規模やインターネット規模で運用されるシステムは、その規模の大きさから冗長性とスケーラビリティが求められるため、セルベースアーキテクチャが特に適している。
セルベースアーキテクチャは、ビジネスとインターネットサービスを連携させようとする企業や、クラウドでWebサービスを構築してデプロイしようとしている企業に適している。コンポーネントやCI/CDパイプラインの設定は、最初にかなりの作業が必要になるものの、企業の成長に応じて規模が拡大したとしても、デプロイをクリーンかつシンプルに保つことができ、新しいセルの開発速度も向上する。
成長中の企業がセルベースアーキテクチャに移行するには、バックドア、サイドチェック、冗長性、手作業で作成したSQLのクリーンアップに取り組む必要がある。チームはセル内に残る問題への対処が続く可能性があると同時に、その問題を解決するための完全な権限を持つことになる。
Amazon.comは、Amazon Prime Videoでの動画配信にセルベースアーキテクチャを使用し、需要が高ければ新しいセルを作成し、パフォーマンスの低いセルをローテーションから外すようセルルーティングを調整して、負荷分散を実現させている。
各セルは状態を保持しないで動画を配信するため、セルが無限ループに陥ると、システムにより自動的にそのセルが削除される。その後、新しいセルが作成され、トラフィックが検出されて再ルーティングされる。
Slackでは、2021年に起きたサービス停止のインシデントを受け、セルベースアーキテクチャに移行した。Slackは、AZはサービス停止のリスクがあると見なし、それぞれのAZをセルとして扱うことで、セルのダウン時にフェイルオーバーとルーティングを可能にするソフトウェアを構築することを決めた。そのために、各AZ内のコードを分離して、サイロ(セル)を作成する必要があった。この取り組みの結果として、もしAZに障害が発生しても、Slackユーザーは、影響を感じることはなくなった。
Copyright © ITmedia, Inc. All Rights Reserved.
Cloud Native Central 記事ランキング