東証システム障害考

 ディスクの応答なしは判断が難しい。まるっきりダメなのか、処理が遅延しているのか。ネットワークならタイムアウトという設定があり、無通信の一定時間でエラーとなるが、ディスクのI/Oについては総合的判断が必要だ。

ストレージのメモリは、冗長の切り替えというより、複数搭載しておりその縮退利用となる。一部のユニットが故障したからといってストレージ全体の切り替えは考慮されていない。故障したユニットの切りはなしとなる。

ストレージは共有であるから、サーバの切り替えのようには判断できない。また対向先にも切り替えは影響する。複数のシステムが搭載している切り替えとは判断が難しい。

メモリは、エラーとなる前に書き込み　読み込みの　試行回数を確認しており、一定回数を超えるとエラーや故障となる。予兆は掌握できる場合がある。

さながら発生日が10月1日ということから、新規アカウントや銘柄の搭載作業のミスという可能性もあると思う。ハード故障だけが原因ではタイミングが良すぎる。

ストレージ・プロセッサーのワーキングメモリと今回言われているストレージのメモリは別であると理解しているが如何であろうか。ディスクI／Oのためのキャッシュメモリと理解している。

1部外者の感想だ。

後日、ストレージのメモリ故障が原因のハングアップで待機系ストレージに切り替わらなかったというが、故障は明示的メッセージが出るが、ハングアップは周辺がタイムアウトするまで無応答だ。この値を短くすると、時間がかかる処理の応答の際このメッセージが出るし、処理がかかる時間は予想できない。切り替わらない設定でなく、設計されていなかった。が正しい表現ではなかろうか。　しかし、7時に発生し、8時に判断して周知し始めたのは、早期判断を下し素晴らしと思う。これは人的体制のことだ。　7時は、オンライン開始のための前処理を開始するタイミングだ、10月1日の朝となるとこのタイミングたからこそ実施される何かがあったのではと想像してしまう。

あたらしいブロックチェーン10

 こんな例はどうだろうか？ある特許情報で見かけた。

「ブロックチェーンのブロックの自ブロックのハッシュを格納する」と。

NG例。ブロック1にブロック1のハッシュを格納するということ。下図において。

2つの値が生成される。

１.自ブロックのハッシュを格納する前のブロックヘッダーのハッシュ

2.自ブロックのハッシュを格納後のブロックヘッダーのハッシュ

1と2では値が違う、事後検算する際には、2の値が返される。しかしブロックヘッダーに格納されている値は、1の値だ。よってブロックチェーンは成立しない。

例えるならブロックチェーンのハッシュ値は、ブロックのサイズ値みたいなもの、サイズを計測してそのブロックにサイズの値を追加したら、サイズが変わってしまう。それだは初めに測ったファイルサイズの意味がない。

次のブロックヘッダーに格納するのが現行技術であり問題ない。当たり前だけど。

あたらしいブロックチェーン9

Block Height０はジェネシスブロック

Block Heightとは

通常のブロックチェーンにおいて、構成するブロックは1つ前のブロックのハッシュ値を格納している、ブロックが積み上がるように記録されている。Block Heightという単位はこの積み上がったブロックの高さブロックの総数。また、一番最初に生成されたブロックを0とし、対象とするブロックが何番目のブロックとして生成されたのかを指している。

あたらしいブロックチェーン8

「従来の」ブロックチェーンのヘッダーについて説明する。ヘッダーに格納されているデータにおいて、あたらしいブロックチェーンでは、2つの親ブロックのハッシュ値を格納している点が従来のブロックチェーンと異なる。（従来は1つ）

この説明は、ジェネシスブロックにも基本該当する。（ジェネシスブロックゆえの一部例外もある） 

●ブロックの構造

ブロックは、大きく分けて２種類のデータで構成されている。

１、そのブロックに関する情報（メタデータ）を含むブロックヘッダ

２、そのブロックに含まれるトランザクションのリスト

ブロックヘッダ詳細

サイズ	フィールド名	説明
4バイト	Version	ソフトウェア／プロトコルのバージョン
32バイト	Previous Block Hash	親ブロック（１つ前のブロック）のハッシュ値
32バイト	Merkle Root	ブロック内の全トランザクションに対するマークルツリーのルートハッシュ
4バイト	Timestamp	ブロックの生成時刻
4バイト	Difficulty Target	ブロック生成時のproof of workのdifficulty
4バイト	Nonce	proof of workで用いるカウンタ

●直前のブロックのハッシュ値

ハッシュ値とは規則性のない固定長の値を吐き出す乱数のことです。

●マークルルート

マークルルートは先ほども解説したブロックヘッダに含まれる情報。これは、ブロック内の全てのトランザクションをまとめた要約値です。

●タイムスタンプ

ブロックの生成時刻。ブロックがいつ作られ、承認されたということがタイムスタンプとして生成される。

●ビッツ

マイニングの難易度を表すための表現方法。 ビッツを用いて算出される目標値をブロックヘッダのダブルハッシュの数値が下回った場合のみ、マイニングが成功する。

●ナンス

ナンスとは、ワンタイムトークンと言われ、リクエストが正当なものであるかどうかを見極めるためのものとして、ブロックチェーン上で、マイニングの際に使用されています。

あたらしいブロックチェーン７

取引データをまとめる、マークルツリー・マークルルート　の概念を説明する。ブロックヘッダーにどのようにデータを格納、または連携させているか説明している。

マークルツリーの基本は2つのデータを1つにまとめる。AとBという2つのデータがあるとする。Aのハッシュ、Bのハッシュをそれぞれ計算します。このAのハッシュ、Bのハッシュそれぞれをまとめた値のハッシュが頂点の値になる。

マークルツリーが実際に使われる場合は、たいてい複数段のツリー構造で構成されており、2段、3段と2個づつハッシュをまとめていきます。最終的に得られた頂点のハッシュ値はマークルルートと呼びます。 

ゼロリスクを求めすぎない

 マスクをした方がいい。しないのは非常識。コロナ禍の東京からの帰省とか　当たり前や常識といえることがある。しかし、人によっては事情がありそうできない場合もある。当たり前のことを声高らかに言うことは容易だ、社会においては、そこから漏れる人もいる、日本ではこうだけど海外では違うとか「常識」もさまざまだ　。また他人に強制するものでもない。多様化の時代、年代による常識の差、国や地域。過敏になりすぎるのも問題だ。

プロジェクトを推進していく上でリスクは排除していいのは当たりまえではある。しかしグループ間、担当者間、会社間においては、ゼロリスクを追究しすぎるとギクシャクする。「信用していないのか」「じゃあかってにしろ」的な関係になってしまう場合もある。それがまた大きなリスクとなる。システムに対するリスクと人間に関するリスクはマネージメントのポリシーが異なる。

虻蜂（あぶはち）取らず

 虻蜂（あぶはち）取らず　ある大臣と役人との間でつかわれた言葉だ。私は、数十年生きてきたが聞いたことも使ったこともなかった言葉だ。
興味があったので由来を検索してみた。
場所は、蜘蛛の巣でおこった。主役は当然蜘蛛だ。蜘蛛の巣に虻と蜂がかかった。蜘蛛はもがく虻と蜂の間を右往左往して結局両方取り逃がしてしまう。という話だ。同様の内容の故事はあるがこの例えは、欲を出して結果を出せない的要素が強調されているようだ。
蛇足だが、虻も蜂も似ている。虻は刺さないが蜂は刺す。こういうことが関連するのかな。と初めて聞いたときはそう思った。まったく関係なかった。（笑）