AR ホームベーカリー

オイラのアウトプット用ホームベーカリー!

仮想化とかコンテナのたとえを個人的に現代的に消化しようとしてうんちでた

うんちしてたら考えがまとまってきたので。

物のたとえ

最近「IT分野をなにかにたとえるのは無理では? 概念だろうとなんだろうと◯◯は◯◯、でいいのでは」という気になっており、例えるのは説明側のエゴというかよほど好適な例でないと学習の阻害になる (喋る側と聞く側で知識の差があるので、ギャップを埋めるために一方的にアウトプットしている) と感じている。

これはいわゆる同業種間での感じで、もちろん他業種や toC でお話する時に、相手の知識や立場にたった物のたとえが悪いということではない。

サーバー=家、という例えのお話です

よく挙げられるたとえとして、「サーバーは家 (部屋) !」みたいなのがあるけど、ここを雑に表現してしまうと、続くコンテナ環境とか説明しづらいよな、と思ったので個人的に整理をしていた。

まずサーバー=家、が成り立つのはコンテナという概念が発生する以前で、それこそ仮想サーバーなんかが流行った後は、「一戸建てと賃貸!」みたいな方便も生まれたけど、そういう整理を兼ねている。 で、個人的には以下のような関係かなあ、と整理した。

例え 現実の単位
国家 運営会社
国土 データセンター
(借地権) 土地 ラック
一戸建て (ラックマウント≒物理占有) サーバー
賃貸マンション 仮想サーバー
部屋 コンテナ
ソーシャルマンション サーバレスコンテナ環境

AWS (東京リージョン) を例にすると以下のようになる。

例え 現実の単位
国家 AWS
国土 リージョン (ap-northeast-1)
(借地権) 土地 アベイラビリティーゾーン (apne1-az1,2,3,4)
一戸建て EC2 (ハードウェア占有インタンス)
賃貸マンション EC2, LightSail
部屋 ECS on EC2
ソーシャルマンション ECS on Fargate

あまり適切ではなかった

書いてて思ったのは、サーバー=部屋概念ありきで広げていくとあまり好適ではないな、という感じでした。

たとえの中に土地 (借地権) の話入れているのは、たとえが必要な層には直感的に伝わりづらい気がする。 AWS という前提がもう賃貸じゃん、ってなるんで。 その中にハードウェア占有インスタンス、みたいな更に困る話があるのがアレ。 まあ今回はしめしめと記載させてもらいましたが。

