ISPの要であるRADIUSシステムのDevOps環境整備とクラウドネイティブ化を3年がかりで実現したことについて、技術検証で頓挫しかけた苦労話から、クラウド化のコツまで詳しくインタビューしました。

ISPの接続認証機能を担うRADIUSシステムを、コンテナやサーバーレス技術を活用して3年がかりでクラウドネイティブ化し、2022年6月から正式にサービスを開始しました。

それにあわせて、開発から運用までをスムーズに連携するDevOps環境を実現し、150台のオンプレミス・サーバーにかけていたシステム運用・保守工数を半減し、インフラ費用を従来の3分の2に圧縮することができました。

DevOps環境の特徴は次の通りです。

複数のクラウドサービス・リージョンを利用することで耐障害性を高めるマルチクラウド
インフラをコードで記述するInfrastructure as Code（IaC）
ソフトウェア開発におけるテストからデプロイまでを自動化する継続的インテグレーション/継続的デプロイ（CI/CD）
バージョン管理システムGitLabを活用してCI/CDを実現するGitOps

クラウドネイティブ化の背景やメリット、苦労した点や工夫について、RADIUSを担当しているお二人にインタビューしていきます。

技術的負債を一気に返却するはずが存続の危機に

Q. RADIUSシステムについて教えてください。

石井： RADIUSシステムは、ISP（Internet Service Provider）の接続認証機能を実現する重要なシステムです。インターネット接続における認証（Authentication）、認可（Authorization）、利用実績の記録（Accounting）を担います。インターネットに接続したいお客様は、宅内装置からアクセス回線を経由してBIGLOBEのインターネット設備に接続します。その際、アクセス回線事業者のRADIUSクライアントがBIGLOBEのRADIUSサーバーを呼び出します。

お客様の数が増えるに従って、我々が運用するRADIUSサーバーも大規模化し、世代交代を繰り返してきました。第1世代はアプライアンス製品に付属してきたRADIUSサーバーを改造したものです。これを内製化するため、オープンソースのRADIUSに複数のモジュールを追加したのが第2世代、コンテナ化してKubernetesで実行する今の形が第3世代になります。

石井賢二（いしいけんじ）
基盤本部モバイルコア技術部エキスパート

1994年日本電気株式会社入社
2001年 NECビッグローブ株式会社（当時）異動
アクセス網の高度化にまつわる業務を経て、2010年よりRADIUSシステムを担当

谷山： 第3世代のシステム構成はRADIUSが出力したログがデータ処理パイプラインを通過することで加工・振り分けされ、監視システムやバックオフィスのシステムに流れるようになっています。このパイプラインはAmazon KinesisやAWS Lambdaを組み合わせたサーバレスな構成とすることで、クラウドネイティブ化を図っています。

Q. 今回、クラウドネイティブ化に挑戦したのはなぜでしょうか？

石井： RADIUSシステムはインフラ部門で運用してきました。インフラ部門は、ネットワーク装置を買ってきてデータセンターで組み合わせ、BIGLOBE固有の接続認証が必要な際にRADIUSを組み込みます。ただ、事業拡大に伴い、第1世代の改修は限界を迎えていました。そこで、第2世代でオープンソースを使ったサービス内製化に取り組みました。

内製化によってできることが増えたのは良かったのですが、オンプレミスのサーバー150台を運用する工数が大きな負担となっていました。また ISPの接続認証機能ですから、作業によるサービス影響は避けなければなりません。当時は表計算ソフトで作った手配書で作業をしていたのですが、精神的な負担もとても大きかったです。

そんな中、2018年にクラウド化を全社的に推進することになりました。オンプレミスのサーバーをクラウドにそのまま移行するLift & Shift戦略が採られることが多いのですが、私は開発と運用が一体となって改善を続けるDevOpsと、それを支えるクラウドネイティブ技術に強い魅力を感じました。

そこで、クラウドネイティブ化を前提に技術検証を開始したのですが、思ったような成果を出すのは難しく、あっという間に1年半が経過してしまいました。

うまくいかなかった原因の一つは、クラウド技術を習得するにも既存業務に忙殺されてしまい、時間が取れなかったことにあります。オンプレミスサーバーで稼働させているRADIUSの保守作業、機能追加に伴うソースコードの調査や改修作業、他部門からの調査依頼の対応などをやりきり、残った時間でクラウド化に取り組んでいました。特に、他部門からの依頼はこちらの都合に関係なく発生し、かつ、優先順位も高いため、その対応で燃え尽きてしまうこともしばしばでした。

