Azure Route ServerとNVAの構成でのハマりどころについて

背景と目的

Hub & Spoke構成のAzure環境で、インターネットやオンプレ拠点との接続用にSASE製品を組み合わせる検証作業をやっていました。

以前はSASE製品の収容をVPN Gateway経由で行っており、BGPで受け取った経路はGateway伝達によりVNetに自動的に反映されていました。拠点増減時に設定変更する必要があるため、今回の構成検討と至ったものみられます（この構成検討は別チームで行っていたので自分はそこまで詳しくない）

Azure Route ServerとNVAの構成でのハマりどころについて_構成図

トポロジ: SASE製品(GW) ↔ NVA ↔ Azure Route Server (ARS) ↔ Hub & Spoke。

この構成変更により、SASE製品とHubの間にNVAを挟むことになりました。NVAが学習したルートをVNetに反映する方法がないため、Azure Route Serverを使うこととなりました。Azure Route ServerはBGPのルートリフレクタとして振る舞い、実際のデータパケットについては扱わないようです。

HubにはAzure Route ServerやNVAの他に、Azure FirewallもありSpokeのすべての通信はAzure Firewallを通過させたい意図があります。Hubは通信の要所としています。HubとSpoke間はVNet Peeringしています。

遭遇した課題

Azure Route ServerとNVA間でBGPはEstablishedになっておりオンプレ拠点のPrefixも受信していましたが、非対称ルーティングが発生し、実際の通信がAzure Firewall等にブロックされる事象が発生しました。調査のためにユーザー定義ルート(以後UDRと表記)をNVAのAzure Firewall接続サブネットに作成し、Spoke宛はAzure Firewallを通るよう指定すると通信ができました。

下記の記事にあるような非対称ルーティングです。オンプレ拠点発、Spoke行きの通信がHubに到達後VNet Peeringを辿ってSpokeに到達するが、オンプレ拠点に戻ろうとする際にAzure Firewallを通ることで非対称ルーティングとなります。

zenn.dev

実際の通信がAzure Firewall等にブロックされる事象というのは具体的に、SpokeのWebサーバからオンプレ拠点に対して、TCPのハンドシェイクは成功しますがHTTPの通信が成功しないという状況でした。nc -z コマンドは成功しますが、curlコマンドの応答がありませんでした。パケットキャプチャを見ると、Azure基盤（Arista）からRSTが返ってきている状況でした。行きと帰りで出現するMACアドレスが違ったため、非対称ルーティングかな？と疑うきっかけとなりました。

Azureのルーティング優先順位

Azureでは下記のルート選択優先順位があります。これはプレフィックス長が同じ場合に適用されます。

複数のルートに同じアドレス プレフィックスが含まれている場合は、次の優先順位に基づいてルートの種類が選択されます。 ユーザー定義のルート BGP のルート システム ルート

learn.microsoft.com

BGP がより具体的なプレフィックスをアドバタイズする場合でも、ピアリングされた仮想ネットワークのシステム ルートは BGP で学習されたルートよりも優先されます。

learn.microsoft.com

これらの仕様を踏まえたうえで、実際に起きたことを見ていきましょう。HubとSpoke間でVNetピアリングを張ると、自動的にSpoke VNetアドレス空間の具体的なシステムルートが生成されます。これに対し、UDRで「172.16.0.0/12（RFC1918）」のような広い範囲を指定しても、LPM（より具体的なルートを優先する原則）によりシステムルートに負けてしまいます。UDRがないと、Spokeのすべての通信はAzure Firewallを通過させたい意図を満たすことができません。

参考: LPMについて

learn.microsoft.com

BGPでSpoke VNetアドレス空間の具体的なルートがAzure Route Serverによって広報されたら問題なく通信できると思ったのですが、実は違いました。「BGP がより具体的なプレフィックスをアドバタイズする場合でも、ピアリングされた仮想ネットワークのシステム ルートは BGP で学習されたルートよりも優先され」てしまうのです。この挙動を回避するにはUDRでオーバーライドするしか無いようです。

BGP運用であっても、バイパスを防ぐためには Spokeサブネットと同じサイズ（/24など）のUDRを「行き」の経路にピンポイントで書く必要があります。

これではBGPを使っている意味が無いというか限定的になってしまいます。Azure Route Serverが経路を広報する際にNextHopをAzure FirewallのIPアドレスに変更するroute-mapのような機能があれば解決されると思われます。

Tips

Azure Route Serverが受け取ったルーティングを確認する方法はありますが、Azure Firewallに伝わっているかを確認する方法がありません。あるけどPreview版でうまく動きませんでした。

