# Dfinity 運用テスト・設計 ###### tags: `Dfinity` 実運用想定 なぜテストするのか？ 調査項目 実際に行うテスト計画 A. 継続的なアクセスによるパフォーマンスの低下を確認する B. 負荷を大量にかける負荷テストによるパフォーマンスの低下を確認する テスト結果 A. 平均タイム 速度 メモリの上昇 B. 1秒間に100リクエストを送信。 1秒間に200リクエストを送信 1秒間に50リクエストをし続けた送信した場合 リカバリプラン 実運用想定 実運用を想定したイメージを記載する。 Dfinityをオペレータ =ノードとして利用 複数立てる → 10個以上で実験としては役立つかと Dfinityをオペレータとして利用するときは複数立てる？一つにする？ Dfinityを分散ストレージとして利用 各データごとに立てる。 → 最低4つ なぜテストするのか？ サービスを安定して運用するため システムを常に正常に保つため → 他サービスへの影響大 サービスの問題点を早期に見つけ、設計レベルからの改善に繋げる 調査項目 Dfinityはログ取得できなさそう？監視を考える必要がありそう。 Dfintyで担保されているところの確認 ■Dfinityへの調査項目 1週間以上継続して運用して、データの更新、取得が正しくできているか その更新、取得のパフォーマンスに問題はないか。 Dfinityで監視、バックアップ、ログ管理等ができるかどうか。 監視 エラーをどこかに吐いて取得するクエリを作成するとか。 memoryのメトリクスを取得するクエスを作成して、外部からポーリングする。 awsで定期的に上記のログとメトリクスを取得して、cloudwatchからGrafanaに流す感じで監視する。 継続性、耐障害性、回復性、性能、拡張性、セキュリティインシデント対応、リカバリプラン(レベル別)、ノードのアップデートしたい時(機能アップデートおよびパッチ)、開発環境の想定。 ↑はリカバリプランもほぼなさそう。 実際に行うテスト計画 長期運用テストと負荷テストの２つを行う。 A. 継続的なアクセスによるパフォーマンスの低下を確認する パフォーマンス コスト AWS Lambdaで定期的にEthescanをスクレイピングしてブロックデータをどんどんcanisterに保存する。被っていてもいいのでどんどん取得する。ユニークである必要はない。逐次Canisterからデータを取得して、取得にかかった時間とともにdynamoかgoogle docs spreadsheetに記載する。パフォーマンスの低下はないか、どこかでエラーが起きないのか(canisterが落ちる等)を確認する。 B. 負荷を大量にかける負荷テストによるパフォーマンスの低下を確認する パフォーマンス コスト 並行で連続的に更新処理と取得処理を断続的に投げてパフォーマンスを計測する。 秒間100リクエストをcanisterに送信する。 テスト結果 A. 平均タイム 更新系処理: 6.3秒 取得系処理: 1.9秒 これがほぼ限界でこの数字に収束していくと思われる。 基本的にCaniterへのメッセージは、キューから順番に処理される。 canister側では処理順を遵守しながら並行で処理できる。 速度 // Average schedule=# SELECT AVG("putSeconds") FROM "RequestRegister"; avg -------------------- 6.3658745554477605 (1 row) schedule=# SELECT AVG("getSeconds") FROM "RequestRegister"; avg ------------------- 1.944398896504168 (1 row) // List putSeconds | getSeconds ------------+------------ 4.43 | 2.79 8.86 | 2.77 6.73 | 1.17 5.01 | 2.26 4.8 | 2.34 5.81 | 2.91 5.97 | 1.8 11.98 | 2.26 9.89 | 2.78 5.1 | 3.43 9.88 | 2.72 5.66 | 3.24 4.6 | 2.73 4.62 | 3.22 4.46 | 2.26 8.79 | 3.18 4.15 | 3.01 6.23 | 1.53 9.24 | 3.09 9.16 | 2.08 5.05 | 2.59 5.01 | 2.19 3.48 | 2.19 8.69 | 0.63 5.58 | 2.57 13.35 | 2.09 4.73 | 1.63 6.11 | 1.05 5.17 | 1.54 5.9 | 1.5 8.96 | 2.8 7.36 | 1.22 7.42 | 1.66 13.26 | 2.27 13.9 | 3.06 10.66 | 3.27 11.13 | 1.55 7.81 | 2.77 4.73 | 4.15 10.83 | 3.17 5.31 | 4.09 5.18 | 3.36 11.6 | 4.4 10.63 | 3.73 4.79 | 2.22 7.24 | 2.2 7.72 | 4.08 5.66 | 2.99 8.33 | 1.83 7.46 | 5.52 (50 rows) メモリの上昇 // 始める前 Memory Size: Nat(1501901) = 1.5MB Balance: 3_899_997_435_390 Cycles // 12時間後(50000データを入れた) Memory Size: Nat(13626061) = 13MB Balance: 3_788_613_917_141 Cycles 大体4万データが10MBとすると。 400万データが1GBになる。 今回は4GBがMAXなので、概算的には1600万データ数まで格納できる。 B. 1秒間に100リクエストを送信。 100個のGETリクエストは全部で16秒で返却できる。 1秒間に200リクエストを送信 503サーバーレスポンスエラーなる。秒間で受け付けれるリクエスト数の制限はある。 1秒間に50リクエストをし続けた送信した場合 実際にリクエストを受け取ってはくれるが、処理速度がかなり遅くなる。 50個のリクエストが最短10秒だったが、70秒まで遅くなる。この場合の落ち着く秒数は70秒。 リカバリプラン canisterに負荷がかかった場合の対応が現状存在しなさそう。