デジタル庁のガバメントクラウドに地方自治体の基幹業務を移行させたところ、当初の見込み運用費3割減は遠く達成できず、ほとんど地方自治体でコスト高になった。
デジタル庁も責任はともかく事実を認めており、ネットワーク構成の複雑化、パブリッククラウドの専門知識のある運用補助者の必要性などを理由としてあげている。さらに、パブリッククラウド向きのアプリケーションの構築、クラウドに詳しい高度人材の育成のような改善策を提案している*1。
以下はその説明の転載だ。
この現状理解はおそらく適切。しかし、残念なことに、改善提案は現実的ではない。ガバメントクラウドを前提にしている限り、大きなコスト削減は困難だ。脱パブリッククラウドの方が現実的。ネットワーク構成は単純になり、脱ハイパースケーラーでクラウド料金の削減になる。
1. 大きなIT投資はできない
パブリッククラウド向きのアプリケーションの構築だが、もっとも初期投資が大きくなる。デジタル庁もASPがアプリケーションをSaaS化しろと言っているが、それは現在稼働中のシステムは廃棄されるということ。SaaS化が起きなくても、人口減少社会で地方自治体が消滅していく。現在のシステムの多くが運用されるのは十年、二十年といった期間だ。やたらと大きな投資は控えるべき。
2. アプリ改修によるコスト削減は困難
そもそもコスト削減のためのアプリケーション改修は鬼門だ。メモリー利用量と起動時間に比例してクラウド利用料金が増加するため、プログラミング言語の変更から行わないと効果が薄い。しかし、クラウド向きのプログラミング言語（i.e. Rust, Go）は、従来つかわれてきた言語（i.e. Java, C#, Python, Ruby, PHP, JavaScript）よりも、開発効率が悪い。何百万人、何千万人が利用するサイトであれば、多少、開発効率が低くとも、リソース消費量が少ないプログラミング言語を選ぶべきではあるが、地方自治体の業務システムはそのようなものではない。そもそもパッケージを購入した地方自治体は、中身について注文がつけられない。
3. 脱パブリッククラウドに大きな困難はない
現状、地方自治体のシステムのほとんどは、基本的に、リレーショナルデータベースをマネージドサービスにしている一方で、アプリケーション自体は仮想ホスト（IaaS）で動かしているに過ぎない。システム構成はシンプルだ。パッケージソフトウェアを利用しているところも多いわけだが、それらも稼働環境を極端に絞っているわけではないはず。オンプレミス（事業者の建屋）、コロケーション（iDC内の一室）、ハウジング（ラック全体/一部分）、ベアメタル（占有レンタルハードウェア）など選択肢は色々とあるが、技術的に移行は困難ではない。
また、パブリッククラウドを使っている最大の利点なのだが、ハードウェアなどの固定資産が無いため、撤退費用が抑制されている。
4. パブリッククラウドでなくてもモダン化はできる
地方自治体ではなくソフトハウスが心配することではあるが、プライベートクラウド（コンテナー運用）、分散バージョン管理システムの導入、CI/CDパイプライン、IDアクセス管理（IAM）、オブジェクトストレージ（とそれを前提にしたデータウェアハウス）、メッセージキュー（MQ）、通信の暗号化、ストレージ暗号化…といったデジタル庁の言うモダンな技術要素は、脱パブリッククラウドをしてもできる。それらを実現する代表的なオープンソースのミドルウェア（もしくはOSの機能）があるからだ*2。キー管理システム（KMS）の代替で有力なものはまだ無いが、それぐらいだ。
5. パブリッククラウドでなくても遠隔バックアップはできる
自治体間で協定を結び、相互に遠隔バックアップをしている事例がある（そうだ）。なお、サーバーを三箇所に分散させたオブジェクトストレージをApache Ozoneで冗長構成すると、うち一箇所が壊滅してもデータは温存される。
6. データ主権の問題も無くなる
さくらのクラウドが晴れてガバクラ採用になったので、そちらに移転すると言うて手もあるが、情緒不安定な超大国の指導者が、ある日突然、嫌がらせで外資系ハイパースケーラーにアカウント凍結を命じたりするリスクを無くせる。
7. 脱クラウドは後退ではなく前進
欧米の最近のベストプラクティスは、初期はパブリッククラウドで構築し、規模が大きくなって安定したら脱パブリッククラウドでコスト削減だ*3。自治体のシステムは機能や規模が想定外に激変することはないので、脱クラウド化の条件を満たしている。
さらに自治体クラウドは、規模の経済を認識した良手だ。デジタル庁も自治体クラウドで既にコスト低廉化がされていた事を認めている。体制を見ると、第3セクター方式でつくった運営会社を設立するなど計画が必要だが、先行事例もある。自治体クラウドではアプリケーションの共有も進めていくわけだが、これはデジタル庁が押すSaaSへの段階的移行ということになる。
*1デジタル庁 (2025) 「自治体情報システムの標準化・ガバメントクラウド移行後の運用経費に係る総合的な対策について」
*2以下に具体的なミドルウェア名などをあげておく。
- IDアクセス管理（IAM）には、Javaで書かれたKeycloakというミドルウェアがある
- オブジェクトストレージ（とそれを前提にしたデータウェアハウス）には、Javaで書かれたOzone、Spark、Hive、Kafkaなどのミドルウェアがある
- メッセージキュー（MQ）には、Javaで書かれたKafka、Pulsarなどのミドルウェアがある
- IaC（Terraform）を、コンテナオーケストレーションツールKubernetesで使うことができる
- 侵入検知（IDS）/ログ監視にはFalcoとWazuhがあり、Kubernetesと組み合わせて使うことができる
- WindowsのBitLocker、LinuxのFull Disk Encryptionでドライブ暗号化ができる
- アプリケーションとオブジェクトストレージやリレーショナルデータベースとの通信はTLSで暗号化できる
開発時の利便性なので、GitHubなどを使ってもよいはずだが、やろうと思えば閉系で開発もできる。
- ソースコードのリポジトリー共有は、sshやGitWebで行うことができる
- CI/CDパイプラインは、Javaで書かれたJenkinsというミドルウェアで構築できる
なお、OSやミドルウェアのアップデートの労力は、パッケージマネージャーのリポジトリーのミラーリングや、コンテナー作成の自動化などで削減できる。インターネットにアクセスできるネットワークの端末から閉系ネットワークの端末に、外付けHDDをつなぎ替えるお仕事が発生すると思うが。
*3The Cost of Cloud, a Trillion Dollar Paradox | Andreessen Horowitz
0 コメント:
コメントを投稿