見出し画像

Day5「マルチクラウドの定義」 @ ガバメントクラウドについて考えるAdvent Calendar 2022

この記事は、ガバメントクラウドについて考える Advent Calendar 2022のDay4「マルチクラウドの定義」となります。

※こちらの記事は基本的には公開情報を元にしていますが、個人的な妄想・意見も含まれておりますので、ご承知おきください。

このAdvent Calendarは、日々活動している中で課題として感じることなどをどこかで整理しなくてはいけないと思っていて、ちょうど良いタイミングだったので、全日自分が思うところを書くというスタイルにチャレンジして、どこまで続けられるかやってみたいと思います。
https://adventar.org/calendars/8293

以前、以下のツイートに多くのことをまとめてみたのですが、改めて整理していきます。

マルチクラウドって何?

さて、今回はマルチクラウドの定義について見ていきたいと思います。ガバメントクラウドは、現在CSP4社でマルチクラウドの構成を取っています。そもそもガバメントクラウドは、基本要件や技術要件を満たせばすべてのCSPと契約するという形になっていますが、そもそもマルチクラウドとはなんなのか、マルチクラウドにする意味というのは何でしょうか?

1システムの中でクラウド同士を繋げることをマルチクラウドと呼ぶのでしょうか?それらはハイブリッドクラウドと呼ぶのではないか?複数システムの連携のためにクラウド同士を繋げることをマルチクラウドと呼ぶのでしょうか?複数のクラウドという選択肢があることでしょうか?

このようなことについては、クラウドの定義についても言えるんですよね。オンプレミスとプライベートクラウドの違いってなんでしょうか?庁内にシステムを置いている場合がオンプレミスですか?だとすればデータセンターにおいて共通基盤になっているのはプライベートクラウドでいいのか?プライベートクラウドは本来国内のクラウドプロバイダーが提供しているIaaSベースのものだけなのか?だとすると、パブリッククラウドとプライベートクラウドの違いは何なのか?

いずれにせよ、私はクラウドタイプ(プライベートクラウド、パブリッククラウド、SaaS)といったものと、クラウド利用状態(マルチクラウド、ハイブリッドクラウド)といったものに分けて考えるようにしています。また、それぞれの定義には注意をしながらお話しをしなければなりません。

今回は一旦以下の定義にしたいと思います(賛否両論あろうかと思いますが)

  • オンプレミス:庁内に置かれたシステム

  • プライベートクラウド:DCに置かれて管理されているもの、IaaSベースのクラウドもこちらに分類

  • パブリッククラウド:ガバメントクラウドに代表されるCSPによるインターネット経由で制御できるもの

  • マルチクラウド:システム間におけるクラウドの組み合わせ

  • ハイブリッドクラウド:システム内におけるクラウドの組み合わせ

このような定義とすると、政府系でもオンプレミスというよりプライベートクラウドがほとんどではないでしょうか。いずれにしても、このような整理の後、マルチクラウドについて考えていきましょう。

マルチクラウドは何がいいのか?

では、なぜガバメントクラウドはマルチクラウドとしているのでしょうか?先程の定義から考えるに、適切なシステムに適切なクラウドを割り当てるべきということではないかと考えます。その選択肢を提供するためと思います。

https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/fb619f03-5fbd-4dd7-8bb1-114c6f63f0ba/32efc6c2/20220930_meeting_executive_02.pdf

それを紐解くために、「政府情報システムにおけるクラウドサービスの適切な利用にかかる基本方針」を見ていきましょう。マルチクラウドについての記載があります。こちらには、「個々の政府情報システムにおいて、主たる環境として利用するIaaS/PaaSのCSPを複数 とするマルチクラウドはコストが増大することが多いため、真に必要性がある場合を除 いては避けること。SaaS等を中心に特定機能に特化して他のクラウドを併用することは 問題ない。」とされています。


つまり、SaaSに限定するならマルチクラウドを使っても良いよということが書かれています。深堀りするために、こちらの資料の詳細版を読んでいきましょう。

https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/fb619f03-5fbd-4dd7-8bb1-114c6f63f0ba/c5871775/20220930_meeting_executive_01.pdf

こちらのマルチクラウドに関する項目にも、「技術的な合理性と経済的な合理性を持たないマルチクラウドは厳に避ける必要がある」と記載があります。また、クラウドプロバイダーに依るベンダーロックインについても、データの移行性が担保され、価格が公開されていればベンダーロックインにはならないから、そのようなケースにおいてはクラウドに依存することにならないとされています。

加えて、後半にはハイブリッドクラウドに関する項目が書かれていて、こちらについても基本的には否定的と見られます。では、(そもそももうちょっと根拠を書いておいてほしいですが…)なぜこのような書き方になっているのか考えていきましょう。