learn.microsoft.com

仮想マシンを立ち上げていたらAzure Portal上でEffective Routesを確認できますが、数が多いとCLIで見るかCSVダウンロードして見るしかないなど微妙な不便さがあります。Hub側とSpoke側両方で見たい場合も両方で仮想マシンを立ち上げる必要があり料金が発生してしまい不便ですね。

共通言語と現場への共感で歩む：医療の「安全」と「DX」を繋ぐための越境の実践というタイトルでDevOpsDays Tokyo 2026に登壇します

こんにちは。 id:hokkai7go です。掲題のとおりですが、4/14-16に東京の大崎ブライトコアホールで行われるDevOpsDays Tokyo 2026に登壇します。

話す内容

医療情報技師という資格を趣味で取得したのは下記の記事で書いたとおりでした。

blog.hokkai7go.jp

医療情報関係の案件獲得したのですが現場は思っていた以上にボロボロで大変な状況でした。現地での泥臭くて楽しい調査や作業を経てようやくマイナスのところから1くらいまで押し戻した中での苦労話をします。

資料はこちらです。

speakerdeck.com

名古屋医療情報学プログラム（NCIP）を修了しました

医療情報

NCIP(NAGOYA Clinical Informatics Program 、以下NCIPと記載)を無事修了しました。

修了証を持って正門前での写真とかを撮りたかったけど、一人だったので隣の図書館写真でお茶を濁します

NCIPとはなにか

NCIP公式ページの説明を引用しました。

医療情報ならびにそのシステム開発に関する人材育成を目的としたリスキリング/リカレント教育のプログラムです。 すでに愛知県と行っている専攻医教育のプログラムである「東海医療情報学社会医学系専門医研修プログラム」を拡充する形で、有料のプログラムを追加し、医療IT教育のリスキリング教育を充実させることを目的としています。 NCIPは、全てWebの講義を予定しており、国内の専門家集団による医療情報に関する体系的・網羅的な知識の習得を目指し、「概要」と「実践」の2つからなる講義体系を形成しています。

このような医療情報分野のリスキリング/リカレント教育のプログラムは米国において広がりを見せているようです。代表的なものに、AMIA（アメリカ医療情報学会）の「10x10プログラム」というものがあるようです。NCIPを開講されている名古屋大学医学部附属病院メディカルITセンター長の白鳥先生からも、米国ではこのようなリカレント教育が先行しているという話を伺いました。

10x10プログラムについてのAIによるまとめを引用します。

2010年までに1万人の医療情報専門家を育成することを目的に、オレゴン健康科学大学（OHSU）と共同で開始された教育プログラムです。現在も継続されており、臨床医やITエンジニアが働きながら専門知識を習得するモデルとなっています。

しかし日本においては、このNCIP以外にはこのような医療情報分野でのリスキリング/リカレント教育のプログラムは多くないようです。これから医療とITどちらも担い手が少なくなっていくと言われています。医療とITどちらの目線からもこのようなプログラムを盛り上げていくことは少ない人間で現場を回していくために必要かつ大事なことだと認識しました。NCIPを知らない方や受講を迷っている方へ情報提供できたらと考え、この記事を書くに至りました。

なぜ受講したか

私は医療情報技師の資格を取得し、ラッキーなことに実際の医療情報関係の案件に携わることができました。しかし、現場で使える知識と技術が足りていないと感じることがありました。このギャップを埋めたいと思っていたところに、医療情報学会のメーリングリストでNCIP第2期開講のメールが来ました。 上述したようにNCIP以外に医療情報分野でのリスキリング/リカレント教育のプログラムは多くないようなので、受講しないと後悔するだろうと思い受講することにしました。

受講費用

登録料1万円+費用25万円で、合計26万円程度でした。他の受講生に聞きましたが会社や医療機関に負担してもらい参加している人が多そうでした。私は自費でした（この点については理由を述べるつもりはないです）。基本的にはオンラインですが、2-3度ほどオフラインでの会合がありました。

講義の構成と全体量

