インフラエンジニア不在でもリリース前に最低限構築しておきたいAWSインフラ構築術

2013年8月16日金曜日 cocomode18 1 コメント
今回はたとえインフラエンジニアが不在※でも、
  • スケーラブルで安心なインフラ環境構築術
を紹介したいと思います。
※インフラ経験者がいないと言う意味ではなく、インフラに時間かけてるリソースが全然ないよ!って意味です。
単純にAWSの構築例を示すだけではなく、その都度AWS特有の設定値の決め方だったり少々マニアック(?)な内容も書いています。なので、対象読者としてはAWS初心者〜中級者くらいの方まで価値のある情報になってると思っています。

ちなみに、ここで紹介する環境はAWS利用費として最低でも6〜7万円/月※ほどコストがかかってしまいますが、インフラエンジニアを雇う費用と比べたら安価だと思うのでそのくらいの費用はなんとかしましょう。※実際にはデータ転送量などもあって、リクエスト数などにも左右されるので、参考程度だと思って下さい。

余談ですが、弊社で先日リリースしたメンズ限定ブランド古着市アプリ「bolo(ボロ)」も現在はほとんどこれから紹介する環境で構築していますし、インフラ構築にかけた時間は大体3人日ほどです。(AWS初心者でも1週間ほどあればなんとかなると思います。)

本題に入ります。

先ほどスケーラブルで安心なインフラ環境と書きましたが、それを満たす条件として
  • SPOF(単一障害点)を作らない
  • 一般的なセキュリティ対策がされている
  • 最低限のサーバ監視を行い、トラブル時に即時アラートされる
  • アクセス増加時などに自由度高くスケールアップが可能
  • 今後インフラを強化したいときにも拡張しやすい
をクリアしてる環境を構築します。
インフラの全体像は下記のような構成になります。
①〜③が基本的なアプリを動かすサーバ達です。www.myapp.com(APIであればapi.myapp.comなど)でリクエストをELBが受け取って、アプリを動かすサーバに渡します。④の監視/Jobサーバでアプリを動かすの必要なcronを動かしたり、必要なコマンドjobを実装したり、アプリサーバの監視などを行います。⑤のコンテンツサーバはAmazonS3を利用して画像や動画を置いておきます。

①Web/APサーバ

まずは基本となるWeb/APサーバ(EC2)を1台構築します。AWSのコンソール画面(GUI)からEC2インスタンスを1台起動します。国内ユーザが多いのであればTokyoリージョンのインスタンスで良いでしょう。

  • AMIは好きなものでいいですが、CentOSの最新版であれば個人的にami-f6b436f7 (Right Image CentOS 6.4 x86-64)がオススメです。
  • Instance Typeはリリース前ならM1 Smallで十分だと思います。逆にmicroは後にEBSを追加出来ないのでオススメしません。
  • Security Group:Web/APサーバ用のグループを作っておきましょう。運用時にはロードバランサのみからリクエストを受け付けるようにしたいので、http(https)リクエストは80(443)ポートではなく任意のポート番号のみ受け付けるようにしておくと外部から直接サーバを叩かれるリスクが減るでしょう。

インスタンスを起動したら、DB以外のweb/アプリケーションサーバ、アプリを動かすのに必要なライブラリなどをインストール、設定していきましょう。先ほどSecurityGroupで80番ポートからのリクエストを受け付けないようにしていたら、webサーバでListenするポート番号を変えておくように注意しましょう。

設定がある程度出来上がってアプリが動かせたらAMIを作成して新たにもう1台EC2インスタンスを起動しておきます。次はロードバランサをいれていきましょう。

②ロードバランサ

ロードバランサでは、80番ポート(http)で受け取ったリクエストを先ほどのWeb/APサーバで決めた任意のポート番号に渡すように設定しておきましょう。httpsを使う場合は、Listenersで443ポートからのリクエストを受け付けるときにSSL証明書をアップロードする用指示されますので、ここにいれればOKです。そして構築したWeb/APサーバを追加しておきます。

ELBの設定のポイントですが、ヘルスチェックはhtmlファイルではなく、言語の動作チェックまでして欲しいので、PHPなら任意のphpファイルを作っておいた方が良いでしょう(適当なスクリプトが書いてあるファイルでOKです)。また各設定値は下記のようにしておくと、ヘルスチェックに失敗した場合は直ぐにそのサーバをリクエスト先から外してくれるので最小にしておくと良いと思います。











また、アプリでsessionを利用してる場合はPort ConfigurationのCookie Stickinessを有効にしておきましょう(ELBのDescriptionタブから設定できます)。

③DBサーバ

