先までは、"愛記"についての記載で、どのようにブロックチェーンSNSに組み込んで実装していけばよいのか、概念的なところからアプローチ方法を記載していった。概念設計としてはひとまず終えた。次は、フェデレーションモデル全体の基本設計といえるところまで、基本設計書に着手できるようなところまで、概念を具体化していきたい。そして、それにつながるDApps側である「愛記システム」を、Pythonプログラムで開発していきたい。
愛の行動のPL,BSを決算書として、個人単位、市町村単位、で公表するような愛記システムというものを考えている。愛の行動のデータベースはブロックチェーンのプログラムであり、日々の愛の行動による愛貨の移動を決算書にまとめていきたい。なお、市町村のブロックチェーンのプログラムは以前にも記載している。その市町村のブロックチェーンのプログラムにつながる愛記システムを、DApps側であるPythonプログラムとして設計したい。その場合、基本設計をどのような手順で進めていけばよいか、詳しく見ていこう。
愛記システムを設計するための基本手順を以下に示す。このシステムは、Pythonを用いて市町村のブロックチェーンと連携し、個人および市町村単位での愛の行動のデータを収集、記録し、決算書（PL、BS）として公表するものである。
基本設計のステップ
- 要件定義
- アーキテクチャ設計
- データベース設計
- API設計
- ブロックチェーンインターフェース
- 決算書の生成
- フロントエンド開発
- テストとデプロイ
基本設計の各ステップを順番に進めることで、ブロックチェーンとDAppsとして繋がる「愛記システム」の詳細な設計が可能になる。各ステップでは、関係者との協議やレビューを通じて設計内容を確定していくことが重要である。
1．要件定義
まず、基本設計の最初のステップである要件定義をしていきたい。どのような機能が必要か、どのような問題を解決するのかを洗い出したい。要件定義はシステム設計の最初の重要なステップであり、システムが解決するべき問題と、必要な機能を明確に定義するプロセスである。以下に、愛記システムのプログラムに必要な機能と解決すべき問題を列挙してみよう。
機能要件
-
愛の行動の記録
-
愛貨の移動の記録
-
決算書の生成
-
個人および市町村単位でのデータの集約
-
データのブロックチェーンへの記録と取得
-
愛貨の管理
-
ユーザー管理
-
通知機能
-
レポート機能
-
ダッシュボード
非機能要件
-
セキュリティ
-
可用性
-
パフォーマンス
-
スケーラビリティ
-
ユーザビリティ
-
コンプライアンス
解決すべき問題
-
透明性と信頼性の確保
-
データの一元管理
-
愛の行動の促進
-
評価制度の確立
-
データのセキュリティとプライバシーの保護
これらの要件を基に、愛記システムの基本設計を進めていくことが重要である。次のステップでは、これらの要件を具体的なアーキテクチャ設計に反映していくことになる。まずは、要件定義の解決すべき問題を一つずつクリアにしていきたい。
データの一元管理
愛記システムにおけるデータの一元管理は、データの収集、統合、保存、アクセス制御、およびバックアップを適切に行うことが重要である。以下に、これを実現するための設計を示す。
1. データ収集
・タイミング:
-
ユーザーが愛の行動を記録したとき
-
愛貨の移動が発生したとき
-
定期的な集計およびレポート生成時
・データの種類:
-
愛の行動データ（行動の内容、日時、場所、関与者）
-
愛貨の移動データ（送信者、受信者、金額、移動日時）
-
決算データ（収支、資産、負債）
-
ユーザーデータ（ユーザーID、プロフィール、認証情報）
-
市町村データ（市町村ID、名前、地理情報）
・方法:
-
各種データを専用のAPIエンドポイントを通じて収集
-
フォーム入力、スキャン、GPSデータなどのユーザーインターフェースからの入力
2. データ統合
・タイミング:
-
リアルタイムでのデータ入力時
-
定期的なバッチ処理（例: 毎日夜間）
・データの種類:
-
各データソースから取得した生データを統合データベースに変換
・方法:
-
ETL（Extract, Transform, Load）プロセスを使用して、異なるフォーマットのデータを統合
-
リアルタイムデータのストリーム処理（例: Kafkaなどのデータストリーミングプラットフォーム）
3. データ保存
・タイミング:
-
データ収集時
-
データ統合後
・データの種類:
-
統合データベース（例: MongoDB、PostgreSQL）
-
ブロックチェーンデータ
・方法:
-
各データベースに適切にインデックスを設定し、効率的なデータ格納を実現
-
ブロックチェーンに重要データをハッシュ化して記録、ハッシュのみをオンチェーンに保存し、詳細データはオフチェーンに保存
4. アクセス制御
・タイミング:
-
データアクセスリクエスト時
・データの種類:
-
ユーザー認証情報
-
アクセス制御リスト（ACL）
・方法:
-
JWT（JSON Web Tokens）を使用してユーザー認証を行い、各APIリクエストの認証と認可を実施
-
ユーザーごとにアクセス権限を設定し、アクセス制御リストで管理
-
RBAC（Role-Based Access Control）を導入し、役割ごとにアクセス権限を定義
5. データのバックアップとリカバリ
・タイミング:
-
定期的なバックアップ（例: 毎日、毎週）
-
システム障害発生時
・データの種類:
-
全データベースのスナップショット
-
ブロックチェーンデータ
・方法:
-
定期的なバックアップスケジュールを設定し、バックアップをクラウドストレージやオフサイトストレージに保存
-
自動バックアップと手動バックアップの両方をサポート
-
データリカバリ計画を策定し、定期的にリカバリテストを実施
データのバックアップとリカバリの設計
データのバックアップとリカバリは、システムの信頼性と可用性を確保するために非常に重要である。以下に、データのバックアップとリカバリの詳細な設計を示す。
1. バックアップのタイミング
- 定期的なバックアップ: 毎日深夜、毎週末
- システム障害発生時: 障害発生後速やかにバックアップ実施
2. データの種類
- 全データベースのスナップショット
- MongoDBデータ
- PostgreSQLデータ
- ブロックチェーンデータ
- ブロックデータのバックアップ
3. バックアップの方法
- スケジュール設定: 定期的なバックアップスケジュールを設定
- クラウドストレージ: Amazon S3やGoogle Cloud Storageなど
- オフサイトストレージ: 物理的に別の場所にデータを保管
4. リカバリ計画
- 自動バックアップ: バックアップスクリプトを自動実行
- 手動バックアップ: 管理者による手動バックアップ
- リカバリテスト: 定期的にリカバリプロセスのテストを実施
バックアップの実装例
1. MongoDBバックアップ
・backup_mongo.sh:
#!/bin/bash
# MongoDBバックアップ
BACKUP_DIR="/backup/mongo"
DATE=$(date +%Y%m%d%H%M)
BACKUP_PATH="$BACKUP_DIR/mongo_backup_$DATE"
# バックアップディレクトリが存在しない場合、作成
mkdir -p $BACKUP_DIR
# MongoDBのデータをバックアップ
mongodump --out $BACKUP_PATH
# クラウドストレージにアップロード（例：AWS S3）
aws s3 cp $BACKUP_PATH s3://your-bucket-name/mongo-backups/
# 古いバックアップの削除（30日以上前のバックアップを削除）
find $BACKUP_DIR -type d -mtime +30 -exec rm -rf {} \;
2. PostgreSQLバックアップ
・backup_postgres.sh:
#!/bin/bash
# PostgreSQLバックアップ
BACKUP_DIR="/backup/postgres"
DATE=$(date +%Y%m%d%H%M)
BACKUP_FILE="$BACKUP_DIR/postgres_backup_$DATE.sql"
# バックアップディレクトリが存在しない場合、作成
mkdir -p $BACKUP_DIR
# PostgreSQLのデータをバックアップ
pg_dump -U your_user -h localhost -F c -b -v -f $BACKUP_FILE your_database
# クラウドストレージにアップロード（例：AWS S3）
aws s3 cp $BACKUP_FILE s3://your-bucket-name/postgres-backups/
# 古いバックアップの削除（30日以上前のバックアップを削除）
find $BACKUP_DIR -type f -mtime +30 -exec rm -f {} \;
3. ブロックチェーンデータのバックアップ
・backup_blockchain.sh:
#!/bin/bash
# ブロックチェーンデータのバックアップ
BLOCKCHAIN_DIR="/path/to/blockchain/data"
BACKUP_DIR="/backup/blockchain"
DATE=$(date +%Y%m%d%H%M)
BACKUP_PATH="$BACKUP_DIR/blockchain_backup_$DATE.tar.gz"
# バックアップディレクトリが存在しない場合、作成
mkdir -p $BACKUP_DIR
# ブロックチェーンデータを圧縮してバックアップ
tar -czvf $BACKUP_PATH $BLOCKCHAIN_DIR
# クラウドストレージにアップロード（例：AWS S3）
aws s3 cp $BACKUP_PATH s3://your-bucket-name/blockchain-backups/
# 古いバックアップの削除（30日以上前のバックアップを削除）
find $BACKUP_DIR -type f -mtime +30 -exec rm -f {} \;
4. バックアップスケジュールの設定
・crontab:
# 毎日深夜2時にMongoDBバックアップ
0 2 * * * /path/to/backup_mongo.sh
# 毎週日曜日深夜3時にPostgreSQLバックアップ
0 3 * * 0 /path/to/backup_postgres.sh
# 毎日深夜4時にブロックチェーンデータのバックアップ
0 4 * * * /path/to/backup_blockchain.sh
5. データリカバリの設計
-
MongoDBリカバリ
mongorestore --drop --dir /path/to/backup/mongo_backup_<DATE>
-
PostgreSQLリカバリ
pg_restore -U your_user -h localhost -d your_database /path/to/backup/postgres_backup_<DATE>.sql
-
ブロックチェーンデータリカバリ
tar -xzvf /path/to/backup/blockchain_backup_<DATE>.tar.gz -C /path/to/blockchain/data
プログラム内でのバックアップトリガー
Pythonコードでシステム障害発生時にバックアップをトリガーする例:
import subprocess
def trigger_backup():
try:
subprocess.run(["/path/to/backup_mongo.sh"], check=True)
subprocess.run(["/path/to/backup_postgres.sh"], check=True)
subprocess.run(["/path/to/backup_blockchain.sh"], check=True)
print("Backup triggered successfully.")
except subprocess.CalledProcessError as e:
print(f"Backup failed: {e}")
# システム障害発生時にバックアップをトリガー
trigger_backup()
この設計により、データのバックアップとリカバリが効率的かつ確実に実施されるようになる。定期的なバックアップと障害発生時の即時バックアップにより、データの保全性を高めることができる。
いかがであろうか、今回はバックアップとリカバリーについて記載した。定期的なバックアップと障害発生時の即時バックアップにより、データの保全性を高めることができるのだから、このように設計していくと良いのだろう。