1時間以上の講義動画が40本以上ありました。ざっくりですが下記のような講義がありました。

  • 医療情報学総論
  • 医療IT化の体制
  • 電子カルテと部門システム
  • 看護や臨床工学における医療DX
  • プロジェクトマネジメント
    • 補足すると、医療DXプロジェクトを遂行するうえでプロジェクトマネジメントの考え方が必要だからこの講義があったと理解している
  • 医療の標準化・最適化
  • 遠隔診療・地域連携システム
  • 医療情報システムと医療安全
  • 災害・BCP・バックアップ
  • 医療ビッグデータとその解析（NDB、DPC、PHR、レジストリ等）
  • 情報リテラシー・情報セキュリティ
  • 診療報酬制度と病院経営
  • 臨床検査データの標準化と品質管理
  • 医療倫理・個人情報保護
  • データの標準化と品質管理
  • 診療情報管理士とシステム
  • 臨床研究と治験

全体量としては60時間程度だったと思います。動画視聴のeラーニングシステムでは最大2倍速まで再生速度を選べたので、少しは動画視聴時間を圧縮しながら学ぶことができました。しかし、投影されている資料を見ながらメモを取る時間があるので、60時間には収まらないどころか少なく見積もってもその2-3倍くらいはかかっていると思います。

感想

講師陣が豪華（医療情報学の第一線で活躍する方々）でした。また講師陣に質問したり話す機会が得られました。非常に濃い経験ができたと感じています。受講生や講師の方とのつながりが得られただけでなく、OB・OGとのつながりも得ることができました（今回私が受講したのは第2期でしたので第1期のOB・OGがいて交流会に来てくれていました）。 受講して知識はついたものの、実務というか医療機関での実践レベルの知識や技術はつかない（例えばDICOMの画像解析や通信解析、医療ビッグデータ解析が今すぐできるようになったわけではない）ので、現場で学んでいく必要があると思います。体系的に知識を得られたので医師やコメディカルスタッフのみなさんとのコミュニケーションはしやすくなったと思います。 受講料は安いとは言えないですが、講義内容のクオリティは高いかつ他では得られない知識と経験が得られますので個人的にはおすすめできます。医療DXを行っていく人や、多職種でチームを組んで行う医療の現場で活躍する方々にとっては大変有益と感じました。

JANOG57 NOCのbackboneチームでスクラムマスター的な役割をしてきた

ネットワーク楽しいとなっているここ最近です。さくらインターネットさんがホストかつ、家から通える範囲でJANOGが開催されるなら手伝う必要があると思い、NOCチームメンバー募集に応募しました。
というのも、RubyKaigiのHelperとしてNOCチームで光ファイバーやUTPケーブルの敷設を行いましたが、L2/L3などもう少し高いレイヤーでのNOC経験を積みたいと思っていたタイミングだったので応募することにしました。
実際にはbackboneチームのメンバーとして採用してもらえました。しかし、学生中心のチームかつ10人程度のワンピザに収まるかギリギリのサイズのチームだったので、チームビルディングをがんばる必要があることが過去の経験上すぐにわかりました。
しかしある程度日本各地に散らばっているメンバーを集めてチームビルディングできる状況にはなく、リモートで打ち合わせと作業を繰り返すしかなかった現状がありました。
こうした現状を打破したのは、2025/12/17に、さくらインターネット本社で行われたケーブル講習会というオフラインでの作業会でした。やはり会って話したり作業する機会は非常に重要だと認識しました。キックオフミーティングを早期に開催する必要があったのだと認識しました。

結果的には大きな問題や怪我もなくJANOG57 NOCの backboneチームで会期を終えることができました。が、チームの組成や距離の問題や、学生リーダーの献身的な貢献によるところが大きく再現性が低いところに課題感があるという振り返りエントリとなります。現役の学生さんたちや、新卒数年目の若手のネットワークエンジニアとのつながりができたのは非常に大きな糧というか、良い出来事だったと思います。
即席チームの組成やその効果的な運用については毎回正解が分からないかつ、手探りの運営にならざるを得ないのが現実です。何かしら次回以降の運営の参考になれば良いなと思います。

最後に、JANOG57スタッフやNOC関係者の皆様お疲れ様でした。ありがとうございました。皆様のおかげで充実した毎日でした。

オンプレ-クラウド間もしくはクラウド間の接続を設計、設定できる人を育成する必要がある

タイトルのまんまですが、 オンプレ-クラウド間もしくはクラウド間の接続を設計、設定できる人が少ないように感じます。エンタープライズ領域でクラウドを使うとなると結局オンプレやネットワークの広範な知識が必要になります。自分でできる物量は限られているので育成する必要があると思うことが増えてきました。

先日、Tech Challenge Party 2026というものに参加して、下記の講演を聞いていました。

f2ff.jp