そんな時に、中途入社でチームに参加してくれたのが谷山さんでした。試行錯誤でぐちゃぐちゃになっていた検証環境をきれいに整えつつ、セキュリティ基準に準拠したシステム構成をTerraformとAnsibleを使ってさっと実現してくれました。また、GitLabを導入してCI/CDパイプラインを構築し、安全にインフラを構築するGitOpsの道を切り開いてくれました。

谷山： 私はエンジニアとして先進的なことに取り組みたくてBIGLOBEに転職してきました。石井さんが「世界標準のやり方でやろう」と声をかけてくれ、自由にやらせてくれたのがとても嬉かったです。

得意なことで補い合いながら課題をクリア

Q. クラウドネイティブ化に挑戦するためにどんな準備をしましたか？

石井： 研修に参加したり、ベストプラクティスを徹底的に調査しました。技術検証が頓挫しかけてからは、Amazon Web Services（AWS）が得意なパートナー会社に参画してもらい、技術力を底上げしています。

また社内システムとの連携インターフェースをクラウドネイティブ化するにあたり、多くの関係者に協力してもらいました。ストレージはAmazon S3、ファイル転送はAWS Transfer for SFTP、REST APIはAmazon API Gatewayにそれぞれ置き換えています。

谷山： 石井さんと私でそれぞれ得意なことが違います。良いところを上手く組み合わせて課題を突破してきました。石井さんは幅広い情報収集が得意です。世界標準のやり方をチームにどんどんインプットしてくれます。

私は深く潜るのが得意です。必要になれば、どんな複雑なネットワーク構成であっても現状を整理しながら理解を深めます。逆に言うと、必要になるまで調べません。プログラマーの三大美徳の一つである「怠惰」な人間なんだと思います（笑）。深く潜りすぎて、世の中のやり方が見えなくなることもあるので、石井さんの情報には感謝しています。

谷山大介（たにやまだいすけ）
基盤本部モバイルコア技術部エキスパート

2020年1月中途入社／社会人8年目
前職大手キャリアのインフラ開発を経て、現在はBIGLOBE RADIUSシステムのマルチクラウド化、モバイル通信サービスdonedoneのアプリケーション向けインフラ開発等のプロジェクトに従事している。

Q. やってみて想定外だったことはありますか？

谷山： 「クラウドなら最初はラフに作って、後から変更すればよい」と考えていたところがあるのですが、設計段階から考えておくべきことがたくさんありました。

石井： そうですね。例えば、個人的に力を入れたのはリソースの命名規則です。パートナー会社が作ってくれた案をベースに、BIGLOBEの業務でよく使われる共通言語（例えば、サービスIDといった用語）を取り入れつつ、devやprdといった一意にならない表現を避けて曖昧さを排除しました。

特に気を使ったのが、出来上がる名前の長さです。長ければ入力ミスやコード量の増加につながりますし、コンソールでの一覧性も低下します。そこで必要最小限に留めたかったのですが、マルチリージョン、マルチクラウドについても考える必要があって苦慮しました。

Tagについても工夫しました。CI/CDの実行プロジェクト名をTerraform Tagに入れることで、そのリソースがCI/CDで作ったものなのか？どのプロセスで作ったのか？が一目瞭然となり、CI/CDの操作も楽になります。後からTagを追加するのはそれなりに大変なので、最初から入れておいて良かったです。

谷山： 命名規則は石井さんも苦しんでましたが、最初に作ったのはとても良かったと思います。Terraformで新しいモジュールを作るときには、その指針に沿うだけでそのリソースが何者か一意に特定できるようになっていたためとても楽でした。AWSでは作成後に変更できないパラメータがあるため、命名規則に限らず最初にポリシーを明確に決めておくことは非常に重要でした。

他にも初期に検討しておくことはたくさんあります。ログを処理するためにストリーミングデータをリアルタイムで扱うAmazon Kinesisを使っていますが、エラーを起こした場合にどう対処するのか？アラームはどう作るのか？といった異常系の対処を予め考えておく必要があります。

