量子テレポーテーションとは、2つのもつれ状態にある光子を利用して、2点間で情報を転送させる技術のことです。
この技術の中核となっているもつれ状態の光子は、非常に不安定なため長距離を移動させることが技術的に困難でした。
しかし、オランダ・デルフト工科大学（QuTech）の研究チームは、もつれ状態の光子を、中継地点で別のもつれ状態の光子と相互作用させることで、3点間でもつれ状態を共有させることに成功しました。
⇧ amazing...
Azure Database for PostgreSQLとは？
公式のドキュメントによりますと、
Azure Database for PostgreSQL is a relational database service in the Microsoft cloud based on the PostgreSQL open source relational database.
https://docs.microsoft.com/en-us/azure/postgresql/single-server/overview
Azure Database for PostgreSQL powered by the PostgreSQL community edition is available in three deployment modes:
- Single Server
- Flexible Server
- Hyperscale (Citus)
https://docs.microsoft.com/en-us/azure/postgresql/single-server/overview
⇧ Microsoft AzureのマネージドなPostgreSQLサービスとあり、作成時に3つの選択肢がある模様。
PostgreSQLをAzure向けに手を加えた感じなんですかね？
⇧ 上記サイト様によりますと、「PaaS（Platform as a Service）」の1種ということらしい。「RNG (Regional Network Gateway)」もよく分から～ん...
ちなみに、「IaaS（Infrastucture as a Service）」の1種である「Azure Virtual Machines」で「仮想マシン」を作成して「仮想マシン」にPostgreSQLをインストールする方法でもPostgreSQLは利用できる模様。
Azure Database for PostgreSQLとAzureのネットワーク
で、Azureのネットワークについては、
Azure のネットワークは、大きく 4 種類に分かれます。
⇧ 上記サイト様が詳しいです。
たまに Azure Storage や SQL Database 等の PaaS に対して VPN 接続したいという話を聞きますが、VPN 接続出来るのは VNET のみですので、Public IP の世界に接続したい場合には ExpressRoute の Microsoft Peering が必要です。(もしくは、App Service Environment や SQL Database Managed Instance のように VNET 内に専用のインスタンスを建てられる上位プランを使用する必要があります。)
⇧「Azure Database for PostgreSQL」のような「PaaS（Platform as a Service）」に接続する方法としては、
- VNET
- Public IP
の2つの方法があるってことのよう。
踏み台サーバー経由によるSSHトンネルでの接続
そもそも、VNETとは？
Azure Virtual Network (VNet) は、Azure 内のプライベート ネットワークの基本的な構成要素です。 VNet により、Azure Virtual Machines (VM) などのさまざまな種類の Azure リソースが、他の Azure リソース、インターネット、およびオンプレミスのネットワークと安全に通信することができます。
https://docs.microsoft.com/ja-jp/azure/virtual-network/virtual-networks-overview
⇧ とあり、「Azure Virtual Network」の略で、オンプレミスの環境から安全に通信するのに必要らしい。
外部から「Azure Database for PostgreSQL」に接続する方法としては、
Azure Database for PostgreSQL - フレキシブル サーバー インスタンス ("フレキシブル サーバー") を作成する際、次のいずれかのネットワーク オプションを選択する必要があります: プライベート アクセス (VNet 統合) またはパブリック アクセス (許可された IP アドレス)。
https://docs.microsoft.com/ja-jp/azure/postgresql/flexible-server/concepts-networking
⇧ とあるので、参考サイト様の情報が正しそうです。
公式のドキュメントで、「プライベート アクセス」で接続する方法の説明があり、
[ネットワーク] タブに移動し、 [プライベート アクセス] を選択します。 サーバーの作成後に接続方法を変更することはできません。
サーバーは仮想ネットワーク内にあるので、サーバーと同じ仮想ネットワーク内にある他の Azure サービスからしかサーバーに接続できません。 サーバーに接続して管理するために、Linux 仮想マシンを作成してみましょう。
⇧ とあることから、何かしらの「Azure サービス」を経由させないといけいない模様。
一般的に、
SSH tunneling is a method of transporting arbitrary networking data over an encrypted SSH connection. It can be used to add encryption to legacy applications. It can also be used to implement VPNs (Virtual Private Networks) and access intranet services across firewalls.
https://www.ssh.com/academy/ssh/tunneling#what-is-an-ssh-tunnel?
⇧「踏み台サーバー」を経由した「SSH トンネリング」なんかの手法がありますが、「プライベート アクセス」での「Azure Database for PostgreSQL」の接続については「踏み台サーバー」を経由した「SSH トンネリング」を行ってるということですかね。
Azure Database for PostgreSQLにローカル環境からSSH接続してみる
まずは、Azure Portalにログインし、「すべてのサービス」を選択。
「Azure Database for PostgreSQLのフレキシブル サーバー」を選択。
「Azure Database for PostgreSQLのフレキシブル サーバーの作成」を選択。
「プライベート アクセス(VNET 統合)」を選択し、「確認および作成」。
「作成」。
続いて、「仮想マシン」を作成。
「作成」を選択。
「Azure 仮想マシン」を選択しました。
「基本」タブで情報を入力し、「ネットワーク」タブを選択。
「サブネット構成の管理」を選択。
「＋サブネット」を選択。
で、「サブネット」が作成できないのですが、
⇧ 上記サイト様を参考に確認したところ、「アドレス空間」と「サブネット」が同じ値になってしまっていたので、「アドレス空間」を修正しました。
「サブネット」を追加で。
「秘密キーのダウンロードとリソースの作成」を選択。
⇧ ダウンロードされた秘密キーはローカル環境の適当な場所に配置しておきます。
Azure Portalで仮想マシンの作成が完了したら「リソースに移動」を選択。
「パブリックIPアドレス」をコピペしておきます。
ローカル環境から「Azure Database for PostgreSQL」に接続してみます。
「A5:SQL Mk-2」というツールを利用して接続していきます。
「データベース」を選択した状態で右クリックし、「データベースの追加と削除(D)...」を選択。
「追加(A)」を選択。
「PostgreSQL（直接接続）（P）」を選択。
「基本」タブには「Azure Database for PostgreSQL のフレキシブル サーバー」作成で設定した値を設定します。
「SSL」タブは「SSL モード」を「優先（SSL接続を優先）」にし、「サーバー証明書を信用する」にチェックを入れてます。
「SSH2トンネル」タブは、「SSH2ホスト名」に「仮想マシン」の「パブリックIPアドレス」を設定。「ユーザーID」は「仮想マシンのユーザー」の値ですがデフォルトだと「azureuser」になってるようです。「秘密鍵ファイル」で「仮想マシン」作成時にダウンロードされた秘密キーを指定します。
で、「テスト接続」で接続できればOK。
設定が済むと、サイドバーに表示されるので、右クリックし「データベースを開く(O)」を選択。
「Azure Database for PostgreSQL」のログインの際の「パスワード」を入力し「接続」。
接続できました。
ネットワーク周りどうするのが良いのかサッパリ分からんです...
現在の日本国内の社内ネットワークなどで最も使用されているサブネット化は、クラスAまたはクラスBのネットワークで「ホスト部を 8 ビットだけにする」というパターンです。
つまり、1つのネットワークに最大254台のホスト数が、ブロードキャストの分割、IPアドレス計画、ルーティング設計、セキュリティの観点から最も都合が良いからです。
また、クラスCではネットワークアドレス数が最大 256 と拡張性がないことから大企業でのクラスC採用は少なく、またクラスCのサブネット化についてもあまりないのが実情です。
⇧ 上記サイト様によりますと、日本国内だと、クラスA、または、クラスBのネットワークが一般的のようです。
モヤモヤ感が半端ない...
とりあえず、課金が怖いので「Azure Database for PostgreSQL」と「仮想マシン」は停止しておきましたが、使わない場合、削除しておいたほうが良いと思います。
今回はこのへんで。
