自己紹介
私は、2023年に新卒でDMMに入社し、同年8月からはプラットフォーム開発本部・プラットフォームチーム（当時の部署名はSRE）で仕事をしています。
普段はEKS・GKEなどのパブリッククラウドのマネージドKubernetesを使用した、Kubernetesマイクロサービスプラットフォーム基盤開発やサポートを行っています。
詳しくは、下記の記事で紹介されているような業務です。
https://inside.dmm.com/articles/gke-authentication-rotation/
ぜひ、ご興味ある方はご覧ください！
JANOGとは？
今回、私は「JANOG53 Meeting in Hakata」（以下JANOG53）に参加してきました。そもそも「JANOGとは？」という方向けに、JANOGについて公式サイトでは次のように定義されていますのでご紹介します。
JANOGとはJApan Network Operators' Groupを意味し、インターネットに於ける技術的事項、および、それにまつわるオペレーションに関する事項を議論、検討、紹介することにより日本のインターネット技術者、および、利用者に貢献することを目的としたグループです 。
JApan Network Operator's Groupより
(https://www.janog.gr.jp/information/)
またJANOGでは、毎回開催地を変えながら定期的にオペレーターや運用者に限らず、多種多様な職種の方が集まって議論する会「JANOG Meeting」を開催しています。これを「JANOG」と呼ぶこともあり、本記事で取り上げています。
聴講したセッション
私はJANOG53で、さまざまなセッションや同じテーマに興味を持つ者同士で自由に議論を楽しむ場「BoF（Birds of a Feather flock together）」に参加しました。その中でも印象に残ったセッションを2つピックアップしてご紹介します。
Kubernetesでネットワークコントローラ「Kuesta（ケスタ）」をつくってみたが、登りたい山はまだいくつもある
Kubernetes（以下K8s）を用いた宣言的ネットワークコントローラ「Kuesta」を開発している中で起きた問題や、どのような背景で作られたのかという点を紹介するセッションでした。Kuestaは、ルーターやスイッチを宣言的に設定可能なネットワークコントローラでK8sという既存ツールを活用し、設定の記述から設定の投入までを自動化するツールです。
「Kuesta」GitHubリポジトリ: https://github.com/nttcom/kuesta
開発に至った背景
主に以下の点が紹介されていました。
1. 根本的に市販ネットワークコントローラはライセンスが高く、また専用の技術スキルが必要でエンジニアを集めるのも大変
一般にネットワーク機器はライセンス費が高額で、特にユーザーが限られるツールライセンスは極めて高額なものが多い印象があります。
2. 既存OSSでは解決できなかった
プロプライエタリツールよりも安価に使えるオープンソースソフトウェア（以下OSS）でのネットワーク装置への設定自動化は既にAnsibleを用いて行っていたようですが、以下のような問題があったそうです。
- ベンダーやネットワークOSによって仕様・オペレーションが異なる
- 複数機器(ノード)の設定投入を行う必要があり、ノード間をまたぐトランザクション管理に対応する必要がある
この問題の発生理由としては、Ansibleでルーターなどを操作する際に専用のモジュールが必要となり、それがうまく整備されていない場合には結局「jinja2」と呼ばれるPythonのテンプレートエンジンを用いて直接テンプレートを作るしかないため、どうしてもテンプレートが肥大化します。
Kuestaを使うメリット
Kuestaを使うことで、上記のような課題をK8sと宣言的な設定の記述で解決できるようになります。
また以下のような部分で、他のメリットも挙げられていました。
- K8sによるコンテナ管理
- リソースの状態の宣言的な管理・監視
- コンテナ数の増減によるスケーラビリティの高さ
- Secretに機密データを保存できる等、K8sでのリソース管理が可能になる
- GitHubによるデータ管理
- WebGUIでのリソースの状態や変更遷移の確認(diffで確認できるため)
- commit単位での切り戻し
- 抽象モデル(JSON)から、それぞれの機器のdevice configを作成・変更できる
その他質問
今回は発表後の質疑応答や議論の時間のほか、登壇後（発表終了後）に直接登壇者へ質問ができる "替え玉スペース" が用意されており、そちらで内部の仕組みについて直接伺いました。
Q. 抽象モデルとなるJSONをGoを経由してdevice configを作成・変更する部分が、このツールのコアなように見えるが、それをK8sで行うとK8sの運用負荷が大きいのではないか？
Ａ. 既存のK8sの機能、例えばオートヒーリングやロードバランサーに乗れることがK8sを使うメリット。例えばconfig作成処理には機器に合わせ複数のデバイスドライバーを使用するが、その仕組みをK8sの機能で並列で行うことができるなどのメリットがある。
Q. K8sで並列化しなくてはいけないほど、抽象モデルから機器へのconfig投入までには実行時間がかかるのか？
Ａ. 実は結構かかる。configだけでも1万行あるため、抽象モデルからconfig作成はもちろん、それを機器投入するにも時間がかかるので、並列化のメリットはある。
Q. GitHubを使用しているが、ArgoCDを追加してGitOpsすることはできないのか？
Ａ. 現在のアーキテクチャではGitHubは生成したconfigを保存するDBとしてしか使っていないため、結論から言うとできない。今後考えていく。
これからのIPv4 over IPv6の話をしよう
IPv4 over IPv6という、近年国内でも主に個人のネット回線契約で一般化してきたIPv4のパケットをIPv6でカプセル化する技術の国内標準化について紹介するセッションでした。ルーター開発のNEC社、ISPのBIGLOBE社、朝日ネット社の3社合同の発表でしたが、議論の時間になると、
- ルーター開発側としてヤマハ社
- 既存VNE事業者としてNTTコミュニケーションズ社 など
いわゆる競合他社・大手コンテンツプロバイダー・CATV等の事業者もそれぞれの立場から標準化について議論に参加され、まさに「JANOG Meeting」といった、非常に印象に残るセッションでした。
今の日本のIPv4 over IPv6の問題について
前提知識として、この問題は日本特有のネットワーク構造に強く影響されているものなので、先にこの日本特有のネット回線の概要を解説します。
日本の回線の構造でIPv4 over IPv6を実現するには、まずNTTのNGN網を通ってインターネットへの出口になるVNEと通信し、そこからインターネットに出ていくという構造になります。つまり、IPv4 over IPv6を使うにはNTTのNGN網の制約内で仕組みを作る必要があります。
より詳しく知りたい方は、IPoEについて説明している過去開催の資料がわかりやすいため、ぜひご覧ください。
IPoEについての資料(過去のJANOGセッション): https://www.janog.gr.jp/meeting/janog42/program/ipoe
ところでIPv4 over IPv6を使うには以下を行う必要があり、これらを行う方式をプロビジョニング方式(以下プロビ方式)と言います。
- IPv6マイグレーション技術の選択(MAP-E, DS-Liteなど)
- 各マイグレーション技術に必要なパラメータの取得
このプロビ方式は、IETFで国際標準化されており、DHCPv6が前提（RFC 8026 / RFC 7598）となっています。
ところがNTT東西のNGN網では、VNE事業者向けにDHCPv6 optionが解放されていないため、国際標準プロビ方式が使えません 。
では今どうなっているかというと、各VNE事業者が独自規格を作り、それぞれの独自規格に合わせてルーター側で設定を行っている状態です。
そのため、以下のような問題が生じていました。
- ルーターベンダー
- VNE事業者ごと独自方式に対応する必要あり
- 開発工数の増大による価格向上
- サービス自動判別の仕組みを提供できない場合、サポート対応工数増加
- 新規VNE事業者
- プロビ方式の仕様検討・設計が必要
- 事業規模が小さく、ルーターベンダーが独自方式に対応しなかった場合、調達面でマイナス
- エンドユーザー視点
- ルーターの開発費上昇による購入価格上昇で費用負担を強いられる
- プロビ方式が統一されていれば、本来は負担しなくてよいはずの費用
- サービス自動判別の仕組みがない場合、ユーザー自身で設定が必要
- サポートセンター問合せによるサービス利用開始の遅延や製品クレーム
解決策
これらの課題を根本的に解決するには、国内標準でプロビ方式を決めるという手段が有効です。
そしてその国内標準方式としてHB46PP(HTTP-Based IPv4 over IPv6 Provisioning Protocol) が作成されています。
HB46PPの仕様: https://github.com/v6pc/v6mig-prov/blob/master/spec.md
この規格に沿うことで、先ほど挙げた課題を一気に解決することが可能となります。
実際にHB46PPにそって実装した2社がどのように実装を行ったのかと、この規格自体の議論が本セッションの主な内容となります。
HB46PPの今後の課題
標準化となると各社の足並みを揃える必要があるものの、完全に足並みを揃えるのは難しいのが現状です。
特に対応が難しく、かつメリットが薄いのが既存のVNE事業者です。
例えば今回の議論に参加したNTTコミュニケーション社は、現状では標準化のために既に動いている仕組みを変えることは難しいと表明しています。
しかしHB46PPを使うことで、エンドユーザー・ルーター事業者・新規VNE事業者・CATV事業者など、さまざまな方面に恩恵があることが既にわかっており、特に新規VNE事業者はHB46PPに対応するケースが出てきています。
私が聞く限りでは、HB46PPが作られる以前の各社の独自規格が乱立し続ける状況はなくなってきており、良い方向に向かっているように感じられました。
標準化は進めば進むほど対応のメリットが増えていき、またルーター設定の簡易化や費用減にもつながるので、自宅にサーバーを持つエンジニアとしては今後より広まってくれると良いなと期待しています。
まとめ
普段はあまりオンプレミスに触らないSREの私がJANOG53に参加し、その中で特に興味深かった2つのセッションを今回ご紹介してきましたが、意外にもさまざまな職種の方々とBoF参加や企業ブース訪問の機会を通じて交流でき、貴重なお話が聞けました。
また参加にあたっては、社内制度「カンファレンス参加支援」を使って参加できました。普段パブリッククラウドを触るSREからしてみると少し遠い「JANOG」ですが、所属のプラットフォーム事業本部をはじめ、さまざまな部・室の協力のもとで今回参加することができました。ありがとうございました！
宣伝
合同会社DMM.comでは、DMMのインフラを支えるエンジニアを募集しております。
