LoginSignup
9
7

More than 5 years have passed since last update.

AutoScalingのかわりにマイルドスケーリング(仮称)を作ってみた

Posted at

はじめに

案件でサーバのスケールを行なうことになったのですが、AutoScalingだとどうも合わないところがあり
自分達でスケールする仕組み、マイルドスケーリング(仮称)を作成しました。

AutoScalingについて

AWSの提供する機能でEC2インスタンスをスケジュールや負荷に応じて増減させる仕組みです。

対象システムについて

今回対象となるシステムは以下の特徴がありました

  • 別会社作成の既にEC2で動いているWebアプリケーション
  • コンテンツはCMSサーバよりWebサーバに定期的に配信
  • WebアプリケーションはRDSにアクセスして情報を取得
  • 監視サーバとしてnagiosを利用
  • Webサーバのホスト名を元に接続するRDSを決定
  • しばらく運用してみて、負荷のあがるタイミングと上限がわかっている

AutoScalingをつかわなかった理由

AutoScalingを検討したのですが、以下の理由で使いませんでした。

ターミネート

  • インスタンスIDが変わってしまうためnagiosの設定毎回変える必要があります
  • コンテンツ同期はホスト名をベースにrsyncしているので同期方法を考えないといけません

RDSはAutoScalingの対象外

リードレプリカ、および、EC2からの接続設定は自分で作成する必要があります

マイルドスケーリングの方針

というわけで自前でスケーリングの仕組みをつくることにしました。何度かイベント対応を手動でおこなっていたので自動化については以下の方針としました。

  • EC2は起動/停止とELBの追加/削除とします。(誤ってヘルスチェックに失敗する事態でもサーバが消えないのがマイルドの命名理由です)
  • Nagiosの設定も起動/停止に連動させます。
  • RDSはリードレプリカの追加と削除をスクリプト化します。
  • サーバの台数をふやしたいときはスクリプト修正もしかたなしとします。
  • 負荷追従については作成しません。(事前にわかっているイベント時に追加、もしくは手動で追加のためです)

つくってみた

以下、作成した際のポイントとなります。

EC2

EC2のNameタグにweb1,web2...webxという設定をします。

で、起動スクリプト中に3台起動のときは、こんな感じで起動します

instances_tag="www1 www2 www3"

aws ec2 describe-instances --output text --query 'Reservations[].Instances[].InstanceId' --filter Name=tag:Name,Values=${instance_tag}

Nagios

cfg_dirオプションをつかいます。以下のような設定をnagios.cfgに追加します。

nagios.cfg
cfg_dir=/etc/nagios/event_dir

設定ディレクトリ内では

www1.cfg_
www2.cfg_
...
www6.cfg_

というファイルを用意し、起動したインスタンスについては

ln -s www1.cfg_ www1.cfg

と変更し、nagios再起動を再起動するとwww1が監視対象になります。
EC2は起動/停止のみなのでIPアドレスに変更はなく設定ファイル名のみの変更で監視対象のon/offができます。

RDSリードレプリカ

リードレプリカは1度に1つしかつくれません。また、作成するとしばらく、snapshotをとるため、しばらく次のインスタンスはつくれません。
このため、スクリプトでwait処理を入れることにして1つずつ作成しています。

リエントラント(再入可能)であること

実行完了に20分くらいかかるため、運用上の理由で中断したりすることがありました。このため、スクリプトは再度実行しても問題ないようにしました。EC2とnagios設定については、特にそのままで問題ありませんが、RDSのリードレプリカについては、起動/停止前にかならずステータスチェックをするコードをいれて、既に起動/停止されている場合は処理をスキップする処理をいれました。

動かしてみた結果

コストはAutoScalingとほぼかわらず

ただし、停止時はEBSのディスク費用がかかります。1GB一ヶ月$0.1程度です。

サーバが消えない安心感はおおきい

関係者が多いため間違ってELBのヘルスチェックに失敗するような状態になったとしてもサーバがきえないのは嬉しいです。AutoScalingでもELBのヘルスチェックに失敗した場合はDetach、もしくはStandbyになってくれるといいのですが。

サーバ台数がだんだん増えてきて、設定変更が面倒になっている。

だんだん機能がふえてきて台数が増えてくると設定変更の作業が大変になってきています。やはり理想としてはAutoScalingがつかえるような状態にするのがよいとおもいます。

まとめ

自身でスケーリングを作る際のポイントについてまとめてみました。機能をわりきることで、意外と簡単に作れるのでオススメです。

9
7
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
9
7