サービスやシステムを開発・運用する上で、AWSやGoogle Cloud、Microsoft Azureといったパブリッククラウドを利用することは、もはや当たり前の選択肢となりました。クラウドサービスの柔軟性やアジリティは現代のシステムには欠かせません。

クラウドサービスは「ネットワーク越しに使う」「共有基盤を使う」などが基本的な定義ですから、物理的な位置はあまり関係がないと言えば関係ないです。しかし最近「データは一体どこに置かれているのか？」「誰がそのデータにアクセスできるのか？」という問いが、これまで以上に重みを持って語られるようになっています。その流れで話題になるのが「ソブリンクラウド (Sovereign Cloud)」という考え方です。

なぜ今、「データの持ち主」が問われるのか？

技術的な詳細に入る前に、まず「なぜいまデータの持ち主が話題になるのか」「なぜソブリンクラウドという考え方が必要になったのか」について話します。

背景にあるのは「データ保護を巡る法規制の強化」と「地政学リスクの高まり」です。

これまでよく話題になっていたのはデータの物理的な場所(データレジデンシー)です。「データは東京リージョンに置いてあるから大丈夫」というやつです。しかし昨今はそれでは済まないアレコレが起きています。

法規制と地政学リスクが浮き彫りにした矛盾

特に大きな影響を与えているのが、EUのGDPR(EU一般データ保護規則)やアメリカのCLOUD Act(クラウド法)です。

• GDPR: (ざっくりと)EU域内の個人データを保護するための非常に厳格な規則です。データ持ち出しの禁止など厳しい要件が多々あり、違反した場合には巨額の制裁金が課される可能性がある
• CLOUD Act: (ざっくりと)アメリカ政府が、アメリカの企業の管理下にあるデータに対して、そのデータが世界のどこに保存されていても開示を要求できる法律

※正確にはご自身で調べてください&専門家にご相談ください

パターンとして、アメリカの企業がEU域内にEU市民のデータを保持している場合に、その企業はアメリカ政府からの開示の要求を受けることがありえます。もしそうなると両方を遵守できなくて困ってしまいます。

このようにデータの物理的な場所と、そのデータを管理・運用する事業者が従うべき法律との間にコンフリクトが生じます。コンフリクトがあるときは解消しないと先に進めないのはコードと同じです。つまり困ります。更に昨今は国家間の対立のような地政学リスクが高まっていて、「物理的なデータの場所だけでなく、そのデータを管理・運用する事業者の国籍や、準拠する法律までを厳密に管理したい」というニーズが生まれました。わたしはこの状況が、ソブリンクラウドが話題になることが増えた大きな理由だと考えています。

「ソブリンクラウド」の要点

「ソブリン(Sovereign)」は日本ではあまり馴染みのない単語だと思います。「主権を有する」「独立した」といった意味合いの単語です。

敢えてソブリンクラウドという単語を持ち出すからには、次の点を満たしたいところです。

• データ主権 (Data Sovereignty): データの制御・操作の主権を確保できること。読み書き・移動・作成・追加・削除などを、データが域内(国や地域)の法律・管轄権にのみ従って制御できることを指す。外国政府の命令など域外の法執行の影響を受けないことがポイント
• データレジデンシー (Data Residency): データが域内(特定の国や地域)の中に物理的に保存・保持され流通している状態を指す。これはデータ主権を構成する一要素ではあるが、場所について(たとえ一時的にであっても)外に出さないことを明確にする
• 運用の主権 (Operational Sovereignty): インフラを運用し、データにアクセスできる権限を持つのが、その域内(の国民や組織)に限定されていることを指す。これにより外国籍の従業員による意図しないデータアクセスといったリスクを低減する

ここまで見ると、ソブリンクラウドが単なる「国内/域内にあるデータセンター」とは異なる志向だとわかります。

理想と現実、そしてトレードオフ

ソブリンクラウドという選択には(当然ながら)メリットやトレードオフ・懸念があります。

ハイパースケーラーの提供する「ソブリン的」ソリューション

AWS、Google Cloud、Microsoft Azureといったハイパースケーラーもソブリンクラウドに対応しようとしています。

例: AWS establishes European Sovereign Cloud as separate company – DCD

