プラットフォームマネジメントでは、ソフトウェア開発の効率化と技術的負債の管理が課題となる。広木氏はこれを「ソフトウェアを効率的に開発発展させるための基礎と土台を管理し、開発者体験を向上させること」と定義した。
「4つのP」でひも解くエンジニアリングマネージャーの仕事、そして生成AI時代の戦い方 (2/3)|CodeZine（コードジン）
そのうえで「早期に不具合を発見することで、修正コストを大幅に削減できる」と説明し、リリース後の修正は開発初期の30倍以上のコストがかかるというデータを示した。この「シフトレフト」と呼ばれるアプローチは、品質管理を開発プロセスの早い段階に移動させる考え方だ。CI/CDや静的解析、SAST/IASTといった技術投資により、品質が自動的に担保される環境を構築する。
「4つのP」でひも解くエンジニアリングマネージャーの仕事、そして生成AI時代の戦い方 (2/3)|CodeZine（コードジン）
広木氏は「失敗できる環境を技術的に作ることが、プラットフォームマネジメントの重要なテーマ」と語った。これを「コード修正の心理的安全性」と言い換え、修正しても間違ったものが簡単にはリリースされない状況であれば、多くの人がリスクを取って挑戦できると説明した。
「4つのP」でひも解くエンジニアリングマネージャーの仕事、そして生成AI時代の戦い方 (2/3)|CodeZine（コードジン）
技術的負債の管理も重要な課題だ。広木氏は「技術的負債の問題は、見えるものと見えないものの非対称性から生じる」と指摘し、CT検査の例を用いて説明した。医師はCT画像で内部の問題を見ることができるが、もしもCT画像がなく外見だけ見れば健康と判断するかもしれない。ソフトウェアも外から見ると問題がないように見えても、内部では深刻な問題を抱えていることがある。
「4つのP」でひも解くエンジニアリングマネージャーの仕事、そして生成AI時代の戦い方 (2/3)|CodeZine（コードジン）
そこでソフトウェアの要素を「見える／見えない」と「プラス価値／マイナス価値」の2軸で分類。「新機能は見えるプラス価値、バグは見えるマイナス価値、アーキテクチャや開発者体験は見えないプラス価値、そして技術的負債は見えないマイナス価値」と整理した。これらの見えない要素を可視化するために、「静的解析」「アーキテクチャテスト」「ADR（Architecture Decision Records）」などの手法を活用することが重要だと提言した。
「4つのP」でひも解くエンジニアリングマネージャーの仕事、そして生成AI時代の戦い方 (2/3)|CodeZine（コードジン）
⇧ どれも周知の事実であって全エンジニアが理解していることだとは思うのだが、「環境構築」のコストが高過ぎて実現できないというのが現状なのよね...
記事の内容を見たわけでは無いので何とも言えないのだが、
「しかるべき確認手順を経ずに記事が公開されたため」――本田技研工業（ホンダ）は、同社のソフトウェアエンジニアが、社内環境などを赤裸々につづった公式ブログの記事を公開翌日に削除した理由について、削除から2日経った5月22日にこう釈明した。
削除された記事は、19日公開の「ソフトウェアエンジニアがHondaに転職して感じたこと4選」。転職2年目のエンジニアが執筆していた（関連記事：「ソフトウェア開発インフラが整ってない」――“赤裸々すぎ”と話題のホンダテックブログ、突然の記事削除 「逆に印象悪い」の声も）。
⇧「ソフトウェア開発インフラ」の構築・管理について、気軽に実現できるものではないということで、
広木氏は「失敗できる環境を技術的に作ることが、プラットフォームマネジメントの重要なテーマ」と語った。これを「コード修正の心理的安全性」と言い換え、修正しても間違ったものが簡単にはリリースされない状況であれば、多くの人がリスクを取って挑戦できると説明した。
という「理想」と真っ向から対立している...
「理想」を実現するための「環境構築」の実現が不可能というジレンマ...
誰でも容易に試行錯誤できる環境を作ることのハードルが高過ぎるのよね...
エンジニアとしては、ストレスが溜まるよね～...
Azureのプライベート エンドポイントって結局IPアドレスだけで接続できずDNS経由が必須なのか...
「Azure テクニカル サポート チーム」の方の公開している情報で、
基本動作
Azure PaaS は基本的にパブリック インターネットからの接続を前提としています。また、ほとんどの Azure PaaS がマルチテナント構成となり、ご利用時に接続する際は、対象の Azure PaaS に該当する FQDN で接続します。
⇧ 基本的に「Azure」の「PaaS（Platform as a Service）」については、「インターネット」を介する接続になるらしい。
「インターネット」を介するのは「セキュリティ」上、好ましくないということだとは思われるのだが、「プライベート エンドポイント」という仕組みが用意されているらしい。
概要
プライベート エンドポイントは主に Azure PaaS に対して、仮想ネットワーク上のアドレス空間のプライベート IP アドレスを用いて接続を提供するサービスです。
プライベート エンドポイントをご利用いただけば、Azure PaaS に対して、ExpressRoute や VPN で接続されたオンプレミスからもインターネット経由ではなく仮想ネットワーク経由で接続が可能です。
⇧ 上記によりますと、
『インターネット経由ではなく仮想ネットワーク経由で接続が可能』
とのことらしい。
■プライベートエンドを利用しない場合
■プライベートエンドを利用した場合
⇧ う～む...
「プライベート エンドポイント」を利用した場合の、
- VNet
- PaaS
間の経路が気になるのだが...
結局のところ、
⇧ 上図の「薔薇色」で囲った部分は、「インターネット」に出てることになるのでないのなら、何なのか？
図に表れていないだけで、「Azure」の「Azure 仮想ネットワーク（Azure VNet：Azure Virtual Network）」の中の話になるのか？
まぁ、謎が深まるばかりなのだが、図で「TCP 接続」とあったので「名前解決（DNS：Domain Name System）」でなくても「IPアドレス」で接続できるのかと思ったのだが、
なお、プライベート エンドポイントの利用にあたり、プライベート DNS ゾーンの利用は必須ではありません。DNS レコードのオーバーライドができれば hosts ファイル、カスタム DNS、オンプレミスの DNS などでも DNS ルーティングが実現可能です。
例えば、仮想マシンの OS 上の hosts ファイルで、接続先の FQDN に対して、プライベート エンドポイントの IP アドレスを指定することでも構成可能です。
⇧「DNS ルーティング」が必須っぽいので、「IPアドレス」のみの「TCP 接続」ってのには対応していないらしい...
「hosts ファイル」というのは、「Linux」だと「/etc/hosts」のことを言っているのだと思うのだが、
「/etc/hosts」ファイルは、ホスト名とIPアドレスを対応させるためのファイルです。
さて、DNSのことを学んでいる方であれば、ここで「それはDNSに対応していれば、DNSがやってくれることでは？」と思うことでしょう。その通りです。/etc/hostsの存在を理解するには、その歴史的背景を理解しておく必要があります。
DNSサーバを構築設定するほどでもない小規模な検証環境などでは、各ホストの/etc/hostsを設定すれば名前解決が行えます。ただし、ほとんどのディストリビューションではDNSよりも/etc/hostsを優先して名前解決を行います。実在するホスト名を/etc/hostsに記述した場合には、想定外のIPアドレスが返ることでホストにアクセスできない（別のIPアドレスに接続しようとする）ことがあるので、注意が必要でしょう。
⇧ とあるように、「名前解決（DNS：Domain Name System）」の仕組みを使っていることには変わらない。
そもそも、「TCP 接続」の定義がハッキリしないのだが、
⇧ 上記サイト様によりますと、「TCP 接続」は「通信」の内訳によって必要な情報が変わって来るっぽい。
と言った感じで様々な「通信プロトコル」があるので、「TCP 接続」と言っても、
のどちらを利用してのことを言っているのかが分からない...
「Azure テクニカル サポート チーム」の方の説明が正しいとするならば、「Azure プライベート エンドポイント」については、「名前解決（DNS：Domain Name System）」の仕組みが必須っぽいので、「IPアドレス」のみの接続はできないということらしい...
「Azure プライベート エンドポイント」の仕様がいまいちハッキリしないのよね...
公式のドキュメントを見る限りでは、
プライベート エンドポイントへの接続
プライベート エンドポイントを使用する VNet 上のクライアントは、パブリック エンドポイントに接続するクライアントと同じ接続文字列をストレージ アカウントに対して使用する必要があります。 プライベート リンク経由の VNet からストレージ アカウントへの接続を自動的にルーティングするために、DNS 解決に依存しています。
https://learn.microsoft.com/ja-jp/azure/storage/common/storage-private-endpoints
⇧「ストレージアカウント」を必要とする「Azure Storage」系の「リソース」に対して「プライベート エンドポイント」による接続をする場合は、
『DNS 解決に依存しています。』
とあるので、「名前解決（DNS：Domain Name System）」が必須らしい。
なのだが、「プライベート エンドポイント」自体の仕様については、
DNSの構成
プライベート リンク リソースへの接続に使用する DNS 設定は重要です。 既存の Azure サービスには、パブリック エンドポイント経由で接続するときに使用できる DNS 構成が既に存在している場合があります。
https://learn.microsoft.com/ja-jp/azure/storage/common/storage-private-endpoints
プライベート エンドポイントで同じサービスに接続するには、別個の DNS 設定が必要になります。この設定は多くの場合、プライベート DNS ゾーン経由で構成されます。 接続に完全修飾ドメイン名 (FQDN) を使用するときは、DNS 設定が正しいことを確認してください。 設定は、プライベート エンドポイントのプライベート IP アドレスに解決される必要があります。
https://learn.microsoft.com/ja-jp/azure/storage/common/storage-private-endpoints
⇧「名前解決（DNS：Domain Name System）」の仕組みが必須とは明示的に記載されていないのよね...
もしも、
⇧ 上記のページに記載の「Azure サービス」が、
『既存の Azure サービスには、パブリック エンドポイント経由で接続するときに使用できる DNS 構成が既に存在している場合があります。 』
のことを言っているのだとしたら、「プライベート エンドポイント」接続をする場合は、ほぼ、全ての「Azure サービス」について「名前解決（DNS：Domain Name System）」を別途用意する必要があることになる気がする...
毎度モヤモヤ感が半端ない…
今回はこのへんで。
