ガバメントクラウドでのコスト削減の考え方

2024年3月13日 14:46

以前のnote記事「クラウドサービスによるディスラプト（破壊的イノベーション）」で、クラウドサービスの変革の1つとして「割引／コスト削減の考え方」を説明しました。

オンプレミスにハードウェアやソフトウェアを購入する場合は、一括払いにしろ月賦払いにしろ固定の購入金額が大きく割引率も高くなり、契約後はその金額を全額払い切らないといけないため、契約前の価格交渉が重要でした。

一方、クラウドサービスは単価が高くなく割引率もそこまで大きくない代わりに、本番稼働後のインフラ運用の工夫でコスト削減を継続的に実施していくことが可能です。むしろ、運用での継続的コスト削減策の方が割引率よりも高い効果を出せます。本記事ではその具体例を提示します。

ここで、サービスイン後の運用のなかでコスト削減を実施しても予算額は変わらないので意味はないという意見もあります。移行1年目の年についてはそう言えるかもしれませんが、2年目以降の予算見積もりには大きく貢献できます。2年目以降は継続的にコスト削減してきたものベースでより精緻に見積もることができるようになります。その意味でも、継続的なコスト削減は大きな意味があると言えます。

また、システムを完全にモダン化しないとコスト削減効果が出ないのではないかという意見もあります。本記事では、システムをモダン化しなくても、現行のアプリケーションの改修を最小にしたクラウド移行でも可能なコスト削減策を例示します。

特に地方公共団体のガバメントクラウド利用では、アプリケーションの改修を最小にしたクラウド移行のケースが多いと考えられ、この記事で書いた対策例はこうしたケースでも活かしていただける考え方となります。これらのコスト削減策はガイドとして配布を開始しており、今後も事例含めてガバメントクラウド利用者にナレッジを共有していきます。

サンプル構成でのコスト削減効果の要約

結論として、次に説明するサンプル構成をベースにこの記事で紹介するコスト削減策を適用すると、現状の構成をそのままクラウドサービスに移すよりも、全体で64%のコスト削減効果が出せると試算できました。
サイズの最適化や稼働時間の短縮、マネージドサービスの活用などのコスト削減策によりトータルでこの効果を実現できます。
その詳細を見ていきます。

サンプル構成

次のサンプル構成を想定した具体的なコスト削減について説明します。

また、為替レートは1USドル=150円で計算します。
コスト試算は2024年1月時点のAWSを例として提示しますが、ガバメントクラウドの他クラウド事業者でも同等で、同じ考え方を適用できます。

コスト削減策

コスト削減策(1)：マネージドサービスの活用

ガバメントクラウドでは、クラウド移行時のシステムのモダン化を推奨しています。システムアーキテクチャをモダン化する際にはクラウドのマネージドサービスの活用も重要になってきます。マネージドサービスを利用すれば、サービスによっては実際の使用された時間だけの課金（従量課金）が可能になるため、使われていないときは課金されないことになり、コスト削減効果が高くなります。

一方で、常時使われるタイプのアプリケーションではCPUなどリソースが使い続けられてその分コストがかかり逆効果なこともあるので、その場合はコンテナなどリソースを固定で割り当てるタイプのサービスを利用することもできます。

システムの移行タイミングによってはすぐにモダン化できないこともあります。その場合は、アプリケーションはなるべくそのまま改修を最小限にして移行しつつ、周辺機能にマネージドサービスを利用した移行も可能です。

とくに運用管理系の基本的な機能はマネージドサービスで用意されていることが多く、オンプレミスの監視サーバーのように常時稼働させる必要がないため、その活用がコスト削減となります。

たとえば、AWSでの監視サーバを例に取ると、監視サーバを4vCPU、16GBのm6i.xlarge上に構築して、24時間365日稼働で年間56万7,648円となります。監視のためのマネージドサービスであるCloudWatchの場合は、計測監視するメトリクスの数での課金となり、CPU使用率などの基本的なメトリクスは無料です。追加でWebアプリケーションサーバとデータベースサーバ、バッチサーバにカスタムメトリクスをそれぞれ5個作成するとして、カスタムメトリクス25個（5個x(2台+2台+1台)=25個）、そのうち10個まで無料のため残り15個で年間8,100円となります。

