クラウドサービスによるディスラプト（破壊的イノベーション）
以前のnote記事「ガバメントクラウドにおけるクラウドサービスの定義について」で、よくある誤解を紹介しつつ本来のクラウドサービスの考え方について整理しました。
本記事では、本来のクラウドサービスが引き起こした従来のIT業界の慣習の破壊的イノベーションについて説明します。
インフラのソフトウェア化
以前のnote記事「ガバメントクラウドにおけるクラウドサービスの定義について」では、NIST（アメリカ国立標準技術研究所）によるクラウドの定義を紹介しつつ、クラウドサービスは柔軟にリソースを増減可能なセルフサービスのITサービス提供であると説明しました。
これはITインフラストラクチャのサービス化とも言えます。あるいはITインフラストラクチャのソフトウェア化とも言えます。
2011年、Webブラウザ「Netscape」の開発者でベンチャーキャピタル投資家として知られるマーク・アンドリーセン氏が寄稿したコラムで”Software Is Eating the World”（ソフトウェアが世界を飲み込む）と表現したように、その後、家電や小売、さらには自動車までソフトウェア化が進んできました。
VRやAR、メタバースといった現実世界のソフトウェア化も進んできています。その流れのなかで、従来は物理でサーバー機器やネットワーク機器を用意するものだったITインフラもクラウドサービスによってソフトウェア化が進みました。
実際に、主要なクラウドサービスでは、ほぼすべての機能をAPIで利用可能です。プログラミングでITリソースを利用可能であり、ソフトウェアとしてクラウドサービスを捉えていることがわかります。
ITインフラをソフトウェア化し、APIでコールすればインフラが構築できるようにサービス群として利用可能な利点は、物理的制約から解放されること、他サービスとリモートで連携可能になること、製品リリース後にあとから機能追加や改変が容易になることなどが挙げられます。
データセンターに出向いて冷却されたマシンルームのなかで機器を組み上げたり、配線したり、コンソールにかじりついてITインフラをセットアップする作業から、オフィスでコーディングする作業に変わります。
クラウド利用が広まりつつあるなか、このようなITインフラのソフトウェア化の流れがこの十数年で進んできており、これまでの物理機器を前提とした考え方を大きく変えることで、下に述べるような多くのメリットを享受できるようになります。
これがIT業界の問題をなんでも解決するわけではありませんが、ITインフラの領域に限っていえば考え方の変更を伴って多くの課題や問題を解決もしくは改善できます。そのうえで、個別具体の課題の解決を考えることで、課題解決がより効率的・効果的になっていくと考えています。
インフラのサービス化、ソフトウェア化によるイノベーション
ITインフラのソフトウェア化により、オンプレミスの時代と比べて次のような考え方の抜本的な変更が必要となります。
以下、内容について説明します。
1.インフラ構築作業
クラウドサービスによるインフラのサービス化、ソフトウェア化が引き起こすイノベーションで容易に想像がつくものが、ITインフラ構築作業の変化です。
これまでの機器のセットアップやソフトウェアの導入、インフラ統合テストといった作業から、インフラ構成をコーディングするという作業に大きく変わります。
最近では、生成AIによるコーディング支援も実用化されつつあり、クラウドインフラのコーディングもこの恩恵を受けることができます。
2.ベンダーとの関係性
これまでのベンダー（ハードウェア／ソフトウェア提供事業会社）との関係性も変わります。ハードウェアは物理的な納品があるため、場所やラック、電源の準備、ケーブルやネットワークの準備、セットアップ作業員の手配など、場合によっては複数の部門にわたって調整が必要でした。
大型機器の場合はベンダー側の物流部門とも営業を経由して調整する必要があり、納品後のサポート含めて円滑にプロジェクトを進めるためにはベンダーの営業とは密な関係性を築く必要がありました。特に大型機器は一般的に高額で、リースによる月賦払いなどがあっても途中で解約できないため、契約した全額を支払う必要があります。
その分、割引率も大きく、その率は顧客によってさまざまで、価格交渉が重要になってきます。製品の原価情報や他部門や他顧客からの売上情報は共有されていないという情報の非対称性からベンダー側が損をすることは事実上ないのですが、なるべく大きな割引率を引き出すためにもベンダー営業との関係性も重要になってきます。
一方で、クラウドサービスは人手を介さずいつでも利用開始と停止ができることが特徴です。より良い利用のためにクラウドサービス事業者の営業との良好な関係作りは有効ですが、ハードウェアベンダーの時とは関係性の作り方が変わります。
3.割引／コスト削減の考え方
コスト削減方法にも大きな変化があります。前述の通り、契約すると固定額を支払わなければならないため、これまでは契約前の価格交渉が重要でした。クラウドサービスでは、単価が小さいこともあり、割引率もハードウェアに比べると小さいことが一般的です。
その代わりとして、利用開始後にコスト削減していくことが重要になります。サーバーを使っていない夜間や土日に停止するだけで50%以上のコスト削減になります。平日12時間の稼働にすると単純計算で64%のコスト削減となります。繁忙期に通常時の4倍の性能が必要な場合は、繁忙期以外で4分の1のサイジングで運用すればコストも75%削減できます。
クラウドサービスの場合、ITリソースをその場ですぐ4倍にしたり4分の1にしたりできますし、その自動化も可能です。どう運用するかの方が、契約前の価格交渉よりもコスト削減効果が大きいため、事前の価格交渉よりもむしろコスト効果の高い運用上の工夫にフォーカスするほうがコスト削減の観点では効果的です。
4.テストの考え方
個別機器のセットアップやその後の個別ソフトウェアの導入などを行ってインフラを構築していく場合は、インフラとしての統合テストもさまざまなレベルで必要ですし、納品後のキャパシティ追加が難しい場合は契約前の性能検証テストも重要になります。
一方で、クラウドサービスでは、機能はあらかじめ統合されておりインフラ統合テストは不要です。こちらも以前のnote記事で「イミュータブルなインフラ運用」として説明しました。
ソフトウェア化されたインフラであるクラウドサービスでは、APIとサービスレベルが定義されていてそのとおり動くため、マニュアルに記載されているとおり動作するかのテストは不要です。
オンプレミス環境では、ソフトウェアやハードウェアの連携が環境依存で想定通り動かないことがありました。すべてのユーザーの環境を想定した連携の事前検証をベンダーが実施することは不可能なためです。クラウドサービスでは、環境自体がクラウドサービス事業者で用意されるため、環境依存でインフラ連携ができないということはありません。
この特性は、従来のインフラエンジニアからすると、大きな認識ギャップがあるところで、考え方の大きな変更を求められます。一方、外部接続検証テストやオペレーション（外部からのデータインプット・アウトプット）含めた全体連携検証テストは、環境依存になるところでもあり当然必要になります。
また、事前の性能テストについても、クラウドサービスでは後からいつでもリソースを追加したり削除したりできるため、実機での設計前の性能検証は不要です。見積もりのための机上のサイジングは必要ですが、設計前のタイミングでの工数かけての性能検証は、昔も今も正確な性能測定は無理なのでそこに工数をかけるべきではありません。
一方、システムによってはサービスイン前の最終フェーズで性能検証は必要です。アプリケーション観点の性能検証は必要ですし、インフラ面でも、キャパシティを見たりインフラ面での性能をチューニングしたりするための性能検証は不要ですが、負荷のかかった状態で想定通りの運用ができるかのサイクルテストは必要になります。負荷のかかった状態でアプリケーションが想定通り動作するか、運用のボトルネックがどこに出るかなどの検証です。
5.可視化
クラウドサービスでは、最初から監視機能が統合されており、ユーザー側で何かを用意したりする必要はありません。クラウドサービスの管理画面にアクセスすればCPU使用率やネットワークなどの基本的な監視情報を確認できます。
ただし、そのシステムにとって、あるいはそのシステム管理者にとって、見るべき情報は別途定義が必要であり、その見るべき情報をすでに取得されている監視データを組み合わせて可視化することが重要です。
たとえば、あるシステムにとっては、ユーザーへの応答時間がつねに2秒以内であることが重要だったり、別のシステムにとっては登録件数（レコード数）が重要な見るべき情報になったりします。
クラウドサービスの機能を使えば、コーディング不要でこれらの情報をダッシュボードとして可視化することが可能です。ユーザーへの応答時間を主要な計測データとして数秒単位で折れ線グラフで可視化しつつ、関連するアクセス数やアクティブなコンテナ数を秒単位でサブグラフとして可視化するということが考えられます。これにより効果的なインフラ状況の可視化が可能です。
こうした指標が可視化されていれば、むしろCPU使用率などは監視する必要はありません。リソースは自動で増減するので個別のCPU使用率などを見る必要がないためです。オンプレミスの時はCPU使用率が高いとリスクでしたが、クラウドサービスでは逆にCPU使用率が高いほど効率的に使用されていて良い状態と言うことができます。オンプレミスの時とは考え方が大きく異なります。ITインフラがソフトウェア化・サービス化されたクラウドサービスでは、物理層に近いCPU使用率などより、サービスとして監視していくことが重要となります。
以上の1から5のイノベーションを、ITインフラのライフサイクルに沿って図示しました。
クラウドサービスによりITインフラがソフトウェア化、サービス化されることで、従来のインフラの考え方は大きく変える必要があります。クラウドサービスを10年以上前の仮想化の延長のような古い捉え方のままでいるとそのメリットを十分享受できません。一方で、考え方を変えるだけなので、アプリケーションの変更等は最小限で本来のクラウドサービス利用が可能です。
今後も、ガバメントクラウドで重視している、コスト効率、迅速性、柔軟性、セキュリティを効果的に実現していくためにも、本来のクラウドサービスの考え方に基づく使い方のガイド等を引き続き実施していく予定です。