architecture-paradigm-space-based

スペースベースアーキテクチャのパラダイム

使用する場面

• 弾力的なスケーラビリティが必要な高トラフィックのアプリケーション
• インメモリデータグリッドが必要なシステム

使用しない場面

• 分散キャッシュを導入するほどではない低トラフィックのアプリケーション
• 可用性よりも強い一貫性が求められるシステム

このパラダイムを採用する場面

• トラフィックや状態の量が単一のデータベースノードの処理能力を超える場合。
• レイテンシ要件を満たすため、処理ユニットの近くに配置されたインメモリデータグリッドが必要な場合。
• 多数の同一で自立したユニットにワークロードを分割することで、線形スケーラビリティが必要な場合。

導入手順

1. ワークロードを分割する：トラフィックとデータを処理ユニットに分割し、それぞれにレプリケーションされたデータキャッシュを配置します。
2. データグリッドを設計する：適切なキャッシュ技術、レプリケーション戦略（同期または非同期）、データのエビクションポリシーを選択します。
3. 永続化を調整する：永続データストアへのライトスルーまたはライトビハインド戦略を、調整プロセスも含めて実装します。
4. フェイルオーバー処理を実装する：データを失うことなくノード喪失からの復旧を検証できるよう、リーダー選出またはハートビートの仕組みを設計します。
5. スケーラビリティを検証する：負荷テストとカオステストを実施し、システムの弾力性と自己修復機能を確認します。

主な成果物

• 選択したグリッド技術、パーティショニング方式、耐久性戦略を詳述したアーキテクチャ決定記録（ADR）。
• 処理ユニットのスケーリング、および「スプリットブレイン」シナリオからの復旧に関する運用手順書。
• キャッシュヒット率、レプリケーション遅延、フェイルオーバーイベントを追跡する監視スイート。

リスクと軽減策

• 結果整合性の問題：
  • 軽減策：データ鮮度に関するサービスレベル合意（SLA）を正式に文書化し、すぐには一貫性が保たれないデータに対する補償ロジックを実装します。
• 運用の複雑さ：
  • 軽減策：データグリッドのオーケストレーションには成熟した自動化が必要です。プロセスの早い段階で、本番環境対応のツールと自動化に投資します。
• コスト：
  • 軽減策：インメモリグリッドは多くのリソースを消費する可能性があります。コストを効果的に管理するため、使用率の厳密な監視と自動スケーリングポリシーを実装します。

具体的なコンポーネント

このパラダイムの実装でよく使われるツールや抽象概念の語彙です。 依存関係ではなく、tools: のフロントマターでもありません。

• data-grid-platform：Hazelcast、Apache Ignite など。インメモリのパーティション分割型データストア
• replication-manager：書き込みを非同期で永続ストレージやリージョン間に転送します
• load-tester：グリッドに単一リージョンの上限を超える負荷をかけ、スケールアウトを検証します

完了条件

• 処理ユニットをデプロイする前に、選択したグリッド技術、パーティショニング方式、レプリケーション戦略 （同期または非同期）、データのエビクションポリシー、耐久性 SLA を ADR に記録していること。
• 処理ユニットのスケーリングとスプリットブレインシナリオからの復旧に関する運用手順書が用意され、 非本番環境で演習済みであること。
• 負荷テストとカオステストにより、本番環境への昇格前に、データ損失なく想定ピークトラフィックの 2 倍以上に対応できることを確認していること。
• システムが実トラフィックを受け入れる前に、アラートしきい値を設定したうえで、監視スイートが キャッシュヒット率、レプリケーション遅延、フェイルオーバーイベントを追跡していること。