Internet Gateway サービス解説

はじめに

こんにちは! BBSakura で基盤となるネットワークを開発している酒井です。

先日、 OCX の新サービスとして Internet Gateway をリリースしました。

この Internet Gateway を用いると、お客さまは OCX 網内から直接インターネットへ接続できます。しかも、このインターネット接続には NAT (SNAT) 機能がついているため、お客さまはインターネット接続のために NAT ルータを別に用意する必要がありません。 既存サービスの Internet Connection でも同様に OCX 網内から直接インターネットへ接続できますが NAT 機能はありません。

今までは NAT 機能込みでインターネット接続を提供する OCX サービスはありませんでした。今回リリースした Internet Gateway を他 OCX のサービスと組み合わせることで、それらの OCX サービスから直接インターネットへ接続することが可能となります。今後もさらに OCX サービスは開発されていきますので、 Internet Gateway との組み合わせで、より柔軟でより便利に OCX を利用頂けるかと考えています。

この記事では、 Internet Gateway の使用方法と一般的な OCX-Router(v1) との接続構成について解説します。

Internet Gateway の使用方法

まず Internet Gateway の各種設定項目と使用の流れについて説明します。

なお、Internet Gateway の使用方法の詳細は ドキュメントサイト で説明されていますので適宜ご参照ください。

設定項目

Internet Gateway を利用するために必要な設定は次の 3 つになります。

  • IPv4 ゲートウェイアドレス
  • (オプション) NAT IP アドレス
  • Static Route

それぞれの設定事項を以降で説明します。

IPv4 ゲートウェイアドレスは、お客さまのネットワークからインターネットへと接続するデフォルトゲートウェイの IP アドレスにあたります。 Internet Gateway では、このデフォルトゲートウェイの IP アドレスをお客さまネットワークの IP アドレス構成に合わせて自由に設定できます。なお、デフォルトゲートウェイはインターネット接続においては不可欠な設定になるため、 Internet Gateway のリソース作成時に IPv4 ゲートウェイアドレスを設定する必要があります。

Internet Gateway リソース作成画面で IPv4 ゲートウェイアドレスにデフォルトゲートウェイとなる IP アドレスを入力しているスクリーンショット。
IPv4 ゲートウェイアドレスの設定

NAT IP アドレスは、インターネット接続時に SNAT するための変換用グローバル IP アドレスのことです。 Internet Gateway リソースを作成すると、デフォルトでグローバル IP アドレスが 1 つ割り当てられます。 Internet Gateway では 1 つのグローバル IP アドレスで約 62,000 の NAT セッションを使用できます。ただし、お客さまのユースケースとして NAT セッション数が 62,000 では足りない場合に、オプションとして NAT IP アドレスを追加し、使用可能な NAT セッション数を増やせます。 OCX ポータル上では追加された NAT IP アドレスは Additional NAT IP Addresses として表示されます。

NAT IP アドレス設定画面でデフォルト割り当てのグローバル IP アドレスと Additional NAT IP Addressesが表示されているスクリーンショット。
NAT IP アドレスの設定

Static Route はインターネットからのダウンロード方向、つまり、 Internet Gateway からお客さまネットワーク方向のルーティングのために設定します。 Internet Gateway は現時点ではダイナミックルーティングプロトコルをサポートしていないため、お客さまネットワークへのルーティングを Static Route で設定する必要があります。例えば、下記のような構成となっていた場合には Internet Gateway の Static Route として、「プリフィックス」には 192.168.10.0/24、「ネクストホップ」には 192.168.100.2 を設定します。

[インターネット] ----- [Internet Gateway](192.168.100.1) ----- (192.168.100.2)[お客さまルータ A] ----- [192.168.10.0/24]

Static Route 作成画面でお客さまネットワークへのルーティングを入力しているスクリーンショット。
Static Routeの設定

使用の流れ

ここでは、実際に Internet Gateway を使用する流れ(手順)を説明します。使用の流れを項目で記載すると次のようになります。

  1. Internet Gateway リソースを作成する
    1. IPv4 ゲートウェイアドレスを設定する
  2. (オプション) NAT IP アドレスを追加する
  3. Static Route を設定する
  4. Internet Gateway を接続したい VC へアタッチする
  5. お客さまネットワーク機器のデフォルトゲートウェイとして Internet Gateway の IPv4 ゲートウェイアドレスを設定する

上記の項目 1 ~ 3 については Internet Gateway の設定項目としてすでに説明済みの内容となります。

Internet Gateway は他の OCX リソースと同様に VC へアタッチすることにより、その他の OCX リソースと通信が可能な状態となります。そのため、項目 4 が必要となります。

また、 項目 5 はお客さまネットワークからインターネットへのアップロード方向のルーティング設定となります。お客さまネットワーク機器や OCX-Router(v1) 等に適切にデフォルトルートのルーティングを設定頂ければと思います。

ここまでの説明内容について設定ポイントを簡潔にまとめた図を下に示しますので参考になれば幸いです。この図では Internet Gateway との接続例として Physical Port を介してお客さまルータを接続しているパターンと OCX-Router(v1) を接続しているパターンを併記しています。

Internet Gateway の使用のために設定が必要なポイントを明示した図。画面最上部に The Internet が雲の形であり、そこに Internet Gateway が SNAT で接続されている。 Internet Gateway には使用の流れで説明した項目 1 - 3 が紐づいている。 Internet Gateway の下には VC が接続されている。 VC には項目 4 が紐づいている。 VC から二股に接続が分かれており、片方は VCI ・ Physical Port ・ お客さまルータ・お客様ネットワーク A と順に繋がっている。もう片方は Router Connection ・ OCX-Router(v1) ・ お客様ネットワーク B の順に繋がっている。お客様ルータと OCX-Router(v1) には項目 5 が紐づいている。
Internet Gatewayの設定ポイント

OCX-Router(v1) と組み合わせた構成

ここでは、 Internet Gateway のユースケースとして OCX-Rotuer(v1) と Internet Gateway の一般的な接続構成について紹介します。

OCX-Router(v1) とは OCX 網内でオンデマンドに利用できるルータ機能です。 OCX-Router(v1) は主にパブリッククラウド接続の際に使用される BGP とともに Static Route の設定も可能であり、 Internet Gateway と組み合わせて使用できます。

簡単な構成図として下の図を用意しました。

Internet Gateway と OCX-Router(v1) を組み合わせて設定するための一般的な構成を示した図。左からオンプレミスネットワークやパブリッククラウドを示した雲、真ん中に OCX-Router(v1) のプライマリが上部に、セカンダリのルータが下部に、右には Internet Gateway と The Internet が並んでいる。OCX-Router(v1) の各ルータからは Internet Gateway 方向に Static Route (デフォルトルート) が、 Internet Gateway から OCX-Router(v1) 方向へ Static Route が矢印で記載されていている。また、割り当てられている IP アドレスとして OCX-Router(v1) に VRRP VIP アドレスが、 Internet Gateway には IPv4 ゲートウェイアドレスが紐づいている。
OCX-Rotuer(v1) と Internet Gateway の接続構成