エンタープライズ領域でクラウドを使うとなると、オンプレの機器も大体登場するので、クラウドだけ知っているというのでは知識や技術が足りないことになります。クラウドはすぐに環境作成できるので知識や技術を得られるのですが、クラウドは物理層や物理層に近いレイヤーについてはいい感じに隠蔽されています。クラウドでのネットワーク設計構築ができるからと言って、オンプレのネットワーク設計構築は出来ると言えません。物理層や物理層に近いレイヤーの知識や技術と、機器の調達や設置についてこれらの経験が足りていません。具体的にはMTUサイズや、BGPのパス属性等、物理的なLANケーブルや光ファイバーのケーブルの規格やSFPモジュールの相性問題やラックの電源容量など、オンプレのネットワークをやっていないと直面しない（しにくい）壁がたくさんあると思います。

上記を踏まえると、逸般の誤家庭と称しておうちのネットワークを業務用機器で構成するといった営み、つまり家庭内ラボ環境を持つことが非常に魅力的であることがわかります。諸先輩方はこのようにして技術習得に励んでおられたのだなと理解したタイミングがありました。

補足ですが、"逸般の誤家庭" というのは、"中古のルーターやスイッチを自宅にラックマウントするような、ネットワーク愛好家" のことを指します

我々ITエンジニアはもともとおうちのネットワークを支える責任があると思います。おうちのネットワークは自分が1番のユーザーです。金銭的な制限の中、どのような機器構成にして、限られたスペースに収まるのか、ライフサイクルはどれくらいとするのか、など考えることはたくさんありますね。楽しいですね。これらの活動を楽しいと思えるかどうかが非常に重要なファクターだと私は考えます。楽しいと思えるなら、知的好奇心に従って様々な課題を発見して解決に向かえますし、コミュニティとの接点も生まれてくるなど副次的な効果も狙えると思われます。

なぜ逸般の誤家庭の話題出したかというと、仕事で使う業務用のNW機器に普段から慣れ親しんでおくことで、Config投入やNW設計についての素振りができます。仕事（本番）は失敗しにくいと思いますが、おうちではたくさん試行錯誤できます。早期にたくさん失敗するのが大事だと思っています。チームや会社内でこうした素振りができる環境を整えていこうとしているところです。

補足ですが、素振りというのは"本番環境や実際の案件とは別に、個人の学習やスキル向上のためにコードを書いたり、ツールを試したりする自主練習のこと"を指します。

言われたことが爆速で出てくるっていうのが一番いいのかなと思ってます。これをやりたいって言ったら、できますよってさらっと言えるぐらい素振りがすべて整っている状態。

Ruby関係の記事ですが、これに書いてある内容が個人的には良いと思っているので紹介します。

product.st.inc

さて本題に戻ります。おうちのネットワークとして業務用のNW機器を使うと、クラウドと拠点間VPN構築したり、BGPで経路交換といったことにチャレンジできます。個人でDirect ConnectやExpress Routeを構築するのは費用的に難しいので、VPNで代替してBGPにトライしようということです。このようにオンプレ-クラウド間の接続はおうちでも試すことができるわけです。こうした取り組みというか素振りが育成の一歩になるのかなと思ったのでした。

Azure / AWS / Google Cloud の組織階層とリソース管理モデルを比較する

AWS方面から来ましたという状態で、Azureのことはめちゃくちゃ詳しいわけではなかったのだが最近業務でAzureを毎日触る機会を得てAzureについてだいぶ詳しくなってきたと感じた。

AWSプロフェッショナルのためのAzureというページがあり、これが大変わかりやすかった。AWSでいうところのあの概念はこちらです。という説明がされており非常に丁寧に感じた。クラウド初学者以外のこうした学習パスがあるのは非常に助かる。AWSやGoogle Cloudにもこのようなページがあるのだろうか？きっとあるのだろう。

learn.microsoft.com

今日はその中でも、アカウントとサブスクリプションの考え方について書き残したいと思う。

アカウントとサブスクリプション

