[2021年12月号] Software Design(技術評論社) サマリー+個人メモ

Software Design の2021年12月号について、

ざっくり内容紹介
個人的に気になった記事やポイント

をまとめている記事です。

サマリー記事の一覧はこちら。

特集①：しくみから理解するDocker
特集②：OSSとの上手な付き合い方
Extra Feature
Column
OS/Network
そのほか
Software Design 2021年12月号

特集①：しくみから理解するDocker

Dockerとコンテナの基本を総復習しよう
- Dockerが実現したもの
  - アプリケーションを実行するために必要なすべてをDockerイメージに入れられる
    - Dockerイメージは、tarアーカイブに含む複数のファイルやディレクトリをあたかも１つのファイルのように扱う抽象的な概念
  - Dockerイメージに含むアプリケーションを、Dockerコンテナとして実行できる
  - Dockerコンテナは、マシン上のほかのプロセスやコンテナの影響を受けずに実行できる
  - Dockerイメージはほかのコンピュータに移動できる
- Docker EngineとDocker Hub
  - 通常「Dockerを使う」という言葉が示すのはLinux上で動作するDocker Engineというデーモンでアプリケーションを動かすこと
    - こいつがLinuxカーネルを制御し、アプリケーションをコンテナとして扱えるようにしている
  - Docker HubはDockerイメージを共有したりする場において中心的な存在、レジストリ。パブリック。
- 用語
  - Dockerコンテナ
    - Linux上の特別な状態のプロセスであり、コンテナとして起動するアプリケーション。実体はプロセス。
  - Dockerイメージ
    - ファイルシステムとメタ情報によって構成される抽象的な概念。ISOのような単一のイメージファイルではなく、実際には複数あるものをDockerコンテナ内からは１つのファイルシステムとして見えるようにしたもの。
  - Dockerネットワーク
    - コンテナ同士の通信やコンテナ外部との通信時に利用するLANのようなもの。
  - Dockerボリューム
    - Dockerイメージ内のファイルシステムからは独立した空間。ファイルの共有とかに使うやつ。
  - Docker Compose
    - コンテナやDockerネットワーク、Dockerボリュームをプロジェクトという単位で扱う。yamlで定義する。
- そもそもコンテナってなんやねん
  - Linuxカーネルが提供するプロセスの隔離機能であり、特別な状態。Dockerはこれを利用しているだけであり、Dockerは関係なくともコンテナの利用は可能である
    - chrootと関連が深いらしい
  - つまりDockerコンテナと呼んだときのコンテナは意味が別。もともとの意味でのコンテナをDockerでは「アプリケーション」として隔離し、それが実際に必要とするものをイメージでひとまとめにしたものがDockerコンテナ。

特集②：OSSとの上手な付き合い方

OSSを賢く使うための勘所
- 「OSSは一切使わない」というポリシーを定めている（ソフトウェア開発を生業にしている）企業が冗談ではなく本当にあるらしいと知って言葉を失っている
  - っていうか事実上無理では…？内部のライブラリとかまで含めたらオープンソースじゃないものだけを使ってプロダクト作るのって可能なのか…？
    - 「curlを作ろう」とかやってたらめちゃめちゃ面白い
- なんかあんまりめぼしい話はなかった
OSSライセンス順守のための基礎知識
- OSSがどうというより、ライセンスに関する体系的な知識は身につけておきたいといつも思っているので積極的に読もうと思った
- 1980年代に「プログラムは著作権で守りましょう」となったが、その定義である「思想または感情を創作的に表現したもの」がヤバいほど不安定
  - 100行なら？1000行なら？どうやったらオリジナル？　…これらは決められない。結局司法の世界（≒裁判）で決めるしかないというものだった
- この稿の筆者さんいわく、「我々法律の門外漢は、とりあえず"ソフトウェアは著作物であり、開発者は著作権者だ"と思っていい」とのこと。ふむふむ。
- よく勘違いされるが、OSSも著作権の放棄をしているわけではない。

Extra Feature

リアルタイム通信アプリを支える技術
- ちょうど次はWebSocketを使ってなんか作ろうかなーと思ってたのでだいぶビンゴ！
  - 単発じゃなくて連載っぽいので今後が楽しみです。
- これまでの歴史
  - ポーリング
    - window.setTimeout() で頑張るのがはじまり。
  - Ajax
    - なんとGoogle Mapで広く知られるようになったらしい。こんなところでも草分けだったのねー。
  - Comet
    - これまでは「クライアントからリクエストしないといけない」点で変化がなかった。そこでサーバーからデータを送信できるようになるあのCometが登場。2006年頃とのこと。
    - 技術的にはHTTPの応用らしい。サーバーから返せるといっても、クライアントから受けたリクエストがおおもとの契機になっているのは変わりなく、「レスポンスをすぐに返さずに必要になったら自分から返せる」というところが新しかった
    - でもこれ当然コネクションが1個につき1応対分なので、大変なことになる。WebSocketの登場シーンが想像できる感じになってきた。
      - ネットワーク上のTCP接続が莫大に増えるせいでC10K問題も抱えていた
  - Sever Sent Events
    - Cometの改良で、HTTP/1.1で導入されて各ブラウザにも普及。1回のTCPコネクション内で何度もレスポンスを返せるようになったのが進展。
  - WebSocket
    - 初の真の意味での「双方向通信チャネル」。ヘッダが軽く、毎回のやりとりでリクエスト/レスポンスという手順もないため通信コストが低い。
    - バイナリデータも扱えるようになった（Sever Sent Eventsは改行2つ区切りで送信するという性質上むずかったらしい）
      - なんのことかわからんかったけど、MDNを見たら本当にそのままの意味だった
- UDPを採用したWebRTCの登場
  - WebSocketはHTTPの拡張であり、接続はTCPである。受信確認が取れない場合には自動でリトライするなど信頼性が重視されている
    - これだとまだまだ通信手順は多くなってしまう、ビデオチャットなど本当にリアルタイム性の高いものだとまだコストが大きかった
  - WebRTCはUDPがベースである
    - UDPおさらい：TCPのハンドシェイクや送信確認、順序保証などを省いたコネクションレス型のプロトコル。送りつけまくるやつ。
  - WebRTCにはサーバーを介せずクライアント同士で通信するP2Pの仕組みもある
- 次回はQUICとRUDPなる新しいプロトコルについて教えてくれる模様。楽しみ

Column

結城浩の再発見の発想法「NFT」
- なんかわざわざ読むほどのことかとも思ったけど、この記事は半ば日記的な側面も持ち合わせ始めたのでトレンド的に書いてみるのもありかなーなど
- 非代替性トークン、つまりブロックチェーン上に作られるトークンのうちほかのトークンで代替することができないもの
  - 固有性を証明できる、という多くの人がなんとなく予測する理解で特に間違っていない
- NFTが担保するのはあくまでブロックチェーン台帳に記載されたトークンの改ざんが困難になるというだけであり、デジタルデータ自体は複製されるし他の人もアクセスはできる。「占有」などのイメージは乖離がありそう。
- 現代でこういう仕組みが取り沙汰されるのって、結局なんでも（デジタルで）手に入る時代になっちゃったからだよねえ。人間のないものねだり、原点回帰、それらと同種のものに思える。

OS/Network

明後日のコンピューティングを知ろう「サイジングの見える化」
- 旅館業を例にして日本全国で1日にどれほどのウェブサイトPV数があるかを示し、サーバーの出荷総額（ハードウェアのこと？）の増加について論じている
  - ちなみにPV数は平均1,705万～1億241万だとのこと。開きありすぎて桁変わってますね…