この構成の主なポイントは 2 点です。

1 つ目のポイントとして、 OCX-Router(v1) の VRRP による冗長です。OCX-Rotuer(v1) はプライマリルータとセカンダリルータのペアで提供され、ペア内で VRRP による冗長化が可能です。いずれかのルータの障害時に通信が継続できるように、OCX-Router(v1) では VRRP で冗長を組むことをオススメします。

2 つ目のポイントは、 Static Route の設定です。 Internet Gateway と OCX-Router(v1) のどちらもお互いに向けて Static Route を設定する必要があります。 Internet Gateway 側は OCX-Router(v1) 配下のお客さまオンプレミスネットワークやパブリッククラウドのネットワークを宛先にし、ネクストホップを OCX-Router(v1) の VRRP VIP に設定します。 OCX-Router(v1) 側はデフォルトルート (0.0.0.0/0) 宛のネクストホップを Interenet Gateway の IPv4 ゲートウェイアドレスに設定します。

このようにして、 OCX 網内のルーティングのハブとしてよく使用される OCX-Router(v1) と組み合わせて Internet Gateway を簡単に利用頂けます。

なお、実際に通信を行なうためには上記の内容に加えて、 OCX-Router(v1) とお客さまオンプレミスネットワークやパブリッククラウド間のルーティングも適宜設定頂ければと思います。

おわりに

この記事では OCX の新サービスである Internet Gateway について解説しました。

Internet Gateway は今後も機能強化していく予定ですので、楽しみにお待ち頂ければと思います。

もし、今回の記事を通して OCX のご利用に興味を持たれましたら、弊社までお問い合わせください!また、不明点などもありましたら遠慮なくお知らせくださいませ。

CTOに就任しました

こんにちは。4月からBBSakura NetworksのCTOに就任した日下部@higebuです。

今までBBSakuraになかったCTOという役職ができ、私が就任しました。

そこで、CTOという役職ができた背景、これから私がBBSakuraでやりたいことについて書きます。

自己紹介

私のBBSakuraでの経歴は以下の通りです。

  • 2019年8月、BBSakura設立と同時にさくらインターネットから出向
  • 2020年4月~2021年3月:開発本部長
  • 2021年4月~2024年3月:全社のテックリード
    • 2021年4月~7月:OCX初期開発
    • 2021年8月~2022年3月:育児休業
    • 2022年8月~現在:モバイル開発グループ グループリーダーを兼任

BBSakura出向前は2016年8月からさくらインターネットで、さくらのセキュアモバイルコネクトを開発していました。さくらのセキュアモバイルコネクトでは独自のモバイルコアを開発しましたが、設立時のプレスリリースにある通り、これがBBSakuraの設立のきっかけとなっています。

BBSakura出向後もさくらのセキュアモバイルコネクトの開発、運用、新規プロダクトの開発などをしながら開発本部長やテックリードを務めてきました。

役職名に関わらず、同じようなことをやってきたのですが、具体的には以下のようなことをやっていました。

  • 注力すべきプロジェクトへのリーダーやプレイヤーとしての参画
  • 新規プロダクトの仕様策定、及び技術選定
  • エンジニアの育成プラン検討
  • エンジニア採用
  • エンジニアと経営陣とのコミュニケーションの橋渡し
  • 両親会社への人事考課フローの整理、及び、メンバーの人事考課
  • 社内で使用するツールの選定及び管理
  • 組織体制についての経営陣への進言

CTOという役職ができた背景と期待されていること

BBSakuraは「全てのモノがつながる社会を支えるテクノロジーカンパニー」を経営理念としていますが、テクノロジーカンパニーとしてのカラーをもっと出していくため、CTOという役職ができました。

そのため、BBSakuraの中でやっていることをもっと外に出していくことを期待されていると思っています。

また、BBSakuraにはCTOとは別に開発本部長もおり、テックリードの頃から同じような役割分担をしていましたが、おおまかに以下のような役割分担になっています。

  • マネジメントをメインで行う人:開発本部長
  • 技術戦略を立案し実行する人:CTO

ただ、今まで同様、社長からは「会社のために技術面でなんでもやる人」であることを期待されていると思います(笑)

何をやっていくのか

BBSakuraは今年の8月に設立から5年になり、組織が大きくなってきましたが、よりスピードを上げて開発していけるようにしたいと思っています。

これには、プロダクトの全体を見られるフルスタックエンジニアを増やすことが重要だと感じています。

BBSakuraでのフルスタックエンジニアとはフロントエンドからクラウドインフラはもちろん、物理、仮想インフラ、SIM、モバイルネットワークまで扱えるエンジニアのことです。(私自身も物理、特にRAN方面は弱いため、まだ名乗れません。。。)

扱っている技術領域が広いため、知識の習得には時間がかかりますが、業務の中で習得できるような流れを作り、プロダクトの開発に活かせるエンジニアを増やしていきたいです。

また、BBSakuraは設立時からフルリモートで業務を行っていますが、人が増えたためにコミュニケーションコストが上がっていると感じており、これを解決する仕組みも整備したいです。

最後に、BBSakuraのエンジニアには、やりたいことがたくさんあるので、それをやれるようにしたいし、それを事業につなげていきたいと思っています。

BBSakuraの新卒社員が社会人1年目を振り返ってみた

こんにちは!BBSakura Networks(以降BBSakura)、モバイル事業本部に所属している佐久間です。普段は、親会社である BBIX のモバイル関連プロダクトの企画業務を担当しています。

この4月で社会人2年目に突入する節目ということで、今回の記事では昨年4月に一緒に入社した同期3名*1にインタビューを行い、BBSakuraでの社会人1年目について振り返ってみました。

友達と韓国に旅行に行った時の写真です(佐久間)
同期の雰囲気を伝えられるよう、インタビューがんばります!(佐久間)

ーーーーーーーーー

佐久間:はじめに、自己紹介からお願いします!

Dennis:初めまして、Poon Waikindennisと申します。出身は香港で、日本に来てから 4年目、5年目かな。入社前は日本の大学院で超音速流体の研究をしていました。具体的には、CFD(Computational Fluid Dynamics)を用いて飛行機のジェットエンジン入り口の高速流体のシミュレーションを行っていました。 挑戦し続ける人生が面白いと思っていて、そこにソフトバンクと自分の思いが一致してるので、通信業界に行こうと決めて、ソフトバンクに入社しました。

佐久間:学生時代の専門内容とは全く関係ない分野を選んだんだね。

