• 開発コスト増加
• スケジュール遅延

今回のブログでは、クラウドリフトで発生する予想外の開発コストと、スケジュール遅延について具体的な例を示しながら解説したいと思います。これからクラウドリフトを検討しているプロジェクトではぜひ参考にして頂き、事前に対策を検討しましょう。

まさかの開発コスト増加

クラウドを利用した多くの人が直面する開発コスト増加とは、クラウド利用料です。想像以上に高額なことに驚きます。詳細を確認します。

クラウド利用料の過小評価

基本的に共通しているところは「ハードウェアやソフトウェアの購入が発生しなくなるため、その分費用が浮くであろう」という前提ありきでプロジェクトを進めた結果、開発コストが増加、超過しているプロジェクトが圧倒的に多いという事実です。まず、クラウド利用料金の体系ですが、次の２パターンで提供されることが一般的です。クラウド毎に名称はそれぞれですが、AWSでは前者をオンデマンド、後者をリザーブドインスタンス料金などと呼びます。

1. 利用した分だけ課金される従量課金体系
2. １年や３年といった固定された期間に対する利用料を割引価格で前払いする課金体系

この課金体系を前提として最大限コストメリットを出そうとすると、システム側がクラウドが提供する課金体系でお得になるようにあわせていくことが大前提となるのですが、多くのプロジェクトではそれが出来ていません。具体例で見てみます。

システム開発で必ず利用する開発環境の運用を例に確認します。
多くのプロジェクトでは、特定期間、業務時間であるに日中帯に利用することが多いと思います。１．のオンデマンド利用を前提として開発環境の利用計画を立てることが多いでしょう。時間にして一か月１６０時間程度（算出ロジックは下記の通り）として算出しているケースもあります。

　平日５日を４週間で２０日、１０時－１８時の８時間　→　１６０時間

しかし、システム開発が進んでくると程度の差はあれトラブルが発生し、開発スケジュールの遅延が発生することはままあります。総合試験といったフェーズでは日回し、耐久テストといったことで１週間連続で２４時間運転するといったこともざらです。トラブルが多ければ、何度も実施しなければなりません。このようなことが考慮されてなければ、どうなるかはご想像の通りです。

初めてクラウドリフトしたケースで、開発環境の利用料金が計画値に収まったという話を聞いたことがありません。オンデマンド利用料は想像以上に高額であり、起動しているインスタンスタイプ、開発期間で変わってきますが、オンデマンド利用時間が計画値の２倍になるような状況であればリザーブドインスタンスで計画したほうが良かった、そんなこともざらにあります。参考として、AWSのEC２オンデマンド利用料が確認できるページを載せておきます。

運用のユースケースに対して、何通りもシミュレーションしたうえで適切なインスタンスタイプや課金体系を導く必要があるのです。

オンデマンドインスタンスの料金 - Amazon EC2 (仮想サーバー) | AWS

オンデマンドインスタンスについては、お客様が使用された EC2 インスタンスの料金のみのお支払いとなります。オンデマンドインスタンスを使用することにより、ハードウェアのプランニング、購入、維持に伴うコストや手間が省け、高額な固定費となりがちな運用コストを、より低額な変動費に抑えられます。

aws.amazon.com

クラウド利用のコストメリットを最大限生かそうとすると、システム側がクラウドが提供する課金体系にあわせないとならない理由がお分かり頂けたのではないでしょうか。

クラウド利用料の超過あるある

多くのプロジェクトで１度はやっている、想定外のクラウド利用料が発生するケース２点をあげておきます。
知っていれば防げる内容なので、同じようなトラブルを引き起こさないようにしましょう。

• インスタンスの停止忘れ

手動でインスタンスを停止する運用にしている場合、停止忘れが発生し夜間、土日の利用していない時間帯で利用料が発生します。これは、結構な頻度で発生します。バッチで特定時間に停止させるといった運用で問題ない場合は、仕組みでカバーしたほうが良いでしょう。

• AmazonRDSインスタンスは、7日後に自動起動する

製品仕様となっているため、プロジェクト側で停止する仕組みを用意しないと、知らない間に利用料が発生します。RDSはEC2に比べて高額となるため、大きなインスタンスタイプを利用していると被害額は大きくなるため、十分な注意が必要です。

RDS インスタンスを 7 日以上停止する

AWS Lambda を使用して、Amazon リレーショナルデータベースサービス (Amazon RDS) を 7 日間以上停止したいと考えています。

repost.aws

