ソフトバンク様とIBMによる分散クラウド「IBM Cloud Satellite」共同検証の結果報告

記事をシェアする:

クラウド黎明期よりマルチクラウド戦略を掲げ適材適所でITプラットフォームを提供されているソフトバンク様。この度、同社とIBMにより、5G/IoT時代を見据えて分散クラウド「IBM Cloud Satellite」の共同検証を実施しました。共同検証の結果について、ソフトバンク法人事業統括の鈴木様、二藤様、李様にインタビューしました。

 

―― ソフトバンク様の、マルチクラウド、ハイブリッドクラウドへの取り組みをお聞かせください。

（ソフトバンク鈴木様）ソフトバンクの法人事業では、従来よりキャリアのコアビジネスである、インターネット、閉域ネットワーク、モバイル、セキュリティ、またグループ会社であるIDCフロンティアを交えたコロケーション、ホスティングといったビジネスを展開しています。これまでキャリアとしての特長を活かした「シームレス」、「セキュア」、「低遅延」といった価値をお客様に提供してきました。近年では、それを更に最大化するため、マルチクラウド戦略を掲げ、IBM Cloud、Microsoft Azure、Google Cloud、AWS、Alibaba Cloud、IDCFクラウドと各メジャークラウドとの協業を推進しています。一方で、ソフトバンクの設備で同社により運用されているプライベート・クラウドサービスとして、ホワイトクラウド「ASPIRE(外部サイトへ)」も提供しております。ソフトバンクは、お客様のビジネス要件に応じて適材適所でクラウド・サービスを提供できるマルチクラウド／ハイブリッドクラウド・インテグレーターと言うことができます。

 

―― 今回、分散クラウドの検証を開始した背景を教えてください。

（ソフトバンク鈴木様）現在、5Gの進展に伴い製造業、流通・小売業など幅広い分野で「エッジコンピューティング」が注目されています。一方で、IoTやAIの活用が進めば進むほど、リアルタイムでのデータ活用や分析の重要度は増し、低レイテンシー・低負荷・セキュアなデータ通信の実現が成否を分ける要因となります。エッジコンピューティングの導入においては、従来のパブリッククラウド単体のソリューションでは解決が困難な課題が発生します。例えば、製造現場のAI画像処理ソリューションを考えた場合、画像データの取り扱いにおいて、レイテンシーによるデータ処理遅延、データ量の増大による通信コスト、データを外出しするセキュリティリスクといった課題が発生します。分散クラウドを導入することで、パブリッククラウドのメリットを享受しながらも、各拠点の現場に近いエッジサーバーで画像認識処理を行うことができるので、レイテンシー、通信コスト、セキュリティの課題を解決することができます。同時に、エッジ、オンプレミス、パブリッククラウドに跨った分散環境を透過的なプラットフォームで一元管理することができれば、アプリケーションおよびインフラの運用効率を大幅に向上させることができます。ソフトバンクは5G/IoT時代を見据えて従来のパブリッククラウド一元化モデルでは解決が難しいこれらの課題を解決するにあたり、分散クラウドというテクノロジーに期待しています。

”分散クラウドとは、パブリック・クラウド・サービスをさまざまな物理的な場所に分散させ、パブリック・クラウド・プロバイダーがサービスのオペレーション、ガバナンス、進化に対する責任を引き続き負うというものです。分散クラウドは、低遅延とデータ・コスト削減のニーズと、データ・レジデンシの要件を抱える組織のシナリオに対して、俊敏な環境を提供します。また、データとビジネス活動が発生する物理的な場所の近くにクラウド・コンピューティング・リソースを配置するという顧客のニーズにも対応します。2025年までに、クラウド・サービス・プラットフォームの大部分は、ニーズ発生地点で実行される少なくとも何らかの分散クラウド・サービスを提供するようになるでしょう。バークは次のように述べています。「分散クラウドは、プライベート・クラウドに取って代わる可能性があり、エッジ・クラウドをはじめとする、クラウド・コンピューティングの新しいユースケースをもたらします。分散クラウドは、クラウド・コンピューティングの未来を示しているのです」”（出典：ガートナー、2021年の戦略的テクノロジのトップ・トレンドを発表）

―― IBMでは分散クラウドを実現するソリューションとしてIBM Cloud Satelliteを展開しています。今回の検証を IBM と実施するに至った経緯を教えてください。

