「メールは基幹システム。もし止まると、業務に大きな支障が出る」。積水化学工業 経営管理部 情報システムグループ 部長の原 和哉氏はこう言い切る。にもかかわらず、同社は2013年から2014年にかけて、メールの機能を含む独自開発のグループウエア「Smile」のインフラを、オンプレミス（自社所有）環境から米Amazon Web Services（AWS）のクラウドサービスに移行した。従来は100台のサーバーで構成していた大規模インフラである。
このインフラ刷新プロジェクトのマネジャーを務めた原氏らが、AWSの信頼性を高く評価したから、というわけではない。「AWSに限らないが、今のところパブリッククラウドサービスは“落ちる”という前提で利用する必要がある」と原氏。AWSの導入前からそういう評価であり、実際に導入した後もその認識は変わらないという。
ならばなおさら、なぜAWSをメールという基幹システムのインフラとして導入したのか。それは、合理的な判断プロセスを経た結果だった。
インフラ刷新プロジェクトの契機は、2014年にSmileが稼働するシステムでストレージの更新時期を迎えたこと。Smileの従来システムは、ストレージのコストの制約で、メールボックスの容量は1ユーザー当たり100Mバイトしか割り当てられなかった。その容量を大幅に増やすことが強く求められていた。
原氏らは、この「メール容量」に加え、「コスト」「BCP（事業継続計画）対応」「ユーザビリティー」「アーカイブ（長期保存できるかどうか）」といった評価項目を立て、（1）オンプレミスのままインフラを全面刷新する、（2）独自開発のグループウエアを捨て汎用的なグループウエアSaaSに切り替える、（3）IaaS/PaaSとしてベストだと評価できるAWSに移行する、という三つの方策を比較検討した。その結果、三つのうち最も優れた方策は、（3）のAWSへの移行だったという。「評価が突出していたわけではないが、すべての項目でバランスが取れていた」（原氏）。
信頼性の問題については、システムの構成要素ごとに、冗長構成にしたり、AWSが障害対応などを行うマネージドサービスを利用したりして解決した。さらに、万が一、AWSというクラウドサービスがなくなったとしても、他社のIaaSに移行できるようにアーキテクチャーを設計した。
「ITインフラSummit 2015」では、こうしたAWS導入の経緯のほか、クラウドならではの反復型の設計・テスト方法、システム運用体制の考え方、クラウドへの移行に備えてオンプレミス環境で取得しておくべきログといったことを、前出の原氏が解説する。クラウドの導入を検討している現場にとっても、既に導入済みの現場にとっても、参考になる点が多々あるはずだ。
