今日のゴール
nindaと他の分散システム技術を比較し、それぞれの特徴と適切な使い分けを学びます。
比較対象の技術
| 技術 | カテゴリ | 主な用途 |
|---|---|---|
| ninda | タプルスペース | 協調・同期・分散データ共有 |
| Redis | Key-Valueストア | キャッシュ・セッション・Pub/Sub |
| Apache Kafka | メッセージキュー | イベントストリーミング |
| PostgreSQL | RDBMS | トランザクション・構造化データ |
| etcd | 分散KVS | 設定管理・サービスディスカバリ |
ninda vs Redis
基本的な違い
| 観点 | ninda | Redis |
|---|---|---|
| モデル | タプルスペース | Key-Value |
| 検索 | パターンマッチング | キーベース |
| 取得削除 | take（アトミック） | GET+DEL（2操作） |
| ブロッキング | 標準機能 | BLPOP等で対応 |
いつどちらを選ぶか
nindaが適している場合：
- 複数プロセス間の協調が必要
- パターンに基づく柔軟な検索
- 生産者-消費者パターン
- タスク分散・ワークフロー管理
Redisが適している場合：
- 高速なキャッシュ
- キーが事前に分かっている
- Pub/Subでのリアルタイム通知
- 成熟したエコシステムが必要
ninda vs Apache Kafka
基本的な違い
| 観点 | ninda | Kafka |
|---|---|---|
| モデル | タプルスペース | ログベースストリーミング |
| 消費時 | takeで削除 | 残る（オフセット管理） |
| ルーティング | パターンマッチング | トピック/パーティション |
| デプロイ | 軽量・組み込み | JVM + ZooKeeper/KRaft |
いつどちらを選ぶか
nindaが適している場合：
- exactly-once処理が重要
- 低レイテンシ（1ms以下）
- 軽量なデプロイ
- 小〜中規模のイベント処理
Kafkaが適している場合：
- イベントの永続化・再処理
- 高スループット（数百万msg/sec）
- イベントソーシング/CQRS
- 複数消費者が同じイベントを読む
ninda vs PostgreSQL
基本的な違い
| 観点 | ninda | PostgreSQL |
|---|---|---|
| スキーマ | スキーマレス | スキーマベース |
| 検索 | パターンマッチング | SQL（リレーショナル） |
| ストレージ | メモリ + WAL | ディスクベース |
| 整合性 | 結果整合 or 強整合 | ACID |
相補的な使用
- PostgreSQL: 永続的なマスターデータ
- ninda: 処理の協調・タスク分散
ninda vs etcd / ZooKeeper
基本的な違い
| 観点 | ninda | etcd / ZooKeeper |
|---|---|---|
| モデル | タプルスペース | 階層的Key-Value |
| 検索 | パターンマッチング | プレフィックス検索 |
| 消費 | take（アトミック） | Watch |
| 特化 | 汎用的な協調 | 設定管理・リーダー選出 |
いつどちらを選ぶか
nindaが適している場合：
- アプリケーション組み込みの協調
- カスタムな協調パターン
- タスク分散・ワークフロー
etcd/ZooKeeperが適している場合：
- サービスディスカバリ
- 設定の集中管理
- Kubernetesとの統合
ユースケース別の技術選択
タスクキュー
| 要件 | 推奨技術 |
|---|---|
| シンプルなタスク分散 | ninda |
| 大量のタスク処理 | Redis |
| 信頼性重視 | Kafka |
| トランザクション必須 | PostgreSQL |
リアルタイム通知
| 要件 | 推奨技術 |
|---|---|
| パターンベース配信 | ninda |
| 大規模Pub/Sub | Redis |
| イベント履歴必要 | Kafka |
分散キャッシュ
| 要件 | 推奨技術 |
|---|---|
| シンプルなキャッシュ | ninda |
| 高機能キャッシュ | Redis |
| 分散キャッシュ | Redis Cluster |
ワークフロー管理
| 要件 | 推奨技術 |
|---|---|
| カスタムワークフロー | ninda |
| 標準的なワークフロー | Temporal/Airflow |
| イベントソーシング | Kafka |
ハイブリッドアーキテクチャ
実際のプロジェクトでは、複数の技術を組み合わせることが多いです。
| 役割 | 技術 |
|---|---|
| マスターデータ | PostgreSQL |
| キャッシュ | Redis |
| タスク協調 | ninda |
| イベント履歴 | Kafka |
技術選択のチェックリスト
機能要件
- データモデル（構造化 vs 非構造化）
- クエリパターン（キー vs パターン vs SQL）
- 一貫性要件（強 vs 結果整合性）
- 永続化要件（一時的 vs 永続的）
非機能要件
- レイテンシ要件
- スループット要件
- 可用性要件
- 運用コスト
エコシステム
- 既存システムとの統合
- チームのスキルセット
- コミュニティ・ドキュメント
まとめ
技術の特徴比較
| 技術 | 強み | 弱み | 最適なユースケース |
|---|---|---|---|
| ninda | パターンマッチング、協調 | エコシステム | タスク分散、ワークフロー |
| Redis | 高速、多機能 | メモリ制約 | キャッシュ、セッション |
| Kafka | 高スループット、永続化 | 複雑性 | イベントストリーミング |
| PostgreSQL | SQL、ACID | スケーリング | トランザクション |
| etcd | 強一貫性 | 機能限定 | 設定管理 |
選択の指針
演習問題
問題24-1: 技術選択
以下の要件に対して、最適な技術（またはその組み合わせ）を選択し、理由を説明してください：
- リアルタイムのチャットアプリケーション
- ユーザー数: 10万人同時接続
- メッセージの永続化が必要
- 既読管理機能あり
ヒント
- リアルタイム配信: Redis Pub/Sub または ninda イベント
- メッセージ永続化: PostgreSQL または Kafka
- 既読管理: Redis（高速な状態更新）または ninda（パターンマッチ）
- スケーラビリティ: 10万同時接続にはRedis Clusterが有利
- ハイブリッド構成を検討: Redis（リアルタイム） + PostgreSQL（永続化）
問題24-2: 移行計画
既存のRedisベースのタスクキューをnindaに移行する場合の手順と注意点を検討してください。
ヒント
- 段階的移行: 新規タスクのみninda、既存はRedisで処理
- APIラッパーを作成して切り替えを容易に
- パターン設計: Redisのキー構造をnindaのタプル構造にマッピング
- 並行稼働期間を設けてテスト
- ロールバック計画を用意
- 監視・アラートの移行も忘れずに
問題24-3: ハイブリッド設計
オンラインゲームのバックエンドで、ninda + PostgreSQL + Redisを組み合わせたアーキテクチャを設計してください。
ヒント
- PostgreSQL: プレイヤーデータ、アイテム、ランキング（永続データ）
- Redis: セッション、リアルタイム状態（位置、HP等）、キャッシュ
- ninda: マッチメイキング、ゲームルーム管理、イベント処理
- 役割分担: 永続 vs 一時 vs 協調 で技術を選択
- スケーリング: ゲームサーバーごとにnindaノード、共有データはRedis Cluster