コミュニケーションメディア事業部リードエンジニアのid:eva-hashimotoです。 今回はSpeeeKaigiで発表した開発しているVICOLLEのIDCフロンティアでオートスケールを導入した話をします。
SpeeeKaigiについてはこちら tech.speee.jp
発表時のスライドはこちら
スライドで発表した内容をつまみ食いしながら説明します。
IDCフロンティアのクラウド環境
IDCFのクラウド基盤としてCloudStackで構築されているため、CloudStack-APIを利用しCLIでインフラ操作が利用できます。 ただし公式のAPIドキュメントではなくIDCF ドキュメントを参照しましょう! 公式ではありとあらゆるインフラ、ミドルウェア操作が記載されていますがIDCF側で対応していないものもあるのです。
ステートレスにする
オートスケールで重要な点として対象のサーバはステートレスでなければなりません。 この点はAWSでも同じですね! 具体的にステートレスとはプログラムの状態やデータを保持しないシステムです。つまりセッション情報やミドルウェアの設定なんかも保持しないデータにあたります。
今回のオートスケール対象はアプリケーションサーバなので下記のミドルウェアが対象です。
- Nginx
- Ruby on Rails(Puma)
オートスケールの流れ
- テンプレートから新規インスタンスを作成、起動
- nginxの設定、アプリのデプロイ
- バランサーにアサイン
テンプレート作成
テンプレートというのはAWSでいうとAMIのことです。作る上で先ほどのステートレスにするということが大前提になり、Railsについてのステートレス方法は他でググってください。 その他の設定としてはOSのパラメータチューニングを行っています。ネットワーク周りやファイルディスクリプタの閾値変更など行っておくといいと思います。
インスタンス作成
オートスケールが作動するトリガーとしてサーバ負荷やコネクション数などあると思います。 今回のサービスではサーバの負荷をトリガーとして説明します。
このような負荷の取得スクリプト(bash)を定期的に叩いてます。
CPU_LIMIT=50 APP_CPU=`sudo ssh {サーバのIP} "mpstat 2 1" | grep 平均値 |awk {'print 100-$12'} |cut -d. -f1 if test $APP_CPU -ge $CPU_LIMIT; then echo app autoscale!! {Jenkins-APIの新規インスタンス構築タスクを叩く} fi
Jenkinsの新規構築タスクはCloudStackのAPIでテンプレートからインスタンスの作成を叩いてます。
ID=`cloudstack-api deployVirtualMachine \ --serviceofferingid ${インスタンスサイズID} \ --templateid ${テンプレートID} \ --zoneid ${ゾーンID} \ --group ${グループ名} \ --name "${インスタンス名}" \ | grep '"id":' | awk -F: {'print $2'}| awk -F\" {'print $2'}`
作成されたインスタンスIDが返却されるので変数で持ち、のちにバランサーのアサイン時のパラメータとして使ってます。
デプロイ
OS起動時にCapistranoを自動起動させています。[/etc/systemd/system/puma.service]
[Unit] Description=puma server After=nginx.service [Service] Type=oneshot ExecStart={Capistranoのコマンド} User=deploy [Install] WantedBy=multi-user.target
nginxの設定に関してはNFSで共有したり、githubで管理されてたりすると思いますので各々に管理されてる方法に合わせて設定ファイルを読み込みましょう。
nginxの設定変更、railsの起動ができたのちにバランサーアサインのAPIを叩いてオートスケール終了になります。
まとめ
IDCフロンティアでもちょっとした手間が必要ですがオートスケールの仕組みを作ることができます。 AWSではauto scaling groupなどで多少楽にできますが自作することでより細かい動作や自由度の高さはメリットではないでしょうか? 現在の仕組みでトリガー作動からバランサーアサインまでの時間が平均で3分くらいになります。 その他詳しい仕組みについてはご連絡いただければと思います。