運用管理系機能は、上表の全体コスト割合が合計10%ほどと高くなくコスト削減効果が薄いかもしれませんが、50分の1から100分の1のコストになるのだとすると検討すべきです。

また、バックアップサーバを2vCPU、8GBのm6i.largeで構築すると、年額28万3,824円となります。クラウドサービスではバックアップ機能も標準であります。たとえば、1TBのストレージ領域のうち50%を使用しており毎日10GBの更新があるストレージを毎日バックアップする場合、AWS EBS Snapshot機能を使えば、年額7万2,000円となります。75%のコスト削減です。現行のバックアップソフトウェア費用もバックアップ用のストレージ費用も含めていないため、それを入れるとさらに大きい削減率となります。

コスト削減策(2)：適切なサイズ（CPU数やメモリサイズ）の選定

すぐにシステムのモダン化ができない場合は、アプリケーションサーバはそのまま最小限の改修での移行となります。

データベースサーバはマネージドサービス化するとしてもデータベースソフトウェアを変更しない場合はマネージドサービスのなかでサーバインスタンス（仮想マシン）を立てるパターンになります。ただし、これらのサイズ（CPU数やメモリサイズ）はクラウド移行のタイミングで見直すべきです。

というのも、クラウドサービスでは再起動するだけでサイズ変更が容易にできるため、必要になったタイミングで柔軟にサイズ変更していくことが可能です。5年後のキャパシティ予測やピーク時のリソースをあらかじめ割り当てておく必要はなく、現在の通常時のサイズで普段運用できます。

たとえば、年度末や月末のピーク時に通常時の4倍のキャパシティが必要になるようなアプリケーションを考えます。その場合、通常時は最大4分の1のサイズで運用することができます。

AWSを例に取ると、Webアプリケーションサーバが現行8CPUコアで稼働しているとして、それをそのままのサイズで持っていこうとすると、m6i.2xlargeというインスタンスサイズが必要で、2台で年額227万592円となります。これはピーク時のサイジングのため、上の考え方で通常時はこの4分の1の2CPUコアで稼働すると、r6i.largeを利用し、2台で年額64万1,232円となります。72%のコスト削減効果です。

データベースサーバはOracleDBで現行16CPUコアで稼働しているとして、それをライセンス持ち込み（BYOL）でそのままのサイズでマネージドサービスのRDSに持っていくとdb.m6i.4xlargeが相当し2台で年額494万640円となります。データベースはCPUは4分の1にできてもメモリサイズは変えられないことも多いので、その場合は、メモリサイズを維持しつつCPU数が8vCPUのdb.r6i.2xlargeが選べて2台で年額291万1,824円となります。41%のコスト削減となります。

月に2日間ピークがあるとすると、そのときだけサイズが2-4倍になるため、予算としては10-20%増しで計算できます。

適切なサイズを判断するには、現行のサーバのCPU使用率などを確認することが重要です。一般論として、クラウドサービス以前は、容易かつすぐにはリソース追加できないためピーク時に合わせて余裕を持ってリソースを準備することが多く、ほとんどのケースで通常時はCPU使用率が10%以下となっています。

そうした場合はサイズを大きく縮小するよい機会となります。クラウドサービスの自動拡張機能などと組み合わせながら、もしくは手動拡張運用プロセスを整備しつつ、サイズを縮小して移行するか、継続的な運用のなかで徐々にサイズを縮小していくべきです。

コスト削減策(3)：未使用時は停止する

クラウドサービスでは、使っていない時間帯がある場合は、停止するだけでその時間分のコスト削減が可能です。

たとえば、バッチアプリケーションが夜間8時間しか稼働していない場合、バッチサーバをその時間だけ起動するとコストが3分の1となります。バッチサーバを16vCPU、64GBで稼働させるとすると、m6i.4xlargeとなり、常時稼働させると454万1,184円となるところ、夜間8時間だけの稼働にすると151万3,728円にできます。67%のコスト削減効果になります。

