導入背景

某公共サービス様の今回のプロジェクトでは、社会で働く多くの人に密着したシステム基盤のご依頼を受けました。

サービスとしては運営上24時間365日の安定した稼働が望まれ、アクセス数も一定であり突発的なスパイクはほぼありません。
ただし以前オンプレミスによる手作業で発生していたリスク軽減への対策及び、Disaster Recovery（災害対策。以下、DR）に関しては強い要望がありました。
従来のプロジェクトではオンプレミスを利用しているため拠点は存在しているものの、どういったアーキテクトを利用することが人的ミスの軽減及びDR対策ができるのかが問題の焦点となりました。

提案内容

いままでお客様が経験していた環境では、オンプレミスと呼ばれる企業様の建物の中に物理的なマシンサーバを手配してインフラの構築をしていました。そのため手作業が発生してしまい確認作業を多く導入したとしても、人的ミスが発生してしまうようなリスクを含んだ状況でした。

そして今回の構築をオンプレミスにしてDRが発生した場合、サービスを理解した有識者でなければ復旧ができないほど巨大な構築でもありました。
Amazon Web Services（AWS）は全ての作業がコマンドで構築することが出来るため、環境構築をコードとして残すことが可能となります。
初期費用が発生してしまうもののテンプレートでインフラ構築をコード化することで、似たような環境を複数用意することが可能となります。また一度環境構築をしてしまえば、コードを流すことだけで同様の環境を何度でも同じようにミスなく構築することが可能になります。

DRの際であっても構築したテンプレートを使用することで、普段サービスに携わっていないサービスへの造詣が浅い人であっても同じサービスを復旧をすることが可能となります。
このようなインフラ構築をコード化して保存することをIaC（Infrastructure as Code）と呼びます、AWSではこのIaCを利用することで同様の環境を何度も、自動的に、ミスがなく構築出来るAWS CloudFormation（以下、CloudFormation）というサービスがあります。今回はCloudFormationによるサービスが一番適していると判断し、こちらでの構築を提案させていただきました。

アーキテクトを構築以降、手作業でのミスは90％低減することが出来ました。現在想定しているDRは発生していませんが、構築時のフェイズにおける防災訓練では別リージョンから稼働している環境と同じ環境を構築することも、現地プロジェクトに参加していないエンジニアにより構築が可能だということも実現することが出来ました。

導入企業様の声

いままでインフラに関して問題があった場合、些細な問題であっても必ずサーバルームへ足を運び状況を確認していました。中にはコードが刺さっていなかったということもあり、自分が成すべきサービスに注力が出来ていないと思ったこともありました。
CloudFormationを導入することでコードとして資材管理することが可能になり、事前に本番と同じ環境を構築することで検証を行うことで、本番でのミスを防ぐことで出来ることは24時間365日安定したサービスの提供の一助になっています。今後のサービスの拡充という点においても大変助かっています。

長期的なプロジェクトとなりましたが、要件定義・外部設計・構築・運用と一連のサポートありがとうございました。
かなり手順書なども作成してもらい、言葉の説明からなにまで負担をおかけしたと思いますが、重ね重ね誠にありがとうございます。

構成図（サービス簡略図）