これ、うんちしてる時に「コンテナが部屋なのはいいけど、じゃあ Fargate とか基盤部分構築しないヤツを部屋、と呼んでいいのか……? ううーん」というのを悩んだ結果「そうだ共用部は運営会社メンテナンスで部屋だけ占有するソーシャルマンションがあるじゃん!(ブッチブリリリ!」となったので、脱糞の爽やかさで脳が焼かれた可能性はある。

日本人の家事情わかりてテスト

とはいえ、Sales なんかの分野の人が、ドメイン外の知識しか持っていない相手に対して「オンプレミス、自社所有は一軒家でここに借地権なんかの話と自分の持ち家メンテナンスの積立、マンションだと修繕費積立がありますし、賃貸マンションだったら借地権は考えなくてまあ大丈夫で、修繕積立なんかも家賃に入ってるか、共益費として設定されていますよね」みたいな、日本人は家を買うために仕事している、みたいなトコもあるので、ある程度の年齢のそういう層への説明としては刺さりやすいのかもしれない。

ある程度の年齢のそういう層、というのが、「決裁権を持っている人間」となるので暗黙的に壮年が対象だし、仮に若年層だとしても決裁権持ってるならある程度住環境へのコスト感は理解できる人のはずだよな、という期待があるので、やはりこれはある種、高等教育の勝利の部分あるよな、と個人的には思います。

自分向けの整理はそんな感じ! もっと良い例えがあったら教えて欲しい、ほならな!

おまけ

ap-northeast-1a とかの AWS 側からの正式なマップ名ってなんだっけ……APAZ? なんかちがうな、となって調べていて、以下のクラスメソッドの記事が出てきたんだけど、一瞬「あれウチのマッピングと違う気がする?!」となって、本文読んでて混乱してしまった。

dev.classmethod.jp

マッピングはランダムであり以下の図のようにAWSアカウントごとにAZのコードとAZ IDのマッピングは異なる場合があるため、注意が必要です。

文中にこのように書いてある。

んだけど、以下のような書き出しなので、いわゆる主語がデカイというヤツを暗黙的に食らってしまいそうになる。

アベイラビリティゾーン「apne1-az3」とは? アベイラビリティゾーン「apne1-az3」は、最近発行されたアカウントでは利用できない古いアベイラビリティゾーン(以下AZ)です。

全体的に「マッピングは決め打ち」と誤読しそうになるので、クラスメソッドくんでもこういう書き方になる時があるんだな、気をつけよう、という気持ちになるのだった。

AWSゥ!

まずおまんがまともな文章書きよればこげんこつならんとよ! 「リファレンスは英語です!」と言っていても、その英ドキュメントもロクでもねえので、本当……という感じ。

2024/10/30

文章の書き方

www.bunka.go.jp

はえ~、となりながら途中まで読んでいた。

お仕事での提出グレード

よくわかんなくて、社内の高学歴兄貴に「赤ペン先生してください、オネシャス!!」って毎回様子を見てお願いしていたので、こういうのは助かる。

まあ X で回ってきたので偶然見て喜んでたら、日付が令和4年とか書いてあって衝撃でしたね。

iMac

突然 M4 iMac が生えてましたね。

www.itmedia.co.jp

8 CPU/ 8 GPU/ 16GB RAM/ 256GiB SSD/ 24 インチ (4.5k) ディスプレイ/ 付属品含め USB-C 統一/ 吊るし最安 199,800 円。 外に持ち出さない前提なら、MacBookPro と外付けディスプレイ買うよりよさそう。

Mac mini

突然 M4 Mac mini が生えてきましたね。

www.itmedia.co.jp

10 CPU/ 10 GPU/ 16GB RAM/ 256GiB SSD/ 吊るし最安 94,800 円。 Retina など高解像度ディスプレイにこだわらないのであれば、これと HDMI 接続の外付けディプレイ 3 万円くらいで買っちゃうのが開発環境的には一番安くてお手軽そう。

740g とのことなので、USB-C のモバイルディスプレイ 13 インチ程度だと 500g ないはずだし、MacBookPro 持つよりは合計重量的に軽い可能性まであるのがすごいなあ。 電源の確保必須だけど。

M4Pro モデルも用意されてて、こいつが背面 USB-C 端子だけ Thunderbolt5 実装で 120Gbps 使えるので「はえ~、ケーブル発熱もすごそう」という感じ。

Thudenrbolt5

pc.watch.impress.co.jp

全然知らなかったんですが、1 レーン 40Gbps を 4 レーン束ねて全二重通信 80Gbps を実現しとるんすね。

送信1 送信2 受信1 受信2
40Gbps 40Gbps 40Gbps 40Gbps

でこれ経路を変更することで、通信速度が非対称になる代わりに送信側が 120Gbps になるということか?

送信1 送信2 送信3 受信1
40Gbps 40Gbps 40Gbps 40Gbps

データの作りや流れが違うとはいえ、 TCP/IP が 1Gbps をいまだに卒業できないのを見ていると、シリアルパラレルケーブルから USB 以降の進化がすげーな、と思うわけ。 (RS-232C でプリンタ接続をしていた Windows98 のおじさんとしては)

120Gbps の転送速度

ja.wikipedia.org

送信 (片方向) 120Gbps っていうと、だいたい PCI-Express3 x16 もしくは PCI-Express4 x8 程度か。 はーめちゃ早い。

しかし、 PCI-Express はこの速度を双方向で保持しているので、実際比較するなら 80Gbps の方でやるべき。 そうなると Gen3 x8 と Gen4 x4 あたりですが。 それだと帯域たりないので、それぞれ x10, x6 相当かなとも思うわけ。

雑に解釈しているけど、いうて GeForce RTX 30, 40 世代は PCI-Express3 x16 とか PCI-Express4 x8 でも数パーセントしか性能劣化が起きない、みたいな話もあるので、外付け GPU が更に有効になりそうですねえという風情ある。 GPU 自体より外付け GPU ボックスの方が高い、みたいな風情になりつつあるけど。

通信速度

こういうホストターゲット型の通信がどんどん高速化するのに対して、雑な分類でいうと TCP/IP は全然市販部分で高速化しねーな、という気持ちがある。

www.softech.co.jp

とはいえ USB がホストターゲット型で、ある意味クローズな環境で完結するのに対して、 TCP/IP は遠距離を結ぶネットワークなので、全体、特に ISP などが底上げされないと高速化は難しいというのもわかるつもりではある。 あるけどさあ、という感じ。

「RJ-45 に Cat7 は存在しない! 10G はまやかしだふじこふじこ」つってる X のエンジニアおっさんが事実言ってるんだとしても、「欺瞞!」って感じるわけよ。 欺瞞ではないんだけど。

実際のところ、10 人が 10Gbps の回線を利用できるというシナリオより、 100 人が 1Gbps の回線を利用できる、というシナリオの方が最低限クリアすべきというように変化している時代だしなあ。 その上で更に高速通信をさせろ、という要求なんだけど、まあ難しいよねというのもわかる。

光速は遅い

こうなってくると「光速は遅い」という話が学術的ではなくて、現実の話になってくる。 いやまあ光ファイバーは現実的には光通信であって光通信ではない、というやつだけど。 素材がね (ファイバーの折れる音)。

qiita.com

AWS snowmobile だ! もうおなくなりになったけど!

www.publickey1.jp

これもファンキーに見えて、計画的にやれるなら転送時間や転送量を考慮するとローコストだよなあ、という感じ。 トラックで持ち出した以降の区間だけ同期できるようにレプリケーション用のリードクラスタ準備しといてあとはぶん回せばいいので。

太古の昔に Togetter かなんかで「HDD 満載したバックかついで新幹線に乗って東京大阪間を移動した」みたいな人見た記憶あるので、データ転送時の損失が物理か電子的か、どの程度の欠損率か、というのを考慮すると物理転送が最強、というのはしばらくはそう!

Heroku では Redis7 ではなく Valkey7 を使う

掲題のとおりです

image の指定を redis から image: "valkey/valkey:7.2" などにします。

engineerjutsu.com

upgrade コマンドなどあるようですが、今んところ公式に Docker ファイル更新内容から含めたアップグレードガイド、みたいなのないっぽくて、 heroku CLI から redis:upgrade 投げろ、みたいなのしか見当たらない。

Valkey

Redis のライセンスが変更になったので fork されたやつ。

OpenSearch といい、あのあたりマネタイズが難しいしクラウドベンダーがタダ乗りするのが許せねえ! という気持ちは十分に理解できるけど、

「ライセンスが違う? これは我々がこんにち表すところの OSS です!」

と言わざるを得ないから、各社ベンダーも

「じゃあ fork してライセンスに抵触しないように使うね」

となるのでウム、という感じですね。

Google ドキュメントで Markdown を有効にして文字数カウントを表示する

Markdown 有効化

ツール > 設定 > Markdown を有効にする

チェックを入れると有効になる

VScode などプレーンじゃないテキストエディタから丸ごとコピペなどすると、変なスタイルが付与されてカラーシンタックスとかめちゃくちゃになる。 ので、既存情報を手動で移行する際は、一度メモ帳など ascii 情報しか扱えないエディタを経由すると良い。

文字数カウント

CTRL+SHIFT+c

チェックを入れると編集画面上に表示できる

標準だと左下あたりに出るはず

常にカウントを表示するのは無理っぽく、文字数など詳細はクリックしている間だけ表示される。 しゃーなし。

概ね

Markdown ソースの保持 にこだわりがない (かつ Google に検疫されていい) なら Google ドキュメントでもよさそうです。 見出しに応じてアウトラインが増えるのは便利ですしね。

逆にクローズドな作業であったり、移植性などを鑑みて Markdown ソース (書式含めて) が保持されてないと困る、という人は VScode なりでがんばりましょう。

2024/10/28

そろそろはてダに引っ越してきて9周年になる。

つまり30代は月に数回程度、はてダを利用してなにかしらアウトプットした、ということになる (はず)。 うーん感慨深い。

技術の進歩

というかこの 10 年くらい、半導体のプロセスルールからスマヒョに代表される技術進歩すごいですよねえ。

2015年頃っていうと Intel の Skylake で 14nm でしたし、今じゃ CoreUltra……はキメラすぎてよくわかんねえな。 一般向け量販品で最先端だと AppleSillicon M4 チップの 3nm でしょうか。 1/4 以下ですねえ。

仮想化からコンテナ

ちょうど Docker がおぎゃあした辺りで「コンテナって仮想化とどう違うんね?」という感じだった気がします。 実際に日常的に使うようになったここ数年なら概ね感覚で理解していますが、当時は「壊れたら全部ポイントスナップショットなりで入れ替え直せばいいじゃん!」で雑に仮想化運用するのが最強だった……。 いやまあ、管理対象がホスト毎なのか否か、で現代では議論するステージが違うとみんな分かっているので暴論もいいとこですが。

そう考えると「技術的に……何も学べていない!」と絶望してたけどそうでもなかったな (特にフリーランスになって以降) という感じ。

突然の振り返り

という感じでした。

もうちょっと 12 月寄りになってからやるべきかな、と思ったけど、ラフな感じで相談してた作業が突然の財務方向からの突き上げ、などでペンディングしており。

「これ作業としては絶対必要だから年末地獄ぞ」というスケジュールになっているのでここまで。 財務君がスケベ心出さなければ、作業概要とスケジュールまで引いて「んじゃやりますわ」直前まで進行してたのに、んも~、という感じ。

VScode の Allowed UNCHosts は CIDR で許可できない

掲題の通りです

掲題の通りです、つらい。

量が多くなるとどうする

現状ではチマチマとアドレス指定するしかなさそうです。

もし利用者が特定個人なら設定同期を使えばいいんでしょうが、そうでないのであれば、アドレスごとに書くのでなく列挙してしまって、内容を wiki やら GoogleDocs やらで共有メンテナンスしていくしかなさそう。

とはいえ /24 程度なら大丈夫かと思うけど、 /16 とかになると全部列挙した時に VScode 起動時のチェックでクソ重くなる、とかならない? 大丈夫? そんな使い方するなって? しらんがな。

なんで CIDR で許可したいの?

192.168.0.0/16 とかしてローカルネットワーク (いわゆるクラス C のプライベートアドレス範囲) を無条件に信頼させたいんですよね、一般の家庭で DHCP 運用なのでそこ信頼できないならオワなので。

これが逸般のご家庭なら、アドレス固定とかセキュリティ考慮とかルーターじゃなくてアプライアンス調達とかするけどよォ……!

Restrict UNCAccess はずせばいいじゃん

そうなんだけどさァ! この手の機能って後年厳しくなって「デフォルトにしました。 無効化してたの? そんなんじゃ甘いよ!」って一転攻勢されるじゃん、という感じです。 セキュリティ対策というお題目さえあればどんどん厳格なデフォルトになるのは、性善説が通用した牧歌的なインターネットが太古のものになって久しいのでまあわかるんすけどね。

特にめちゃくちゃやる気のある人以外は「デフォルトでいい感じになっててほしい」というやつで、昔 MySQL かどっかの中の人が「どいつもこいつも結局デフォルトのコンフィグ変更しないから文句ばっか言うやんけ! もういい! アタイ制限厳しくする!」と言っていた気がするのでそうなんだろうな……と、脳内理論が飛躍しつつ思いを馳せていた。

RDS のインスタンスリタイア

RDS hardware maintenance scheduled

という通知が AWS から飛んできたので、スケジュールされた日時を見た所、平日日中帯になっていた。

流石にこれはマズい、という事で深夜に手動で再起動してインスタンス移動を実施することにした。

やること

といっても難しくなく、該当のインスタンス詳細を開いて メンテナンスとバックアップ タブから Maintenance on the underlying hardware 列のラジオボタンをチェックして、 今すぐ適用 ボタンを押すだけ。

あとはダウンタイムが生まれるのは SingleAZ 運用かつインスタンスリタイアでしょうがない、というのは事前にわかっていたので、終了するまで待機する。

よく言われるクラスメソッドくんのわかりやすい記事は以下。

dev.classmethod.jp

おまけ

AWS は、再起動とかハードウェアの変更 (今回のインスタンスリタイアとか EC2 の EBS 拡張とかのような) を伴う作業では、環境が壊れない事を保証していないらしい。

なので万が一壊れて立ち上がらない、というのを防ぐために事前にスナップショットバックアップを作成しておくと良い。

ただこれは容量次第ではめっちゃ時間がかかるので、ReadReplica 作るとか、実施するかは応相談としたほうがよいと思いました。

おわり。