スポンサードリンク

2013年12月02日

AWS:AmazonEC2を使ったソフトウェアテスト手法(検証方法)について

私がAWSのAmazon EC2を使う立場にあって、最も画期的な使い方だと思う方法を記載します。
これは、一応社長に対しても発表した内容ですので、有効性は高いと思います。
この方法は、2011年の1年間で実際にERPパッケージの開発・テスト手法の中で取り入れられ
今も運用されているものです。

■サーバはテストと開発におけるボトルネック
「テストをしたくてもテスト環境がない」というのはよく聞かれる話だと思う。
特に根本部分のテストとなると、なおさらそうであろう。
根本の設定を変更すると、その上に乗っている全ユーザ、全部署設定が影響を受ける。

例えば、ログイン画面の修正を行った場合、
それを50人くらいのテスターがテストしている環境に適用して
もしバグが出てログインできなくなったら、50人の工数がパーになるのだ。
(出社してすぐに、アウトソーシング先から大量にログインできませんという
 問い合わせが殺到している光景を思い浮かべて欲しい)

そうこうしていると、ログイン画面の修正はどこでテストすればいいんだ?
となり、結果的にこの修正は出荷されない。

■テスト環境を、個別に最速で用意できればいい
以下が、私が考えた上の問題に対する解決策となる。

0:テストのための環境はAmazonEC2上に作成する
1:出荷されたパッチセットは、そのタイミングで綺麗にテスト環境に適用し、AMIを取得する
2:AMIには1つのInstanceだけで全アプリケーションが動作するよう構築する


これをやれば、上記の問題は解決できる。

まず
0:テストのための環境はAmazonEC2上に作成する
なのだが、これは大前提となる。まずは使って欲しい。
AWSを利用するにあたってのセキュリティ等はVPCとダイレクトコネクト(専用線)で担保する。
※テストのための環境を、以下"テスト環境"と記載する

次に、
1:出荷されたパッチセットは、そのタイミングで綺麗にテスト環境に適用し、AMIを取得する
であるだ、これが非常に大切。

例えば、年に4回パッチセットを出荷しているとする。
仮に、2013年だと、3月、6月、9月、12月だとしよう。
これであれば、まず3月に出荷されたパッチセットを、しっかりとテスト環境に漏れなく適用し、その環境を一旦停止して、AMIとして保存する。
ここでは、「2013年3月パッチセットAMI」と仮に命名する。

AMIは、EC2の中でも最も便利な機能だろう。
サーバ(Instance)はAMIとして保存でき、AMIからいくつでも複製できる。
つまり、「2013年3月パッチセットAMI」を利用することで、
「2013年3月パッチセット環境」を簡単に複製することがでる。

しかし、この簡単な複製を邪魔するものがある。
それに対する解決が、
「2:AMIには1つのInstanceだけで全アプリケーションが動作するよう構築する」
の部分となる。

AMIをLaunchしました、でもその後、いろいろと設定変更が必要ですぐに使えません・・・
こうなってくると非常に億劫である・・・。
「テストしたい」と言われても「面倒だから後で」となってしまい、サーバ運用者がボトルネックになりかねない。

そうならないように、AMIをLaunchしたらすぐに環境が利用できる・・・
弊社であれば、IP部分は全てlocalhostで設定し、サービスはもちろん自動起動。
Oracleにはループバックアダプターを噛ませることで、設定変更なしでの環境複製を可能した。

■簡単に環境が複製できることで可能となるテストたち
上記0〜2が完璧に回ると、最初に記載した「テストができない」という問題は解決できる。

もし2013年、全てのAMIが揃っていたとしよう。
「2013年3月パッチセット環境の元AMI」
「2013年6月パッチセット環境の元AMI」
「2013年9月パッチセット環境の元AMI」
「2013年12月パッチセット環境の元AMI」
この4つが手元に存在することになる。

ここで、例えば現場から
「最新のパッチセットでログイン画面の修正テストがしたい」
 けれど、全体への影響が怖い」
と言われたら、あなたは
「2013年12月パッチセット環境の元AMI」
から1つその人専用のサーバを立ててあげればいい。終わったら破棄(Terminate)すればOK。

