AWS Cloud Roadshow 2014レポート – 受託開発時における AWS クラウド活用術 #AWSRoadshow

AWS Cloud Roadshow 2014レポート – 受託開発時における AWS クラウド活用術 #AWSRoadshow

Clock Icon2014.10.31

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、せーのです。

今回は2014/10/31に札幌プリンスホテルにて行われました「AWS Cloud Roadshow 2014 札幌」の中からアマゾン データ サービス ジャパン株式会社の#ヤマンこと片山さんと株式会社アグレックスの古山さんによるセッション「受託開発時における AWS クラウド活用術」のレポートを致します。

主に自サービスや大規模サービスにしか使えない、と思われているAWSの違った一面が見られれば幸いです。

従来の受託開発

スタンドアロン〜ルームシェア

特に札幌では大規模な使い方、というのはあまり見られません。札幌でのソフト屋さんに多いのは「受託開発」になります。「うちは受託だからクラウドなんて使いどころがない」と思われている方も多いかと思います。でも開発環境にAWSを使うと、結構イイことが多いのです。

では従来の受託開発ではどのような環境での開発が多いのでしょうか。オンプレですね。自社でサーバーを買うわけです。そしてそこに開発環境を立てます。 開発が終わり本番リリースを完了するとこの環境はどうなるでしょう。最初のうちはバグ潰し等で稼働していますが、そのうちシステムが安定稼働し始めると開発環境はほぼ使われることがなくなります。ここで「買ったサーバーだから使わなくてもコストがかからない」と思われる方がいるのですが、そんなことはありません。サーバーを置く場所、電気代、定期的なメンテナンス等、細々細々とコストが掛かっていきます。

ではどうしましょう。つぶしますか?潰すわけにはいかない、というのは受託をやっている方なら身にしみてわかるかと思います。いつ修正依頼、追加発注がくるかわからないからです。開発サーバーはいつ使われるかわからないけど、いつでも使えるように常に準備しておかなくてはいけません。そしてプロジェクトごとにサーバーを買い足し、サーバールームがカオス状態に陥ります。

そこで次に出てくる発想が「ルームシェア」です。一つの環境に色々なプロジェクトを相乗りさせるわけです。これをやりだすと様々な問題が出てきます。代表的なものとしては「ミドル、OSを勝手にバージョンアップ、設定変更出来ない」「他のチームのプロジェクトソースが丸見え」等があります。

仮想化環境

そこでVMware、Hyper-V、Xenなどのソフトウェアを使用して仮想化環境を組むことになります。そうするとそれぞれ環境がわかれるので、一見めでたしめでたし、に見えますが、仮想化環境の運用というのは職人的な技が必要です。 コンピュータに詳しくない人にはここら辺がなかなか伝わらないところですがサーバーとは「いつか壊れる」ものです。仮想化環境であれば壊れた際に連鎖的に被害が拡大します。それを防ぐために定常的に監視、メンテナンス、ハード交換等が必要になります。これをキチンとするためには専門に1人雇わないといけないレベルになりますので結構なコストがかかります。 またオーバープロビジョニングという障害などが予期せぬタイミングで発生しお隣のプロジェクトソースに多大な影響を与えたりしますので、そういう対策も行わなくてはいけません。 色々やらなきゃいけないことは増える、でもそこにコストはかけられないのでなんとかかんとかやっている、という現状の受託の会社さんは多いかと思います。

これらをAWSを使うと一気に解決できます。

AWSを開発環境に使うメリット

必要な時に必要なだけ使う

開発時は動作確認が主になるのでサーバーのサイズは少なくて良いですが、本番前にはレスポンスや負荷のテストも必要になるので本番同様のサーバーサイズが必要になります。そんな時AWSなら数ステップでインスタンスサイズを自由に変えられます。

使わない時は止めておく

本番リリースし安定稼働しはじめると開発環境ではやることがなくなります。そういう時はサーバーを停止しておけば僅かな維持費で状態が維持できます。そして追加の開発時はまたスケールダウンして使えばコストパフォーマンスになります。クラウドですから当然その他のハードメンテナンスは全てAWSが面倒を見てくれます。

時間単位でON/OFFする

