アメリカの核兵器管理機関に勤務する男性が、個人所有のポルノコンテンツを誤って政府のネットワークにアップロードしてしまったため、機密の取り扱い許可を剥奪されたことが分かりました。この男性は異議申し立てを行い、過剰な監視を「スペイン異端審問」に例えました。
AI生成の「ロボットポルノ」を政府のコンピューターに保存していた男性が核の機密情報にアクセスできなくなり「過剰な監視」に異議申し立て - GIGAZINE
加えて、「自身の個人的なドライブが雇用主のシステムに接続されていても、何らかの形で区切られており、個人用資料が政府支給のコンピューターを汚染することはないと考えていた」とも話したそうです。
AI生成の「ロボットポルノ」を政府のコンピューターに保存していた男性が核の機密情報にアクセスできなくなり「過剰な監視」に異議申し立て - GIGAZINE
⇧ どちらかと言うと、「アメリカの核兵器管理機関」のセキュリティ対策の杜撰さの方に驚きですが...
雇用主が業務用端末（外部のネットワークからアクセス不可）を支給していない意味が分からない...
とりあえず、
フールプルーフ (英: fool proof) とは、安全工学における用語のひとつで、工業製品やシステムを設計する際、誤操作や誤設定などの間違った使い方をしても、少なくとも使用者や周囲にとって危険な動作をしないように、あるいはそもそも間違った使い方ができないように配慮する設計手法のこと。英語では「壊したり間違えたりすることなく、誰でも簡単に使える」という意味を持つ、idiot-proofという言葉が使われることもある。
フールプルーフが目指す「誤用されない設計」とは、本質的に防御的な設計 (英: defensive design) となる。これは、「人間は往々にして間違いを犯すものである」という前提に立った考え方に基づいている。
⇧ 上記の思想が少しでもあれば、雇用主が業務用端末（外部のネットワークからアクセス不可）を支給すべきという結論になるはずなので、雇用主側の職務怠慢のような気もしてしまうのよ...
「GitHub」とかも、個人のプライベートな「アカウント」を業務で利用せざるを得ない状態で、業務用のソースコードが流出した事件が過去にありましたが、公私混同な状況を作り出している雇用主側の責任が問われないのは謎過ぎるのよ...
どちらにとっても「精神衛生上」良くないですし、本質的な業務ではないことに意識を向けざるを得ない状態で業務に取り組むことになるのは好ましくないと思いますしな...
Docker Composeはマルチテナント且つマルチユーザーでの利用は想定されない気がする...
公式の「Docker」のドキュメントの「Docker Compose」に関する部分を確認した限り、「プロジェクト名」を指定するオプション「-p」を利用すれば「マルチテナント」構成は実現できると思いますと。
ちなみに、「Docker」の「Compose」ファイル（docker-compose.yml的なもの）を配置する「ディレクトリ」を分離していれば、オプション「-p」を指定しなくても同様なことが実現できるっぽい。
ドキュメントに「デフォルト：directory name」、「default: the path of the, first specified, Compose file」って記載があるので。
■Docker Compose V1
■Docker Compose V2
⇧ 上記にある通り、
- Docker Compose V1
- Docker Compose V2
のどちらも、「-p」オプションは用意されている。
「Docker Compose V1」と「Docker Compose V2」の違いについては、
⇧ 上記サイト様が整理してくださっておりました。
話が脱線しましたが、表題の件にある、
- マルチテナント
- マルチユーザー
の両方を「Docker Compose」で実現するのは難しい気がする。
ネット上の情報を漁っていたところ、
⇧ stackoverflowで、
『Why doesn't Docker support multi-tenancy?』
という疑問が上がっていた。
いや、「-p」オプションを使えば、「マルチテナント」っぽいことができるのだけど...
「ChatGPT」氏に質問してみたところ、以下のような回答が返ってきた。
✔️ 推奨構成：プロジェクト名を「顧客 × ユーザー」で分ける
まぁ、「Docker Compose」だけで、
- マルチテナント
- マルチユーザー
を実現しようとすると、そうならざるを得ないのかもしれないが、現実的ではないのよな...
ライブラリの利用を視野に入れる場合は、以下のような方式があるっぽい。
🎯 結論
| 方法 | 実現可否 | コメント |
|---|---|---|
| TinyProxy 単体 | ❌ ほぼ不可能 | 動的ルーティング不可 |
| TinyProxy × 多重構成 | △ | あまりに複雑、スケールしない |
| Traefik | ✅ 最も適切 | Docker Compose との相性が最高 |
| Nginx + Lua | ◎ | 高機能だがコードが必要 |
| Caddy | ○ | 手軽で自動TLS |
そもそも、「Docker コンテナ」が軽量とは言え、数が増えてきたらリソースを逼迫することになりますからなぁ...
となって来ると、複数の「ユーザー」で「Docker コンテナ」を共有する感じになるんかね？
ただ、複数の「ユーザー」で共有するとなると、ファイルの更新系の処理とかで競合して、「スワップファイル」の発生が雨霰となりそう...
一般的に「ユーザー」毎に独立した操作をさせたいのであれば、何某の「ユーザー」を一意に識別することが可能な「情報」があると話が早いわけなのだが、「Google Colab（Google Colaboratory）」などは、「Google アカウント」毎に領域を確保している気がする。
「Google Colab（Google Colaboratory）」は、無償で利用できるのに「ユーザー」毎に「仮想マシン」を用意してくれているので、太っ腹な感じではありますな。
ネットの情報を漁っていたところ、
⇧ 上記サイト様で、メジャーどころの「クラウドサービスプロバイダー」における「仮想マシン」の料金の比較を整理してくださっておりました。
「Microsoft Azure」の値上げが際立ちますな...
| 2024年5月 | 2025年2月 | 2024年5月 | 2025年2月 | 2024年5月 | 2025年2月 | |
| クラウド | 最安 | 最安 | 2vCPU Linux | 2vCPU Linux | 2vCPU Windows | 2vCPU Windows |
| AWS | 1330 | 1374 | 13488 | 13937 | 23562 | 24347 |
| Azure | 1030 | 1573 | 16138 | 16416 | 27780 | 28520 |
| Google Cloud | 1322 | 1376 | 10443 | 10819 | 20517 | 21228 |
| OCI | 779 | 862 | 4151 | 5634 | 13734 | 16243 |
| さくらのクラウド | 2530 | 2530 | 11330 | 11330 | 13970 | 13970 |
まぁ、最安値でも、コストはかかるので、仮に「ユーザー」数が、10000人だったした場合、2025年2月時点の最安値の「OCI（Oracle Cloud Infrastructure）」で見積もってみると、
■最安値の「OCI（Oracle Cloud Infrastructure）」で10000台の仮想マシンを利用する場合の月額の見積もり
862（円/月） × 10000（ユーザー） = 8,620,000（円/月）
⇧ エグい金額になりますな...
話が脱線しましたが、つまり、「Docker Compose」環境で「マルチテナント」且つ「マルチユーザー」を実現するには、「ChatGPT」氏の回答にあるように、「顧客 × ユーザー」の「Docker Compose」環境を用意するしか無いという感じになるんかね...
現実問題として、「テナント」毎に「仮想マシン」を割り当てるのは許容範囲として、「ユーザー」毎に「仮想マシン」を割り当てるのは、余程、予算が潤沢にあるプロジェクトでもない限り、無理筋な気がしますと。
「Kubernetes」とかは「保守・運用」面で難ありな感じもするので、誠にもって悩ましい限りですな...
う～む...、「リソース」を提供せざるを得ないような「サービス」は設計が難しいのもさることながら、利益も上げにくいよね...
ただでさえ、円安の影響で「クラウドサービスプロバイダー」の「サービス」の利用料が高騰してますしな...
「地方自治体システム標準化」のコスト増の問題については、
⇧ 上記の『地方公共団体の基幹業務等システムの統一・標準化に関する関係省庁会議（第5回）（令和7年（2025年）6月16日開催）』で取り上げられているっぽいのだが、
⇧ とりあえず、「デジタル庁」の不手際なのに、「見積精査支援の拡充」とか謳っているのは「サイコパス」過ぎるんだが...
一般的な企業とかなら、訴訟を起こされてもおかしくないような気がしてしまいますな...
そして、「クラウドサービスプロバイダー」の「サービス」を利用している限り、「ランニングコスト」は計上され続けるので、「円安」の影響がダイレクトに響いて来ますしな...
そもそも、
⇧ 初手の構想段階の時点で、「課題」の優先順位が不明瞭なのよね...
「クラウドサービスプロバイダー」の「サービス」に切り替えたとて、「保守・運用」の業務が無くなるわけではないですしな。
『統一・標準化の効果を踏まえ、地方公共団体の情報システムの運用経費等については、標準化基準に適合した情報システムへの移行完了予定後の令和８年度
（2026 年度）までに、平成 30 年度（2018 年度）比で少なくとも３割の削減を目指すこととする。また、国の削減目標は令和７年度（2025 年度）までに令和
２年度（2020 年度）比で３割削減であることを踏まえ、削減目標の更なる上積みを目指す。 』
という「理想」を掲げるのは構わないのだが、根拠を示してもらわないとどうしようもないのよね...
言い方悪いかもしれないが、やっていることが詐欺師と変わらないので、提案になっていないのよな...
「プロジェクト」に参画してる「ステークホルダー」は、とばっちりもいいとこですよね...
どう考えても、「プロジェクト」を企画、主導していた
の責任だからなぁ...
「開発ベンダー」に責任転嫁してる発言は言語道断だよね。
毎度モヤモヤ感が半端ない…
今回はこのへんで。
