DX化の流れにも後を押され、オンプレミス環境からクラウド環境へのクラウドリフトが加速しています。日本国内では「クラウド・バイ・デフォルト原則」に従い「新規システム導入を行う際は、クラウドサービスを第一に考えること」（以降クラウド）といった政府方針にも支えられ、この流れが今後も止まることはないでしょう。一方、多くのプロジェクトでは、オンプレミス環境からクラウド環境へのリフト経験、移行経験がないことにより、下記2点の課題を抱えるプロジェクトが後を絶ちません。
- 開発コスト増加
- スケジュール遅延
今回のブログでは、クラウドリフトで発生する予想外の開発コストと、スケジュール遅延について具体的な例を示しながら解説したいと思います。これからクラウドリフトを検討しているプロジェクトではぜひ参考にして頂き、事前に対策を検討しましょう。
まさかの開発コスト増加
クラウドを利用した多くの人が直面する開発コスト増加とは、クラウド利用料です。想像以上に高額なことに驚きます。詳細を確認します。
クラウド利用料の過小評価
基本的に共通しているところは「ハードウェアやソフトウェアの購入が発生しなくなるため、その分費用が浮くであろう」という前提ありきでプロジェクトを進めた結果、開発コストが増加、超過しているプロジェクトが圧倒的に多いという事実です。まず、クラウド利用料金の体系ですが、次の２パターンで提供されることが一般的です。クラウド毎に名称はそれぞれですが、AWSでは前者をオンデマンド、後者をリザーブドインスタンス料金などと呼びます。
- 利用した分だけ課金される従量課金体系
- １年や３年といった固定された期間に対する利用料を割引価格で前払いする課金体系
この課金体系を前提として最大限コストメリットを出そうとすると、システム側がクラウドが提供する課金体系でお得になるようにあわせていくことが大前提となるのですが、多くのプロジェクトではそれが出来ていません。具体例で見てみます。
システム開発で必ず利用する開発環境の運用を例に確認します。
多くのプロジェクトでは、特定期間、業務時間であるに日中帯に利用することが多いと思います。１．のオンデマンド利用を前提として開発環境の利用計画を立てることが多いでしょう。時間にして一か月１６０時間程度（算出ロジックは下記の通り）として算出しているケースもあります。
平日５日を４週間で２０日、１０時－１８時の８時間 → １６０時間
しかし、システム開発が進んでくると程度の差はあれトラブルが発生し、開発スケジュールの遅延が発生することはままあります。総合試験といったフェーズでは日回し、耐久テストといったことで１週間連続で２４時間運転するといったこともざらです。トラブルが多ければ、何度も実施しなければなりません。このようなことが考慮されてなければ、どうなるかはご想像の通りです。
初めてクラウドリフトしたケースで、開発環境の利用料金が計画値に収まったという話を聞いたことがありません。オンデマンド利用料は想像以上に高額であり、起動しているインスタンスタイプ、開発期間で変わってきますが、オンデマンド利用時間が計画値の２倍になるような状況であればリザーブドインスタンスで計画したほうが良かった、そんなこともざらにあります。参考として、AWSのEC２オンデマンド利用料が確認できるページを載せておきます。
運用のユースケースに対して、何通りもシミュレーションしたうえで適切なインスタンスタイプや課金体系を導く必要があるのです。
クラウド利用のコストメリットを最大限生かそうとすると、システム側がクラウドが提供する課金体系にあわせないとならない理由がお分かり頂けたのではないでしょうか。
クラウド利用料の超過あるある
多くのプロジェクトで１度はやっている、想定外のクラウド利用料が発生するケース２点をあげておきます。
知っていれば防げる内容なので、同じようなトラブルを引き起こさないようにしましょう。
- インスタンスの停止忘れ
手動でインスタンスを停止する運用にしている場合、停止忘れが発生し夜間、土日の利用していない時間帯で利用料が発生します。これは、結構な頻度で発生します。バッチで特定時間に停止させるといった運用で問題ない場合は、仕組みでカバーしたほうが良いでしょう。
- AmazonRDSインスタンスは、7日後に自動起動する
製品仕様となっているため、プロジェクト側で停止する仕組みを用意しないと、知らない間に利用料が発生します。RDSはEC2に比べて高額となるため、大きなインスタンスタイプを利用していると被害額は大きくなるため、十分な注意が必要です。
事前検証の甘さが招くスケジュール遅延
クラウドリフトを一から経験しているエンジニアや有識者はまだまだ少ないのが現実です。そういったメンバーを集めて体制を組もうとしても、まず集まりません。集まったとしてもクラウドの有識者は短期、スポット参画となる人が多いでしょう、それだけ希少な人材であり、需要も単金も高いということです。一方、プロジェクトとしては経験のないクラウドリフトに対して事前の検証やリスクに関する洗い出しが必須であるにも関わらず、そういった事情により事前検証やリスク洗い出しが甘くなる傾向にあります。当然、見切り発車となり、いざトラブルが発生したとしても適切な対策が立てられず、スケジュールが延伸するといった「典型的な炎上プロジェクト」へ発展します。
クラウドリフトプロジェクトにおけるスケジュール延伸は、オンプレミス環境でのそれに比べて格段にリカバリが難しくなります。なぜそのようなことになるのか、その背景を探ってみましょう。
従来の機能・非機能は実現できるのか
クラウドリフトの大前提を確認しておきます。目的は、クラウドへの移行を低リスク、低コストに抑えることにあります。プロセスとしては必然的にオンプレミス環境での基本的な設計思想はそのままとし、追加の発生となる設計や構築稼働は抑えなければなりません。クラウドで提供されるマネージドサービスを最大限活用し最適化する（クラウドネイティブ）といったことが目的ではありません。その上で、従来の機能・非機能をクラウド環境上でどのように実現するのか事前の検証が非常に重要になってきます。なぜなら、AWSやAzureといったクラウドは、オンプレミス環境と違って開発者が好き勝手自由に構築、利用できるわけではなく、クラウドの利用規約や仕様に従ってシステムを構築しなければならないからです。それら事前の検証をPocと呼び、プロジェクトの推進に大きな影響を与えかねない不確実性を取り除く作業が必要なのです。
Pocでは何をすれば良いのか
プロジェクトでの不確実性を取り除くとは、具体的に何をすれば良いのでしょうか。現実的にはPocの教科書的な説明を聞いただけでは抽出できません。結論としては「プロジェクトによる」となります。それでは元も子もないので、検討例の一例を示します。
既存システムがOracleをアクティブスタンバイのHA構成を採用しているとしましょう。考えられるクラウドリフトのパターンは、AWSの場合下記２通りです。
- Amazon RDS for OracleをマルチAZ構成とし、マネージドサービスのアクティブスタンバイをフル活用 → 多くのPJではこちらの構成を採用しているイメージ
- Amazon EC2にクラスタソフトを導入しオンプレミス環境と同様にHA構成を構築する → 構成により制約があり使いずらい印象
当該プロジェクトの場合、これらをPoc対象に抽出したポイントは以下の通りです。RDSを利用しても非機能要件で定義した可用性と性能を担保可能であることが検証できたため、１．の採用を決定しました。
- クラウド上における高可用性の構成に関してはAWSとして様々技術情報が展開されている → 複数の処理方式が検討可能
- RDSというマネージドサービスの利用が初 → RDSの制約を見極める必要がある（Pocで確認できたRDSの制約の一部を下記記事で紹介しています）
- AWS上のHA構成はオンプレイ以上のレイテンシーとなるため性能評価が必須 → マルチAZ構成の場合、性能劣化する事象が報告されている
実際にはAWSの有識者に参画して頂き、既存の設計から検証したほうが良いポイントについてアドバイスをもらいましたが、AWS Well-Architected フレームワークを参照し、AWS上で検討すべき項目についての理解も深めて取り組みました。
Poc不足のプロジェクトが9割
AWS有識者からアドバイスをもらったと記載しましたが、クラウドリフト経験のないプロジェクトとしては良い選択だったと思います。具体的には、アマゾンウェブサービスジャパン社から技術コンサルティングという形でスポット参画してもらいましたが、冒頭で述べた通り多くのプロジェクトでは、AWS有識者を確保するための単価が高いという理由により、本来実施すべき検討が出来ていない現実があります。結果として、大切なポイントを事前検証できず、いざ設計、構築しようとしたら想定する機能が実装できなかった、実現できなかったという事例は枚挙にいとまがありません。
機能が実現出来ないだけなら、大幅なコスト超過を覚悟で当該機能を作りこむことも可能な場合もあるでしょう。一方、目標とする性能に届かない場合は、さらなる悲劇が待ち受けています。
EBSやEFSのIOPS、スループットの変更にも限界があります。設定可能な最大値に変更しても性能目標を達成出来ない場合は、処理方式の変更も視野に入れなければなりません。しかし、処理方式の変更となると、設計からやり直しとなります。これまで実施してきた試験が全て無駄となり、超過するコストもリスク予備費では対応できないレベルで高額となることが予想されます。そもそも、EFSのスループット引き上げで対応できたとしても、EFSのスループット引き上げによるコストインパクトも大きく、通常時にそのスループットでシステムを運用していくことは現実的ではないでしょう。
ちなみに、クラウドを利用するということは、目先のハードウェア、ソフトウェア費用を下げるためではありません。初期の導入費用を抑えつつ、将来のビジネス拡張にむけて柔軟に対応するためといった要素のほうが大きいことを理解しておくべきでしょう。
Pocに関しては、クラウドリフト経験のある有識者を含めて行うことを強く奨めます。
まとめ
クラウドリフトはオンプレミス環境同士の移行とは全く異なります。従来の開発プロセスでは対応できないことも多いので、今まで以上に徹底的にリスクを洗い出し、万が一リスクが顕在化した場合でも想定の範囲内に収めておく必要があります。そのためには、次の２点を必ず考慮してください。
- クラウド利用料を最適化したいならば、システム側がクラウドが提供する課金体系に運用をあわせる
- 設計を踏襲可能なのか、マネージドサービスによる新設計とするのか、性能は目標を達成することが可能かPocを行う
コメント