Dennis:そうそう。今は、BBSの開発本部でOCXの拠点構築を担当しています。 データセンターに行って機器を設置したり、コンフィグを入れたりなど、実際に構築するのはもちろんですが、構築以外の仕事も多いです。 例えばお客さまとの調整や調査とか、部品の調達、機器の購入、各拠点の資料作成など、構築にまつわる一連の業務をやります。

ビールとラーメンが好き(Dennis)
ビールとラーメンが好き(Dennis)

佐久間:Dennis君、ありがとう!では、北村くんも自己紹介をお願いします。

北村:はい、北村瑠唯と申します。仙台出身で、大学時代は経済学部で機械学習を用いて株式市場とSNSの関係性について研究していました。就職活動の時、ITに関連する仕事で、色々なことをやっている会社の方がチャンスがありそうで面白そうだなと考えていて、通信だけではなく幅広い事業をやっているイメージがあったソフトバンク株式会社に入社しました。

今は、BBSの事業本部でOCXのサービス企画を担当していますが、実際はエンジニアがやる仕事以外ほとんど全部をやっています。 サービス設計や事業計画の作成に加えて、営業でお客さまとお話しすることもあるし、広報系の仕事もするし。

趣味の登山に行った時のフィルムで撮った一枚(北村)
趣味の登山に行った時のフィルムで撮った一枚(北村)

佐久間:うんうん。仕事の幅がすごく広いイメージがあるな。 では最後に今井くんお願いします!

今井:今井陽と申します。出身は東京で、入社前は大学院で交通シミュレーション研究をしていました。シミュレーターのコードを書いて色々検証して…ということをやっていて、昔からソフトウェエンジニアに憧れていたので、この業界に決めました。 今は、BBSの開発本部でOCXの新機能開発や機能修正を担当しています。ただ、普通の開発だけではなくて、運用周りもやっています。お客さまから問い合わせをいただいた時に、内部で原因調査をしたり、開発物のリリースをしたり。8割開発、2割運用みたいなイメージかな。

ニューヨークの橋にいい感じに座ってる写真(今井)
ニューヨークの橋にいい感じに座ってる写真(今井)

佐久間:自己紹介ありがとうございます!では、早速なんだけど、今の配属が決まった時はどのように感じましたか?

Dennis:僕は元々、構築展開課を希望していたので嬉しかったです。出張で各地のデータセンターに行けるのが面白そうだなと思っていました。 実際は、データセンターでの作業が長くなることが多いので大変なこともあります(笑)

北村:僕は、入社した時にずっと新規事業に関わりたいと話していたので、希望通りだった印象です。

今井:僕も、めちゃくちゃ希望通りでした。入社前から、小規模でもいいから、実際に手を動かして開発をできるところがいいと言っていて、そこを汲み取ってもらえたのかなと思っています。

佐久間:みんな希望通りの配属だったんだね。では配属後、そこからのギャップはありましたか?

今井:僕は、自分が想像していたよりがっつり開発できるところに来てびっくりしました。実際働き始めてみると、自社開発するベンチャー企業みたいな雰囲気で、ゴリゴリのエンジニア集団という印象です。

北村:あとは、良い意味で自由度が高いなと思います。例えば、出社・リモートの選択はかなり自由にできています。一時期はずっとリモートでしたが、最近は週3日くらいの頻度で出社していて、自分の予定に合わせて、午後から出社することもあります。気分転換でソフトバンク本社のオフィスに行くこともありますし(笑)

佐久間:なるほど、他の二人は働き方についてはどうですか?

今井:僕もテレワークに関しては自由で、配属された当初は、エルダー*2の先輩と顔を合わせて色々と教えてもらうために週1日~2日出社していましたが、今はほぼリモートで働いています。

Dennis:僕は出張が多いのでオフィスに出社することは少ないです。データセンターに行くことはありますが。課のメンバーも小さなお子さんがいたりして、出張以外はリモート中心にされてる方が多いです。

佐久間:ありがとうございます! BBSakuraは東京以外にも、大阪や北海道、栃木など住んでる場所も様々で、働き方は柔軟だよね。 次に、業務をしていく中で大変だったことや成長できたことはありますか?

Dennis:初めは機器の取り扱いが大変でした。一度、作業中に力を入れ過ぎてしまったせいで部品を壊してしまったこともありました。それから部品ごとに何を注意しなければいけないか、気にして作業するようにしています。

北村:僕は、初めは会議や資料に出てくる専門用語が全然わからなかったので、ネットワーク業界に慣れるまでに時間がかかりました。 1年間で成長できたこととしては、いろんな視点でものを見るようにはなれたかなと思います。サービス仕様書を作るにしても、運用保守の方が読んだらどう思うかとか、別の視点を意識するようになりました。

今井:僕は、実は大変だったことがあんまり思いついていなくて。複雑なシステムを持つOCXの開発をやっていて、もちろん最初はわけのわからない中で修正など対応をしなくてはいけないので、内部がどうなっているか学びながら進めるのは大変ではありました。でも、初心者でもできそうなプロジェクトから任せられて、だんだん難易度が上がっていくというように、僕がうまく学びながら成長できるようにタスクを振っていただいていたと感じています。

佐久間:ありがとうございます。では最後に、今後やってみたい仕事や目標があれば教えてください。

Dennis:僕は先日、CCNA*3に合格することができたので、次のレベルであるCCNPに挑戦して、業務で使用する機器やネットワーク全体の理解を深めたいと思っています。

佐久間:おめでとう!CCNAはDennis君の業務に関連する内容なの?

Dennis:そうだね。業務で使うコマンドとほぼ同じコマンドがテストに出てきたりしてました。CCNAに合格すると作業の理解が深まるので、早めに勉強した方が良いと思います。

北村:僕は、事業部として、数字を見ながら事業全体を管理していくというところ、言い換えると、より経営に近いところに興味があるので、財務の部分をもう少し勉強していきたいです。社長の佐々木さんを初め、上位層の見ている景色をしっかり認識しつつ、目の前の自分のタスクも確実にこなしながら業務に取り組んでいきたいです。

今井:僕は、自分で開発内容を考えるところからやりたいなと思います。 一年目の時は与えられたタスクに対応するということがほとんどだったのですが、BBSakuraは作りたいものを提案したらやらせてくれる会社だと思うので、自分で欲しい機能を提案していきたいと思います!

佐久間:みなさんありがとうございました!

ーーーーーーーーーーーーーーーーー

最後に、、、

昨年配属された当初は私含め、ネットワークの専門知識を持っている人はほとんどおらず、みんなが初心者からのスタートでした。しかし今回のインタビューで、同期がそれぞれの場所で諸先輩方から仕事を教えていただき、活躍している様子を聞けてとても嬉しくなりました! また、新卒社員でもBBSakuraらしく柔軟な働き方をしている姿も印象的でした。 これから社会人2年目の年となるので、さらに業務の幅を増やしてBBSakuraの行動指針である「Beyond the border」を体現していきたいと思います。