AWSのソリューション・アーキテクトからは、設計上考えておくべきことをリストとして提供していただきました。そのリストを見た時は、こんなに考えておくことがあるのか！と驚きましたが、最終的にはそのほとんどをクリアすることができています。

Q. 他にも、気をつけるべきポイントはありますか？

石井： オンプレミスでの常識は通用しないですね。定期的に処理をさせるバッチとして AWS Lambdaを動作させる時は、起動時刻も同時起動数も保証されません。Amazon DynamoDBを使ってロックの仕組みを導入するなど、きめ細やかな対応が必要でした。

また、AWS Lambdaは処理中のデータに問題があった時の扱いが難しく、アプリ側でAmazon S3に格納しています。Amazon S3の品質レベルはとても高いのですが、障害が全くないとは言い切れません。そこで、東京リージョンのAmazon S3が使えなくなったら大阪リージョンにフォールバックする仕掛けが必要になります。複数のリージョン上にシステムを構築しただけでは耐障害性は獲得できません。

ちなみに、今回のプロジェクトはベストプラクティスを参考に、最初からアベイラビリティ・ゾーンを3つ使うトリプルAZ構成を採用し、クラウドもオンプレと変わらず単一障害点のない24時間365日サービスの稼働に耐える構成を実現しています。

石井： 社内システムとの連携では、連携先システムへの考慮が不足していて迷惑をかけてしまいました。例えば、Amazon S3のオブジェクト数は事実上無制限ですが、オブジェクト数が多すぎて連携先で処理しきれなくなってしまったり、負荷試験の前後に評価環境のAmazon AuroraをAmazon KinesisやAWS Lambdaと共にスケールアップ・スケールダウンしたところ、連携先のアラーム発報を引き起こしてしまったり。いくらクラウドにスケーラビリティや伸縮自在性があっても、連携先にどのような影響を及ぼすかはよくよく考慮しなければいけません。一緒に解決してくれた関係者にはとても感謝しています。

フルリモートでも無事故のリプレースを実現したGitOps

Q. 今回の取り組みによって、どんなメリットが生まれましたか？

石井： コスト削減はもちろん、他社のベストプラクティスを参考にしながら、世界で議論されているようなDevOps環境に近づけた実感があります。インフラからアプリケーションまで全てのレイヤーをGitで管理するGitOpsを導入したことで、情報共有も、Issue管理も見える化が格段に進みました。

谷山： 実は、コロナ禍になってから私はほとんど出社することなく、このプロジェクトを成功させることができました。GitOpsを導入したことによる恩恵です。

以前は口頭でやり取りしていることが多かったのですが、在宅勤務になったタイミングで GitLabのIssueを中心としたコミュニケーションが実現できていたため、作業のヌケモレを圧倒的に減らせています。

以前はとても長かった朝会も、見るべきIssueだけを確認すればよくなったのでグッと短縮できました。Amazon VPCの削除といった「やるべきタスク」をいちいち「あの件どうなりました？」と確認しなくて済んでいます。

技術検証中にインフラ環境が不安定になっても、GitLabでその原因をすぐに把握できるようになりましたし、各自の作業がどこまで進んでいるかを追いかけられるのも助かります。

RADIUSのGitOpsについては過去に2つの記事を書いています。よろしければご覧ください。

style.biglobe.co.jp style.biglobe.co.jp

石井： クラウドは情報を集約できるのが良いですね。Amazon CloudWatchを見れば、何が起きているのかすぐに分かります。調査がとても楽になりました。

エンジニアが働く環境としてのBIGLOBEとは

Q. 中途入社された谷山さんから見て、BIGLOBEはどんな組織だと思われますか？

谷山： BIGLOBEには勉強好きな人が多いです。社内でハンズオンやライトニングトーク大会などを活発に開催していて、CI/CDやIaCなどの自動化についても知っている人も多いです。

しかし、社会インフラである通信を提供する立場ですから、お客様が使うサービスで障害を起こすことはできません。今回は不具合を洗い出すために、移行元のオンプレミス環境に流れているトラフィックをクラウド環境にミラーリングする並行稼働期間を作り、本番データ相当のデータで試験を重ねました。さらに、サービス開始間際には、旧環境に切り戻しをする判断をいつでも下せるよう、利用者の認証でトラブルが発生していないかをリアルタイムで監視するシステムをAmazon OpenSearch Serviceを使って組み上げていました。こうした入念な準備によって、障害を一切出すことなく、リプレースを完遂することができました。

