読書会(データ指向アプリケーションデザイン)第6回議事録
[ 戻る ]
=================================================================
Java読書会BOF「データ指向アプリケーションデザイン」を読む会 第6回
=================================================================
.. csv-table:: 開催概要
"日時", "2021年03月27日 10:00 - 17:00"
"場所", "川崎市教育文化会館 第3会議室"
"出席者(敬称略)","高橋(徹)、高橋(智)、岩永、松永、遠藤、平山、吉本、岩室、加藤"
第8章 分散システムの問題
========================
8.2 信頼性の低いネットワーク
----------------------------
8.2.4 同期ネットワークと非同期ネットワーク
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
* 「回路が確立される」とあるが、回路より回線のほうがしっくりくる気がしないか？
* しかし回路のほうが通信品質をハードウェアで解決していることが強調されている感じがする
* 電話交換機も原理的には回路のつなぎ変えだし
* 英語では電話回線のことを "telephone circuit" とも言う
* 原書でも "circuit"
* ATM に関するこの脚注は、ATM はより良いものだったのに廃れたことを嘆いているようにも見える
8.3 信頼性の低いクロック
------------------------
* クロックって日本語にできないのだろうか？
* CPU 等のクロックと同義？ちょっと違うような
* 「クロックと時間」「時刻のクロック (time-of-day clocks)」・・・混乱してきた
* 時間的な刻み、的なことと考えればよいだろうか
8.3.1 単調増加のクロックと時刻のクロック
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
* IoT だとセンサーデータの時刻に何を使うのかが問題になる
* ゲートウェイやデバイスの時刻を取ると、インターネット不通時のデータがズレることがありうる
* クラウドの時刻を取ると、インターネット不通時からの再送信のデータが実態とズレる
* 両方記録しておいて活用用途に合わせて使い分けるのが良い
* 複数の CPU ソケットを持つマシンのタイマーの同期の問題は重要
* マルチコアでも起きるけれど、対策されていることも多い
* 省電力機構で CPU クロックが変わることがあり、それが本件に影響することもありうる
* nano time があてにならなくなる
8.3.2 クロックの同期と正確性
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
* NTP サーバーみんなどこ使っている？
* NICT とか mfeed とか
* うるう秒の扱いは難しい
* smearing は最近広がっている (Google Public NTP や Amazon Time Sync Service など)
* 原子時計の同期は大変そう、GPS の時計は米軍が管理しているらしい
* 複数の時刻ソース (原子時計ベースのサーバーや GPS など) を使って信頼度をあげている NTP サーバーもある
8.3.3 同期クロックへの依存
~~~~~~~~~~~~~~~~~~~~~~~~~~
* 既存の監視システムに時刻のズレを検知する仕組みとかあるのかな？
* 簡単に自作はできる (監視システムを作って運用している)
* 銀行のシステムでは日付は独自に管理し、その日の全ての処理が終わってから日めくり処理をするなどの工夫がみられる
* Spanner の TrueTime API は、信頼区間がわかったとしても、それに通信のラウンドトリップも考慮しないといけないよね？
8.3.4 プロセスの一時停止
~~~~~~~~~~~~~~~~~~~~~~~~
* HotSpot JVM の CMS といえば、最近 (JDK 14 で) 削除された
* たしかにサーバーでは、特にクラウドでは swap を作らないことが多い
* EC2 とかも最初はないし、Docker もデフォルトでオフ、Kubernetes も同じ
* プロセスを大量に起こしておきたい場合など特殊なケースでは swap は効果があるぞ
* メモリがなくなるとどうなるんだっけ？→ OOM Killer が色々なプロセスを殺しはじめる
* JVM はメモリ容量に柔軟にリミットをかけられるのがうれしい
* ``SIGSTOP`` なんて使う機会あるっけ？
* シェルスクリプトとかでシグナル番号間違えたとか？
* vi の終了方法が分からない初心者が適当にキーボード叩いて Ctrl + Z で終了できたとぬか喜びするパターンを聞いたことが...
* ノード単位で GC のタイミングをコントロール？そんな仕組みがもうあるのか？
* Java だったら JMX とか使って監視する？本当にできるのだろうか → 後日調査したい、参考文献も併せて調べてみよう (**宿題1**)
* フル GC を定期的にかけて、その間はロードバランサーでトラフィックがこないようにするとか
* Java の ``System.gc()`` って今も効果あるんだっけ、完全に無視する VM もあったような
* Java 11 で入った Epsilon を使えば GC なしランタイムが簡単に実現できるね
* 二重ポインタを使って stop-the-world を極限まで小さくするアプローチもあるよね
8.4 知識、真実、虚偽
--------------------
8.4.1 真実は多数決で決定される
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
8.4.2 ビザンチン障害
~~~~~~~~~~~~~~~~~~~~
* p.331 9行目「ビザンチンの将軍たちが他の **年** の将軍たちよりも・・・」は、「都市」の誤植と思われる
* NTT によると、宇宙線の影響で通信機器が年間3万件誤作動しているとのこと
* https://www.tokyo-np.co.jp/article/92902
* メインフレームの CPU などは放射線など当てて検査をしたり、シールドを施したりしているはず
* メモリなら ECC メモリを使うことで1ビットなら修正でき、2ビットは検出のみできる
* パリティ付きメモリ (1ビットの誤りを検出だけできる) は最近流行っていないね
第9章 一貫性と合意
==================
* 地図にある自家製合意アルゴリズムの難破船、なかなか闇深い
9.1 一貫性の保証
----------------
9.2 線形化可能性
----------------
9.2.1 システムを線形化可能にする条件は？
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
* 新旧どちらの値が返されるかわからないのが "regular" register とは？どのへんが "regular" なのか
* 原書では脚注の文に参考文献 7 と 30 (訳書の番号だと 25 に対応) が記載されており (訳書ではなぜか文献番号が省かれている)、その文献にそのあたりの説明があるかもしれない
9.2.2 線形化可能性への依存
~~~~~~~~~~~~~~~~~~~~~~~~~~
* 図 9-5 のようなシステムは、 S3 では問題の可能性があったが、最近結果整合性が保証されるように仕様変更されて問題は解消した (GCS のほうは Spanner の力を借りることで以前より保証されている)
9.2.3 線形化可能なシステムの実装
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
9.2.4 線形化可能にすることによるコスト
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
* 脚注6の「推しき的に分割すること」って誤植？原書を調べよう (**宿題2**)
----
次回は、 p.369 の 9.2.4.2 線形化可能性とネットワークの遅延から
----
[ 戻る ]