今日のゴール

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

前回: パフォーマンスチューニング | 目次 | 次回: 振り返りと今後の展望