複数クラウドの運用

まず複数のクラウドを利用していけば行くほど、運用管理は大変になるかと思います。クラウドごとに知識を習得して追従し、別々のコンソールを見て、別々の特性を持つシステムを運用管理していかなければなりません。現にデジタル庁としても、CSP4社ごとのIaCやアカウント管理を提供していかなければならない立場のため、これをタイムリーに4社分サポートするのは大変なはずです(これがあまりCSPを増やしたくない要因であったりすると邪推しますが…)保守体制的にも、複数のクラウドを利用すると別々の保守窓口に依頼することになり煩雑になることが想定されます。

別日に書く予定ですが、特定のCSPとのレベルの高い保守契約を結ぶケースにおいても、複数結ぶことになったりするのではないかと思います。これは今までのシステムごとの調達時にも起きていたような気がしますが、政府系の調達において、入札の結果、意図せず複数のCSPになってしまうことはあり得るかもしれません。

クラウドロックイン

クラウドロックインについては、おそらく特定の技術を導入したことにより、価格をコントロールされて高く買わざるを得ないということを懸念しているのだと思います。そのため、データが移行できるようになっていて、価格のコントロールされる範囲を、公開価格のクラウドを利用すればロックインと呼ばないということを意図しているように見えます。技術的に代表的なものとしては、Oracleデータベースから他のデータベースへの移行といったことがあるかと思いますが、このケースでもデータが移行できないわけではありませんし、どちらかといえばこのようなミドルウェア系を変える時には、ミドルウェアの機能によって成立していたものを、アプリケーション側や別のミドルウェア等の仕組みで実現するための改修がかかるため、頓挫することが多いのではないかと思います。これは別にクラウドを使ったからといって変わるものではないと思いますし、先日からお伝えしているクラウドネイティブに利用すればするほど同様の状態になると思われます。

ハイブリッドクラウド

最後にハイブリッドクラウドですが、こちらはオンプレミスの定義次第かなと思いますが、オンプレミスを先程の定義とすると確かに微妙です。しかしながら、オンプレミスをプライベートクラウドと置き換えるとどうでしょうか。技術的な観点と、別日にお話しする主権的な観点で、特に政府系のシステムにおいては、このように分けることはないとは言い切れないと思います。

こちらのスライドのように特定の技術が特定のクラウドでしか実現できないというケースもあり、その場合にはハイブリッドクラウドという選択肢があり得るわけです。

マルチクラウドの主体者とユーザーの選択

ここまでこれといった断定が難しかったのは、いろいろな前提条件によって取るべき判断が変わってくると考えているからです。つまり、クラウドに依存することよりメリットを取るというのであればそれでいいと思いますし、複数クラウドを運用するデメリットよりもそうまでしても使う理由があれば使えば良いと思います。これはユーザーの選択です。その選択のための選択肢は柔軟にカバーされる必要があり、一律で制限されるものではないと思います。

そもそもマルチクラウドになるのかについては、いつも話題になります。敢えてマルチクラウドになるという発想にはなかなか至りません。なんらかのためにマルチクラウドになってしまう、が正しいと思いますし、それに向かってどうしていくかが正しいアプローチなのだと思っています。

今までの基幹システムにはじまる情報システムは安定性が重視されてきましたが、今新たに求められる情報システムはLoB(Line of Business)の方々が迅速性や拡張性を自部署の人材だけで提供していこうというものです。そのプラットフォームとして既存の情報システム基盤がマッチしないケースがあるのは当然です。そのようにして、各LoBがクラウドサービス利用に進むのは何らおかしくありません。しかしながら、情報システムの担当者からすれば範疇外のシステムが増え、LoBの情報システムを含めたシステム全体を見ている主体者からすると、全体コスト最適化ができる余地があるのではないか、未把握のシステムのセキュリティの甘さにより情報漏えいをしてしまう危険性があるのではないかということが懸念として出てきます。

また、様々なクラウドがそれぞれの意思によって利用されることにより、この主体者としてはクラウド選択が制限されてしまい、非効率なやり方を許容することになるなどの懸念も出てくるわけです。

この結果、クラウド集約をしていくという判断もあるかもしれませんし、このクラウドをどう統制していくかという判断もあって然るべきです。このあたりをクラウドファーストで先行していた海外の動向は明日また共有させていただきたいと思います。

執筆後記

このようにガバメントクラウドを考えるAdvent Calendar 2022では、以下の流れで進んでいくことになると思いますので、Day5以降もお待ちいただければと思います。

  • ガバメントクラウドの在り方

  • ガバメントクラウドの整備における課題感

  • ガバメントクラウドの利用における課題感

  • ガバメントクラウドの今後について考えてみる

Twitterなどで情報発信していますので、もしよろしければ覗いてみてください。