冗長化を行わない選択肢

弊社は、基幹業務システムに ERP パッケージの「Infini One」を利用しています。

Infini One
https://www.future-one.co.jp/service/InfiniOne.html

このシステムを導入したのは 2018 年 7 月で、当時はまだアンダーデザインに社名を変更する前（旭コムテク時代）でした。
GA (General Availability) したばかりの「東京リージョン・アベイラビリティゾーン d」にフロントサーバーとデータベースサーバーの 2 つのインスタンスを設置し、UD社内 LAN と AWS を VPN でセキュアに繋ぎました。

そして、運用開始から半年が経ったころ (2019 年 3 月頃) に構成の見直しなどを含めてAWSのベストプラクティスに向けた最適化を行うべく、再構築プロジェクトを立ち上げました。
先月（2019年8月）、この再構築プロジェクトが一旦完了しましたので、改修時のエピソードを何回かに分けてご紹介させていただきます。

単一障害点の多いシステム設計の見直し

上図を見ていただくと分かるように、システムは単一のアベイラビリティゾーンに設置されているため冗長化できていません。折角 AWS インフラを利用しているのですから、高可用性と高耐久性を両立した、冗長化された構成にしたいところ。
再構築プロジェクトのチームでは、高可用性を確保するためにプライベートサブネットに設置された EC2 インスタンスをネットワーク・ロードバランサーでロードバランシングし、高負荷時にスケールアウトする構成にできないか調査することにしました。そして、RDSは Multi-Az構成にして有事の際には自動で別アベイラビリティゾーンの RDS インスタンスにフェイルオーバーする仕組みを導入しようと考えました。

開発元に実績がなく、冗長化するなら有償で検証してから

早速、Infini Oneの開発元である Future One 様に問い合わせしたところ、過去にロードバランサーを使った冗長構成の実績はないとの回答をいただきました。また、実装する場合は有償による検証を行いたいとのこと。
決して安い金額ではなかったので、社内稟議にかけて実施可否を確認する必要がでてきました。

システムのアクセス元は社員のみ

そもそも弊社が利用しているInfini OneはAWS 上にありながらも、フロントサーバーとデータベースサーバーの両サーバーがプライベートサブネットにあり、インターネットから通信ができないようにされています。VPNゲートウェイを経由した、社内LANアクセスのみ許可しているのです。従業員からアクセスがありますが、不特定多数から予想外のアクセスでバーストすることもありません。ある程度、利用頻度と傾向が予測できました。

マネージド型のMulti-Az はコスト高

データベースサーバーに関してもEC2 インスタンスからマネージド型のRDS に変更し、且つ、有事にフェイルオーバーし可用性を維持できる Multi-Az 構成にした場合、コストは倍以上になります。これも社内稟議に諮る必要がありました。

冗長化で得られる費用対効果が薄い

Infini Oneには、弊社の社員が日々登録した案件情報や実績が保存されています。先にも書きましたが不特定多数のお客様がアクセスされるシステムではないので、仮に障害が発生してダウンしてしまってもECサイトやプロモーションサイトのように機会損失が起こる可能性は低いです。（社員のモチベーションは下がるかも知れませんが…）

冗長化を行わないという選択肢

以上の調査結果を元に、再構築プロジェクトのチームは社内稟議にかけ役員判断を依頼しました。結果、基幹システムは冗長構成を行わないことになりました。
とはいえ、お客様と私たちを繋ぐ重要なデータが保管されているわけですから、バックアップをしっかり取得するよう依頼されました。

弊社のように、システムの利用用途によってはコストメリットと機会損失を天秤にかけて、あえて冗長化しないという選択肢もあるかと思います。

次回は、バックアップに関する改修エピソードをご紹介します。