テストした証拠を残したい場合は、別途全ユーザが利用している全体利用のテスト環境にマージすればいい。
ここで怖がっているのは「全体への影響が怖い」という部分なので、
そこさえ解決できれば後は今までの流れと変わらない。

■運用における注意点
この運用は画期的でとても便利なのだが問題がいくつかある。

A:そもそもテストデータがないと不便
せっかく「2013年12月パッチセット環境」を用意してもらっても
1からテストデータを作成するのは大変だ。
であるから、最初からデータが入っている環境を利用してこれをAMIとする必要がある。
だからこそ、最初に「0:テストのための環境はAmazonEC2上に作成する」と記載した。

B:放置されるとコスト増
Instanceの料金は単純に利用時間に比例する。
上記テストが終わっても便利だからと言って個人的にずっとキープされると、
一人のためにお金がずっとかかってしまう。
利用が終わったら、ちゃんとInstanceは破棄する運用を徹底する必要がある。

C:やはり運用には手間がかかる
先に
「2:AMIには1つのInstanceだけで全アプリケーションが動作するよう構築する」
があるが、少なくともLaunchだけは手作業が必要になってしまう。これが面倒なのだ。
これをAMI管理者が問い合わせを受け、OKしたものだけがLaunchされる流れとなるが、この調整は以外と面倒である。

しかし、誰しもがLaunchするようにしてしまうと、謎のInstanceが大量に存在するというカオス状態になるので、これはお勧めできない。
実際にこれを行ったこともあるが、EC2の利用料金が異常に高額となった。
それはもう、数千万という単位になる。

■その他
IPについてはVPCを利用していることから、基本的には勝手に空きIPでLaunchされる前提で記載している。
他に特筆する点としては、Instanceにインストールされているソフトウェア以外の部分、
主にミドルウェアだが、開発ライセンス等の使いたい放題ライセンスではないと運用が厳しい。
そこはミドルウェアの保守契約の変更を行って対応すべし。

■コストについて
AWSは利用した額だけが請求される。従量課金制なので、固定額ではない。
はっきりいってこれは、予算という仕組みと非常に相性が悪い。
しかも、AWSには利用上限がない。使おうと思ったらいくらでも使えるのである。
オーバースペックで使い続けられると、簡単に数百万円、時には数千万円にまでコストはかかる。

そのため、このコストという視点をしっかりと持って
1:上長には、従量課金制を理解してもらい、ある程度上下幅をもった稟議とすること
2:コスト意識をしっかりと持ち、時には強制的にサーバを破棄/停止する権限が運用者に必要

であると考える。
ここをないがしろにすると、「便利になったがコストが厳しい」という非常に面倒なことになる。
つまり、過剰投資だ。

AWSを利用するとき、まずは使うことに視点が行くと思うが、あまりに自由度が高いのはよくない。
しっかりとコストの視点を持たなければ運用とは呼べない

■まとめ
とにもかくにも、サーバ構築という部分がボトルネックにならないというものは素晴らしいフットワークを発揮する。
一度このフットワークの軽さを覚えたら、なかなか元へは戻れないだろう。

特にAMIは他にも「古いバージョンが不要となっていくが、たまに必要となる」
というバージョン管理が必要なソフトウェアでは、かなり重宝する。
なぜなら、「古いバージョンのお客様で不具合が見つかった」となれば
「ではそのバージョンの古いパッチセットAMIからサーバを構築してすぐにテストしよう」
とできるからだ。

今までであれば
「1社だけがこのバージョンで運用しているので、
 社内の古いテスト環境がそのためだけに保守されないといけなくなっている」
という、ある種の呪いがかけられたりしたのであるが、
AMIであれば、そのバージョンの環境はAMIとして担保されているのだ。
しかもAMIは保守するコストが非常に安い。
そのため、そんな呪いからは解放される
すぐさまテストではAWS及びAmazonEC2を使うんだ!

以上です。
posted by hinata_hisa at 13:33 | 東京 ☀ | Comment(0) | 仕事の話 | このブログの読者になる | 更新情報をチェックする
この記事へのコメント
コメントを書く
お名前: [必須入力]

メールアドレス:

ホームページアドレス:

コメント: [必須入力]

認証コード: [必須入力]


※画像の中の文字を半角で入力してください。