企業が検討すべき“分散クラウドにおけるプラットフォームアーキテクチャ”：分散クラウドのアーキテクチャと開発・運用体制の考え方

分散クラウドへの注目が高まっている。本稿は分散クラウドのメリットや導入後の注意点などを紹介する。

[工藤雄大, 酒井勇輔，株式会社日立ソリューションズ]

　本連載は分散クラウドの要素や活用パターンを、クラウドシフトやアーキテクチャ、組織構成の観点から紹介している。第2回となる本稿は、分散クラウドにおけるプラットフォームアーキテクチャのメリットと変化について、機能配置パターンを例に紹介する。

この連載について

　本連載は、企業が抱えているクラウドシフトに関する課題を解決するために、エッジコンピュータを活用した新たな手法がなぜ効果的なのかを解説します。

筆者紹介：株式会社日立ソリューションズ　工藤雄大

技術革新本部 生産技術部 Cloud CoE 技師

インフラ系新技術、新製品の評価及びソリューション開発に15年以上従事。特技は製品・技術を外から（not Source）挙動解析すること。近年のテーマはエッジコンピュータ、分散クラウド関連技術。インフラ系技術コミュニティーでも活動。

筆者紹介：株式会社日立ソリューションズ　酒井勇輔

技術革新本部 生産技術部 Cloud CoE 技師

アプリケーション共通基盤の設計・運用や、基盤上でのアプリケーション開発支援に従事。近年は、アプリとインフラの横断領域（いわゆる DevOps／SRE）に関する組織設計・プロセス設計が主な関心領域。

そもそも“分散クラウド”とは

　クラウドの形態が分散クラウドに進化しつつある。これはオンプレミスやパブリッククラウドといった特定の場所に依存せずに、一貫性のあるクラウド活用を実現するためだ。分散クラウドでは、連載第1回で述べたコストやロケーション、技術難易度の課題を考慮し、機能配置を検討する必要がある。その際はアプリケーションやサービス、使われるデータの配置が重要だ。

　分散クラウドはパブリッククラウドを主軸に図1に示すエッジコンピュータやマルチクラウド、コントロールポイントから構成される。

図1　分散クラウドの構成要素（筆者作成）

エッジコンピュータ

　本稿では「パブリッククラウドの一部機能をオンプレミスで分担して処理する基盤」をエッジコンピュータと呼ぶ（図2）。これは連載第1回の「クラウド分野のエッジコンピュータ」と同義だ。

図2　エッジコンピュータ（筆者作成）

マルチクラウド

　本稿では「多種のクラウドを組み合わせてシステムを構成する基盤」をマルチクラウドと呼ぶ。マルチクラウドはそれぞれのクラウドAPIをコントロールポイントから利用して実現する。

コントロールポイント

　本稿では「クラウド基盤群・クラウドシステムの管理といった役割を果たすコンポーネント」をコントロールポイントと呼ぶ。 エッジコンピュータやコンテナ実行基盤である「Kubernetes」、他のパブリッククラウドなどの各プラットフォームのAPIを呼ぶ機能を持つ。これにより、各プラットフォームを透過的に一元管理できる。

アーキテクチャからみる分散クラウドにおける機能配置

　ITシステムのアーキテクチャを検討する場合、オンプレミス環境で保持するのが望ましいデータもある。その場合、データの生成場所や保存場所の近くに、当該のデータを処理する機能を配置する必要がある。

　分散クラウドはそのようなデータ保持の制約をクリアしながら、パブリッククラウドの機能群とシームレスに連携できる。分散クラウドのメリットについて、性能とセキュリティそれぞれの観点で例を挙げる。

例1（性能の観点）：工場機器の監視システムにおける機能配置

　分散クラウドの適用が有効なケースに「高いリアルタイム性が求められる場面」での適用がある。例えば、産業分野における工場機器の異常検知を実施する場面などが代表的なユースケースだ。このユースケースのポイントと機能配置のイメージは以下のようになる。

• 性能確保のために機器の稼働データをリアルタイムで処理をしつつ、統計データを集計して分析したい
• エッジコンピュータにリアルタイム処理が必要な機能を配置する
• パブリッククラウドに複数拠点から収集したデータを分析するための機能を配置する

図3　性能観点での機能配置（筆者作成）

　常時発生し続ける機器の稼働データをストリームデータとして扱いながら、ミリ秒単位のレベルで分析し異常を検知したい場合、図3の下部のように、エッジコンピュータにリアルタイム処理の機能を実装し、対応できる。

　厳しい性能要件が求められるアプリケーションを、データの発生源に近いオンプレミスで実行するのは以前から存在する考え方だ。分散クラウドは「リアルタイム性の要件」に加えて、パブリッククラウドの特性である「中央集権的な管理も求められる」場合に効果を発揮する。

　これは発生したデータを統計処理した上でパブリッククラウドにアップロードし、複数の拠点から集約したデータに対して集計や分析を行いたいケースなどだ。分散クラウドでは図3の上部のように、パブリッククラウド上にデータ分析機能を実装できる。

例2（セキュリティの観点）：機械学習システムにおける機能配置

　AI（人工知能）によるデータ分析を効率的に行うために、パブリッククラウドが提供するサービスやソリューションを活用したい場面もある。一方、非常に高い機密レベルが規制要件として求められるケース（医療データの管理など）では、パブリッククラウドにデータを預けるのは困難な場合がある 。このような場合の対応策に「連合学習」という手法がある。このアーキテクチャのポイントは以下の通りだ。