*1:2023年のBBSakura新卒メンバーは全員がソフトバンク株式会社、BBIX株式会社からの出向扱いとなっています。

*2:エルダー:新入社員一人につきエルダーという先輩社員が一人ついて、業務や会社のことなど、相談に乗ってくれます。

*3:CCNA:コンピュータネットワーク機器の大手、 シスコシステムズ合同会社による認定資格であり、ネットワークエンジニアの入門資格

MWC2024感想レポート

はじめに

こんにちは、BBSakura Networksの秋山です。
今回はスペインのバルセロナで開催されたMWC2024に来場者として参加させていただいたので、その感想をレポートしたいと思います。 MWCとは前回の記事で解説されているように総出展者数2700社以上、参加者は200カ国以上から10万人以上にも及ぶ大規模なモバイル通信関係の展示会です。
自分は普段OCXのバックエンド開発をしており、モバイル通信とは直接的な業務の関わりがない&まだ新卒2年目の若造だったということもあり、正直参加は難しいかなと思っていたのですが、立候補したら快く参加させてくれました。会社には感謝してもしきれません。

全体の所感としては、思ったよりモバイル通信に特化した展示というわけではなく、メインがAIやセキュリティでもモバイルが絡んでいればよしとしているような雰囲気があり、様々な製品を見ることができてとても楽しめました。もちろん、モバイル用のアンテナや監視ツールなど、モバイルに特化したものもあり、5日間ありましたが飽きることはなかったです。

MWC会場前にあったMWCと書かれたモニュメントの写真
MWC会場前にあったモニュメント

面白いと思った展示

6G対応アンテナ

Ericssonさんのブースで6G対応のアンテナが展示されていました。このアンテナはセンチメートル波を採用しており、7GHzから15GHzの周波数帯域を使うことができるように設計されているとのことです。8GHzという広い帯域での通信を実現するために、この四角のアンテナ内部で400MHzの帯域幅を持つアンテナ要素を組み合わせてアレイ(複数のアンテナ素子が連続して配置されている状態)を構成しているとのことで、そのアンテナ要素の制御に関する開発を進めているということでした。6Gが実際のモノとして実現されているのを見るのはこれが初めてで、5Gの先の6Gを既にここまで進めている企業もあるのかと衝撃を受けました。

Ericssonブース展示されていた6G対応の次世代型アンテナの画像
6G対応の次世代型アンテナ

量子通信

スペインの政府機関から補助を受けているグループが集まって量子通信に関する展示を出していました。モバイル通信とは直接的な関係はないですが、認証系で使われることが期待されるとのことでした。画像は量子通信で認証を行っている様子で、ラック内上部の機器が通信の暗号化におけるエンコードをしていて、ラック内下部の機器はその暗号化における鍵の発行を行っているそうです。量子通信は概念を聞いたことがあるくらいでしたが、実際に量子通信が実用化されているのを見るのは初めてで技術進歩の早さを実感しました。

2つのラックの上にそれぞれPCがあり、PCからラック、もう一方のラック、PCへ量子通信ができている様子
量子通信が行われている様子

モバイル銃痕分析機

スペインの警察も展示をしていました。展示されているのはモバイル銃痕分析機で画像の中で床に置いてある部分をリュックのように背負って、ケーブルの先を手に持って銃痕にあてがうようにして使うとのことです。手に持っている部分にはレーザー照射装置が内蔵されており、銃痕にレーザーを当てて、そのエネルギーで散った物質による光の波長変化をカメラで読み取って銃痕を分析するようです。想定されている銃痕として画像にある小さな拳銃の弾からアサルトライフルの弾まで想定されているようで、日本とは想定しているものが違うなと思ったのを覚えています。

モバイル銃痕分析機が展示されており、机の上のPCと繋がっている。机の上には薬莢がおいてあり、拳銃からライフルの薬莢がサンプルとして置いてある
モバイル銃痕分析機の展示

スペインでの生活

今回なぜ自分でもMWC2024に参加できたのかというと、旅程を組んでくださった方が旅費を徹底的に削って下さり、より多くの人間が参加できるようになったためです。飛行機はなるべく安い便で行き、宿もホテルではなくAirbnbで家を丸ごと借りて、参加メンバー全員で泊まっていました。家を借りているため、キッチンや調理器具が非常に充実しており、食事もほとんど参加メンバーで自炊していました。会社の人と一つ屋根の下で生活するというのはもちろん、同じ食卓を囲むという経験は新鮮で楽しかったです。
複数人が各々で食べたいものを作るとライスとピザとハンバーグの山が食卓に並ぶという知見を得ることができました。

各々が料理をした結果食卓に並んだのはライスとピザとハンバークの山
スペインでの自炊の様子

スペイン観光

空いた時間でスペインの観光もしました。遠出するほどの時間はなかったので、自分はバルセロナ市歴史博物館に行きました。ここはバルセロナの旧市街という場所の地下にあるという特徴があります。バルセロナの旧市街は地理的にはかつてのローマ時代に都市があった場所で、現在の旧市街はそのローマ時代の都市遺跡の上に建っている状況です。このバルセロナ市歴史博物館はその地下遺跡に繋がっており、地上は旧市街になってますが、地下に潜ると1000年以上前のローマ時代の遺跡に切り替わるので結構な衝撃がありました。

バルセロナ市歴史博物館の地下にローマ時代の民家などを含んだ街の遺跡がある
バルセロナ市歴史博物館の地下遺跡

最後に

今回のMWC2024での経験はとても貴重なものでした。6Gや量子通信など、今までニュースでしか接することがなかった技術を実際に目にし、スペインで生活や観光を経験することができて、参加の立候補をして本当に良かったと思います。こうした若手でも意欲があればチャンスを掴める環境をありがたく思うと共に、ここで得た経験をなるべく還元しながら来年以降も新たに若手が参加できる雰囲気作りに貢献したいと思います。

おまけ

スペインのゴミ出しは全種類毎日出せるらしく、便利さに感動しました

スペインの道路には大きなゴミ箱があり、毎日回収されている
スペインのゴミ出しはとても便利

MWC2024に参加してきました!

MWC2024とは?

MWCとはMobile World Congressといい、毎年2月末頃スペインのバルセロナで開催されている、世界最大のモバイル通信関係の展示会になります。 いわゆるMNO(Mobile Network Operator)国内だと、SoftBank、Docomo、KDDI、Rakutenだけではなく、Mobile Network向けのソリューションや周辺ビジネスを提供している企業さんも数多く出展されていて、その広さは日本最大の東京ビッグサイトの展示面積の2倍の20万㎡にも及びます。

総出展者数は、2700社以上、参加者は200カ国以上から10万人以上にも及び、コロナ禍で一時期参加者が落ち込る以前と比較しても多くなっています。

MWC2024の概要が記載されている画像、参加者10万人、出展者2700社以上、参加国205カ国
MWC2024

MWC2024全体の展示状況