クラウドは故障することを前提にシステムを構築します。きちんと備えれば、高い品質を実現することができ、品質以上の価値を享受することができます。

安全にやる限り、新しい取り組みに反対する人はいません。私が入社してからすぐに、部門として初めてGitLabを利用する申請をしましたが、上位上司も社外サービスの活用を高く評価してくれました。

世の中の潮流を知っている人も多く、幹部も反対しないので、本人のやる気次第で変えられる会社だと思います。私は、上司が自由にやってよい、と声をかけてくれたので幸運でした。

インフラ系でここまで自動化を実践している組織はまだまだ少ないと思います。インフラに関する知識を持ち、内製化が好きで、TerraformやAnsibleなどでIaCを全力でやっていきたい人にはピッタリだと思います。

Q. 歴史あるRADIUSシステムを支えてきた石井さんにとって、今回の取り組みはどんな意義があるでしょうか？

石井： 谷山さんという心強い味方が増えたおかげで、三度目の正直である真の内製化に大きく近づくことができました。また、世界標準の仕組みに近づけたことで、メンバーが楽になり、かつ、今後の改修もやりやすくなったと思います。私が引き継いだ時はとても大変な思いをしたのですが、あんな思いは次の人にさせたくないですね。

ただ、今回はあまりにたくさんのことに取り組んでしまい、正直詰め込み過ぎだったと反省もしています。AWS化、クラウドネイティブ化に加えて、GitによるコードレビューからCI/CDを自動化するGitOpsまで幅広く挑戦しました。システム構築後、関係部門と調整しながらサービスに影響を出すことなく移行するのも非常に大変でした。

取り組んだもの一つひとつが奥深いもので、試行錯誤を加えているうちに、当初のやり方から変わっていったものもあります。Gitは柔軟性が高い分、その使いこなし方はよく議論になります。例えば、有名な開発フロー（ブランチ戦略）にGit Flow、GitHub Flow、GitLab Flowがあります。当初はGitHub Flow一本で進めていたのですが、少し適用が難しいケースもありました。今ではリリースブランチと環境ブランチをそれぞれ準備するGitLab Flowも取り入れ、向き不向きを試行錯誤しながら管理しています。

新しいことに挑戦して学びが深まった結果、過去の自分にはツッコミを入れたくなることもしばしばです。GitOpsとCI/CDに挑戦した結果、ブランチ構成を丸ごと組み替える羽目になったり、自分の過去のコードに日々打ちのめされています。

ただ、自分の未熟さを感じこそすれ、目の前の動くコード、動くインフラから目を背ける訳にはいきません。外部環境もサービスも日々変化しています。触らなければインフラもサービスも緩やかに死んでいきます。

機械学習を活用した監視の高度化など、やりたいことは尽きません。CI/CDの自動化により、改修に伴うリリースを安全かつ頻繁に実現できるようになったので、高い品質を保ちながら、新しいことに挑戦し続けていこうと思います。

BIGLOBEはインフラ構築からアプリ開発まで幅広く取り組んでいる会社です。手作業が得意な人もいれば、自動化が好きな人もいます。インターネットは複数の組織で支えられていることから、交渉力が重宝される場面も多いです。たくさんのお客様に末永く使っていただくサービスを提供するためには、コスト計算やマネジメントスキルも重要になります。ぜひ、いろんな方に来ていただき、一緒になって企業理念である「つながる歓び、つなげる喜び」を生み出していきたいですね。

※ Amazon、Amazon Web Services、Amazon Aurora、Amazon CloudWatch、Amazon DynamoDB、Amazon Kinesis、Amazon S3、Amazon VPC、OpenSearch、AWS Lambdaは、米国その他の諸国における、Amazon.com, Inc. またはその関連会社の商標です。

※ Ansibleは、米国Red Hat, Inc. の米国およびその他の国における登録商標もしくは商標です。

※ fluentd、および、Kubernetesは、米国及びその他の国における The Linux Foundation の商標または登録商標です。

※ GitLabは、GitLab B.V.の米国およびその他の国における登録商標または商標です。

※ Terraformは、HashiCorp ,Inc.の米国およびその他の国における商標または登録商標です。

※ 記載している団体、製品名、サービス名称は各社またはその関連会社の商標または登録商標です。