こんにちは、Enterprise Cloud部 ソリューションアーキテクト1課 の 宮形 です。
大型のオンプレミスからクラウドへのサーバーリフトプロジェクトを担当しておりますと、どのお客様からの期待が高いのが「コスト削減」になります。ところが、現状オンプレミスで動いているサーバーやネットワークの仕組みを洗い出し、それらをAWS上で動かそうとAWS利用料を試算すると「思ったより安くならない」「逆にコストが高くなった」というお話をお聞きします。
その理由は様々だと思いますが、本BLOGでは私がこれまで経験することが多かったその理由についてご紹介させていただきます。
- オンプレミスのサーバースペックをそのままAWS EC2インスタンスへ適用している
- 過剰な目標稼働率(SLA)が設定されている
- 開発環境、検証環境をフル構成ですべてリフトしている
- 過剰にバックアップが取得されている
- 必要以上にBCPが行われておりデータ転送量が多くなっている
- 大容量データを高価なストレージサービスに保管している
- オンプレミスと機能重複している箇所がありコストが2重にかかっている
- まとめ
オンプレミスのサーバースペックをそのままAWS EC2インスタンスへ適用している
サーバーをクラウドリフトする際、心配毎の一つとしてパフォーマンス劣化があります。その心配がために、クラウドリフト前のサーバースペックをそのままEC2インスタンスへ適用してしまいがちになります。現状ご利用されているサーバーの構成次第ですが、一般的にパブリッククラウドの方が同じ性能の場合のサーバーコストが高くなる傾向があります。
「単純リフトは逆に高くなる」のはパブリッククラウドの常ですのでクラウドに最適化された方法にシフトすることが望ましいです。
オンプレミスの時点でサーバースペックが過剰であることが分かっているのであれば、クラウドリフトを機にサーバースペックの適性化は行うべきかと思います。事前に検証環境を容易に作れるのもパブリッククラウドのメリットですので、PoCでパフォーマンス計測を行うことも効果的となります。
過剰な目標稼働率(SLA)が設定されている
お客様と要件定義をしていると、「目標稼働率 99.99以上」や「SLA 99.99%以上」という要件がよく見られます。システムの安定稼働としては納得なのですが、これを AWS のEC2インスタンスで実現しようとすると、マルチAZ 2台以上のインスタンスを用意しロードバランサー等で冗長構成とする必要がありAWS利用料がその分高額となります。
高い目標稼働率(SLA)はパブリッククラウドではコスト増となります。本当にミッションクリティカルなシステムのみに留められるよう整理頂くことをお勧めします。
開発環境、検証環境をフル構成ですべてリフトしている
開発環境や検証環境を24時間365日利用するという事は非常にまれかと思います。EC2やRDSなどインスタンスが伴うAWSサービスにおいては、時間あたりの起動に対してAWS利用料がかかります。月間で想定される利用時間を設定し、使わない時はインスタンスを停止する計画によりコストを下げることができます。
また、開発環境、検証環境はバージョンアップや機能改修等の特定時期しか使わないのであれば、普段は削除しておき利用時のみ CloudFormation テンプレートで都度作成することもコストを下げるために効果的です。
過剰にバックアップが取得されている
AWSのEC2におけるバックアップとしては、AMIやスナップショットといった増分バックアップの手法が一般的です。バックアップとして取得されたデータはAWS内の安価なストレージに保管されるのですが、かといって過剰の頻度、保持世代でバックアップを取得するとコストが高くなってしまいます。
例えばアプリケーションサーバー等であれば日常的に殆ど変更がかからないと思いますので稼働時点やメンテナンスの前後のみなどにバックアップ取得を限定することで、コストを下げることができます。ソースコードはGit等で管理できておりいつでも最新状態にデプロイできる状態であれば、クラウド上ではサーバーのバックアップそのものが不要という整理も出来ると思います。
オンプレミスではDBサーバーのバックアップファイルやダンプファイルを世代取得し、それを保管するためのストレージを用意していたケースも多いと思います。DBサーバーをAWSにおいてRDSに置き換えられた場合、RDSでは自動バックアップ機能が標準搭載されており、ポイントインタイムリカバリの機能も有しています。またスナップショットから簡単にインスタンスを別領域にリストアすることもできます。バックアップファイルやダンプファイルの運用は必要なくなる可能性もありますので、見直しすることでコストを下げることが出来ます。
必要以上にBCPが行われておりデータ転送量が多くなっている
AWSをはじめパブリッククラウドでは複数リージョンを利用することが可能で、メインリージョンとは別に遠隔リージョンをBCPサイトとして構成することで、万一メインリージョンが被災ストップした場合でもBCPサイトで事業を継続することができます。
便利で心強い機能なのですが、BCPサイトを維持するためにメインリージョンから遠隔リージョンに日々バックアップデータを転送する必要があり、このリージョン間のデータ転送コストが比較的高いためコスト増に繋がるケースが多く見受けられます。コストを下げるためにBCPの対象システムを整理することをお勧めします。
大容量データを高価なストレージサービスに保管している
AWSでは数種類のストレージサービスが提供されています。そのうち、仮想サーバーEC2のローカルディスクにあたるのは EBS となります。この EBS は容量対コストが比較的高額となる傾向があります。一方 オブジェクトストレージのS3では容量対コストが安価です。大容量データ等は EBSではなく 安価なS3へ移行出来ないか検討することで、コストを下げられる可能性があります。
ただしS3は原則としてOSのローカルファイルシステムとしては利用できない点に注意が必要です。アプリケーションからのアクセス方法は再考のうえ作り変えが必要となる可能性があります。
オンプレミスと機能重複している箇所がありコストが2重にかかっている
例えばAWSでは Network Firewall という完全マネージドサービスのファイアウォール機能が提供されており大規模環境ではよく使われています。時々みうけられるのが、AWS上に Network Firewall があるのにオンプレミス側にも Firewall のアプライアンスがあり機能重複しているケースです。構成上どうしても両方必要ということでなければ、どちらか片方に機能を寄せもう片方を廃止することでトータルコストを下げることができます。
まとめ
いかがでしたでしょうか。私が経験したオンプレミスからの大型クラウドリフト案件でAWS利用料が高くなってしまうケースをご紹介させていただきました。
本BLOGではいわゆる単純なサーバー移行 クラウドリフトのケースで紹介しましたが、クラウドでよりコストを下げるにはサーバーレスやマネージドサービスの活用といったクラウドモダナイズが有効となります。これには多くの場合アプリケーション側を対応する必要がありますので容易ではないことが多いですが、既にAWSクラウドリフトをされたご利用者の方には次なる一手として是非ご挑戦いただくとよいと思います。
本記事が少しでも皆様のお役に立てれば幸いです。