2つ目のしくじりは、仮想サーバ「Amazon Elastic Compute Cloud」(EC2)の復旧に手こずったこと。
アイレットはある時、顧客からEC2のインスタンスタイプ変更の依頼を受けたため、いったんEC2を停止。インスタンスタイプを変更した後に再起動しようとしたところ、うまく起動しなかったという。
そこで、あらかじめ取得していた「Amazon Machine Image」(AMI、インスタンスの構成などを記録したテンプレート)のバックアップから起動しようとしたところ、これも予期せぬソフトウェアエラーにより起動できなかった。最終的には、壊れてしまったインスタンスから、ブロックストレージ「Amazon Elastic Block Store」(EBS)だけを抜き出し、新たに作成したインスタンスにアタッチすることで何とか復旧にこぎ着けたという。
また別の顧客から「AMIからバッチサーバを復旧してほしい」という依頼を受けた際には、AMIから正常にEC2サーバを起動できるようにするはずが、普段なら15〜20分で終わるはずのバッチ処理が1時間たっても終わらないトラブルに見舞われた。
原因を調査したところ、AWSには「AMIからサーバを復元した際は、初期化が必要」という仕様があることが分かった。AMIからEC2サーバを復旧した直後は、データはまだストレージに置かれたままの状態で、データにアクセスがあった時点で初めてダウンロードされる。そのため、初回アクセス時はサーバのパフォーマンスが極端に低下してしまったのだ。
「こうしたしくじりを経験したおかげで、たとえAMIのバックアップと取っていたとしても100%安心できるとは限らないことを学んだ。『本当にそのAMIからサーバを復旧できるのか?』『復旧した後にきちんと動作するのか?』といった点をあらかじめ確認しておくことが大切だった」(古屋さん)
Copyright © ITmedia, Inc. All Rights Reserved.
Special
PR