Day1「ガバメントクラウドの仕様要件考察」 @ ガバメントクラウドについて考えるAdvent Calendar 2022
この記事は、ガバメントクラウドについて考える Advent Calendar 2022のDay1「ガバメントクラウドの仕様要件考察」となります。
※こちらの記事は基本的には公開情報を元にしていますが、個人的な妄想・意見も含まれておりますので、ご承知おきください。
このAdvent Calendarは、日々活動している中で課題として感じることなどをどこかで整理しなくてはいけないと思っていて、ちょうど良いタイミングだったので、全日自分が思うところを書くというスタイルにチャレンジして、どこまで続けられるかやってみたいと思います。
https://adventar.org/calendars/8293
以前、以下のツイートに多くのことをまとめてみたのですが、改めて整理していきます。
後々noteにはまとめるとして、ガバメントクラウドについて少しまとめて語っておこう。個人的妄想と推測が入り混じっているので、その前提でご覧ください。
— Junnosuke Nakajima | VMware (@jnakajima1982) October 11, 2022
ガバメントクラウドの要件
まずガバメントクラウドに国産クラウドが入れないのかというところですが、現在の技術要件ではIaaSベースのクラウドでは応募することが難しいと言えます。そのため、国産クラウドでは要件を満たせない、そして満たすことができる未来もかなり遠いと思います。ではまぜガバメントクラウドの要件として、PaaS/SaaSが必須となっているのか。
それは最終的なアプリケーションのアーキテクチャとして、クラウドネイティブを目指しているからに他ならないと思います。今すぐにクラウドネイティブ化できなくても、最終的にクラウドネイティブなアーキテクチャに変えることができるクラウドサービスでないとダメだからだと思います。
クラウドネイティブ
そもそもクラウドネイティブというのは何なんでしょうか。CNCFという団体が定義しています。「パブリッククラウド、プライベートクラウド、ハイブリッドクラウドなどの近代的でダイナミックな環境において、スケーラブルなアプリケーションを構築および実行するための能力を組織にもたらします。」とされています。
その他は、以下に引用しておきます。
このアプローチの代表例に、コンテナ、サービスメッシュ、マイクロサービス、イミュータブルインフラストラクチャ、および宣言型APIがあります。
これらの手法により、回復性、管理力、および可観測性のある疎結合システムが実現します。 これらを堅牢な自動化と組み合わせることで、エンジニアはインパクトのある変更を最小限の労力で頻繁かつ予測どおりに行うことができます。
Cloud Native Computing Foundationは、オープンソースでベンダー中立プロジェクトのエコシステムを育成・維持して、このパラダイムの採用を促進したいと考えてます。 私たちは最先端のパターンを民主化し、これらのイノベーションを誰もが利用できるようにします。
これを素直に読み解けば、クラウドネイティブなアプリケーションはパブリッククラウドに限定されたものではないということです。少し以下のスライドで整理しましょう。
今までのアプリケーションはOSがあり、OS上にミドルウェアやアプリケーションがインストールされ、それぞれのOSが連携し合うことでシステムとして成立していたものでした。これをモノリシックなアプリケーションと呼ぶこともありますし、Webシステムの3階層なんかも代表例と言えるでしょう。
話を整理するために、クラウドネイティブアプリケーションを2つに分類します。1つは、今までのシステムをクラウドが提供するサービスに分割していくというものです。仮想マシンサービスもあるでしょうし、コンテナやサーバレスなどのようにクラウドサービス側がプラットフォームを意識せずに用意してくれているサービスを踏まえたアプリケーション設計になります。これらはクラウドから提供されるSLAや機能などのサービス仕様をよく理解して設計する必要がありますが、今までインフラ技術者に作ってもらっていたプラットフォーム部分をクラウド事業者に委託することができ、かつサービスによっては常に稼働させて常に料金がかかるスタイルではなく、利用時だけ料金が必要になるような形にすることによって、低廉な費用を実現するということが目指されているわけです。しかしながら、クラウドサービスが提供しているサービスが基準となっているため、稼働させるクラウドによっては同一サービスが存在しないであるとか、詳細仕様が異なるなどの点を考慮する必要があります。
もう1つは、クラウドの機能に合わせるのではなく、そのアプリケーションが持っている機能ごとに分割するタイプのクラウドネイティブアプリケーションです。よくマイクロサービスという言葉で表現されたりするでしょうし、コンテナで構成されることが多いと思います。こちらでは、機能ごとに分割されるため、特定の機能に障害があっただけで全体が止まってしまうのではなく、該当機能だけに影響範囲を留めることができるという特徴があるだけでなく、需要が高まる特定機能部分だけ柔軟に拡張したりといったことも可能な側面があります。それが故に、機能ごとの連携や全体が見えにくくなるといったことをどう解決するかということも考えていく必要があります。
このようにクラウドネイティブなアプリケーションを目指すことにより、低廉なコスト・拡張性・委託範囲の増加などのメリットを得ることができると言われています。
そのため、この形を目指すが故にガバメントクラウドとしては、IaaSだけにとどまらないPaaS/SaaSを保持するクラウド事業者をガバメントクラウド事業者として認定することにしていると思われるため、国産クラウドがこの枠組に入るのは難しいと言えます。逆に言えば、SalesforceやCybozuさんなど特定のSaaSエリアに特化した強力なクラウドサービス事業者は、IaaS/PaaSを持っていないので、この枠組には入ることができません。
クラウドネイティブの実装
ここでクラウドネイティブの定義に戻りますと、「パブリック・ハイブリッド・プライベートクラウドなどの近代的な環境において…」となっています。しかし、クラウドネイティブの実装方法の2つのうち、クラウドが提供するサービスを利用した前者のパターンは、ソフトウェアを様々なクラウドに持ち込んで動かすのとは対照的に、そのクラウド上でしか利用できないという形になり、クラウドネイティブの定義のうちのクラウド種類が限定的となります。
これが悪いと言っているわけではなく、技術実装の選択でしかないと思います。クラウドネイティブを実現するコンテナ技術を使えば、パブリック・ハイブリッド・プライベートといったすべてのクラウド種別に対応することが容易というように。
つまり、何が言いたいかというと、クラウドネイティブ技術の実現方式は多く存在し、アプリケーションの特性によって、「プラットフォーム部分をできるだけクラウド側に委託したいので、クラウドサービスが提供するマネージドサービスを利用していく」ということもあれば、「多くのクラウドに対応したくて、マネージドサービスの技術仕様に依らないもう少し自由なアプリケーション開発をしたいのでコンテナを使うケース」もあるわけです。
ただ今のガバメントクラウドの仕様は、クラウド種別をパブリッククラウドだけに制限されるような形になっており、かつクラウドネイティブの実装方法もマネージドサービスがなければガバメントクラウドになり得ないという方針となっているように見えます。
政府クラウド利用の指針
ガバメントクラウドチームが出している「政府情報システムにおけるクラウドサービスの適切な利用にかかる基本方針」についても、「クラウドスマート」の方針が書かれています（このクラウドスマートについては別途今後触れます）
このスマートとは何を指しているかというと、「モダン技術の利用であり、マネージドサービスとIaC（Infrastructure as Code）」と記されています。基本的にはクラウドサービスが提供しているサービスを最大限に利用して楽になりなさいということなんだと思います。
日本のクラウドがマネージドサービスを提供できるか
では、国産クラウドがマネージドサービスを提供するようになればいいじゃないかという話なんですが、ここをどう考えるかが非常に悩ましいところです。まず今までは国産クラウドベンダーは同時にアプリケーション開発事業者でもあったケースは多いと思います。そのため、クラウド自体に機能が豊富でなかったとしても、SIも含めてシステムをどう構成するかということで賄ってきていたんだと思います（これがブラックボックス化を生んでいたという批判もあろうとは思いますが）。また、運用監視等のソフトウェアも自ら提供していたケースもあり、クラウドサービス自体がIaaSというスタイルを取っていたとしても、SIとソフトウェアで解決してきたのではないかと思います。
加えて、これらのマネージドサービスの開発・運用は規模が必要になってきます。従量課金のようなことを目指す上でも、事前にプラットフォームはスケールするために多めに準備しておかなければならないですし、それらのための運用体制も必要ですし、利用を促進するために継続的な機能開発も必要ですし、かなりの投資が必要です。また、先程のソフトウェア開発の事情から、マネージドサービス提供版と今までのソフトウェアとしての提供版の双方を並行開発することになります。
このような事情から優先順位が高い投資対象にはなりにくかったのではないかと推測します。そのため、今回採用されている4社は従前より積み上げて今の提供サービス一覧になっているのと同時に、基本的には全世界が対象のサービスであるため、上記のことをクリアしていくだけの投資をする価値があると判断されてここまで到達しているわけなので、日本のクラウドベンダーが一朝一夕でこのマネージドサービスを開発することはかなり難しい判断だと思います。
どうなっていくのが良いのだろう？
とは言え、先程のクラウドネイティブの定義であるとか、実装方法には要件に応じた実現方法があり、日本のクラウドベンダーや先に挙げた特定領域に強いクラウドベンダーが存在します。手法は目的ではなく、それらによって得られるメリットが目的なのですから、今のアプリケーションを総合的に見つめ直した上で、そこに行くまでの選択肢はもっとたくさんあってもよいのではないかと思っている次第です。闇雲に増やすのではなく、クラウドサービスに委託する範囲がセキュリティ的にも一定のレベルになければならないわけではあるはずなので、ISMAP以上のクラウドを対象とするなど、アプリケーション開発方法・実装方法の幅を広げたほうが、よりこの方針に向かっていくのではないかなと思います。
新しく作っていくアプリケーションならまだしも、今あるアプリケーションを変革していくには既存の技術的制約や開発者のスキルセットなどの前提条件が大きく絡んできて、様々な事情を加味した柔軟な選択が必要になると思います。現在の4社がその高度化されたクラウド事業者であるというのは間違いないものとして上位に位置づけ、日本のクラウドベンダーや特定領域に強いSaaSなどまで裾野を広げる形で枠組みが設定されるとよいのかなと思います。
そもそもガバメントクラウドって適用範囲がどこまでなんでしょうか。政府が載せるシステム全体が対象でしょうか？でもそれはISMAPが元々の発想だったんじゃないでしょうか？このあたりが曖昧なのも、混乱しがちなポイントかも知れません。
執筆後記
このようにガバメントクラウドを考えるAdvent Calendar 2022では、以下の流れで進んでいくことになると思いますので、Day2以降もお待ちいただければと思います。
ガバメントクラウドの在り方
ガバメントクラウドの整備における課題感
ガバメントクラウドの利用における課題感
ガバメントクラウドの今後について考えてみる
Twitterなどで情報発信していますので、もしよろしければ覗いてみてください。