開発時でも夜中は開発しません(ん?今何か聞こえましたが、、、(夜中に開発しないなんてことは)、、、無視します)。開発しない時はサーバーを自動で止めるようにスケジューリングしておくことでコストダウンにつながります。例えば朝10時から夜10時まで開発時間とすると、自動で夜10時から朝10時までサーバーを止めるようにすればコストは通常の1/2で済みます。

AWSのフルマネージドサービスを活用する

AWSには専用的なサービスがたくさんあります。例えば自前でロードバランサーを構築するのは大変なので開発環境には作らなかったりする場合も多いですが、開発環境でシングルサーバーで構築していて、本番でロードバランサーを挟んだ途端にセッションが切れて障害頻発、、、なんてこともよくあることです。 AWSではELBというロードバランスサービスが用意されています。こちらは数クリックでロードバランサーの準備とサーバーへの接続が可能になりますので、本番リリース前にロードバランステストを簡単に行うことができます。 またマシンイメージを簡単にコピーすることができるので出来上がった開発環境を小さいインスタンスで数十台並べて負荷テストを行い、終わり次第一台を残して一気に潰す、というような運用も可能です。これらをインフラ部隊に頼むと1ヶ月はリードタイムをください、なんて言われるところですがAWSならセルフで出来るのもメリットですね。

ライセンスを別途買わなくていい

これも結構あるあるなのですが、例えばベンダーさんのDBのエンタープライズ版、SSL証明書等ライセンスが別途必要なものがあります。常に使うものであれば別途買っても良いかと思うのですが、テスト等の一時的に使うものになかなかライセンスを買うわけにはいきません。AWSのサービスには予めライセンス付きで提供されているサービスも多いので、一時テストの際にはそちらを使用して本番環境では別途ライセンスを買って使う、というのも開発環境ならではの賢い使い方です。

三現主義

三現主義、とは製造業等で昔から言われている言葉なのですが「現場で現物を見て現実を知る」というものです。つまり机上であれこれ考えるよりまずやってみて、その結果を元に考えるという方針ですが、昨今のITの現場はまさにこれが当てはまります。 現在のシステム開発においては経験に基づく裏付け、いわゆる「やってみた」が必要です。AWSのクラウドを使うと小さなサーバーを簡単に立ち上げることができますので、それを使ってどんどん「やってみる」ことができます。失敗したらサーバーごとTerminate(廃棄)してしまえばいいのです。課金は時間単位なのでコストは最小限で済みます。このメリットはとても大きいです。ミドルウェアを試しに入れてみて、ダメだったら捨てる。これを繰り返してサービスに最適なソフトやモジュールを探していくことができます。

開発、テスト、本番機をコピーでつないでいく

開発をやっていて困るのは「細かい環境差異のせいで開発で動いていたものが本番で動かない」という現象。それを無くすためにクラウドではマシンイメージをコピーしていく方法があります。 開発をsmallで作り、マシンイメージをコピーしてmediumで立ち上げてテスト、OKであればlargeでコピーして本番に使用する。これで環境差異はなくなります。

ワンタイムトークンを活用する

AWSはユーザー毎に触れるサービスを限定することができます。また一時トークンというものを発行することもできますので、例えば社外の開発者と共に開発をしたり、開発者がプロジェクトから離れる、加わる等の流動があった際にはトークンの発行を止めるだけでその後の開発をセキュアに進めることができます。

サービスにタグ付けしてコスト管理をする

AWSはほとんどのサービスにタグを付けることができます。プロジェクト毎にタグ付けをして、CostExplorerというAWSサービス等を使うとどのプロジェクトにどれくらいコストがかかっているのかを簡単に管理することができます。

まとめ

以上、受託開発環境にAWSを使うメリットを列記致しました。プログラマーにとってインフラ構築、インフラ管理というのはハードルがなかなか高いものです。AWSを活用するとGUIやAPIを通して簡単に、そしてコストエフェクティブにインフラ環境を整えることができます。是非ご検討してみてください!

旅はまだ続く

AWS CloudRoadshowはこの後福岡、名古屋、大阪と続いていきます。AWSに興味はあるけどコストはどうなんだろう、本当に便利なのだろうか、と慎重になっている方は無料ですので是非会場に足を運んで頂ければと思います。

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.