事前検証の甘さが招くスケジュール遅延

クラウドリフトを一から経験しているエンジニアや有識者はまだまだ少ないのが現実です。そういったメンバーを集めて体制を組もうとしても、まず集まりません。集まったとしてもクラウドの有識者は短期、スポット参画となる人が多いでしょう、それだけ希少な人材であり、需要も単金も高いということです。一方、プロジェクトとしては経験のないクラウドリフトに対して事前の検証やリスクに関する洗い出しが必須であるにも関わらず、そういった事情により事前検証やリスク洗い出しが甘くなる傾向にあります。当然、見切り発車となり、いざトラブルが発生したとしても適切な対策が立てられず、スケジュールが延伸するといった「典型的な炎上プロジェクト」へ発展します。

クラウドリフトプロジェクトにおけるスケジュール延伸は、オンプレミス環境でのそれに比べて格段にリカバリが難しくなります。なぜそのようなことになるのか、その背景を探ってみましょう。

従来の機能・非機能は実現できるのか

クラウドリフトの大前提を確認しておきます。目的は、クラウドへの移行を低リスク、低コストに抑えることにあります。プロセスとしては必然的にオンプレミス環境での基本的な設計思想はそのままとし、追加の発生となる設計や構築稼働は抑えなければなりません。クラウドで提供されるマネージドサービスを最大限活用し最適化する（クラウドネイティブ）といったことが目的ではありません。その上で、従来の機能・非機能をクラウド環境上でどのように実現するのか事前の検証が非常に重要になってきます。なぜなら、AWSやAzureといったクラウドは、オンプレミス環境と違って開発者が好き勝手自由に構築、利用できるわけではなく、クラウドの利用規約や仕様に従ってシステムを構築しなければならないからです。それら事前の検証をPocと呼び、プロジェクトの推進に大きな影響を与えかねない不確実性を取り除く作業が必要なのです。

Pocでは何をすれば良いのか

プロジェクトでの不確実性を取り除くとは、具体的に何をすれば良いのでしょうか。現実的にはPocの教科書的な説明を聞いただけでは抽出できません。結論としては「プロジェクトによる」となります。それでは元も子もないので、検討例の一例を示します。

既存システムがOracleをアクティブスタンバイのHA構成を採用しているとしましょう。考えられるクラウドリフトのパターンは、AWSの場合下記２通りです。

1. Amazon RDS for OracleをマルチAZ構成とし、マネージドサービスのアクティブスタンバイをフル活用　→　多くのPJではこちらの構成を採用しているイメージ
2. Amazon EC2にクラスタソフトを導入しオンプレミス環境と同様にHA構成を構築する　→　構成により制約があり使いずらい印象

当該プロジェクトの場合、これらをPoc対象に抽出したポイントは以下の通りです。RDSを利用しても非機能要件で定義した可用性と性能を担保可能であることが検証できたため、１．の採用を決定しました。

• クラウド上における高可用性の構成に関してはAWSとして様々技術情報が展開されている　→　複数の処理方式が検討可能
• RDSというマネージドサービスの利用が初　→　RDSの制約を見極める必要がある（Pocで確認できたRDSの制約の一部を下記記事で紹介しています）

404 NOT FOUND | いまさら聞けないシステム開発

意外と知らない、だけど知っておくべきシステム開発の基本と裏話を伝えていきます

sys-univ.com

• AWS上のHA構成はオンプレイ以上のレイテンシーとなるため性能評価が必須　→　マルチAZ構成の場合、性能劣化する事象が報告されている

実際にはAWSの有識者に参画して頂き、既存の設計から検証したほうが良いポイントについてアドバイスをもらいましたが、AWS Well-Architected フレームワークを参照し、AWS上で検討すべき項目についての理解も深めて取り組みました。

AWS Well-Architected フレームワーク

docs.aws.amazon.com

Poc不足のプロジェクトが9割

AWS有識者からアドバイスをもらったと記載しましたが、クラウドリフト経験のないプロジェクトとしては良い選択だったと思います。具体的には、アマゾンウェブサービスジャパン社から技術コンサルティングという形でスポット参画してもらいましたが、冒頭で述べた通り多くのプロジェクトでは、AWS有識者を確保するための単価が高いという理由により、本来実施すべき検討が出来ていない現実があります。結果として、大切なポイントを事前検証できず、いざ設計、構築しようとしたら想定する機能が実装できなかった、実現できなかったという事例は枚挙にいとまがありません。

