サラサラと読めた。
でも他人の失敗から、自分の失敗と同じ鮮度で学ぶのは非常に難しいんだろうなと思った。
【感想】Learning DNS
O'ReillyのDNS本に必ず名前が出てくる著者のビデオを見てみる。
Databases typically have indexes
The Domain Name System is no different
https://learning.oreilly.com/videos/learning-dns/9781771373692/9781771373692-video217128/
DNSがなによりもまず（分散）データベースであるということがよく分かっていなかった。そしてデータベースシステムなのでインデックスがある。DNS以前（HOSTS.TXT）の検索時間計算量はO(n)だった。
Later, top-level domains were reserved for every country in the world, called country code top-level domains, or ccTLDS
https://learning.oreilly.com/videos/learning-dns/9781771373692/9781771373692-video217130/
.jp等、国別のトップレベルドメインのことをccTLDSと呼ぶ。
Resolution is the process by which resolvers and name servers cooperate to locate data stored in DNS
Resolution proceeds top-down by default
https://learning.oreilly.com/videos/learning-dns/9781771373692/9781771373692-video217134/
resolverが適切なname serverを探すことをresolutionと呼ぶ。デフォルトではトップダウンに進む。例えばroot→com→google→wwwのように。しかし、これだと上位のname serverの負荷が非常に高そうだがどう解決するのか。
Queries and responses are types of DNS messages
https://learning.oreilly.com/videos/learning-dns/9781771373692/9781771373692-video217135/
- Usually using UDP
DNS queryとDNS responseはDNS messageと呼ばれるインタフェースでやりとりをする。DNS messageはUDP上でやり取りされるので、packet lossを考慮しなければならない。
DNS message自体はTCP/IP インターネット以外のネットワークも利用可能なように設計されているものの、実質はインターネット以外には使われていない。
TIME TO LIVE
Cached data must eventually time out in order to force name servers to re- Each resource record has a value associated with it called time to live
https://learning.oreilly.com/videos/learning-dns/9781771373692/9781771373692-video217136/
先述の性能問題を解決するためにcachingがある。DNSにおけるcachingは
- nameとaddress（DNS responseのanswer）のcaching
- name serverのaddressのcaching
2つの意味がある。cachingなので当然TTLもある
Authoritative, Recursive And Caching Name Servers
https://learning.oreilly.com/videos/learning-dns/9781771373692/9781771373692-video217138/
3種のname server
- authoritative: 主機能がnon-recursive query
- recursive
- caching
primaryとsecondaryは誤解されやすい。
The forwarder is the name server that receives -not sends - the forwarded query
https://learning.oreilly.com/videos/learning-dns/9781771373692/9781771373692-video217140/
forwarderはforwarder queryを受信者であって、forwader queryの送信者ではない。
Nowadays, to allow internal name servers to
resolve Internet domain names without giving them direct access to the Internet
https://learning.oreilly.com/videos/learning-dns/9781771373692/9781771373692-video217141/
forwardingを使う理由は主に会社内のname server全てをインターネットに公開せずに名前解決を行うため。ただしDNSのポート番号53は公開されていることが多い。また、Log4Shellの際に指摘されていた環境変数の漏洩には無効であるように思われる。むしろ recursive queryを必要最小限に抑えることが必要なのか？
To map a single domain name to multiple IPv4 addresses, simply use multiple A records
Determining the order in which they're returned is complicated
https://learning.oreilly.com/videos/learning-dns/9781771373692/9781771373692-video217143/
Aレコードの語源はaddress recordだが、実質的にはIPv4レコードを意味する。単一ドメインに複数のIPv4をマッピングしたい場合、複数のAレコードを使う。ただし、どのIPv4が返されるかは単純ではない。
多分クライアント依存。逆に言うとクライアントをコントロールできるのであればDNSをロードバランシングに使えるかもしれない。
Recursive namne servers that receive CNAME records as a response restart the query
- Replacing the alias witth the canonical name
- So don't chain CNAME records!
https://learning.oreilly.com/videos/learning-dns/9781771373692/9781771373692-video217146/
CNAMEはエイリアス。まずAレコードを探し、なければCNAMEを探す。無駄な処理が走るのでCNAMEを数珠つなぎにするのは一般にいい考えではない。
BIND name servers support several configurable RRset orders:
- Round robin/cyclic: The first record is rotated to the end in the next response
- Random: The records are raurned in random order
- Fixed: The records are always returned in the same order, the order in which they appear in zone data
https://learning.oreilly.com/videos/learning-dns/9781771373692/9781771373692-video217152/
RRsetがロードバランシングなのか？
Some folks use RRset order to distribute load among a set of servers, but
Ordering relies on the clent using the first address returned first
- Intermediate name servers (e.g., your local recursive name server) may reorder RRsets, too
- If the client reorders, all bets are off
https://learning.oreilly.com/videos/learning-dns/9781771373692/9781771373692-video217152/
…と思ったら即座に夢が打ち砕かれた。しかし"rrset load"でググってもこういう回答は出てこないのでやはりO'Reillyは素晴らしい。
結論としてインターネットからのアクセスをコントロールするという目的においてはDNSはact-sbyをマニュアル（ないし半自動）で切り替える程度の利用にとどめるのが懸命ぽい。理由は単純でクライアント頼みの箇所が多すぎるから。データセンター内でクライアントをコントロールできる場合はこの限りではないと思う。
この本も面白そう。
【感想】最新ネットワークアーキテクチャー CLOSネットワークについて解説します。
CLOSネットワークがあまりに分からなくて見つけた動画。
CLOSネットワークとは?
大規模なデータセンターネットワークを作るために、登場した新しいネットワークアーキテクチャー。
Microsoft, Facebook, Google, Yahoo Japan, LINE をはじめ多くの大規模Webコンテンツ企業で運用中。
シンプルな技術を利用することで、 機種を選ばずほぼ無制限にネットワークを拡張できる。
非常にわかりやすいまとめ。やはり今の時代はスケーラビリティが最も優先されるアーキテクチャ特性なのかもしれない。規模というよりデータセンター内通信の多寡が選定基準か？
レイヤー2ネットワーク特有の課題
https://youtu.be/sS0pKmqxKjY?t=1080
課題から入ると分かりやすい。レイヤー2の制約に引っかかるような巨大L2ネットワークが要請されたことにより、ボトルネックを移動させる必要があった。スケールしづらいところを小さくし、スケールしやすいところを大きくするというパターンと考えられる。
安定性があり運用もしやすいネットワーク
自動化システムによるネットワーク運用自動化
安定しないものに対して自動化はできない。安定させるためには、枯れた技術で容易に組めることが必要が。これがアーキテクチャ。安定しているから、その上で高度自動化のようなチャレンジがてきて競争優位性につながる。
CLOSネットワークそのものについても学びがあったし、技術のイノベーションという観点でも学びがあった。
【感想】Cloud Native Data Center Networking
インフラの勉強をするために、Cloud Nativeと言うタイトルの本をすべて読むシリーズ。
"Northbound traffic moves from the compute nodes into the network and leaves the enterprise network toward the internet; southbound traffic goes from the internet back to local compute nodes. In other words, this is classical client-server communication."
via Check out this quote from Cloud Native Data Center Networking - https://learning.oreilly.com/library/view/-/9781492045595/ch01.html
northbound/southbound trafficという用語を初めて知った。
"However, after packet-switching silicon began supporting routing, as well, there was no need to restrict switches to bridging. Some use the terms “L2 switch” for switches that offer only bridging, whereas an “L3 switch” can also do routing. Many vendors still use this distinction to drive different pricing and licensing for bridging versus routing ports."
via Check out this quote from Cloud Native Data Center Networking - https://learning.oreilly.com/nullch01.html
switchはbridging/routing両方の意味で使われる。bridgingをL2 switch、routingをL3 switchと呼ぶことがある。
"In this chapter, we looked at how the evolution of application architecture led to a change in the network architecture."
via Check out this quote from Cloud Native Data Center Networking - https://learning.oreilly.com/library/view/-/9781492045595/ch01.html
やばい。全然分からなかった。
"Networking in a Clos topology is pretty much what this book is about."
via Check out this quote from Cloud Native Data Center Networking - https://learning.oreilly.com/library/view/-/9781492045595/ch02.html
Clos topologyが引くほど分からない。
日本語でも分からない。
この方のチャネルでまず基本を勉強してから戻ってくることにする。
【感想】業務デザインの発想法 ~「仕組み」と「仕掛け」で最高のオペレーションを創る
保守・運用、ITIL、DevOps、SREなどを調べていて上記記事にたどり着き、その関連書だったので読む。
1. 「運用開始前」「運用開始後」の2軸で考える
p. 27
当たり前だがその通りだ。
「有用性×保証」で業務の価値や脆弱性を診断する
...
一般的に、有用性⇒機能要件、保証⇒非機能要件と考えられます。
p. 54
分かるようで分からん。
運用テストは要件定義の段階で。
p. 56
なるほど。
業務デザインの発想法 ～「仕組み」と「仕掛け」で最高のオペレーションを創る | Gihyo Digital Publishing … 技術評論社の電子書籍
「業務デザインの発想法」仕組みと仕掛けで創る | メイドイン人事
ここらへんもあとの参照用に。
1-1 どんな業務を提供するのか，メニューを定義する ～運用項目設計
(1)運用を開始するために何をすればいいか？ ～タスクの洗い出し
(2)毎日発生する仕事，たまにしか発生しない仕事を見極める ～定常業務／非定常業務定義
(3)標準化すること，都度考えて対応することを決める ～ルーチン／ノンルーチン区分
(4)やることの詳細を定義する ～プロセス定義
(5)やることの流れを定義する ～フロー定義
業務デザインの発想法 ～「仕組み」と「仕掛け」で最高のオペレーションを創る | Gihyo Digital Publishing … 技術評論社の電子書籍
当たり前すぎるのだが、やるべきことを抜けなく漏れなく洗い出すことがすべて。
つまるところ半期のjob descriptionを常に更新することが必要なのだと思われる。
ITILやサービスマネジメント勉強しないとだなあ。
【感想】生産マネジメント入門〈1〉生産システム編 (マネジメント・テキスト) | カーリル
【感想】先進製造業の生産マネジメント論から見た事務用情報システム開発 - 三津石智巳から参照されていたので読む。背景として、「生産プロセスとは情報システムの稼働・運用を意味する」というメタファーが有用であると考え、共通フレーム2013における
- 保守プロセス
- 運用プロセス
- サービスマネジメントプロセス
に対する製造業からの知見を得ようとするものである。
…は本書の守備範囲を超えるものである。議論を明確化するためにも、本書においては、企業パフォーマンスの1ファクターである「競争力」、すなわち、…
p. 12
いきなり本筋とはあまり関係がないのだが、風呂敷を広げすぎない、この態度が参考になる。
というか、「製品設計情報」の転写というモデルは酒井崇男氏の本で知ったが、「「タレント」の時代」の参考文献を読み返すと、本書の著者である藤本隆宏氏の著書がいくつも挙げられている。
製品開発システム
- ←労働力ほか
- →製品設計情報（開発期間・開発生産性・総合商品力）
生産システム
- ←生産資源（原材料・部品・労働力・資本設備）
- →製品（生産性・コスト・品質・納期・リードタイム・フレキシビリティ）
最終顧客
p. 13 図を文字に起こした
ここで、新規開発後の情報システムは「生産システム」に該当する。Web APIにあてはめると、「生産資源」がHTTPリクエスト、「製品」がHTTPレスポンスと考えることができる。BtoBtoCの情報システムにあてはめると、「生産資源」がBからの商品情報登録・更新で、「製品」がCによる購入と考えることができるだろうか。
インプット個数に対する良品アウトプットの比率を「歩留まり」（yield）という。
p. 21
情報システムにあてはめるとなんだろう。HTTP 200の比率かな。
レイアウトのタイプ
- 万能型
- 機能別
- 製品別（半流れ式）
- 製品別（流れ式）
p. 37 図を文字に起こした
アーキテクチャ図にそっくり。製品別がマイクロサービスアーキテクチャといったところか。半流れ式はmessage queueを使った非同期呼び出しに当てはまる。
既存の設備を使いながらでも、適切なレイアウトを選択することによって、大幅な生産性向上が可能
p. 40
アーキテクチャをリファクタリングすることで、性能を改善できるような話。
いわゆる「大量生産システム」は、前述の「専用生産設備」「部品の互換性」に加えて、「同一形状の製品・部品を大量に繰り返し生産すること」と、それによる「製造コスト・製品単価の大幅な低減」を特徴とする。したがって、「アメリカ式製造システム」の確立は、「大量生産方式」への道を開くことになる。
p. 63
ここでいう「前述」は「アメリカ式製造システム」を指す。
生産マネジメントの製造における「部品の互換性」は、ソフトウェアのproductionにおいて何を意味するだろうか。互換性があるとは、仕上げ工がいらないという意味なので、事前に計算されたインデックスのスキャンだけで検索が完了し、DB以後にアプリケーションロジックを必要としないというような意味に捉えるのはどうか。すなわち、生産マネジメントの製造における「十分な加工精度」とは、ソフトウェアにおいては書き込みパスの十分効率的な時間・空間計算量および、スケーラビリティということになる。
むしろ、「互換性部品」による銃の生産は、高コストなやり方だったのである。…銃の場合に軍が「部品交換性」にこだわったのは、おそらくは「部品が互換的ならば、戦場で壊れた銃を解体し、壊れていない部品を再組み立てすることで相当数を迅速に再生できる」という軍事上の理由からであり、コスト低減と大量生産のためではなかった。
p. 64
おもしろ。「互換性」のような「品質特性」はあればあるだけいいものではなく、要求から必要な品質特性が導出されるによるというのが改めてよくわかる。
フォードは、生産技術に関する、新しい工作機械、治具、レイアウト、マテハン（物資搬送）などの実験を累積していった。失敗した工作機械のスクラップの山ができたという。「フォード方式は一日にしてならず」である。
p. 70
まさに「アジャイル」である。ハードウェアであれ、ソフトウェアであれ、生産に先立っては仮説検証が必要である。
19世紀以来のアメリカ産業の200年の歴史は、互換部品の追求にせよ作業の標準化にせよ、要するに部品間・作業間の「すり合わせ」を減らす努力の歴史であったといえなくもない。
p. 89
なるほど。OSI参照モデルなんかもここの系譜から来ておるのだろうな。