• 重要なデータはオンプレミス環境に置き、マスキングや暗号化して統計処理したデータは中央集権的にパブリッククラウドで扱う
• オンプレミスでの学習結果（固有モデル）を暗号化してクラウドに転送する
• 複数のオンプレミス環境から収集された学習結果に基づき、共有モデルを作成する
• 共有モデルをオンプレミス環境の固有モデルへ反映する

図4　セキュリティ観点での機能配置（筆者作成）

　分散クラウドを連合学習のプラットフォームとして活用する場合、図4のようにそれぞれのオンプレミス環境にデータと固有モデルを保持する必要がある。オンプレミス環境のエッジコンピュータで生成した固有モデルは、マスキングや暗号化を経てパブリッククラウドに送信され、共有モデルへ反映される。更新された共有モデルはそれぞれのオンプレミス環境のエッジコンピュータにダウンロードされ、固有モデルが更新される仕組みだ。これであれば、セキュリティ要件を確保しながら優れた機械学習モデルを作成できる。

分散クラウド導入後の運用メリット

　性能やセキュリティを考慮したアプリケーション配置は、分散クラウド無しでも実現可能だ。ただ分散クラウドは、運用関連のメリットを高められる。以下は代表的なメリットだ。

メリット1：一元管理でシステム全体の運用負荷を低減

　分散クラウドでは、前述のコントロールポイントによってパブリッククラウドとエッジコンピュータを透過的に一元管理できる。コントロールポイントでは、エッジコンピュータのアプリケーションをパブリッククラウドと同様に監視できる。また、エッジコンピュータ自体の稼働やパッチ適用などもパブリッククラウドから確認できる。

図5　一元管理で運用負荷を低減（筆者作成）

メリット2：可用性実現による業務継続性の向上

　分散クラウドはアプリケーションの可用性とシステム全体の可用性で、業務継続性を向上させる。

　アプリケーションの可用性という観点では、エッジコンピュータで個別に可用性を確保する設計が必要だ。システム障害が発生してもアプリケーションがコンテナ化やマイクロサービス化されていれば、図6のようにパブリッククラウドや他のエッジコンピュータへ退避させやすい。一方、単にアプリケーションだけパブリッククラウドに退避させると性能問題が発生する可能性がある。アプリケーションの退避を前提としたデータ配置設計が重要だ。

図6　アプリケーションの可用性という観点で業務継続性が向上（筆者作成）

　システム全体の可用性という観点では、図7のように継続したい業務に関連するアプリケーションをエッジコンピュータに配置し、オンプレミス環境のシステムがパブリッククラウドと分離して動作するような設計とすることで通信回線の障害などが発生しても業務が継続できる。

図7　システム全体の可用性という観点で業務継続性が向上（筆者作成）

メリット3：機能分散による性能の向上

　分散クラウドでは「エッジコンピュータ自体のスケールアウト」「パブリッククラウドへの機能分散」の構成を取れる。機能分散では、エッジコンピュータの処理能力が不足した場合に、一時的に処理をパブリッククラウドに分散させる。この場合、機能を分散させる前提でのデータ配置設計が必要だ。

図8　機能分散による性能の向上（筆者作成）

分散クラウド導入後の運用の変化

　分散クラウドは機能配置を柔軟に組み替えられるため、運用面でもメリットがある。一方、システムの責任範囲とアプリケーションの在り方が変化するため、以下のような注意も必要だ。

変化1：システムの責任範囲の変化

　通常、パブリッククラウドにおけるシステムの稼働責任は、コンポーネントごとに「責任共有モデル」の概念が適用される。オンプレミス環境で稼働するエッジコンピュータは特に責任分界点が複雑になる。エッジコンピュータの提供形態によるが、責任分界点は図9のようになることが多い。

図9　エッジコンピュータの責任分界点（筆者作成）

　パブリッククラウドであれば、クラウドベンダーとユーザーの二者間の責任共有になるが、エッジコンピュータを導入するとハードウェアベンダーとも責任共有の関係性が発生する。システム不具合が生じた際は原因の切り分けが複雑になるため、障害検知や可視化などのオブザーバビリティの確立が重要だ。

変化2：アプリケーションの開発・運用の変化

　分散クラウドでは、各拠点で稼働するアプリケーションを一元的に管理して開発・運用の工数を低減できる。

　従来型のアプリケーションの開発・運用と、分散クラウドでのアプリケーションの開発・運用の違いは図10のようになる。従来型のアプリケーションの開発・運用では、運用者はアプリケーション実行基盤を個別に運用し、開発者はその実行基盤上で個別に開発を行う。

　分散クラウドでのアプリケーションの開発・運用では、単一のコントロールポイントを通じてパブリッククラウドやエッジコンピュータを単一のクラウドのように扱う事が可能だ。これにより、CI／CD のようなパブリッククラウドで活用されるクラウドネイティブな技術を活用できる。

図10　アプリケーションの開発・運用（筆者作成）

　今回は分散クラウドにおけるプラットフォームアーキテクチャについて、機能配置パターンを例にとり、メリットと変化について紹介した。 次回の第3回では、分散クラウド上で開発・運用を円滑に進めるための組織構成を解説する。