また、踏み台サーバは、調査やメンテナンスでログインする時にだけ使用するため、普段は停止しておけます。月24時間だけの稼働の場合、2vCPU、8GBのm6i.largeとして、常時稼働の場合の年額28万3,824円に対して9,332円となります。97%のコスト削減です。

検証環境についても、開発フェーズやメンテナンスフェーズの多くの期間でつねに稼働させておく必要はなく、平日12時間の利用で土日は停止可能だとすると、(12時間x5日)÷7日で64%削減が可能です。メンテナンスフェーズで月に10日間、日中16時間しか稼働しない場合は、78%のコスト削減となります。

コスト削減策(4)：適切なストレージサイズの定義

オンプレミスで統合ストレージなどを使ってストレージを構成する場合、実際のデータサイズに対してかなり大きなストレージ容量が定義されます。一方で、クラウドサービスでは実際のデータサイズで見積もりを考えるべきで、オンプレミスで割り当てられたストレージ容量をそのまま当てはめて試算するのは過剰です。

たとえば、オンプレミスのストレージでは、業務的に必要な見積もり容量が1TBだとしても、性能維持のために数割余裕を持った容量にしたりRAID構成を組んだりスペアディスクが必要だったりで、実容量の2.5-3倍ほどになります。さらにバックアップを複数面もつためにたとえば2面だとその3倍見積もられて7.5TBのストレージ領域となります。

この容量をそのままクラウドストレージの見積もりに使うと過剰です。クラウドサービスでは、1TBのストレージ割り当てにRAIDなどの容量は含まれているので余剰を入れなくてもよいです。

バックアップは実容量だけが増分で取られるので、毎日10GBの更新で日次バックアップを30日分取得するとすると0.3TBが増分バックアップ容量となります。初回のフルバックアップは実容量に対して取られるので1TBの割り当ての使用率が50%だとすると、0.5TBがフルバックアップ容量です。すべて足して1.8TBがクラウドサービスで必要なストレージ容量となります。4分の1以下です。

AWSのEBSで見積もると、オンプレで7.5TBの統合ストレージが必要だったところが、1TB分のEBS gp3ストレージと、0.8TB分のSnapshot費用で、年額24万4,800円となります。

もし保存データがファイルで、オブジェクトストレージに格納可能だとすると、オブジェクトストレージは通常のブロックストレージの4分の1以下の価格で、かつ実容量だけなので、先ほどのとおりディスク使用率が50%だとすると、ここからさらに8分の1以下の価格にコスト削減可能です。オブジェクトストレージも積極的に活用していくことが重要です。

コスト削減策(5)：ネットワーク通信量

ネットワーク通信量についても過度な見積もりが散見されます。クラウドは通信料金やダウンロード通信料が高いという神話がなぜか世の中に流れています。おそらく、以前にクラウドサービスからオンプレミスに回帰したシステム事例が記事になったことがあり、その事例がファイル共有サービスや動画配信サービスの事例で、通信料の高騰を理由に回帰したとされていたことが要因の1つと考えられます。ただ、ファイル共有サービスや動画配信サービスは通信量が膨大になるかなり特殊なシステム例で、ほとんどの行政や民間企業のシステムはこの例に当てはまりません。

たとえば、AWSで閉域網で利用している際に、毎日100GBをAWSから拠点やオンプレミスにダウンロードしても月1万8,893円、1TBダウンロードしたとしても月18万8,928円の通信料です。

一般的な行政や民間企業のシステムでは、通信料金は全体クラウド利用料の数%、5%以下です。もしそれ以上の極端な通信費用が見積もられる場合は、見積もりに不正確なところがあると想定されますので見直すべきと考えます。

サンプル構成でのコスト削減効果

上で具体例として説明してきたサンプル構成のそれぞれのサーバに対するコスト削減策とその効果を一覧表にしました。コスト削減率は、現行のサーバ構成（CPU数やメモリサイズ、ストレージ容量）をそのままクラウドサービスのコンピュートサービスに持ってきたものに対する削減率となります。負荷分散装置のみ、現行の想定として2台で年額80万円（5年400万円）として削減率を出しています。