MWCはその年によってIoTとか5Gとか大きなテーマがあり今回はAI一色になるかなと思っていたのですが、見本市ということもありそんなこともなかったです。 モバイル通信を含む周辺のビジネス全般を展示しているような企業が多く、例えばAIを使って障害のサポートをしてくれるとか、AIを使ってRU(無線ユニット)の設置場所や処理を行う基地局を適切に選定し続けてくれるというような、AIを活用した製品というようなものがちらほらとあるような感じで、あまり最新のという印象はうけませんでした。

中国企業の露出は相変わらずすごい!でも・・・

MWCに行かれたことのある方はご存知かもしれないですが、MWC会場は大きな8つのHallに分かれているのですが、その一つであるHall1の80%〜90%がHuawei社が占めています。1社で10,000㎡程度は占めていて、中国メーカーはいくつかの国では苦境に立たされているとされていますが会場ではまだまだ大きなプレゼンスはあった印象でした。 2018年のファーウェイさんのブースですが、どうでしょう?変わっていますか?変わってないですか?

MWC2024のHall1にあるファーウェイブースの写真、2018年と2024年の比較が出来るようにしている。
Hall1のブースの写真2018年‐2024年

ちなみに・・・

MWCというか、海外の展示会は出展されているそのものを見るというよりも、あらかじめアポイントを取った企業の意思決定権のある人や、次に繋げるためのミーティングがメインになっているという側面があります。そのため展示スペースの大部分がミーティングスペースだったり、そもそも展示しておらずミーティングスペースをメインにしている企業さんも多いです。会場のうちHall7の1/3程度がミーティングエリアになっているというと、どれくらいの企業がミーティングを重視しているかわかりますでしょうか?

MWC2024会場マップ、ミーティングエリアが塗りつぶされている。
MWC2024の会場

個人的に面白いなと思ったもの

会社としてはモバイルコア関係のものや、モバイル通信関係の企業をみてまわったので、そのあたりは他のかたがきっちり書くと思うので、ここでは個人的に面白かったものをいくつかご紹介します。

通常のサーバーを液浸する溶液と専用のケース

通常のサーバーを漬け込んで液冷にしてしまう機材 基本的にはどんなサーバー(メーカーが認めていなくても)も液冷に出来るという説明がされていました。 H100等を搭載したサーバーも稼働実績があるとのことなので、電力は潤沢にあるけど、新しく発熱量の多いサーバー機器を入れたい場合にはサーバールームやデータセンターの冷却機の更新が必要などというような状況であれば、利用もあるのかなと思いました。 ただ、データセンターの運用オペレーションが大きく変わってしまうので、なかなか難しくはありそうです。

サーバーが専用の液に浸かっている写真
液浸サーバー用溶液&ケース

IOWNに利用される(であろう)サーバー

富士通さんのブースに設置されていた、IOWNに利用されているサーバーとのことでした。 高性能で、消費電力に強みがあるとのことだったのですが、展示されている方的にはイチオシは写真の中央部に乗せてあるクーラーボックスだそう。 これは通常のクーラーボックスと入れ替えるだけで液冷にすることができるということを仰っていました。

サーバーの画像
サーバー機材

NECさんのブース

□ 動画送信をスムースにするための仕組み

NECさんのブースでは、モバイル通信を使った場合に必要なエリアのみのデータを送信することによって、動画全体がカクつくのを抑えるような仕組みや通信が遅くなるエリアでは接続先を切り替えて通信をすることによって、動画送信をスムースにする仕組みが展示されていました。 これは自動走行車(レベル3<異常時には人がリモート等で介在する>)などを利用する際に効果的で実用的なものであるなと思いました。

車両から撮影した動画をデータ転送した際の画像貼り付けられている、NECの技術を利用しない場合は動画全体がカクついているのに対し、利用した場合には動画が鮮明になっている。
NECが開発した技術を使う場合使わない場合

□ NECの生成AI

NECの生成AIは動画を読み込ませるとどのような状況であったのかを日本語の説明文を作成出来るというものでした。 実際の動画でも交通事故の動画を読み込ませて、何が起こったかを生成していました。読み込まれた動画はオートバイと自動車の接触事故で生成された文章は、自動車がオートバイの動きをよく確認しなかったため事故が発生したと思われるというようなものでした。 しかし、私が感じたのはオートバイが車線変更を実施した際に、車の確認をしていないために発生したのではないかと感じたので、かなりの乖離があり、利用方法としては、事故発生時の動画を読み込ませて事故の当事者が納得したのなら、そのまま保険等の負担割合を決めて、納得できなければこれまでどおり保険調査員が介在するような形で省力化を計っていくというような使い方でできそうでした。

いずれも実用が近そうで面白かったです。

NECの生成AIの説明画像
NECの生成AIの説明画像

日本ブース!

海外の展示会には各国が国として展示をして、各国のソリューションのアピールをしているものがあります。 日本もMWCの展示で力を入れており、Hall6総務省がすでに製品化されているようなものを持っている企業と、4YFNでJETEROがスタートアップでこれからソリューションが出来るような企業とそれぞれ展示しておられました。

日本ブースの写真
日本ブース
4YFNは4年後に来る(かもしれない)という技術の展示なので荒削りですが、非常に面白いものがたくさんあります!

JETROブースの写真
JETROブース

BBSの継続的な海外展示会参加に向けて

個人的には、特定の人だけが行き続けるというよりはなるべく多くのワカモノに行ってほしいという希望があります。

MWC開催タイミングのホテルや飛行機はめちゃ高です。 普通のホテルでも1泊5万円とかザラで、飛行機も高くなる傾向があります。

なので、普通のやり方ではコスト的に多くのワカモノには行ってもらえないので、下記のようにやっていくのはどうかな?

当たり前ですが、楽しいから行くというような理由は企業では通用しません、きちんと目的とどのような成果が得られるかの説明ができる状態にしておくことは必要です。

そのうえで

 行くこと自体はとにかく早く決めておく

 決めることによって、ホテルその他の予約が非常に安価にできます。宿泊場所も都合の良いところが安く、キャンセルポリシーも有利な場合が多いです。  航空券も早めに抑えることによって、相当コストが抑えられます。たくさんのワカモノに行ってもらおうとすると、こういうのって重要です。

 ちなみに、今回当社の若者たちは、MWC会場から地下鉄で1本、ドア2ドアで20分くらいのところに、Airbnbで一軒家を丸ごと借りて、6日間ほど過ごしていました。最大9名まで泊まれて、6日間で60万円ちょっとなので、なかなかリーズナブルであったのかなと思います。

リビングルームの画像
Airbnbで宿泊した施設

 こういうイベントごとは、決まった人が常に行くというよりは、新しいことに敏感で挑戦をしようとするワカモノにこそ多く行ってほしいと思っていてできれば次のワカモノに同じように紡いで行ってほしいなと思います。

