NVIDIAは7月17日(現地時間)、「Isambard-AI, the UK’s Most Powerful AI Supercomputer, Goes Live｜NVIDIA Blog」において、英国科学の転換点となるAIスーパーコンピュータ「Isambard-AI」の稼働開始を発表した。
Isambard-AIは英国における先端技術研究の主要拠点、ブリストル大学スーパーコンピューティングセンター(BriCS: Bristol Centre for Supercomputing)に設置された。同システムは英国内で最速かつ世界でもトップレベルのエネルギー効率を誇り、同国内の研究者や企業に新時代のコンピューティング環境をもたらすとして注目を集めている。
⇧ エネルギー効率にも配慮されているのは素晴らしいですな。
Azure Functionsの関数アプリの実行についてAzureネットワーク内外のどちらにも対応したいのだが...
実現したいこととしては、「Azure Functions」の「関数アプリ」に対して
- Azure ネットワーク外からのアクセス
- 要するに、Azure以外のサービスからのアクセス
- Azure ネットワーク内からのアクセス
- 要するに、AzureのAzure Functions以外のサービスからのアクセス
のどちらにも対応したいのだが、実現できるのかが分からない...
一応、
⇧ 上記のページでユースケースについて、「Azure」側が想定している「シナリオ」が公開されているのだが、
■ファイルのアップロードを処理するファイルのアップロードを処理する
■リアルタイム ストリームとイベント処理
■機械学習と AI
■スケジュールされたタスクを実行する
■スケーラブルな Web API を構築する
■サーバーレス ワークフローを作成する
■データベースの変更に対処する
■信頼性の高いメッセージ システムを作成する
⇧ 上記を見ても、「Azure Functions」の「関数アプリ」に対して
- Azure ネットワーク外からのアクセス
- 要するに、Azure以外のサービスからのアクセス
- Azure ネットワーク内からのアクセス
- 要するに、AzureのAzure Functions以外のサービスからのアクセス
のどちらにも対応できるのかどうかが分からない...
公式のドキュメントの「Azure Functions のネットワーク オプション」のページを見てみるも、
Azure Functions のネットワーク オプション
この記事では、Azure Functions のホスティング オプションで利用できるネットワーク機能について説明します。 以下に示すネットワーク オプションは、受信ネットワーク機能と送信ネットワーク機能として分類することができます。 受信機能を使用すると、アプリに対するアクセスを制限できます。一方、送信機能を使用すると、仮想ネットワークでセキュリティ保護されているリソースに接続でき、送信トラフィックのルーティング方法を制御することができます。
ホスティング モデルには、さまざまなレベルのネットワーク分離機能があります。 正しいものを選択することで、ネットワーク分離の要件を満たすことができます。
⇧ 結局のところ、知りたい情報に辿り着かない...
「FAQ（Frequently Asked Questions）」のページを見るも、
⇧ どちらも対応する方法については記載がない...
とりあえず、
『仮想ネットワーク内のリソース、および、仮想ネットワーク外（Azure以外のクラウドサービス、オンプレミス環境など）から関数アプリをトリガーする解決策を掲載してください。』
と「フィードバック」を送ったけども、おそらく対応されないだろうな...
ちなみに、
⇧ 回答のテンプレートにある、
『フィードバックには回答できませんが、Microsoft のチームは、お客様のコメントをエクスペリエンスの改善に活用させていただきます。』
の文言の信憑性が全く無いのよね...
まぁ、公式の「ドキュメント」の「ファインダビリティ（Findability）」が1mmたりとも改善される兆しが無いところを見るに、「貴重なフィードバック」というものは全くもって活用できていないんだろうなぁ...
大企業だから、販売促進活動に血眼になる必要がないほど余裕があるのかもしれないが、「ユーザー」は離れていくことになるよね...
ネットの情報を漁っていた限りでは、
ちょっと話がずれるのですが、Azureは○○と××の機能は共存できないという事がちょくちょくあります。（そしてドキュメントに書いてあるとは限らない）
これとこれを組み合わせれば実現できそうだなという考え方が通用せず、作った後に想定外の事象が発覚することもざらで困ります。。
前述のAzure Storage アカウントのNW制限を行う際、「WEBSITE_VNET_ROUTE_ALL=1」というパラメータを設定しました。
加えて、これはグローバルIP向け通信をVnetに向ける場合にも必要です。デフォルトではプライベートIP向け通信のみがVnetに向きます。
なので、セキュリティポリシーで無制限なインターネットアクセスは許容しないという場合も「WEBSITE_VNET_ROUTE_ALL=1」が必要です。
では、どうしたら良いかと聞いたところ…
NSG全開放ですよｗ
どちらもセキュリティ上必要なのに、組み合わせるとなぜガバガバになるのか。コレガワカラナイ
⇧ 何やら、「セキュリティ」がガバガバにならざるを得ないという話が...
「Azure Functions」は「サービス」として破綻しているってことなんですかね...
実用に耐えない感じになるとか、公式の「ドキュメント」に記載がない時点で公式の「ドキュメント」は「一次情報」としての意味が無いのよね...
ちなみに、Wikipediaの内容については、
ウィキペディアに執筆してよいかどうかの基準は「真実であるかどうか」ではなく「検証可能かどうか」です。つまり、私たちがウィキペディアで提供するのは、信頼できる情報源（ソース）を参照することにより「検証できる」内容だけだということです。このことをウィキペディアでは検証可能性 (Verifiability, V) と呼んでいます。
検証可能性は、ウィキペディアの内容に関する三大方針の一つです。あとの二つは、「中立的な観点」と、「独自研究は載せない」です。ウィキペディアではこれらの方針を併せて標準名前空間、つまり記事に書くことができる情報の種類と質を決定しています。これら三つの方針は相互に補完しあうものであり、それらをばらばらに切り離して解釈すべきではありません。編集者はこれら三つの方針を併せて理解するよう努めてください。この三つの方針は議論の余地がないものであり、他のガイドラインや利用者同士での合意によって覆されるものではありません。
⇧ 上記にあるように、「検証可能な情報源」が重要とあるのだが、「Azure」の「ドキュメント」のように「透明性」が担保されていないような情報の扱いは難しいと思う...
「Azure」の「ドキュメント」については、「一次情報」の時点で情報の欠落が著しいので、手の施しようが無い気はする...
言い方は悪いのだが、「Azure」側が意図的に「偽装工作」してるのと変わらない気がしてしまうのだが...
やましいことが無いなら、公式の「Azure Functions」の「ドキュメント」に、
- 実現できること
- 実現できないこと
は、遍く明記すべきですしな...
そもそも、「FAQ（Frequently Asked Questions）」でお茶を濁す運用を止めて欲しい気はしますな...
結局のところ、「要件」が公式の「ドキュメント」で網羅できていないんよね...
う～む、「Microsoft」の公式の「ドキュメント」に「ファインダビリティ（Findability）」を求めるのは酷な話なのだろうか...
ここまで酷い公式の「ドキュメント」になってしまう理由が単純に知りたいのだが...
誠に遺憾であるのだが、「Microsoft」の「ドキュメント」は、
計算機科学において、Garbage In, Garbage Out（ガービッジ・イン、ガービッジ・アウト／ガベージ・イン、ガベージ・アウト）、略してGIGOとは、欠陥のある、または無意味な（garbage）入力データは無意味な出力を生み出すという概念である。直訳は「ゴミを入力するとゴミが出力される」。すなわち、「『無意味なデータ』をコンピュータに入力すると『無意味な結果』が返される」という意味である。Rubbish in, rubbish out (RIRO)とも表現される。
⇧ 上記を体現してしまっているのよね...
大企業だからこその誠実さの欠片もない横暴がまかり通っているのかもしれないですが、「ユーザー」のこと全く考慮していないんだろうなぁ...
「Azure」の「サービス」の「開発プロジェクト」に従事している開発者にとっては、気楽で良い環境なのかもしれないですが...
業務で避けようが無いというのもあるのだが、「Azure」の「サービス」を利用せざるを得ないのが「ストレス」しか無いのだが...
情報が散逸している公式の「ドキュメント」を読んで、知りたい情報が手に入らない可能性が高いからして、「ストレス」が蓄積されることが確定しているので、本当に割に合わない...
毎度モヤモヤ感が半端ない…
今回はこのへんで。