機能が実現出来ないだけなら、大幅なコスト超過を覚悟で当該機能を作りこむことも可能な場合もあるでしょう。一方、目標とする性能に届かない場合は、さらなる悲劇が待ち受けています。

EBSやEFSのIOPS、スループットの変更にも限界があります。設定可能な最大値に変更しても性能目標を達成出来ない場合は、処理方式の変更も視野に入れなければなりません。しかし、処理方式の変更となると、設計からやり直しとなります。これまで実施してきた試験が全て無駄となり、超過するコストもリスク予備費では対応できないレベルで高額となることが予想されます。そもそも、EFSのスループット引き上げで対応できたとしても、EFSのスループット引き上げによるコストインパクトも大きく、通常時にそのスループットでシステムを運用していくことは現実的ではないでしょう。

ちなみに、クラウドを利用するということは、目先のハードウェア、ソフトウェア費用を下げるためではありません。初期の導入費用を抑えつつ、将来のビジネス拡張にむけて柔軟に対応するためといった要素のほうが大きいことを理解しておくべきでしょう。

Pocに関しては、クラウドリフト経験のある有識者を含めて行うことを強く奨めます。

まとめ

クラウドリフトはオンプレミス環境同士の移行とは全く異なります。従来の開発プロセスでは対応できないことも多いので、今まで以上に徹底的にリスクを洗い出し、万が一リスクが顕在化した場合でも想定の範囲内に収めておく必要があります。そのためには、次の２点を必ず考慮してください。

• クラウド利用料を最適化したいならば、システム側がクラウドが提供する課金体系に運用をあわせる
• 設計を踏襲可能なのか、マネージドサービスによる新設計とするのか、性能は目標を達成することが可能かPocを行う

この5日を保存しておく仕組み、バックアップソフトウェアで実現できると安易に考えているとしたら、それは危険です。

AWS Backup世代管理の仕様と問題

AWS Backup（以下AWSバックアップ）の世代管理仕様で考えると、保存期限の指定は日数のみです。つまり、休日や祝日を世代数から除外するなどの設定をすることができません。

世代数に「休日、祝日を含む、含まない」といった管理できないということは、土日、大型連休や年末年始など休日、祝日をまたぐ運用に対して注意が必要です。

上記の例、バックアップ保存期限の要件として5営業日、バックアップデータを保存しておく必要がある場合を考えます。

AWSバックアップ機能で保存期限を5日と指定すると、土日をまたぐケースだと3営業日分しかバックアップデータが存在しなくなります。5日連続休日になる場合だと直前1日分しか存在しなくなります。5営業日のバックアップデータを保存しておくといった要件を満たせません。

これはAWSバックアップに限った話ではなく、休日、祝日を営業日、非営業日として管理できるバックアップソフトのほうが少ない印象です。

では、バックアップソフトウェアにその機能がない場合、対策はどうしたら良いでしょう。

対策

多くの場合は、下記3点が現実的な対策となります。

それぞれのメリットデメリットを勘案し、プロジェクトで最も影響が少ない対策を選択することになります。

AWSバックアップも年々進化しており、やがては休日、祝日をバックアップ世代に含める、含めないの管理ができるようになる可能性があります。

採用する場合は、最新仕様を確認するようにしてください。

このような情報は実際に体験しないとわからないですよね。是非、参考にしてください。

原因

Auto Scaling対象EC2に対して、停止時に無効化していたAuto Scalingのヘルスチェック※を起動直後に有効化すると、タイミングによってはAuto ScalingがEC2の状態を起動（正常）ではなく停止（異常）と判断し、再作成となる。

※ヘルスチェック
一般的には、負荷分散しているサーバやネットワーク機器がダウンした場合に負荷分散対象から切り離すための監視機能のことを指します。ただし、システム、製品によってヘルスチェック対象となるものがノードなのかプロセスなのかなど違うため実装方法は異なります。

Auto Scalingインスタンスのヘルスチェックに関する詳細は下記を参照してください。

Auto Scaling グループ内のインスタンスのヘルスチェック - Amazon EC2 Auto Scaling

Amazon EC2 Auto Scaling がヘルスチェックの失敗をモニタリングして対応し、誤検出の可能性を軽減する方法について説明します。

docs.aws.amazon.com

対策

Auto Scaling対象EC2を停止起動する際は、EC2のヘルスチェック状態が正常になっていることを確認してからヘルスチェックプロセスを有効化する。 具体的には、Auto Scaling対象EC2を起動した5分後にヘルスチェックプロセスを有効化するなどを実施する。