DBサーバはEC2で構築してもOKなのですが、DBサーバを構築する際に難しいのがデータのバックアップとスケール構成だと思います。AWSのRDSを利用してMulti-AZオプションを付けておくだけで、s3への自動バックアップと更に別ゾーンにホットスタンバイ状態でコピーを作ってくれます。AWSの中でもRDSは一番コストも高いですし、Multi−AZオプションをつけると更に倍のコストがかかるのですが、同じレベルのDBを運用することを考えると断然RDSがオススメです。

Multi−AZを付けておけば、DBインスタンスの変更時などもホットスタンバイ状態のDBに切り替えてからDBを更新してくれるのでダウンタイムもほとんどないです(実際計測した時は確か1〜2分ほどだったと思います)

RDS構築の際に、SecurityGroupでリクエストを受つけるサーバを指定できますが、ここで先ほどの構築したWeb/APサーバのSecurityGroupを追加しておけばそれ以外のサーバからはアクエスできなくなりますので便利です。まだ作成してないですが、④の監視/jobサーバのSecurityGroupもおいおい追加していきましょう。

InstanceTypeはもちろんリクエスト数によりますが、一旦db.m1.mediamインスタンスくらいにして1週間ほど運用してみてから必要なサイズにスケールダウン/アップすればいいと思います。DBのスケールアップ/ダウンには多少時間がかかるので初めは大きめがいいと思います。

④監視/jobサーバ

サーバ監視や、アプリに必要なcronjobなどを動かすためのサーバを別に1台用意しておくと利便性が向上すると思います。このサーバは特別必要なわけではないですが、例えばcronjobなどは①のWeb/APサーバで構築してしまうと、AMIでコピーして新たにサーバを追加した際など構築した台数分のcronが動いてしまいます(一度誤って無駄にcron叩いてしまったことがありました。。。)。サーバ監視に関しては監視ソフトを入れて本格的にリソース監視をしても良いですが、リソースがあまりないのであればAmazonCroudWatchで初めは十分だと思います(設定は後に説明します)が、今後監視ソフトを入れたくなった時にも使えるので。
更に、弊社では社内の人がアクセスする管理画面などは、分離してこのサーバで動かしたりしてます。とにかく、色々自由に使えるサーバが1台あると便利っすよって話です。

⑤コンテンツサーバ

コンテンツサーバとしてAmazonS3だけ使ってるって人も多いと思いますが、やはりあったほうがいいでしょう。ポイントとしては、Bucket名をドメイン形式(上記ならimg.myapp.com)にしておいて、bucket policyに下記を入れておくと、Route53でリクエストを簡単にs3に向けることができるようになります。

{
"Version": "2008-10-17",
"Statement": [
{
"Sid": "AddPerm",
"Effect": "Allow",
"Principal": {
"AWS": "*"
},
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::img.myapp.com/*"
}
]
}

もちろん、公開して良い画像のみをこのバケットにアップロードするようにしましょう。独自ドメインでアクセス出来るようにしておくと、後にCDNを作りたいなーって時でもアプリ側の参照先を変えないで比較的用意に導入できると思います(AmazonCloudFrontを利用する場合)。

また、アプリから画像のアップロードなど扱う場合はバケットの設定のLogginオプションを有効にしておくと、過去のバケットに対する操作ログが残りますので念のため有効にしておくと良いでしょう。

AmazonCloudWatchで監視

最後に今まで構築して来たサーバの監視・アラート設定をしていきたいですが、AmazonCloudWatchを使えば最低限の監視は容易にできるようになります。詳細のリソース監視をするには結局監視ソフトを導入する必要がありますが、アラート設定など面倒な作業を省いて簡単にできるのでこのくらいはリリース前にできる範囲です。必要な分だけアラートを作ればいいと思いますが、基本的にはこの辺を僕は見ています(もちろん運用するアプリによってまちまちなので基本的な部分って思って下さい)。
  • ELB(UnHealthyHostCount)
  • EC2(CPUUtilization、NetworkIn)
  • RDS(CPUUtilization、DatabaseConnections、ReadThroughput、ReadLatency、FreeStorageSpace)

最後に

以上で基本的なリリース前に欲しい環境がひと通りできると思います。
記事が長くなりすぎてしまうので、もろもろ省いてしまったところもありますが、何か質問・意見などあればどしどしコメントでもメールでも下さい。

1 コメント:

吉田直人 さんのコメント...

読みました。知識不足&理解力不足により、本音を申し上げますとぜんぜん理解できていません!苦笑 ですが、今後ともブログ更新楽しみにしております!!

コメントを投稿