オンプレミス環境で
運用してきたBIGLOBE RADIUSの
AWS移行とクラウドネイティブ化を同時に実現
GitOpsベースの
DevOpsプラットフォームにより、インフラ構築、運用、保守を自動化

CI/CDの適用で
システム運用・保守の負担を軽減したい

BIGLOBE は、国内有数のインターネットサービスプロバイダーだ。5G/LTE対応のモバイル、大容量の光回線をはじめ、Wi-Fi、ADSL、ダイアルアップといった多種多様な回線のインターネット接続サービスを提供している。ネットとリアルの世界において顧客の"Quality of life"をより豊かにする「Life-changing Company」となることが目標だ。

同社は 2019年度からの4カ年計画で、オンプレミス環境で運用するシステム基盤を全面的にAWSに移行する方針を定めた。オンプレミス上のシステム基盤をAWSへまずリフトした後にシフトする、いわゆるリフト＆シフト方式が主流の中、リフトをスキップし、一気にクラウドネイティブへシフトするアプローチをかけたのがBIGLOBE RADIUSだ。

BIGLOBE RADIUSは、BIGLOBEモバイルをはじめとする多種多様なインターネット回線の認証、認可、アカウンティング処理、いわゆるRADIUSを中核とし、付随する膨大なデータのETLまで一手に引き受けるシステム群の総称である。大きく、認証まわりと他システムとのインタフェースを担うフロントエンドシステム、RADIUSサーバのログデータ検索・分析システム、契約情報や接続実績情報などを一元管理するバックエンドシステムから構成される。300万人を超える会員がアクセスする同システムは常時毎秒1,000件近く、回線障害発生時には秒間1万件を超えるリクエストに対して数十ミリ秒単位で応答する仕様だ。その性格上、24時間365日の安定稼働が求められる。

基盤本部 モバイルコア技術部　寺内 智也　氏は、「BIGLOBE RADIUSは多種多様な回線を収容し、それぞれ異なる契約情報を理解する必要があるため、モジュールの作り込み量も膨大です。フロントエンド、バックエンドシステムともに場所やSLAに応じて負荷分散、ホットスタンバイといったさまざまな冗長構成をとり、万一の災害・障害時においても事業を継続できる仕組みになっています。ただ、従来のシステム運用・保守のプロセスは手作業で行うことが前提で、構成管理もExcelベースでした。システムの複雑さが増すにつれ運用・保守にかかる工数とコストが増加するとともに業務の属人化も進み、人為的ミスによるトラブル発生のリスクも高まっていたのです」と語る。

この問題をどうするか。解決策として挙がったのが、AWSへの乗せ換えとクラウドネイティブアーキテクチャによる再構築だった。このためにはGitOps、コンテナ、サーバレスなどの技術を活用したDevOpsプラットフォームを構築し、CI/CD（Continuous Integration：継続的インテグレーション/ Continuous Delivery：継続的デリバリー）を実現する必要があったのだ。

AWSマネージドサービスを
熟知するJMASをパートナーに

BIGLOBE は2019年4月、BIGLOBE RADIUS のAWS移行プロジェクトを発足した。まずはあるシステムベンダーの協力を得て構想の具現化に取り組んだものの結局うまくいかずプロジェクトは足踏み状態に陥ってしまったという。転換点となったのがJMASの訪問だった。AWSのパートナープログラムを通じて知ったJMASをパートナーとして迎え入れるかどうか評価することにしたのだ。

基盤本部　エキスパート　石井 賢二　氏は、「BIGLOBE RADIUSについて実現したい大まかな構成を示すと、JMASはすぐに社内検討に入り、プランを提示してくれました。各種AWSマネージドサービスを活用した最適化へのステップをわかりやすく説明し、われわれの発言から類推できる潜在的な課題にも言及してくれたことが印象的です。大いに頼もしさを覚え、JMASに協力を要請したのです」と話す。

また、クラウド移行を安全かつ確実に行うためには、移行元の環境や業務特性を十分に理解する必要がある。その点においても、オンプレミス環境のインフラ、およびアプリケーション開発におけるJMASの実績が評価された。

プロジェクトではJMASのインフラチームと、アプリケーションチームが参画・連携し、AWS上でのインフラ構築、およびコンテナを利用したアプリケーションのリホスティングを実施した。DevOpsプラットフォームの構築にあたっては、OS・ミドルウェアなどのインフラの設定をコードとして定義するInfrastructure as Codeのアプローチを採用。GitLab CIを用いてTerraformの適用自動化を実行できる仕組みとした。Gitリポジトリに変更点がプッシュされるたびにビルドやテストを自動実行するよう設定し、開発環境でテスト済みのコードを検証および本番環境に適用するGitOpsだ。

BIGLOBE RADIUSの一部であるログデータ検索・分析システムにもマネージドサービスがフル活用されている。Amazon OpenSearch を採用し、コンテナから出力される大量のログデータを一元管理し、インタラクティブに検索・分析できる仕組みを開発。Amazon Kinesis Data Stream、Amazon Kinesis Data Firehose、AWS Lambdaなどのサービスも活用して社内ユーザからの問い合わせに対し、1日あたり6,000万件近く出力されるログについて数カ月分を瞬時に検索・回答できるようにした。

DevOpsプロセスを効率化し、
運用・保守の工数とコストを大幅に削減

BIGLOBE は2021年3月、AWS東京リージョンにてクラウドネイティブアーキテクチャを適用したBIGLOBE RADIUSを稼働させた。冗長化のためしばらくの間はオンプレミス環境の旧システムを動かしてきたが、AWS大阪リージョンを利用したHAクラスターの構築・リリースを終えたタイミングで停止させた。AWS大阪リージョンでのサービスの追加にあたっては、既存のコードにいくらか手を加えて実行するだけで安全かつ迅速にリリースを完了したという。

BIGLOBE RADIUSは、フロントエンド稼働より1年経過しているが、認証リクエストに対するレスポンスは遅延許容の1/10を保っており、安定稼働を続けている。また、ログデータの検索・分析パフォーマンスに対するシステム運用者の性能劣化や不具合の報告もない。

GitLab技術に基づくDevOpsプラットフォームを構築できたことも成果だ。各種マネージドサービスを適切に組み合わせることでソースコードの開発からビルド、テスト、デリバリー、デプロイメントまでの自動化を実現し、DevOpsプロセスを効率化できた。

寺内　氏は、「かつては約150台のサーバを運用してきましたが、いまではその対象もOpenShiftのEC2インスタンスに限られます。コンテナ部分を除くほとんどをSaaS利用にしたこともあり、システム運用・保守に必要な人員は半減しました。インフラ費用も従来の3分の2に圧縮できた計算です。リザーブドインスタンスも利用すれば、さらなるコスト削減が見込めます」と語る。

今後は、AWSとGCP （Google Cloud Platform）のマルチクラウド環境による冗長化も進めていく計画だ。また、OSSやSaaSなども活用したシステムの分析強化にも取り組んでいく。

石井　氏は、「他のシステムの多くについては、リフト＆シフト方式でAWS移行を進めていくようです。JMASにはコンサルタントの立ち位置でもご参画いただき、全社的なクラウド最適化へのアプローチを加速してもらいたいと考えています。クラウド活用におけるベストプラクティスの取り込みと実装スキルの習得に引き続き注力し、随時フィードバックをいただけると、われわれとしては心強い限りです」と話した。