最後に

実は、バルセロナの最終日に会食に行った先でスリにあいました。 スリが多いのは以前行ったときから認識していたのですが、以前よりも会場の治安が良くなっていた気がしており、気が緩んでいたのかもしれないですね。

本当に体の正面に掛けていた、ボディーバックから引っこ抜いていったと推測しています。 正面からチラシのようなものを持って近づいてきて、眼の前でゆらゆらさせて気を引き、その隙に引っこ抜かれた(と思う)のですが、その時には全く気が付きませんでした。

幸い盗られたのはiPhoneだけで、保険が利用できて金銭的な被害は最少で済んだのですがみなさんも行かれるときには気をつけて下さい。

ボディーバックからiPhoneをスられている画像、生成AIで作成されている。
iPhoneをスられた

ちなみに、盗られたiPhoneを「探す」でしばらく見ていたのですが、バルセロナ市内をウロウロした後、バルセロナから車で1時間程度の場所に行って消息を絶ちました、たぶんバラされて売られていったのでしょう。

さて、こんな感じでMWC参加してきましたが、もちろん当社もしっかりと他社さんと面談しモバイルやOCX方面のビジネス面でもいろいろ進めさせていただいております。当社にご興味がありましたら、ぜひカジュアル面談しましょう! www.bbsakura.net

バルセロナの地図、盗られたiPhoneが移動している状態が示されている。
盗られたiPhoneの動き

おまけ。MWCで見た、(本当に)変わったもの

 ひとのみみ型マイクがついたマネキン

 これは、スマホが人の耳にどのように聞こえているのかを測定する計測器です。  ものすごくニッチですが、こういうものもありました。

マネキンの画像
マネキンの画像

 脳卒中かどうかを調べるための装置

 展示していた企業によると脳卒中なのに病院に連れて行くなど適切な処置をしないことによって、死亡する例があるらしく、このヘッドギアをつけて計測すれば病院に行かなくてはならないかどうかがわかるというものだそうで、医療へのアクセスのしやすさが異なる国ではこういった需要もあるのかもしれませんね。

ヘッドギアをつけたマネキンの首部分の画像
ヘッドギアをつけたマネキンの首部分

新卒のJANOG53体験記

はじめに

こんにちは、BBSakura Networks株式会社(以降BBSakura)にてOCXのクラウド直接接続まわりを担当してる太田です。

今回は新卒の私が初めてJANOGに現地参加した際の面白かったテーマについて2つ記述してみようかなと思います。

NETCON

www.janog.gr.jp

NETCONとは

上記サイトの文言だとNETCONとは

ネットワークエンジニアのためのコンテストです。JANOG参加者が誰でも参加できるネットワークコンテストを開催します。コンテストでは、実際にトラブルが起きているネットワーク環境を提供します。 それらを実際に解いていただくことで、ネットワークエンジニアとしてトラブルシューティングの勘を高めていこうという企画です。

だそうです。ここで私が引っかかったのが2点。

  1. ネットワークエンジニアのための →まだネットワークエンジニアを名乗るには早すぎる私が参加して大丈夫なのか

  2. JANOG参加者が誰でも参加できる →え、もはやネットワークエンジニアじゃなくても参加できる?

と難易度が全く分からず、参加して大丈夫なのか不安でしたが、「現地問題」という現地でしか解けない問題があったので部屋に寄ってみることにしました。

現地問題

(写真を撮り忘れたのが恐縮ですが)現地問題ではスイッチ、ルーター、光ケーブルなどなど実際の物を用いたトラブルシューティングを行うのが、オンライン問題との大きな違いです。(ちなみに現地問題は合計で4問でしたがオンライン問題は約30問ありました)

私が取り組んだ問題がこちらです。(答えも載っています) note.com

要約すると

  • 機器にSFPも光ケーブルも刺してるのにリンクアップしない。どうにかしてリンクアップさせてください。

という内容です。

私は物理機器を全く触ったことがなかったので、右も左も分からず、とりあえず何をすればいいかをスタッフの方に聞きました。 すると「まずはハードウェアのインターフェースの情報が見れるコマンド」を探してみようと言われたので、ひたすらググり続け、見つけたコマンドを打っては「いや、これ違うな」を繰り返していました。(そもそもベンダーによってコマンド違うのなんとかしてくれ)

そして最終的に見つけたコマンドが

show chassis hardware

です。これをJuniper機器で打つとハードウェアに関する様々な情報が出てきますが、その中にインタフェースに刺さってるSFPモジュールの情報が出てきます。

今回は最初に両ポートに刺さってたSFPモジュールが一致していなかったため、片方を抜いてもう片方に合わせてあげるとリンクアップするという内容でした。

とまあここでは簡単に書きましたが、実際は何も分からない中、ほぼ全てスタッフさんに導いて頂き、なんとか回答に辿り着いています。ありがとうございました。

結果的に誰でも参加できるは正しかったですね(次はもう少し自力で解けるようになりたい)

エンジニアのキャリアパス古今東西 ~エンジニアが経営に参加してみたら見えるようになった世界~

www.janog.gr.jp

JANOGでは、登壇者が大勢の聴衆に向かって特定のテーマを元に語りかけ、聴衆の質問を受けながら議論を深めていくミーティング形式のプログラムが複数開催されています。プログラムの中には難しい技術的な要素を含むものも多いですが、誰にとっても聞きやすい系のものもあります。

今回私が取り上げるのはその中の一つで、エンジニアのキャリアパスについて語られていたものです。登壇者は4名でそれぞれが

  • エンジニアをやっていたら, ~~~~~になっていました

といった方々です。この中で1人次元が違うなあと感じた方がいるのでその方について思ったことを書いていこうと思います

その方のスペックは

  • 34歳時点でCOO
  • 学生時代にCCNPを取得
  • 転職3回

と言った感じで正直凄すぎて参考にならないと感じましたが、その方が仰っていたことの中で以下のような点は実践することができるのではないかと思いました。

  • 予算・納期のことは常に考える
  • 20代のうちはいいマネージャーを探し徹底的に観察
  • CCNPを取得(大変そう)

他にもマインドのことや管理職になって変わったことなど色々仰られていましたが、果たして自分はエンジニアに向いているのか、管理職・経営に向いているのかも考えさせられるプログラムでした。20代もあっという間に終わる気がしているので日々を大切に過ごしたいです。

おわりに

初めてのJANOGでしたが、多くの刺激をもらったと同時に「いつになったらこの方々のレベルに到達できるんだろうか」と虚無感にも駆られました。まずは「ネットワークエンジニア」を名乗れる段階まで成長し、いつかはJANOGで発表する側、そしてこんな記事を書かれる側に回れる日が来るように、日々精進していきます。

OCXを支える技術 #4 Building the OCX Identity Provider System with Kratos and Hydra / Kratos と Hydra で作る認証認可基盤

Japanese follows English.

