Takanobu ()
とりあえず、トピ立てました。
■サーバ
aws m3.large (CPU:2core , メモリ:7GB)
インスタンス(4台)
東京 1a,1b シンガポール 1a,1b
mijin(java) はメモリ4GBで起動
■整合性確認
ユーザ数:100,000 部門数:1
クライアントスレッド数:1
mijin4台にラウンドロビンで接続、４台のうち２台を定期的にリブート
■性能確認
ユーザ数:100,000 部門数:1024
クライアントスレッド数:10
■考察
・xem の残高不足でエラーが 数回発生
→設定で手数料を 0 にすることが可能
・取引日時、送信者、受信者、取引額が同じ場合に重複取引としてニュートラルが返される
→mijin 側で重複取引を防止する機構が働いた
・mijin サーバのロードアベレージが 2 を超えることは無かった
・性能
多カード対１部門の構成で分間約 3,000 取引、多カード対多 部門の構成で分間約 3,800 取引
公称値は秒間数万との報告もあり、今回の結果は低い結果(最適化ができ ていなかったことなどが考えられる)
レイテンシーが高い環境でのテストは奇妙な結果となった。
→NEM Core Client API 等にmijin サーバに必要以上の負荷を掛けない仕組み（SleepFuture）
・APサーバ側トラブル
mijin へのリクエストデータを作成するのにハッシュの計算や署名を行うためにＣＰＵパワーが使われた
ランタイムエラーが発生した。発生率は極めて低い
対象の取引の確認リクエストを行うと、クライアント側でランタイムエラーが高確率で発生
■サーバ
aws m3.large (CPU:2core , メモリ:7GB)
インスタンス(4台)
東京 1a,1b シンガポール 1a,1b
mijin(java) はメモリ4GBで起動
■整合性確認
ユーザ数:100,000 部門数:1
クライアントスレッド数:1
mijin4台にラウンドロビンで接続、４台のうち２台を定期的にリブート
■性能確認
ユーザ数:100,000 部門数:1024
クライアントスレッド数:10
■考察
・xem の残高不足でエラーが 数回発生
→設定で手数料を 0 にすることが可能
・取引日時、送信者、受信者、取引額が同じ場合に重複取引としてニュートラルが返される
→mijin 側で重複取引を防止する機構が働いた
・mijin サーバのロードアベレージが 2 を超えることは無かった
・性能
多カード対１部門の構成で分間約 3,000 取引、多カード対多 部門の構成で分間約 3,800 取引
公称値は秒間数万との報告もあり、今回の結果は低い結果(最適化ができ ていなかったことなどが考えられる)
レイテンシーが高い環境でのテストは奇妙な結果となった。
→NEM Core Client API 等にmijin サーバに必要以上の負荷を掛けない仕組み（SleepFuture）
・APサーバ側トラブル
mijin へのリクエストデータを作成するのにハッシュの計算や署名を行うためにＣＰＵパワーが使われた
ランタイムエラーが発生した。発生率は極めて低い
対象の取引の確認リクエストを行うと、クライアント側でランタイムエラーが高確率で発生
Tanugami ()
補足：SleepFuture
http://www.nem.ninja/org.nem.core/or...eepFuture.html
補足：朝山所長による以下記事への見解
アララのブロックチェーン報告書から、RDBMSと比べた利点・欠点を読み解く
http://itpro.nikkeibp.co.jp/atcl/column/14/346926/101100657/?n_cid=nbpitp_twcm
朝山所長：
mijinノードはメモリ上でリアルタイムに残高照会できますから、
コンセンサスが取れている限りリクエストが来た時点でダブルスペンドは防げますので、
ブロックに書き込まれるのを待つ必要がありません。
アララ社が課題としたのは、あえてブロックへの書き込み確認を持って確定とした場合、
そこに処理に一定の工数と処理コストがかかるとした点で、
我々はプライベート利用のmijinでは殆どの場合リクエスト受領時で確定とし、
時に確認するよう普段は推奨しています。
もう一点APサーバーに負荷、とあるのは、
電子署名には5msもあれば通常のサーバーでも問題なく、
今回の実証に使用したサーバーがレポートにあるように本当に安価、
であったことがひとつの原因かと思われます笑。
実際に負荷が問題ないサーバーにアップグレードしたとしても激安環境でした。
mijin/NEMコア開発者といつも話しておりますが、
すでにもうmijinではブロックタイムは、利用者の都合に合わせた存在に過ぎず、
99.99%以上はメモリ上で決済が完結したとしてもよい機構に進化しています。
まだまだ、初期ブロックチェーンの呪縛からは逃げ切れていないようです。
コスト削減にも懸念かのような表現もありますが、
当のアララ社のレポートでは実際に処理に必要なサーバー等の試算をした上で、
結論として現時点の簡単な実装でも7割以上の削減が可能、とあります。
第三者として提供したため設定も電子マネー用に特別しておりませんので、振り幅はまだまだあります。
私の言葉だけでは何ですから、
実証テストをして頂ける企業様にはクラウド上のmijinテスト環境をご用意いたしますので、
是非ご自分の目でお確かめになって頂きたい。
実際にはダブルスペンドも、ソフトフォークも、意図的に発生するのも困難で、
発生させたとしても正しいチェーンの選択が容易です。
mijinては、もう本当にブロックタイムの設定は「趣味」になっています。
そもそもビットコインの10分も最初の決め打ちで余り意味がないでしょう。
既に旧バージョンのmijinでも、
数百万アカウントの残高紹介をメモリで完結した某銀行の実験もありましたから、
ブロックタイム待ちには本当にもう意味が無く、更に言うと設定は可変で自由です笑
ブロックチェーンの欠点は、一定時間未来への猶予を与えないと、
リバースされる可能性のコストが許容内に収まらない、という点であり、
プライベート型はDecentralizationの妥協を代償にその時間を限りなく
ゼロに近づけるのが目的です。
「ロック＆リリースによるリニアなデータ記録が常識である時代は終わるのです」
http://www.nem.ninja/org.nem.core/or...eepFuture.html
補足：朝山所長による以下記事への見解
アララのブロックチェーン報告書から、RDBMSと比べた利点・欠点を読み解く
http://itpro.nikkeibp.co.jp/atcl/column/14/346926/101100657/?n_cid=nbpitp_twcm
朝山所長：
mijinノードはメモリ上でリアルタイムに残高照会できますから、
コンセンサスが取れている限りリクエストが来た時点でダブルスペンドは防げますので、
ブロックに書き込まれるのを待つ必要がありません。
アララ社が課題としたのは、あえてブロックへの書き込み確認を持って確定とした場合、
そこに処理に一定の工数と処理コストがかかるとした点で、
我々はプライベート利用のmijinでは殆どの場合リクエスト受領時で確定とし、
時に確認するよう普段は推奨しています。
もう一点APサーバーに負荷、とあるのは、
電子署名には5msもあれば通常のサーバーでも問題なく、
今回の実証に使用したサーバーがレポートにあるように本当に安価、
であったことがひとつの原因かと思われます笑。
実際に負荷が問題ないサーバーにアップグレードしたとしても激安環境でした。
mijin/NEMコア開発者といつも話しておりますが、
すでにもうmijinではブロックタイムは、利用者の都合に合わせた存在に過ぎず、
99.99%以上はメモリ上で決済が完結したとしてもよい機構に進化しています。
まだまだ、初期ブロックチェーンの呪縛からは逃げ切れていないようです。
コスト削減にも懸念かのような表現もありますが、
当のアララ社のレポートでは実際に処理に必要なサーバー等の試算をした上で、
結論として現時点の簡単な実装でも7割以上の削減が可能、とあります。
第三者として提供したため設定も電子マネー用に特別しておりませんので、振り幅はまだまだあります。
私の言葉だけでは何ですから、
実証テストをして頂ける企業様にはクラウド上のmijinテスト環境をご用意いたしますので、
是非ご自分の目でお確かめになって頂きたい。
実際にはダブルスペンドも、ソフトフォークも、意図的に発生するのも困難で、
発生させたとしても正しいチェーンの選択が容易です。
mijinては、もう本当にブロックタイムの設定は「趣味」になっています。
そもそもビットコインの10分も最初の決め打ちで余り意味がないでしょう。
既に旧バージョンのmijinでも、
数百万アカウントの残高紹介をメモリで完結した某銀行の実験もありましたから、
ブロックタイム待ちには本当にもう意味が無く、更に言うと設定は可変で自由です笑
ブロックチェーンの欠点は、一定時間未来への猶予を与えないと、
リバースされる可能性のコストが許容内に収まらない、という点であり、
プライベート型はDecentralizationの妥協を代償にその時間を限りなく
ゼロに近づけるのが目的です。
「ロック＆リリースによるリニアなデータ記録が常識である時代は終わるのです」
Takanobu ()
m3.large の選択について。
性能評価においてはm3.largeもありかと思いますが、集中アクセスが散見されるような条件だとt2シ リーズも選択肢になるのかなと思いました。
アクセスが増えるとメモリを食うのか、CPUパワーを先に消費するのか見極めたいところでもあります。
インスタンスについては別クラウド会社も混ぜて接続するのが理想でしょうか。
全サーバが同時にダウンしていることはほとんどありませんが、awsサイトにログインできない、なんてこと は時々あります。（数秒単位の話をしてますよ）
整合性確認
クライアントからの接続は、やはりラウンドロビンになりますでしょうか。ELB使うとそこが単一障害点にな りそうですし。
接続先mijinが落ちてた場合の振り分けアルゴリズムが必要ですね。
性能確認
クライアントスレッド:10 とありますが、サーバ1台で生成？少しクライアントのパワーが足りなかったような気もします。
あるいはコネクション数の限界に達していたかも、somaxconn とか ulimit の値が気になります。
送信情報が同じだと重複取引としてニュートラルが返される。→このフォーラム住人なら既知の仕様ですね。
公称値は秒間数万との報告もあり→これはカタパルト？
性能評価においてはm3.largeもありかと思いますが、集中アクセスが散見されるような条件だとt2シ リーズも選択肢になるのかなと思いました。
アクセスが増えるとメモリを食うのか、CPUパワーを先に消費するのか見極めたいところでもあります。
インスタンスについては別クラウド会社も混ぜて接続するのが理想でしょうか。
全サーバが同時にダウンしていることはほとんどありませんが、awsサイトにログインできない、なんてこと は時々あります。（数秒単位の話をしてますよ）
整合性確認
クライアントからの接続は、やはりラウンドロビンになりますでしょうか。ELB使うとそこが単一障害点にな りそうですし。
接続先mijinが落ちてた場合の振り分けアルゴリズムが必要ですね。
性能確認
クライアントスレッド:10 とありますが、サーバ1台で生成？少しクライアントのパワーが足りなかったような気もします。
あるいはコネクション数の限界に達していたかも、somaxconn とか ulimit の値が気になります。
送信情報が同じだと重複取引としてニュートラルが返される。→このフォーラム住人なら既知の仕様ですね。
公称値は秒間数万との報告もあり→これはカタパルト？
Tanugami ()
補足：SleepFuture
http://www.nem.ninja/org.nem.core/or...eepFuture.html
補足：朝山所長による以下記事への
LHJ ()
Takanobu さんの「AWS m3.large」の客観的な評価は正しいと思います。
ただ、インスタンスの性能（スペックアップではなく帯域幅と通信処理性能）を変更すれば対金融機関でも使え ます。
Azure よりも数倍まともです。Azure は使い物になりません。LHJさんは鬼詳しいのでこれは断言します。
Google Cloud （コンテナー技術）での検証をLHJさんは詳細に行ったことはありませんが、ちょっと厳しいかな？Webサ ービスでは良いかもしれませんが金融レベルでは未知数です。検証する体力（お金）がないでござる orz…。
で、結局クラウド（プライベートクラウドも含め）は使えないやん！と言う SIer や経営層は、大金払って IBM のメインフレームでも使ってくださいとしか言えませんね。それでも SLA 100% ではないので、SEさんは24時間365日、監視アラートの電話に震えて、熾烈な環境で頑張るしかないでし ょう。
無論、LHJさんはお断りですね。AWSを使います（笑）
ただ、インスタンスの性能（スペックアップではなく帯域幅と通信処理性能）を変更すれば対金融機関でも使え ます。
Azure よりも数倍まともです。Azure は使い物になりません。LHJさんは鬼詳しいのでこれは断言します。
Google Cloud （コンテナー技術）での検証をLHJさんは詳細に行ったことはありませんが、ちょっと厳しいかな？Webサ ービスでは良いかもしれませんが金融レベルでは未知数です。検証する体力（お金）がないでござる orz…。
で、結局クラウド（プライベートクラウドも含め）は使えないやん！と言う SIer や経営層は、大金払って IBM のメインフレームでも使ってくださいとしか言えませんね。それでも SLA 100% ではないので、SEさんは24時間365日、監視アラートの電話に震えて、熾烈な環境で頑張るしかないでし ょう。
無論、LHJさんはお断りですね。AWSを使います（笑）
LHJ ()
> インスタンスについては別クラウド会社も混ぜて接続するのが理想でしょうか。
マルチクラウドでできますよ。AWS のLBと、GoogleのLB（世界最強のLB）を組み合わせます。AWS のオートスケーリング機能は若干時間がかかるのは事実です。インスタンスの立ち上げに時間がかかりますので 。ゆえに最初から冗長構成（EC2を複数台稼働）してラウンドロビンをします。
Googleの凄いところは、オートスケーリング機能が恐ろしく早い。数秒でインスタンス（Googleで はコンテナーと言う）が起動します。ここがGoogle Cloud の凄いところです。アカマイ（CDN）を使う方法もありますが、お金がかかるのでサービス規模と予算に依存 します。
また、IIJ の GIO（クラウド）も凄いですよ。FX会社も採用しているクラウドです。国内のクラウド会社であれば IIJ でしょう。なお、LHJさんは IIJ の中の人ではありませんが、IIJ 以上の国内クラウド企業はいませんね。これは断言します。IIJ はなんといっても The Internet の第一人者であり、日本の The Internet を支え、USで上場してから日本で上場した歴史あるIT企業です。バックボーン（WAN）の世界で知らない方はおりません。
ご参考になれば幸いです（にっこり）
マルチクラウドでできますよ。AWS のLBと、GoogleのLB（世界最強のLB）を組み合わせます。AWS のオートスケーリング機能は若干時間がかかるのは事実です。インスタンスの立ち上げに時間がかかりますので 。ゆえに最初から冗長構成（EC2を複数台稼働）してラウンドロビンをします。
Googleの凄いところは、オートスケーリング機能が恐ろしく早い。数秒でインスタンス（Googleで はコンテナーと言う）が起動します。ここがGoogle Cloud の凄いところです。アカマイ（CDN）を使う方法もありますが、お金がかかるのでサービス規模と予算に依存 します。
また、IIJ の GIO（クラウド）も凄いですよ。FX会社も採用しているクラウドです。国内のクラウド会社であれば IIJ でしょう。なお、LHJさんは IIJ の中の人ではありませんが、IIJ 以上の国内クラウド企業はいませんね。これは断言します。IIJ はなんといっても The Internet の第一人者であり、日本の The Internet を支え、USで上場してから日本で上場した歴史あるIT企業です。バックボーン（WAN）の世界で知らない方はおりません。
ご参考になれば幸いです（にっこり）
Takanobu ()
確かにmijinではブロックを意識することはほとんどありませんね。
ただ、アカウント生成直後は注意が必要と感じています。
残高100円 のアカウントからの1円抜き差しは、たいして問題になりませんが、
残高0円のアカウントで1円を抜き差しすると、ときどき順序が違ってあれ？ってなります。
もちろん結果が狂うことはありません。エラーが返されて受け付けてくれなくなるだけです。
（-1円は存在しませんからね）
ただ、アカウント生成直後は注意が必要と感じています。
残高100円 のアカウントからの1円抜き差しは、たいして問題になりませんが、
残高0円のアカウントで1円を抜き差しすると、ときどき順序が違ってあれ？ってなります。
もちろん結果が狂うことはありません。エラーが返されて受け付けてくれなくなるだけです。
（-1円は存在しませんからね）
Tanugami ()
≧公称値は秒間数万との報告もあり→これはカタパルト？
現在、カタパルトは秒間1300程度とかなんとか 画像が公開されていましたね
https://forum.nem.io/t/stories-from-the-dev-front-diary/2641
現在、カタパルトは秒間1300程度とかなんとか 画像が公開されていましたね
https://forum.nem.io/t/stories-from-the-dev-front-diary/2641
Takanobu ()
おおぉ、すごいクラウドマスターですね。
今後の参考にさせていただきます！
今後の参考にさせていただきます！