複数の工場や店舗を中央から管理するとき、拠点との回線が切れたら、現場のクラウド基盤まで使えなくなるのでしょうか。答えは、中央へ何を任せ、拠点に何を残しているかで変わります。画面に拠点を一覧できることと、その拠点が自力で制御を続けられることは、別の設計だからです。
StarlingXのDistributed Cloud（分散クラウド）は、中央管理と拠点側の自律した制御を組み合わせます。OCP Korea Tech DayのOpenInfra講演で紹介されたこの基盤について、StarlingX 12.0の公式文書から、回線断、保守のための同期停止、拠点内の機器故障を分けて見ていきます。［1］［2］
簡単にまとめると？
- StarlingXのサブクラウドは、拠点内に制御と認証の仕組みを持ち、中央との接続が失われてもローカルサービスを動かす設計です。
- 中央の同期対象か、オンラインか、設定が同期済みかは別の状態です。保守用のUnmanagedも、回線断そのものを意味しません。
- 中央回線への依存を減らしても、1台構成の機器故障や、アプリが利用する外部サービスの停止までは防げません。
中央が束ねるもの、拠点に残すもの
Distributed Cloudは、中央のCentral Cloudと、一つ以上のサブクラウドをL3ネットワークで結びます。サブクラウドは、単なる遠隔端末ではなく、コンテナ化したアプリケーションを動かすStarlingXのシステムです。中央には、自身の設備を管理するRegionOneと、サブクラウド群を管理するSystem Controllerという役割があります。［3］
System Controllerは、サブクラウドの追加、対象となる設定の同期、稼働状態やアラームの監視、システムソフトウェアの更新管理を担います。一方、サブクラウドには自律した制御プレーンがあり、公式の概要は、中央へ向かう接続が失われても拠点内のローカルサービスが動作する構成だと説明しています。すべての制御を中央へ毎回問い合わせる構成ではありません。［2］［3］
この違いを具体的に示すのが認証です。公式構成文書では、サブクラウドのサービスは、その拠点内のIdentity Providerだけで認証するとしています。StarlingXのサービスではKeystone、KubernetesではService Accountを使うため、中央との通信が途切れたことだけで、認証先まで失う作りにはしていません。ここで説明しているのは基盤サービスの認証であり、上に載せるアプリ独自のログイン先まで自動的に拠点内へ移るわけではありません。［3］
回線断でも残る処理を、アプリの依存先までたどる
説明用の例として、工場Aと工場Bにそれぞれサブクラウドを置き、中央から管理する構成を考えます。工場Aと中央を結ぶ回線だけが切れ、工場Aの電源、機器、拠点内ネットワークは正常に動いているとします。工場Aに制御と認証を残す意味は、この場面で現れます。中央へ到達できないことと、拠点内の基盤サービスがすべて止まることを切り離せるからです。これは構成の理解を助ける仮例で、実機試験の結果ではありません。
ただし、工場Aの検査アプリが、判定のたびに中央にあるデータベースを読むなら、その処理には回線への依存が残ります。アプリのログインに外部の認証サービスを使う場合も同様です。ローカルのクラウド制御が動くことだけから、アプリの入力、処理、結果の保存まで成立すると判断することはできません。
そこで構成を選ぶときは、制御プレーンの配置に加え、アプリが使う認証先、データ、保存先を一つずつたどります。中央へ送る結果を一時的に現場へ残す設計なら、その保存容量と後から送る手順も確認対象です。これらは本稿で提案するアプリ側の確認事項であり、StarlingXが任意のデータを自動的に保管・再送するという説明ではありません。
Managed、Online、In-syncは同じ「正常」ではない
中央から見える状態も、一つの表示だけでは読み切れません。公式のdcmanager subcloud listの出力例は、management、availability、syncを別々の列にしています。その例には、managedかつonlineでも、out-of-syncのサブクラウドが載っています。接続状態と設定の同期状態は一致するとは限らないのです。［4］
| 表示 | 読み分ける内容 | その表示だけでは分からないこと |
|---|---|---|
| management | 中央からの設定同期を行うManagedか、保守用のUnmanagedか。 | 物理的に回線が切れているか、アプリが正常か。 |
| availability | 中央の一覧に、Online／Offlineのどちらで報告されているか。 | 設定の同期完了や、業務処理の完了。 |
| sync | 同期対象の状態がIn-syncか、Out-of-syncか、Unknownか。 | アプリ独自のデータや外部サービスまで正常か。 |
この表は公式構成説明とCLIの出力例を整理したものです。表示の更新間隔や障害の検知時間を示す表ではありません。詳細を見るdcmanager subcloud showの例では、identity、patching、platformの同期状態も別々に表示されます。再接続後の確認でも、Onlineへ戻ったことだけでなく、どの同期項目がどう表示されているかを調べる手掛かりになります。［3］［4］
特にUnmanagedは、通信障害の名前ではありません。公式文書では、拠点を保守するため、中央からの同期操作を切り離す状態としています。その間に中央側で行った設定変更は中央で待たせ、Managedへ戻したときにサブクラウドへ送ります。通信できる状態なら、Unmanagedでもアラームは中央へ送られます。「同期を止める」と「監視の通信まで止める」を同じ操作として扱わないことが大切です。［3］
反対に、回線そのものが切れている間は、その回線を使う中央への報告も届きません。拠点の処理が続いていても、中央から現在の様子を確認できない場面があります。Unmanagedの設定保留についての説明を、そのまま「あらゆる通信障害中の変更が必ず再送され、順序どおりに適用される」という保証へ広げることもできません。
中央との回線断と、拠点内の1台故障を分ける
もう一つ分けたいのが、拠点を外部から切り離せることと、拠点内の機器を冗長にすることです。StarlingXはサブクラウドにSimplex、Duplex、Standardなどの構成を使えます。12.0の構成比較表では、1ノードのAIO-SX（All-In-One Simplex）は冗長性とコントローラーサービスの高可用性が「なし」、AIO-DX（All-In-One Duplex）とStandardは「あり」とされています。［3］［5］
工場AがAIO-SXなら、中央回線の故障には拠点側の自律性が役立っても、その1台が故障したときに代わりのローカルコントローラーが生まれるわけではありません。複数拠点を中央で束ねるだけでは、各拠点の電源、サーバー、保存装置といった、同じ原因で一緒に止まり得る範囲をなくせないためです。
AIO-DXなどを検討する場合も、「冗長性あり」は全アプリの無停止を意味しません。アプリを何台へ配置するか、保存先をどう構成するか、障害時にどれだけの処理能力が残るかは別の条件です。小さな拠点を1台で構成する判断と、拠点内の機器故障も受け止める判断を、中央管理の有無と分けて行う必要があります。
試すなら、切る場所と観測する場所を対応させる
導入を判断するための確認では、まず「中央との回線だけが失われる場合」と「拠点内の機器が故障する場合」を別の試験にします。前者では、現場からの基盤へのアクセス、アプリが必要な入力と保存先、中央側の状態表示を分けて観測します。接続を戻した後は、設定の同期状態とアプリの実際の動作も照合します。後者では、選んだ拠点構成で代替できる制御と、代替できない処理・保存先を確かめます。
ここで挙げたのは、公式の構成から導く確認の考え方です。本稿は障害試験を実施したものではなく、復旧時間、データ損失の有無、可用性の数値を示すものでもありません。StarlingXを選ぶ際に見るべきなのは、「分散しているから止まらない」という一語ではなく、中央から切り離しても成立させたい現場の処理と、その処理が依存するものが、同じ拠点のどこまで揃っているかです。
参考資料
- Seongsoo Cho／OpenInfra Korea User Group「Open Infrastructure: Global Trends」、2026 OCP Korea Tech Day、全36頁。StarlingXの紹介はpp.19–22。OCP公式資料一覧。
- StarlingX 12.0「Overview of Distributed Cloud」。中央管理、サブクラウドの自律した制御プレーン。
- StarlingX 12.0「Distributed Cloud Architecture」。System Controller、拠点内の認証、Managed／Unmanagedとネットワークの役割。
- StarlingX 12.0「Manage Subclouds Using the CLI」。一覧と詳細表示、管理状態の切り替え。
- StarlingX 12.0「Deployment Model Comparison Matrix」。AIO-SX／AIO-DX／Standardの冗長性とコントローラーサービス。
資料確認日：2026年10月12日。構成と操作表示はStarlingX 12.0の公式文書に揃えています。講演にある個別企業の導入規模や効果を、この構成の性能保証として用いていません。