和訳は英語の次に記載されています。

Hello, I'm Atreya, a full-stack engineer at BBSakura Networks where I lead the UI team and oversee our identity provider's development and maintenance. I also collaborate closely with our API team, lending a hand in backend tasks if required, since I was involved in backend development as well during the early phases of the project.

Identity management has always been an integral component of modern applications and for software engineers seeking to construct a bespoke identity provider system, understanding the underlying architecture is essential. In this article, I'll be sharing insights into how I built our in-house identity provider system using open-source solutions: Kratos and Hydra.

What is an Identity Provider?

At the core of any robust digital solution is an identity provider (IdP) system. An IdP system is essentially the backbone that supports user authentication (verifying who the user is) and authorization (determining what the user can do).

The Core Components of our IdP System

Our IdP system comprises the following critical components:

  1. OCX Identity Provider: This server is at the heart of our system. Not only does it render the UI, but it also operates as a bridge between Hydra and Kratos. With Kratos already offering a configuration option to integrate Hydra, our Golang server focuses on rendering the UI, handling consent and logout requests, and forwarding the generated access token to our frontend console.

  2. Hydra: An open-source OIDC-compliant OAuth2 Server, Hydra's primary responsibility in our setup is to issue access tokens once the user is authenticated through Kratos. This ensures that our backend only needs to validate the access token for each API request.

  3. Kratos: A headless, open-source identity management system, Kratos provides the authentication mechanics. By being headless, it offers the flexibility to design a UI consistent with our system's overall design and functionality.

The following diagram illustrates how the three components talk to each other:

a sequence diagram illustrating how the three components talk each other. From left to right, the four participants are placed: OAuth 2 Client (Browser), OCX Identity Provider, ORY Hydra, and ORY Kratos. The sequence is as follows:  1. the OAuth 2 Client initiates an authorization code flow or an implicit flow request to Hydra. 2. Hydra verifies that there is no user session, i.e. the end user is not authenticated. 3. Hydra redirects to the OCX Identity Provider and sends a request with login challenge. 4. If there is no valid flow ID, the OCX Identity Provider retrieves the authentication details. 5. If there is no user session, the OCX Identity Provider follows link to '/self-service/login/browser?return_to="/login?refresh=true&login_challenge=xxx"'. 6. Kratos creates and stores a new login flow. 7. Kratos returns 'HTTP 302 Found <selfservice.flows.login.ui_url>?flow=<flow-id>' to the OCX Identity Provider. 8. OCX Identity Provider shows the login UI to the client (browser). 9. The user fills out the form and clicks login. 10. OCX Identity Provider submits the form to Kratos with 'POST /self-service/login/browser?flow=<flow-id>'. 11. Kratos validates the form and sets a cookie on the client (browser). 12. OCX Identity Provider redirects to Hydra's redirect URL with the verifier.  13. Hydra redirects to the consent endpoint '/oauth2/auth/requests/consent' with the concent challenge. 14. OCX Identity Provider obtains and accepts detailed information about the requested scope (OpenID, OCX Portal, etc.) 15. OCX Identity Provider redirects to the Hydra redirect URL with the verifier. 16. Hydra verifies grant. 17. Hydra sends an access token to the client (browser).

Why Kratos and Hydra?

