コード日進月歩

しんくうの技術的な小話、メモ、つれづれ、など

プロセス管理の技術であるSupervisorについてざっくりまとめる

スーパバイザモードの話とよくわからなくなるので。

Supervisorとは

2004年頃からある、プロセスを常時起動するデーモン化のためのツール。python製。 Supervisor: A Process Control System — Supervisor 4.2.5 documentation

どういうときに使われるものなのか

デーモン化はsystemdのserviceを使う方法などがありますが、それよりも簡単に行えるのがsupervisorです。 とくにdockerの場合などは、systemdなどを使って複数プロセスを立ち上げることもできないわけではないのですが、supervisorでカバーできるケースがほとんどなので、よく使われる傾向にあります。

参考リンク

トークンバケットとはなにかをざっくりまとめる

言葉からは動きが想像できなかったのでざっくりまとめる。なおパケット(Packet)ではなくバケットBucket)。

トークバケット(Token Bucket)とは

帯域制御の方法のひとつ。トークン(送信権)を一定時間のペースで発行し貯蓄され、流れていくるトラフィックのパケットに関して、対応できる量のトークンがあれば処理を行う。対応する量がなければトークンがあてがわれなかったトラフィックは破棄される仕組み。トークンの貯蓄は無限に行うことではなく、一定量貯まるとそれ以上はたまらないため、波がある場合でもすべてのトラフィックが処理されるわけではない。

送信権であるトークンをためるバケツを用意し、そのバケツが一杯になったら新たなトークンの追加がされない考え方。

特徴

トークンの量が一定量確保されている状態であれば、流れてきた通りの処理ができる。そのため、いわゆるバーストのような一時的にトラフィック流量が跳ね上がる状態でも等しくカットされるわけではなく、トークンが貯まっていれば対応はできることになる。

参考リンク

通信経路におけるポリシング(Policing)とシェーピング(Shaping)についてざっくりまとめる

トークバケットを整理するときに、前提として気になった部分だったので切り出してまとめる。なおシェービング(shaving)ではない。

それぞれの言葉の意味

いずれも通信における帯域制御に使われることばで、帯域などを占有しないように制限値を設ける場合にその制限値を超えるトラフィックが発生したときの考え方の分類。

ポリシング(Policing)

ポリシングは制限値を超えるトラフィックがある場合に超えた部分を切り捨てる考え方。制限量を超えたタイミングだと相手まで到達しないものが出てくる。

シェーピング(Shaping)

シェーピングは制限値を超えるトラフィックが来た場合に、蓄積を行い順次処理をしていくようなやり方。制限量を超えるトラフィックを超える場合は遅延して処理していくことにはなる。

イメージ比較

制限値を超えたときの処理イメージを比較すると以下のようになる。

ポリシングとシェービングのイメージ図

手法 超過したトラフィックの処理方法 長所 短所
ポリシング 破棄する 超過分を破棄するの変化がない 破棄されてしまうので情報が損失してしまう可能性がある
シェーピング 遅延させる 損失がすくない 遅延をするのでリアルタイム性が失われる

関連リンク

リモートコミュニケーションを見直すときに読みたい記事『チームで仕事をするなら、リアクションし続けよ』

適宜振り返りたい記事なのでメモとして。

対象記事

チームで仕事をするなら、リアクションし続けよ|森 一貴(Mori Kazuki)

みどころ

リアクションが重要なことを説いているのだが、なかでも一番下のフレーズが印象深く残るポイント

議論において黙って静かにしていることは、実は透明になることではない。それは黙っていようがなんだろうが、「そのアイデアに賛同しません」という意味である、「そのアイデアはそこまでおもしろくないですね」と発言しているのと全く同じ意味である。だから、黙って静かにしていることは、それそのものが、議論を後ろに引っ張ることなのだ。

リモートミーティングの場合は、ビデオOFFや音声がうまく乗らないなどで、リアル対面よりはリアクションが薄れる。そのため、肯定なのか否定なのか思考中なのかが判断つきづらいのだが、何も反応がないことはマイナスに働くことは自分自身の無意識化にある体験を言語化されたようで非常によかった。

関連リンク

脆弱性周りの略語をざっくり整理する

