Call of Venture ベンチャーの呼び声

スタートアップ企業で働く1人の若者。テック系スタートアップブログ。

トップ > 【AWS】CodeDeployとAutoScaringを使った並列化の全手順まとめ。

【AWS】CodeDeployとAutoScaringを使った並列化の全手順まとめ。

AWSでサーバーの並列化を行いました。

デプロイにはCodeDeployを利用しました。

 

使用したAWSサービスを列挙すると

  • CodeDeploy
  • AutoScaling
  • EC2
  • RDS
  • ELB
  • VPC
  • IAM

などです。VPCなどは使うに決まってるし、AutoScaringは独立したサービスではないのですが、一応記載しました。

 

この記事を読む方に先に伝えておきたいのは、サーバーのどのステータスに応じてスケーリングしたいのかによって、使うべきサービスは変わるということです。

CodeDeployを使用した並列化では、CloudWatchのアラームによってスケーリングが起こります。

よって、CloudWatchでとれないデータ（メモリ使用率、LoadAverate）ではスケーリング出来ません。（カスタムメトリクスでできるらしいです）

OpsWorksはメモリ使用率やLAに応じてスケールできるらしいです。

 

作業の流れ

 VPCから全て作りなおし、完成後にサービスをそちらに移行します。

構成

CloudFlare（AWS外部のCDNサービス）

↓

ELB

↓

並列化EC2インスタンス（AutoScaringGroup）

↓

RDS

 

CloudFlareは、画像をキャッシングしてくれる無料で使えるCDNです。

「CloudFlare S3」などで調べると幸せになれるかもしれません。

Route53は使用しません。

 

全手順

作業中に時折振り返って作成したものです。誤りがあったらご指摘下さい。

 

準備するもの

VPC

最初に作る。後に作るものはすべてこのVPC内に作る。

CIDR例 10.0.0.0/16

 

インターネットゲートウェイ

作る。

 

ルートテーブル

先ほど作ったインターネットゲートウェイを0.0.0.0/0へ追加

 

サブネット2つ
subnet1のCIDR 10.0.0.0/24

subnet2のCIDR 10.0.1.0/24

ELB作成時に2つ必要。使うのは1つでも構わないので、不要ならELB作成後一つ外す。
先ほど作ったルートテーブルを関連付ける。
Public IPの自動付与はONにします。

 

セキュリティグループ

A: ELBのセキュリティグループ（80を全て許可）
B: EC2ステップサーバー（アプリケーション・サーバーの管理用サーバー）のセキュリティグループ（22を全て許可）
C: アプリケーション・サーバーのセキュリティグループ（Aからの80、Bからの22を許可。）

D: DBサブネットグループ
- RDSを使う場合、VPC内にDBを立てる段階で求められるので指示に従って作成。

 

AMI
起動時にサービスが立ち上がる状態にしておく。（chkconfigなどの設定）

CodeDeployAgentをインストールしておく
$ sudo yum install ruby
$ sudo yum install aws-cli
$ cd /home/ec2-user
$ aws s3 cp s3://aws-codedeploy-ap-northeast-1/latest/install . --region ap-northeast-1
$ chmod +x ./install
$ sudo ./install auto
$ sudo chkconfig codedeploy-agent on
$ sudo rm -rf install

上手くインストール出来ない場合は、本家ドキュメントを参照。

docs.aws.amazon.com

 

 

ELB

作成します。80を80にルーティング。

ヘルスチェックの設定を確認しておく。今回はhttpで80番にヘルスチェックするようにしました。

Auto Scaring
- 起動設定の作成
- Auto Scaring Groupの作成

- 先ほど作成したELBをアタッチします。

- ヘルスチェック方法をELBに変更します。

 

Code Deploy

参考URL :
- http://aws.amazon.com/jp/codedeploy/getting-started/

デモは動く環境として立てておくとデバッグに使用できます。

 

必要なもの
▼ デプロイ先のリソースを操作する権限のあるロール
- ロール作成後、インラインポリシーを追加

{"Statement":[{"Resource":["*"],"Action":["ec2:Describe*"],"Effect":"Allow"},{"Resource":["*"],"Action":["autoscaling:CompleteLifecycleAction","autoscaling:DeleteLifecycleHook","autoscaling:DescribeLifecycleHooks","autoscaling:DescribeAutoScalingGroups","autoscaling:PutLifecycleHook","autoscaling:RecordLifecycleActionHeartbeat"],"Effect":"Allow"},{"Resource":["*"],"Action":["Tag:getResources","Tag:getTags","Tag:getTagsForResource","Tag:getTagsForResourceList"],"Effect":"Allow"}]}

- ロール作成後、信頼性関係の編集

{"Version": "2008-10-17","Statement": [{"Sid": "1","Effect": "Allow","Principal": {"Service": "codedeploy.amazonaws.com"},"Action": "sts:AssumeRole"}]}

▼ appspecファイル

- ソースコードのルートに作成
- 各デプロイイベントに対応するスクリプトを任意の場所に作成
- デプロイイベントスクリプトを記載
- デプロイ後、tmpファイルのpermissionを変更


CodeDeploy めっちゃ詰まったところ

列挙します。

▼ appspecに記入された、スクリプトファイルが実行できないエラー

- CodeDeployコンソールの「デプロイ」→当該デプロイの詳細をオープン→「すべてのインスタンスを表示」→失敗したインスタンスの「イベントの表示」→失敗した箇所の「ログを表示する」からエラーログが確認できます。
- [stderr]sudo: sorry, you must have a tty to run sudo.
- 端末からじゃないとsudoできないよエラー
- /etc/sudoersの `Defaults requiretty`をコメントアウト。
- /etc/sudoersのパーミッションはデフォルトでは440なので、chmodで640にして編集し、終わったら440に戻す。
- codedeploy-agentが正しく動かない状態だと、codedeployコンソールにエラーが出ず、なにで失敗しているのか分からない。

▼ プロジェクトファイル内でコマンド(bundle, rakeなど)を実行できない。
- bundle: command not found エラー
- コマンドをフルパスで設定すると良い。
- whereis bundleで出てきたパスで実行。

▼ afterinstallイベント時に、パーミッションを指定しているのにデプロイされたコードではされていない。
- chmod時点では、対象が存在しなかった。
- リビジョンに含まれておらず、サーバー起動後にRailsによって自動生成されているものだった。
- 解決: afterinstall段階でmkdirし、その後パーミッションを変更する。