（ソフトバンク鈴木様）前述のように、ソフトバンクでは、パブリッククラウド、プライベートクラウド、エッジコンピューティングの世界においてプラットフォームに縛られることなくお客様ニーズに応じて、適材適所でリアルタイムでのデータ活用や分析、低レイテンシー・低負荷・セキュアなデータ通信を実現できる世界を目指しています。一方で、IBMはハイブリッドクラウド＆AIのテクノロジー・プロバイダーとして、Red Hat OpenShiftを中核としたソリューションを展開しており、分散クラウドの基盤もRed Hat OpenShiftがベースとなっています。IBMの分散クラウドIBM Cloud Satelliteを使うことにより、いつでもどこでにでもクラウド・サービスやアプリケーションを配置することができます。しかも、たった一か所から数クリックで一貫した共通クラウド環境として展開でき、一元的に管理可能である点も大変魅力的です。データは、オンプレ環境に保持したままで良いので、データ転送やデータ保護の考慮が不要です。AI、IoT、分析サービス、アプリケーションがデータのある場所に来てくれるため、ネットワーク遅延の影響もないに等しいです。サービスの運用管理（インストール、セキュリティ・パッチ、アップグレード）についてもIBM Cloudが担ってくれます。特にソフトバンクのようなマルチクラウド／ハイブリッド環境において、オープン性がより重視されるエッジコンピューティングのアーキテクチャとの親和性を考慮すると、オープンなテクノロジーをベースとしたIBM Cloud Satelliteは、プラットフォームとして有力な選択肢になると考えています。

 

―― 今回の共同検証の内容についてご説明をお願いします。

（ソフトバンク李様）今回の共同検証では、マルチクラウドサービス基盤を提供するプロバイダという観点で、IBM Cloud Satelliteからマルチクラウド／ハイブリッドクラウドに跨る異なるクラウド環境を分散クラウドとして管理することを想定しました。下図は、今回の検証環境のアーキテクチャ概要です。パブリッククラウドであるAzure、AWS、Google Cloud、IBM Cloud環境および弊社のプライベートクラウドであるASPIRE上にそれぞれSatellite上で稼働するRed Hat OpenShiftサービスを稼働させました。これらの環境に対する運用管理者としての接続方式はVPNや専用線などの接続が考えられますが、個別設定が必要となるため今回の検証ではパブリックIPを利用するインターネット経由で接続しました。ASPIREはプライベートIP経由で接続しました。また、コンテナイメージを格納するコンテナ・レポジトリは設置場所等を十分に検討する必要がありますが、本検証では手軽に利用できるIBM Cloud Container Registryを利用しました。Red Hat OpenShiftサービス上で稼働するコンテナ・アプリケーションに対する接続テストでは、標準で利用可能なIBM Cloudが管理しているドメインを利用しました。

以下のようなIBM Cloud Satelliteの主要機能の検証を行いました。OpenShift上に動作するアプリケーションやIBM Cloudサービスとの連携、Satellite Link機能は今回の評価対象外としました。

• 検証1. 環境のデプロイメント
  • Satelliteのデプロイメント方法として、サービスが提供する以下の2種類を実施しました。
    • 手動セットアップ：あらかじめサーバーやネットワークの環境を構築し、その上でにSatellite環境をセットアップ
    • テンプレートを利用した自動セットアップ：「IBM Cloud Schematics」のテンプレートを利用したサーバー環境とSatelliteの自動セットアップ
  • 自動セットアップは利用できる環境が限られるものの、Satellite 環境を稼働させるためのサーバーのセットアップが行われます。Terraformベースのオートメーションツール対応クラウドサービス「IBM Cloud Schematics」によるデプロイが行われますが、各クラウドプロバイダで発行されるAPIキーを利用することでセットアップの自動化が実現されています。

• 検証2. リソースの配布
  • 構築した環境に対するアプリケーション・リソースの配布は「Satellite Config」という機能の検証を行いました。OpenShiftのクラスターをグルーピングしたグループに対し、yaml形式で配布するリソースの定義を行います。新しいリソース・バージョンを設定することで対応するアプリケーションのリソースがデプロイされることを検証しました。

• 検証3, 4. ロギング/モニタリングとの統合
  • マルチクラウド環境でサービスを提供する場合、複数のSatellite環境、その上で稼働するOpenShiftサービスとコンテナアプリケーションに対し、監視が必要となります。IBM Cloudで提供されている「Log Analysis」（動作ログ）, 「Activity Tracker」（監査ログ）、「Monitoring」（メトリクス）の各サービスを用い、各環境から必要な情報が収集され、ダッシュボードで表示でき、検索等の処理を実施できることを検証しました。

• 検証5. アクセス許可（IAM: Identify Access Management）
  • サービスの運用時に担当者の役割に応じて必要となるアクセス権限の分離が必要です。「IBM Cloud IAM (Identify Access Management)」を用いて、OpenShiftクラスターおよびProject(Namespace)単位でのアクセス制御ができるか検証しました。

評価した項目はいずれも稼働し、テストケースに設定した検証項目もすべて実施できました。検証結果を下表にまとめます。

＜分散クラウド検証結果＞