Developing an identity provider from scratch is a daunting task. Instead of reinventing the wheel, we decided to stand on the shoulders of giants: Kratos and Hydra. Our choice was strategic. Both tools are open-source and built using Golang, a language we're familiar and comfortable with. This not only ensures a smooth integration with our backend service, but also makes it feasible for our team to contribute back, be it bug fixes or feature enhancements. I've personally fixed a bug (https://github.com/ory/kratos/pull/2507) and proposed a new feature (https://github.com/ory/kratos/issues/3037) to Kratos which I am currently developing.

On the frontend, we are using Next.js along with NextAuth.js. NextAuth.js simplifies the task of setting up custom OIDC-compliant OAuth2 servers with Next.js. All that needs to be done is register an OAuth client ID and client secret in Hydra and setting up the client ID and secret from Hydra into the NextAuth configuration. The result is a seamless bridge between our frontend console with our identity provider system.

It's worth noting that while Kratos is our choice for storing fundamental authentication details, the majority of business-centric data, including user roles, preferences, and more, is safely housed in our backend database. This clear demarcation ensures system clarity and efficiency.

Why not use services like Auth0 or Okta?

You might wonder, why not adopt mainstream services like Auth0 or Okta? Here's why:

  1. Control Over User Data: With our chosen setup, we have complete control over user data.

  2. Transparency: As Kratos is open-source, we're privy to how the data is saved. This transparency is paramount from a security perspective. Being open-source, Kratos affords us a detailed look into its workings. To illustrate, here's the schema of the tables that store user data.

an ER diagram illustrating the schema of the tables that store user data. There are seven tables (networks, identities, identity_credential_types, identity_credentials, identity_verifiable_addresses, identity_recovery_addresses, identity_credential_identifiers ), with columns and relationships for each table.

Final Thoughts

Incorporating existing, robust solutions like Kratos and Hydra allowed us to focus on optimizing our business logic rather than grappling with the foundational challenges of developing an identity provider from scratch. The synergy between these tools and our custom Golang server resulted in an IdP system that is not only efficient but also scalable and maintainable.

For those interested in diving deeper, Kratos and Hydra both boast excellent documentation ( https://www.ory.sh/docs/ecosystem/projects ) . While we chose the self-hosted open-source versions of Kratos and Hydra, it's worth noting that Ory, the company steering the development of these tools, offers a managed cloud service. This might appeal to those who prefer a managed service over the responsibility of hosting by themselves.

Additionally, an open-source example of Kratos-Hydra integration using Golang can be explored here ( https://github.com/atreya2011/go-kratos-test/tree/hydra-consent ). Building on top of proven platforms accelerates development and ensures that we're working with industry-tested security and performance standards. In essence, it's about smart engineering.

Happy coding!

Disclaimer: This article is not an endorsement of Kratos and Hydra.

日本語訳

こんにちは、BBSakura Networksのフルスタックエンジニア、アトレヤです。UIチームをリードしており、認証認可基盤の開発とメンテナンスも行っています。また、プロジェクトの初期段階ではバックエンド開発にも携わっていたため、必要に応じてAPIチームと密接に協力し、バックエンドのタスクにも手を貸しています。

「アイデンティティ管理」はモダンなアプリケーションに不可欠な要素であり、専用の認証認可基盤を構築しようとするソフトウェアエンジニアにとって、基盤となるアーキテクチャを理解することは極めて重要です。この記事では、オープンソースのソリューション、Kratos と Hydra を使用して認証認可基盤を構築した方法についての知見を共有します。

Identity Provider とは何か?

全ての堅牢なデジタル・ソリューションのコアには、認証認可基盤があります。認証認可基盤は基本的に、ユーザー認証(ユーザーが誰であるかを確認すること)と認可(ユーザーが何をできるかを決定すること)をサポートするバックボーンです。

OCXの認証認可基盤のコアコンポーネント

OCXの認証認可基盤は、以下の重要なコンポーネントで構成されています。

  1. OCX Identity Provider: このサーバーはOCXのシステムの中心にあります。UIをレンダリングするだけでなく、HydraとKratos間のブリッジとしても動作します。Kratosは元々Hydraを統合する設定オプションを提供しており、"OCX Identity Provider" はUIのレンダリング、コンセントとログアウト・リクエストの処理、生成されたアクセストークンをフロントエンドに転送することにフォーカスしています。
  2. Hydra: OIDC準拠のオープンソースOAuth2サーバであるHydraの主な役割は、ユーザがKratosを通して認証された後にアクセストークンを発行することです。これにより、OCXのバックエンドはAPIリクエスト毎にアクセストークンを検証するだけでよくなります。
  3. Kratos: オープンソースのヘッドレスなアイデンティティ管理システムであるKratosは認証の仕組みを提供します。ヘッドレスであることで、OCXのシステム全体のデザインと機能性に合致したUIを設計する柔軟性を提供します。

実際の処理の流れは、以下のシーケンス図を参考にしてください。

コアコンポーネント間のやりとりを示すシーケンス図。左から、OAuth 2 Client (Browser), OCX Identity Provider, ORY Hydra, ORY Kratos の 4 つの登場人物が配置されています。シーケンスは以下の通りです。1. OAuth 2 Client は Hydra に対して 認可コードフローまたはインプリシットフローのリクエストを開始します。2. Hydra はユーザーセッションがない、つまりエンドユーザーが認証されていないことを確認します。3. Hydra は OCX Identity Provider にリダイレクトし、認証のためのチャレンジを含むリクエストを送信します。4. 有効なフロー ID がない場合、OCX Identity Provider は認証情報の詳細を取得します。5. ユーザセッションがない場合、OCX Identity Provider は Kratos に対して '/self-service/login/browser?return_to="/login?refresh=true&login_challenge=xxx"' のリンクを辿ります。6. Kratos は新しいログインフローを作成および保存します。7. Kratos から OCX Identity Provider に 'HTTP 302 Found <selfservice.flows.login.ui_url>?flow=<flow-id>' を返します。8. OCX Identity Provider はクライアント(ブラウザ)にログイン UI を表示させます。9. ユーザーがフォームを埋めてログインをクリックします。10. OCX Identity Provider は Kratos に対して 'POST /self-service/login/browser?flow=<flow-id>' でフォーム送信します。11. Kratos はフォームの有効性を検証し、クライアント(ブラウザ)に cookie を設定します。12. OCX Identity Provider はベリファイアとともに Hydra のリダイレクト URL にリダイレクトします。13. Hydra はチャレンジとともに同意エンドポイント '/oauth2/auth/requests/consent' にリダイレクトします。14. OCX Identity Provider は要求されているスコープ(OpenID, OCX ポータルなど)について詳細な情報を取得し、受け入れます。15. OCX Identity Provider はベリファイアとともに Hydra のリダイレクト URL にリダイレクトします。16. Hydra は権限を確認します。17. Hydra はクライアント(ブラウザ)に対してアクセストークンを送信します。

なぜKratosとHydraなのか?

認証認可基盤をゼロから開発するのは大変な作業です。車輪を再発明するのではなく、我々開発陣は巨人(HydraとKratos)の肩の上に立つことに決めました。この選択は戦略的でした。KratosもHydraもオープンソースで、開発陣が慣れ親しんでいるGolang言語を使って開発されています。これは、OCXのバックエンドとのスムーズな統合を保証するだけでなく、バグ修正や機能拡張などにOCXのチームメンバーが貢献することを可能にします。私自身、バグ ( https://github.com/ory/kratos/pull/2507 ) を修正し、現在開発中の新機能 ( https://github.com/ory/kratos/issues/3037 ) をKratosをメンテしているOry社に提案しました。

フロントエンドでは、Next.jsとNextAuth.jsを使用しています。NextAuth.jsでNext.jsにカスタムのOIDC準拠のOAuth2サーバをセットアップする作業が簡単になります。HydraにOAuthのクライアントIDとシークレットを登録し、NextAuth.jsのコンフイグにこのクライアントIDとシークレットを設定するだけです。その結果、OCXフロントエンドのコンソールと認証認可基盤をシームレスにつなぐことが可能になります。

Kratosは基本的な認証情報を保存するために使用されており、ユーザのロールなどを含むビジネス中心のデータの大部分は、違うバックエンドデータベースに安全に格納されています。この明確な区分により、システムの明瞭性と効率性が保証されます。

なぜAuth0やOktaのようなサービスを使わないのか?

Auth0やOktaのような主流のサービスを採用していない理由は以下の通りとなります。

  1. ユーザデータの管理: ユーザデータを独自に管理することができます。

  2. 透明性: Kratosはオープンソースであるため、データがどのように保存されるかを知ることができます。この透明性はセキュリティの観点から最も重要なことです。オープンソースであるため、その仕組みを見ることもできます。例として、ユーザデータを格納するテーブルのスキーマは以下の通りとなります。

ユーザデータを格納するテーブルのスキーマを表す ER 図。7 つのテーブル(networks, identities, identity_credential_types, identity_credentials, identity_verifiable_addresses, identity_recovery_addresses, identity_credential_identifiers )があり、各テーブルのカラムや関係性が書かれています。

最後に

KratosやHydraのような既存の堅牢なソリューションを組み込むことで、認証認可基盤をゼロから開発する基礎的な課題に取り組むよりも、ビジネスロジックの最適化に集中することができました。これらのツールとカスタムGolangサーバであるOCX Identity Providerとの相乗効果により、効率的であるだけでなく、スケーラブルでメンテナブルな認証認可基盤を構築することができました。

KratosとHydraはどちらも優れたドキュメントがあるのでぜひ読んでみてください ( https://www.ory.sh/docs/ecosystem/projects ) 。OCXではKratosとHydraのセルフホスト型のオープンソース版を選びましたが、これらのツールの開発を主導しているOry社がマネージドクラウドサービスも提供しています。これは、自分でホスティングして責任を負うよりも、マネージドサービスが良いというチームには合っていると思います。

さらに、Golangを使用したKratosとHydraのブリッジ実装のオープンソース例をこのレポ ( https://github.com/atreya2011/go-kratos-test/tree/hydra-consent ) で見ることができます。実績のあるプラットフォームの上に認証認可基盤を構築することで、開発を加速し、業界でテストされたセキュリティとパフォーマンスの標準を確実に使用することができます。要するに、スマートエンジニアリングということです。

ハッピー・コーディング!

www.DeepL.com/Translator (無料版)で翻訳し、修正したものです。