軽い気持ちで Power BI から Azure SQL Database に接続したかった。
テナントID が 00000... という謎のエラーで認証が通らなかった。
AADSTS900021: Requested tenant identifier '00000000-0000-0000-0000-000000000000' is not valid. Tenant identifiers may not be an empty GUID.
Azure SQL Database に Active Directory 管理者 を設定する。
エラー番号でググったらこのサイトに当たりました。ありがとう。
Azure にて Virtual Network NAT というサービスがパブリックプレビューになり、AWS や GCP と同等の構成を行うことが可能になりました。
Azure では Virtual Network NAT を使うという選択肢が増えたとお考え下さい。
この記事は Azure Advent Calendar 2019 の 11 日目です。 qiita.com
Microsoft Azure では Private IP から Public IP への通信は基本的に自動で NAT 変換が行われます。 Microsoft のドキュメントでは NAT ではなく、 SNAT と明記されることが多いようです。
Source NAT, 送信元 NAT と呼ばれます。
SNATとは、2つのTCP/IPネットワークの境界にある機器が双方のIPアドレスを自動的に変換するNAT（Network Address Translation）のうち、送信元アドレスを書き換える方式。
(中略)
SNATは組織内のLANなどでプライベートアドレス（ローカルアドレス）しか持たないパソコンなどが、ネットワーク境界の機器が持つグローバルアドレス（インターネット上のアドレス）を使って外部と通信するためによく用いられる。
具体的な例では Public IP を持たない VM がインターネットにアクセスしようとするときに SNAT 変換が行われます。
私が調べた限りですと、 Azure だけちょっと特殊に見えました。それぞれ具体的に見ていきましょう。
VPC を使用して、 Public IP を持たない EC2 インスタンスがインターネットにアクセスするためには、 NAT Instance と呼ばれる EC2 を別途作成するか、またはマネージドな NAT Gateway を使用します。
2019年12月現在、 NAT Instance を積極的に採用する理由はあまりなさそうに思えたので、 NAT Gateway を利用した場合のイメージを作成しました。正確に書くと Router が入るようですが、説明を簡素化するため省略しました。
このとき、NAT Gateway と Elastic IP が課金されます。
GCP の場合も AWS とほぼ同様に見受けられました。
こちらの情報が大変参考になりました。
料金は AWS とほぼ同様のようです。
Azure の場合は NAT Gateway を用意しなくても SNAT 変換されます。
公式ドキュメント のシナリオ３相当になるのですが、宇田さんの記事がよりわかりやすいです。
以下のように Azure の NAT は3種類のパターンに分かれます。
Azure の良い特徴でもあり、悪いところかもしれません。ほかのクラウドを使っていた人からするとちょっと戸惑うと思います。
明示的に SNAT Gateway のような機能を用意しなくても暗黙的に SNAT がされます。料金はかかりません。
他のクラウドのように SNAT Gateway のようなものを作りたければ、先の2のパターンになり、外部 LB が NAT Gateway 兼 Load Balancer のように動作します。
SNAT ができる数は限られていまして、枯渇すると単純に通信ができなくなります。数年前の自宅用ルーターではわりとよく起きていたと思います。
クラウドにおいても、当然利用できるポートは限られています。
外部 LBを立てた場合です。
アプリ上でプログラミングを工夫することで SNAT の消費を避けることができます。以前書いた記事を参照してください。
しかしながら、個人的に懸念しているのは、昨今のアプリはコンテナ化により 1 VM 上で動作する個々のアプリは増加しており、それぞれのアプリは独立したコンテナ上で動いているため、使用する SNAT 数は爆発的に増えていると考えています。つまり、各コンテナ間で SNAT を共有するプールのような仕組みは無いため、 マイクロサービスのように Public IP で外部サービスを多数利用する場合、 SNAT の枯渇はかなり起きやすい問題では？ と考えています。
まだ自分の中での仮説にすぎないので、今後この問題に直面した時に、なんらかの解があればまたブログなどにしたいと思います。
今回は Azure だけでなく、AWS と GCP も加えましたので、皆さんの参考になれば幸いです。
この記事は Microsoft Azure Advent Calendar 2018 の 10 日目の記事です。
12/4 に 発表されたばかりの Azure Kubernetes Service(AKS) 向けの機能です。
名前の通り仮想ノードです。Kubernetes ではノードを常に立ち上げておく必要がありますが、virtual nodes では必要なときのみノードを立ち上げることで、バーストの対応や料金の節約が期待できます。
ザックリいうと、「Kubernetesノードのサーバーレス化」です。
Azure には従来から virtual kubelet というものが用意されています。
両者の違いは、自動で追加するか、手動で追加するかの違いです。
virtual nodes の実装は virtual kubelet です。従来の通り、 virtual nodes を使用せず、 virtual kubelet を手動で使用することもできますが、今後は virtual nodes を使用して、 AKS でマネージドしてもらうほうが手間いらずで便利なのではと思います。
なお、余談ですが、virtual kubelet は CNCF プロジェクトになり、Azure 以外にも AWS Fargate などでも使用できます。
こちらの手順に沿って実行していきます。Azure CLI とポータルを使用するパターンがあります。ポータルから作成しました。
virtual nodes (preview) オプションを有効にして、 AKS を作成します。1点注意として、virtual nodes をサポートしているリージョンは複数あるのですが、US系は一部問題が発生しているらしく、 West Europe を選択しました。
デプロイを行うとおよそ8分くらいで AKS が出来上がります。
ポータルから Monitoring - Insight(preview) にて確認すると virtual Node らしきものが表示されています。
次の yaml を デプロイします。
apiVersion: apps/v1 kind: Deployment metadata: name: aci-helloworld spec: replicas: 1 selector: matchLabels: app: aci-helloworld template: metadata: labels: app: aci-helloworld spec: containers: - name: aci-helloworld image: microsoft/aci-helloworld ports: - containerPort: 80 nodeSelector: kubernetes.io/role: agent beta.kubernetes.io/os: linux type: virtual-kubelet tolerations: - key: virtual-kubelet.io/provider operator: Exists - key: azure.com/aci effect: NoSchedule
ポイントは nodeSelector と tolerations で virtual-kubelet が指定されています。この点からも virtual-kubelet がベースであるということがわかります。
デプロイ方法は kubectl apply -f virtual-node.yaml を実行します。
およそ2分くらいで Running になりました。Azure Container Instances(ACI) の立ち上がる速度に依存します。早いときは30秒前後ということもありました。
デプロイしたインスタンスは AKS の内部IPなので、外部からアクセスできません。チュートリアルに沿って、 AKS 上にもう一つインスタンスを動かして curl で確認します。
インスタンス作成
kubectl run -it --rm virtual-node-test --image=debian
curl で動作確認
apt-get update && apt-get install -y curl curl -L http://10.241.0.4
curl の実行結果に HTML が表示されているのが確認できました。
AKS の Monitoring - Insight(preview) にて実際に動作している ACI を確認できます。こちらも便利な機能ですね。
リソースグループには ACI インスタンスが表示されていました。
後始末をしてみます。
kubectl delete -f virtual-node.yaml で deployment を削除します。
pod は即消える。(ここに表示されているのは動作確認時にcurlで使用したpod)
ACI も即消える。
Monitoring - Insight(preview) にはまだ残っていました。こちらはタイムラグがあるようです。
virtual nodes は手軽に利用可能で、利便性が高そうです。まだ preview 段階ですが、積極的に使用していきたいと考えています。スピンアップがミリ秒単位になれば KNative などと組み合わせて、サーバーレス環境を構築するのも面白そうですね。
今回のリリースでは Azure の VMSS(Virtual Machine Scale Sets) の対応がされました。これにより今までより早くノードが展開できることと、OSイメージによるノードの管理ができることが期待できます。
リリースの詳細はこちらの記事を参照してください。
記事に書いてあるとおり、ACS(Azure Container Service) Engine ではすでに使えるようになっています。
AKSの対応はまだですが、AKS の Service Level Objective (SLO) によるとマイナーバージョンアップは30日以内に対応するとあるので、今月末には使えるようになると思われます。
SLO の詳細はこちらの記事を参照してください。
ACS Engine の作成方法などは後回しにして、結果から書きます。
検証環境はSouthEastAsiaで行いました。次の結果です。
| 変更前ノード数 | 変更後ノード数 | デプロイ時間(mm:ss) |
|---|---|---|
| 2 | 5 | 02:17 |
| 5 | 30 | 03:54 |
| 5 | 30 | 04:08 |
| 1 | 30 | 04:16 |
| 30 | 5 | 01:47 |
| 30 | 1 | 02:52 |
| 30 | 1 | 02:18 |
ノード数を増やす操作が少数の場合が2分台、30台ほどで4分台という感じです。 ノード数を減らす操作は1分〜2分というところです。
十分高速かなと思います。
下記サイトを参照して行いました。詳細を書こうと思ったんですが力尽きました。。。 また別の機会に書きたいと思います。
VMSS 対応でデプロイとノードのアップデートがやりやすくなりそうです。
とはいえ、ノードを増やすのに4分程度はかかるので、瞬間的なスパイクはまだオートスケールでは対応しきれないと思います。 その点は Virtual-Kubelet で、ACI(Azure Container Instances) を使用すると瞬時にインスタンスが立ち上がるのでカバーできるかもしれません。
オートスケールについて、後日また検証したいと思います。
ラジオ聞いてて真壁さんのお話で思い出したんですが、Ephemeral OS Disk in limited preview にてこう書いてありました。
Ephemeral OS Disk, a new type of OS disk created directly on the host node, providing local disk performance and faster boot/reset time.
明確にブートが早くなると書いてありましたね。ノード増やしたときのブート時間は今後もっと縮まる可能性が高いかもです。
Kubernetes に適用できるかはわかりませんが、早速プライベートプレビュー申し込んでみました。
Azure のディスク性能は Ultra SSD にて 160K IOPS と劇的上がっています。
また、シングル VM において Windows Hyper-V 環境では 10-Million IOPS という研究もされているようです。
Azure Ephemeral OS DiskってIaaSの使い方だけじゃなく、その上で動くPaaSにもインパクトあるんですよね。 なおローカルで爆速なストレージを、って背景はこの辺を読むとニヤニヤできます。 [PDF] Achieving 10-Million IOPS from a single VM on Windows Hyper-V https://t.co/bVgMyBJZ5Q
— Toru Makabe (@tmak_tw) October 5, 2018
クラウドはディスクが遅いと思われるかもですが、そろそろ逆転するかもしれませんね。
なんとCFPが通りまして、JAPAN CONTAINER DAYS V18.12に登壇させていただけることになりました。嬉しい限りで本当に皆さんのおかげだなと思います。CFPの内容は次の通りです。
Jenkins x Kubernetesが簡単だと思ったら大変だった話
昨今、コンテナやkubernetesに対応したCI/CDツールはたくさんありますが、古くからあるJenkinsも当然対応しています。今回はプロダクション環境で実際に使用した経験から、Dockerビルドの苦労話や、Declarative Pipelineでコード化することでいわゆる「Jenkinsおじさん問題」を解決したことをお話しします。
また、Jenkinsを実際運用するにあたって、パブリッククラウドの比較や連携方法も合わせてお話しします。
理由は２つあると考えました。
JAPAN CONTAINER DAYSはベンダー主催ではない公平な場であり、規模も自分にとってはde:code以来の大きさだと思いますので、自分の実力を試したいという気持ちがありました。なので、1つ目の理由は誰かのためというよりは自分のためですね。
私はMicrosoft AzureのMVPなので、普段はMicrosoft系のコミュニティに参加することが多いです。コミュニティは「常連さん」みたいな感じで知り合いも多く、楽しいですし、とても居心地が良いです。しかし、そのままでは結局「内輪ウケ」にとどまってしまうと思い、Microsoft系以外のコミュニティに参加することがとても大事だと常々考えています。これはなにも突然思いついたことではなく、過去にも様々なコミュニティに参加させていただきました。
つまり、もう一つの理由はMicrosoft系ではないコミュニティに参加することで、Microsoft Azureを普段リーチできない層に訴えかけることができる。と考えています。
今回はAzure色はほとんどなく、CI/CDの考え方。kubernetesとどう連携させるか？その際ハマるポイントはどこか？という点をお伝えして、皆様が実際に構築・運用する際のヒントを持ち帰っていてだければと思っています。
CFPに書いていたパブリッククラウドの比較については、主題から離れてぼやけてしまうのと、４０分にしてはちょっと盛り込みすぎ感がありますので、セッション構成上もしかしたら削ってしまうかもしれません。すみません。たとえ削ったとしても、それはそれでまた別な機会にお話させていただければと思います。
12月は皆様にお会いできることを楽しみにしています。どうぞよろしくおねがいします！
申込みはこちらから！
Test Driven Development Boot Camp(TDDBC) 、テスト駆動開発のブートキャンプを10/20(土)に仙台で行います。気づいたら今年で8回目で震災後から毎年開催し、毎年TDD の伝道師、和田卓人(@t_wada)さんに来ていただいています。
仙台の方も、遠方の方も是非お越しください。