自身の理解のためによく聞くものだけでも、の整理

CVE(Common Vulnerabilities and Exposures)

CVEは脆弱性を識別するための共通脆弱性識別子。要するに個々の脆弱性に関してわかりやすく管理するために振られるユニークなID。

管理しているのはアメリカ政府の支援を受けている非営利団体のMITRE社。またこのCVEを採番する権利がある機関のことをCNA(CVE Numbering Authorities)と呼ぶ。

https://www.cve.org/

JVN(Japan Vulnerability Notes)

日本国内で報告された脆弱性を共有するためのポータルサイト。国内で提供されているソフトウェアの脆弱性情報の流通を目的にしている。

前述のCVEの運用とともパートナーシップを結んでおり、JVN内で報告された脆弱性とCVEで互換性のあるものはわかるように扱わている。

https://jvn.jp/

NVD(National Vulnerability Database)

アメリカ国立標準技術研究所(NIST)が管理している脆弱性管理のデータベース。CVEや後述のCVSSなどが記載されるデータベースだが、2024年時点では運用が停滞している。

KEV(Known Exploited Vulnerabilities catalog)

実際に悪用が確認された脆弱性の一覧。CVEと連動して実際に悪用が発生したものを取り扱っている。

CVSS(Common Vulnerability Scoring System)

CVSSは脆弱性の深刻度に関しての指標を出すための手法。算出すされた指標の値はCVSSスコアと呼ばれる。

このCVSSスコア自体はバージョンによって異なり、現在最新のバージョンはv3となっている。

SSVC(Stakeholder-Specific Vulnerability Categorization)

CVSS同様に脆弱性を図る指標としてカーネギーメロン大学ソフトウェア工学研究所で考えられた指標。CVSSが脆弱性自体を数値化するのに対し、対応すべき方針が提示されるのが特徴

参考リンク

2024年末時点での世の中の横長広告のサイズを調べる

横長のバナーの推奨サイズは各社どうなっているのか雑に調べる。

参照元

今回は日本国内で多く使われるであろう、Google、LINEヤフー、Instagram(Meta)の情報をもとに整理する。

参考にしたものはは以下

Web広告のサイズの多くは1.91:1の1200x628がベース

昔は特定のサイズで名前があったが現在ではアスペクト比と推奨サイズで規定を表現することが多い様子。参照元で登場するサイズで多く登場するのは以下の2パターン

比率名称 推奨サイズ 補足
1:1 1,200 x 1,200 完全な正四角形、スクエアなどと呼称される
1.91: 1 1,200 x 628 横長の四角形、横長のものに使われる

縦長の画像をサポートしているものに関しては各社まばら。

参考サイト

システム開発におけるインピーダンスミスマッチという言葉の意味をざっくり整理する

なぜ急に電気記号の話が?と思ったことがあるのでざっくりまとめる

よく使われる場面

インピーダンスに関しては身近な話では音響機器の話で出てくる。出力のインピーダンスが高いもの(ハイインピーダンス)に対して、受けてである入力のインピーダンスが低いもの(ローインピーダンス)をセットするとロスが多いなどの話で表現される。ここに関しては前提知識がないとイメージがつきづらいので、以下サイトの絵を参照すると理解しやすい。

インピーダンスとインピーダンス・マッチング | アンブレラカンパニー | BUZZ

本来はインピーダンスが同等な者同士で接続すればロスは限りなくゼロだが、現実的にはそうはいかないので、ローインピーダンスからハイインピーダンスのものにつなげることが良いとされている。

転じて、ソフトウェアにおけるインピーダンスミスマッチとは

ソフトウェアにおけるインピーダンスミスマッチは O/R(Obeject/Relation)インピーダンスミスマッチ として表現され、いわゆるオブジェクト指向での Object とリレーショナルデータベースがもつ Relational なデータ間でミスマッチが発生してロスが起きることを指している。

具体的な事象としてはRDBに定義したテーブル定義から、アプリケーション上で取り扱うオブジェクトを起こす特に変換ロスが発生するようなことを指している。そのためRailsActiveRecordなどはRDBのテーブルとアプリケーション上のModelをほぼ同一に取り扱っているので、インピーダンスミスマッチは発生しない設計となっている。

関連リンク