ミサワホームは業務システムのAWS（Amazon Web Services）移行を進めており、2014年5月時点ではサーバー全体の約3割がAWS上で稼働している。オンプレミス環境（自社所有のシステム基盤）の常識が通じない、AWSならではの“想定外”に直面し、現場は試行錯誤を繰り返した。
「システムの大半をAWSへ移行する」―。ミサワホームの宮本眞一（企画管理本部 情報システム部長）は決断した。同社は2011年から、自社の全システムを対象にした再構築プロジェクトを進めている。その方針として掲げたのが、冒頭のAWSへの移行だったのである。
このプロジェクトの目的は、ミサワホームグループ全体のIT統合。これまでグループ企業40社が個別に構築・運用してきたシステムを標準化して統合する。グループ企業の規模は、数十人から1000人規模までさまざまだ。統合スケジュールが流動的になる可能性もあった。宮本は「サーバーやストレージなどのシステムリソースがいつごろどれだけ必要になるのか見通しが悪かった。だからといって、余裕を持ってシステムリソースを確保するとコストが膨らむ」という課題を抱えていた。
ここで目を付けたのがパブリッククラウドサービス（以下、クラウド）だった。「クラウドなら、柔軟にシステムリソースを増やせる」と宮本は考えた。
メインのシステム基盤としてAWSを選定。2013年4月から次々と、AWS上に既存システムを移行したり、新規システムを構築したりしている。2014年5月9日現在、ミサワホームのサーバーの約3割はAWS上で稼働するまでになった（図1）。
ただ、オンプレミス環境での開発・運用しか経験のなかった情報システム部のエンジニアは、想定しなかった苦労に直面した。技術担当の森嶌浩之（企画管理本部 情報システム部 システム推進課 参事）は「AWSには独特の流儀が多い。それをきちんと理解しておかないと、トラブルに発展してしまう」と指摘する。実際、宮本や森嶌ら情報システム部のチームは、AWSの利用を開始してから三つの“想定外”に直面した（図2）。
再起動しない仮想マシン
「仮想マシンのOSがいつまで経っても起動しません。どうしてでしょうか？」。第1弾として営業支援や人事情報などのシステムをAWSに移行した2013年初頭、森嶌は他のエンジニアからこう相談された。システムは深夜に停止（シャットダウン）させ、ディスクイメージのスナップショットを取得してバックアップ。その後に再起動するのだが、それがうまくいかなかったのだ。これが一つめの“想定外”である。
相談してきたエンジニアによると、ハイパーバイザー上で仮想マシン（Amazon Elastic Compute Cloud=EC2）は立ち上がるが、OSが起動しないという。AWSのマネジメントコンソールには「Status Checks」という項目がある。仮想マシンの起動状況を2段階で表示するものだ。まず「1/2」と表示されて仮想マシンの起動プロセスを実行する。仮想マシンの起動が終わると「2/2」に変わり、OSの起動プロセスへと移る。ときどき、いつまで待っても「2/2」が終わらず、OSが起動されなかった。
森嶌はピンと来た。情報システム部はAWSを本格採用する以前、野村総合研究所（NRI）に実運用に耐えるサービスかどうかの調査を依頼していた。その分厚い調査報告書の中に「まれに仮想マシンの起動や停止ができないことがある」という記載があった。
解決策としては、仮想マシンを起動し直すしかないが、話はそう簡単ではなかった。実は、Status Checksに表示される項目は、リアルタイムに反映された情報ではないのだ。Status Checksでは起動できていないように見えるが、実際には起動している―そうした仮想マシンが存在することが分かっていた。下手に仮想マシンを再起動すると、別のトラブルを引き起こす可能性がある。
そこで出した結論は、「5分間にわたってStatus Checksが2/2のまま止まった仮想マシンは再起動する」という方針だった。問題発生時には自動的に再起動をリトライするように、富士通の運用監視ツール「SystemWalker」のスクリプトを作成した。