数年前にAzureを触った時に、サブスクリプションって何？と思った記憶がある。個人利用レベルだったので、特段うまみを感じなかっただけでなく、面倒な仕組みだと感じたことを覚えている。当時はサブスクという言葉が今よりも広く使われる前だったと記憶していて、概念がつかみにくかったのだと思う。今ならサブスクと言われたらすぐにわかる。(がAWSアカウントと同じ概念とすぐわかるかどうかは別の話）

AWSやGoogle Cloudに業務で触れることがあり、またAzureに戻ってきた。 今回の業務はかなり大きな企業でのAzure利用だった。大きな企業でAzureを使う場合にはサブスクリプションや管理グループ、リソースグループという概念が非常に便利だということに気がついた。

AWSにもResouce Groupsというものがあるらしいのだが、自分はこれまであまり意識したことがなかった。

docs.aws.amazon.com dev.classmethod.jp

表にしてみた

クラウド ルート階層 中間階層 リソースを格納する最小単位 補足
Azure Entra ID（テナント） Management Group Subscription → Resource Group ResouceGroup は必須であり、デプロイ・IAM・Policy 単位
AWS AWS Organizations OU（任意） Account ResourceGroup は任意の論理ビュー（タグ or Stack）
Google Cloud Cloud Identity / Organization Folder Project → リソース Project が課金・IAM・API の最小単位

比較してみたら、各社の設計が少しずつ違って興味深い。

  • Azure
    • Resource Group は物理的な配置単位で、必ずどこか１つの RG に属する
    • デプロイ、RBAC、Lock、Policy 適用が RG レベルで可能
  • AWS：
    • Resource Groups はタグ or スタックで絞る“フィルタ結果”であり論理ビュー
    • 属さないリソースがあっても OK（構造ではない）
    • IAM/Policy/Network などの境界は Account が単位
  • Google Cloud
    • Project が Azure の Resource Group + Subscription の中間のような存在
    • Project が API 有効化 / 課金 / IAM の最小単位
    • Folder で大規模組織階層を構成
    • Resource Group という名前の機能は無いが、Project が Azure の Resource Group よりも強力な境界

Azure の Resource Group は“箱”であり、AWS のそれは“ラベルで集めた一覧”ということのようだ。

アカウント管理

アカウント管理方法というかSSOあたりについてはAzureが変わっていると思うのだが、Entra IDという強力なサービスを持っているのがデカいと思う。IAMについて触れるとそれだけで長くなるのでこの記事では触れないことにする。

レイヤー Azure AWS Google Cloud
ID基盤 Entra IDテナントが全 Azure 組織の根幹となる IAM Identity Centerで外部IdP連携可能 Cloud Identityで外部IdP連携可能
ID/SSOの構成 Entra ID で SSO と RBAC を統合する IAM Identity Center を使い、Org 配下の複数 Account に SSO構成可能 Cloud Identity を使ってSSO構成可能
ポリシー適用単位 Management Group / Subscription / Resource Group(Azure Policy / RBAC) Org / OU / Account(SCP / IAM) Org / Folder / Project(IAM Policy)

Azureの場合はAzureを管理する側にもEntra IDについて分かる人がいると良いように思う。PIMなどEntra IDの機能を使ってAzureの権限管理することもあるだろうし、Azureを使っている以上Entra IDだけでなくActive Directoryについての知識も求められることがあるので、知っていて損はまったくないと思う。

さいごに

マルチクラウドやオンプレとの接続を考えたときに、どれもわかっている人の存在が必要になると最近思っているので、こうした比較も大事だろうと思ったのだった。物理機器に好んで触れている昨今だったが、クラウドにどっぷり浸かる久しぶりの体験をしているなかでこの記事が生まれた。テーマごとに書いていくのが面白そうだなと思うが、ネットワークや仮想マシンについてはこの分量では全く収まらないと予想されるので戦々恐々としている。

有言実行、不言実行

雑な文章

食器を洗っていて思い出した話を書いておきます。
食器を洗っておくわと宣言したものの、食器を洗わずに外出してしまいそうになりました。このようにやると宣言したがやっていないというのは、相手からすると何やねんとなる出来事であり避けるべきであります。

他のパターンを考えてみると、言ってから行う有言実行が有名でしょう。やると宣言してからやるのかっこいいですね。
言わずにやってしまう不言実行は、「文句や理屈を言わずに、黙ってなすべきことをなすということ」です。これが一番早そうです。コミュニケーションには一定のリソースを割く必要があるので明らかに価値があり、わざわざ伝えるまでもないようなことは不言実行がよいのではないでしょうか。「許可より謝罪」という言葉が近いかと思いましたが、これは超訳であるという話もあるようですね。

 

 

他のパターンとしては、言ったけど実行していない（有言未実行）、言ったけど実行できなかった（有言実行不可能？）などがありそうです。言ったけど実行できなかった（有言実行不可能？）は、学びがあればまあ良いのではないでしょうか。

特にまとめはないですが、何かあれこれ理由を言う前にやってしまったほうが早くないか？と思うことが非常に増えています。AIにより最初のステップが踏み出しやすくなったわけですし、あれこれ理由を言う前に手を動かすと良いと思ったのでした。私はそうします。