導入、管理、運用の各フェーズにおける考察を以下のとおりまとめました。

• 考察1. 導入フェーズ
  • Public Cloud とPrivate Cloud関係なく、簡単にどこでもOpenShiftがデプロイできるのは大きいメリットである。
• 考察2. 管理フェーズ
  • IBM Cloudのモニタリングとロギング機能にてマルチクラウド（クラスタ）の一元管理ができる。
  • 各クラウドサービスでしか提供されていないリソース（ロードバランサーやストレージなど）をOpenShiftで利用する場合、Satelliteでは一元管理ができません。その場合、Satelliteと各クラウドで管理が分断される。
  • マルチクラスタの管理機能はまだ発展途上でした。機能提供が予定されているサービスメッシュなどが利用できるようになると、より高度なアプリケーションの運用が可能になるので、機能提供が待ち望まれる。
• 考察3. 運用フェーズ
  • Satellite Configuration機能にてマルチクラウド（クラスタ）へのリリースを管理できるのは便利な機能と思うが、実運用を行うためには運用面で工夫する必要がある。

 

―― 今回のご検証の結果、製品へのご要望がありましたらお聞かせください。

（ソフトバンク李様）検証の結果、現時点のIBM Cloud Satelliteには大きく2点強化いただきたい点がありました。

• 課題1．永続ストレージを利用するためのシームレスな統合
  • Satelliteのデプロイでは永続ストレージの機能がベータ提供されているのみで、GUIでは利用することができませんでした。永続ストレージを利用するためには、各クラウドサービスでのサービスのプロビジョニングやそれを利用するためのOpenShiftコマンドの実行など手順が膨大かつ煩雑なため、GUIを通じて簡単にこれらを動的にプロビジョニングできる機能が望まれます。
  • OpenShiftでは内部レポジトリーを利用するために永続ストレージが必要で、内部レポジトリーを利用できない場合GUIからアプリケーションのデプロイ操作を実施する方法が限定されてしまいます。開発者の生産性を高める上でも永続ストレージを簡単に利用できることが期待されます。
• 課題2．Satellite Config機能の利便性
  • Satelliteにおけるリリース管理を担うSatellite Config機能に関してさらなる機能強化を期待しています。
  • Satellite Configurationでは設定ファイル（バージョン）ごとに管理する仕組みになっていますが、上記管理方法は利便性が低いため、Gitのように親和性のあるバージョン管理仕組みへ改善が必要と思われます。また、各yamlファイル（設定ファイル）ごとに配布対象のクラスタグループの指定が必要となるため、そのバージョン管理が煩雑になります。さらにyaml形式で自由に記述できるフォームが提供されているが、担当者を支援するフォームでの入力や、検証を行う機能がないと、ミスが発生しやすいと考えます。

補足：現在、Satelliteサービスはお客様からのフィードバックをいただきながら、継続的に機能強化・改善を進めております。永続ストレージについては、評価いただいた際にはベータ版としての提供で、GUIがなくご不便をおかけしました。製品としてはストレージ機能の正式サポートにあたり、GUIの提供やメジャー・クラウドのストレージ・サービスとより親和性の高い統合を計画しています。また、プライベートクラウドでご利用いただける他社製品を含むストレージ製品もSatellite環境から簡単にご利用いただける統合機能を提供予定です。これらにご期待ください。Satellite環境で管理下のOpenShiftクラスターに資産を配布するSatellite Configについてはご指摘のとおり、単体では手動でバージョン管理を行う必要があり、GitOpsのような機能を持ち合わせておりません。ただし、IBM Cloud Continuous DeliveryサービスではCI/CDパイプラインのデプロイメント先としてSatellite管理下にあるRed Hat OpenShiftマネージドサービスも選択することができます。こちらをご利用いただくことで、Gitと組み合わせてご利用いただけるようになります。バージョン管理されているマニフェストファイルとSatellite Configの配布機能を組み合わせてご利用いただくことで手動でバージョン管理する負荷を解放することができます。

 

―― ソフトバンク様の今後の取り組みについてお聞かせください。

（ソフトバンク二藤様）従来のパブリック・クラウド一元化モデルから大幅な転換を迎えている現在、分散クラウドは5G/IoT、エッジコンピューティングを支える基盤として必要不可欠なテクノロジーになると考えております。お客様が分散クラウドを使ってパブリッククラウドのサブセットを物理的に近い場所で利用できるようになると、エッジコンピューティングにおける遅延問題の低減、データコストの削減、特定の地域にデータをおかなければならないという法律への対応なども可能になります。今後、ソフトバンク自身のキャリアかつマルチクラウドベンダーとしてのノウハウとIBM Cloud Satelliteが提供するテクノロジーを組み合わせて、両社ともに5G/IoT時代に社会に価値を提供していければ、と考えています。

 

プロフィール