現地の信頼できるパートナー企業との協業や子会社設立によって、経営を本体からある程度切り離して運用の一部を切り離しソブリン化を実現するモデルのようです。

メリット:

• 使い慣れたハイパースケーラーのAPIやサービスを、ある程度の互換性を保ちながら利用できる可能性がある
• グローバルレベルで開発された最先端のサービスへのアクセスが期待できる
• グローバルレベルの調達力を背景にカスタムソリューション(独自チップなど)を利用できる

トレードオフ・懸念:

• 根本的なソフトウェアスタックや基盤技術、調達の力関係などは結局のところアメリカ企業依存のものであり「主権」と言えるか微妙さがある
• 利用できるサービスや機能が(通常のリージョンと比較して)限定的になったり遅れたりする可能性がある
• 価格が割高になる傾向がある

国産クラウドという選択肢

もう一つの選択肢として国内事業者のクラウドサービスがあります。たとえばさくらインターネットの「さくらのクラウド」 などです。

メリット:

• 事業者もインフラも国内にあるので、法的な観点での主権は非常に明確
• 日本語での手厚いサポートが期待できる
• 中の人との距離が近く、相互のフィードバックが成立しやすい

トレードオフ・懸念:

• ハイパースケーラーが提供するような多様なPaaS、SaaSのラインナップは期待しにくい。特に運用系サービスの充足度合いは現時点で差がある(ガバメントクラウド対応で埋まるかも)
• 調達力/調達量が限定的なので、価格やチップ選択肢の競争力はグローバル企業に及ばない

フルサイクルで見たときの「主権」の難しさ

また重要な観点としてアプリケーション開発のライフサイクル全体で見たときの主権の問題があります。

稼働基盤としてのプラットフォーム(IaaS/PaaS)だけを国内のソブリンな環境に置いたとしても、システムやサービスは「ソブリン」とは言いづらいものがあります。

たとえばソースコードはGitHub、メトリクス・ログなどモニタリング/オブザーバビリティはDatadog、ページングはPagerDuty、チケットはJira、データ分析基盤はSnowflakeだとしたら、ソブリン的にはどうでしょう。これらの基盤やサプライチェーンが海外の法規制下にある場合、稼働基盤だけを国内に閉じてもソブリンクラウドが目指す効果は限定的になり、リスク管理が複雑になりそうです。

真の(?)主権を追求するならば、ソースコードリポジトリー、運用系サービス、運用や開発を管理するサービス、データ分析基盤といった開発・運用サイクル全体を国内で完結させなければとなってきます。たとえば国産SaaSで固めるならはてなのMackerelなど選択肢はありますが、レンタカーを乗り換えるようにすっと乗り換えられるようなポータビリティはありません。フルサイクルを通じた主権は技術的にもコスト的にも非常に大きな挑戦です。

まとめ：我々エンジニアは、この「現実」にどう向き合うべきか

というわけで、ソブリンクラウドの背景や意図、技術的な課題について話しました。

技術的な要因・制約ではなく社会的な要因・制約に対処するのはちょっと嫌な気持ちになるエンジニアもいるかと思いますが、技術を使って現実にうまく対処するのもエンジニアの腕の見せ所だと思います。

わたしが思うに、エンジニアの「地力」はユーザー価値を支える「保証」(≒非機能要件)と向き合う実践力だと思います。すなわち信頼性、可用性、キャパシティ、パフォーマンス、セキュリティ、持続性といった観点を現実の状況においてうまくいい感じに実現したいですよね。ソブリンクラウドはこのうち主に持続性に関わる重要事項です。

ソブリンクラウドとの向き合いは、実はインフラエンジニアの問題ではありません。アプリケーションがどのようなデータを扱い、それがビジネスにとってどのような価値を持つのかを最もよく知る事業責任者やCxOが議論をリードしリスクをマネジメントすべき話題です。

対応が早すぎても遅すぎてもロスになります。とはいえ突然期日が発覚して間に合わなかったら…というリスクがあります。ロスとリスクを天秤にかけて判断せねばですね。

日頃からポータビリティやデータロックインに向き合って手当てしておき、また最小構成や最小要件について検討しておくとよさそうです。典型的にはBCP/大規模災害対策の文脈の活動ですが、備えあれば憂いなしというわけです。