2014年2月4日 第4回 OSS運用管理勉強会での発表資料です。 http://www.oss-kanri.org/20140204_vol04/ RubyとZabbixを使ってHeroku(PaaS)をオートスケールするBounscaleというサービスの機能・内部構成・技術ノウハウなど。

1. （株）DTS
大西正太

3. About this talk
 DTSにて取り組んでいるBounscaleに
ついてご紹介します
 Zabbixを利用して動いているサービス
です

5. Me
 大西正太
 (株)DTS
 保有資格
 ビアテイスター
 オイスターマイスター

6. Ruby(Rails) Programmer / Architect / PM
2005～

7. 発表・記事など

9. Bounscaleとは




Webアプリの負荷が高まったら、
自動的に計算能力を高めて、
サービスのレスポンス低下を抑止する、
Heroku(PaaS)上のアドオンです

10. Bounscale利用の何がいいのか
従来のリソース管理
Bounscale導入後
 オペレータの人件費発生
 自動化による人件費削減
 不十分なレスポンス改善
 レスポンスの即時改善
オペレータ
手
監視ツール 作
業
Webシステム
インターネット
スパイクトラフィック
Bounscale
自
動
Webシステム
インターネット
スパイクトラフィック

11. オートスケールの設定をすると

12. サービスのレスポンスを維持してくれる
 緑のグラフがレスポンスタイム
 青い点が計算能力 (Dyno)

14. HerokuはPaaSの一種
PaaSはクラウドの一種

15. PaaSの範囲
SaaS(App)
Software as a service
PaaS(ミドル/
言語/フレームワーク)
Platform as a service
IaaS(HW/OS)
Infrastructure as a service

16. PaaS Players

17. PaaSを使うと
 開発時
 サーバ構築省略
 プログラムを書いて
 アップロードすれば
 ブラウザから利用できる
 運用時
アプリ
engineer
インフラ
engineer
PaaS
App
 インフラ保守の省略化
App
 プロセス監視省略
 フェイルオーバー省略
 セキュリティパッチ省略
 性能が落ちてきたらワンクリックでリソース追加
 Bounscaleを使うとワンクリックも不要

19. Herokuの特徴
 Salesforce社が買収(2011)
 RubyのPaaSとしてスタート
 今はマルチ言語対応(Java,Scala,node・・・)
 Rubyの生みの親、まつもと氏やRubyVM開発者の
ささだ氏が在籍
 300万以上のサービス
 最小プランは無料

20. Heroku add-ons
 ワンクリックでアプリに機能追加できる機構
 サーバ版のAppStoreのイメージ
 Heroku社～サービサ～アドオンのエコシステム
 Herokuが課金を実施しレベニューシェア
 現在100前後のアドオンが公開されている
 Bounscaleはこのアドオンとして公開している

21. Heroku add-onsのイメージ
①カタログトップ
②Bounscaleトップ
→適用App選択
③Appトップ
→Bounscaleアイコン
クリック
④Bounscale画面

23. 詳細なアーキテクチャ

24. 大体こんな感じ
アプリ
アプリ
利用
User
リリース
スケールイン・アウト
リソース
情報出力
zbxapi
gem
History
ログ参照
WebAPI
スケール
WebAPI
リソース
情報取得
設定
Item,Action,
Trigger設定
History取得
ZabbixAPI
開発者
Bounscale
Agent
gem
+
カスタム
Item
カスタム
Action
Trigger

25. カスタムItemの実現方法
 Zabbixのagent拡張機構を利用
 Itemの種類を独自に増やすことができる
# zabbix-agentd.conf
UserParameter=heroku.resource.cpu[*],
ruby /xxx/heroku_status_get.rb cpu $1 $2 $3 $4
・heroku.resource.cpuをキーとしたItemを作成可能になる
・このItemは指定のコマンド（今回はRubyスクリプト）実行の
標準出力をHistoryの値として記録する

26. カスタムItemで取得するリソース
 アプリレイヤから取得した結果を出力しているため低
～高レイヤな情報を取得可能
 CPU時間
 メモリ
 スループット
 1分辺りのリクエスト数
 ビジー率
 直近10秒のうちリクエスト処理している時間の割合
 レスポンスタイム
 Herokuは仮想化(AWS)＋コンテナ化(LXC)されてい
るので低レイヤな情報はあまりあてにならない
 レスポンスタイム＋ビジー率の利用を推奨

27. カスタムActionの実現方法
 普通にZabbixのActionからcommand実行
 TriggerがアラートをあげたらAction実行して
いるだけ
 特にトリッキーなことはしていません
 スケールアウトしたらアラートをacknowledgeし
て対応済みとして取り扱うようにしている
 acknowledgeのコメント欄にスケール数などの詳細
情報を記録。Webコンソールの履歴表示に情報を
活用したりしている。

29. Zabbix使ってよかったところ
 とにかく安定している
 ZabbixServerもAgentも全然落ちない
 メモリが増えていく事もない
 古いデータが増加し続けることもない
 黙々と作業を続けてくれる

30. 大変だったこと(1)zbxapiが微妙
 ZabbixAPIのRubyラッパー
 対応バージョンが古い(Zabbix1.8?)
 旧Verになかったオブジェクトは自分で定義したり
 HostInterface等。一応DSLチックに追加できる。
 旧Ver向けのバリデーションを無効化したり
 名前空間が分割されていない
 グローバルにItem/Actionクラスが定義されて衝突
 エラーメッセージがいい加減でほとんどの場合
APIのPHPソースを読む事になる

/frontends/php/api/**/*.php
 最近github上でメンテされてて直ってるかも？
 https://github.com/red-tux/zbxapi/commits/master

31. 大変だったこと(2)Trend APIがない
 History:全Item値履歴 / Trend:丸めたもの
 Historyがあるんだから、Trend APIは必要な
いとフォーラムに書いてある・・・
 Historyはデータが多いので性能対策必要
 バッチでRuby側のDBにデータを転送・保持
 Zabbix側のHistoryは24時間で自動削除設定
 ただし結果的に全体の性能に適したアーキテ
クチャになったとも考えられる
 ZabbixのMySQLはスキーマが1つしかない
 Ruby側は各利用者ごとにスキーマを分けている

32. 大変だったこと(3)APIの性能
 Item/Action/Triggerの操作などに1秒前後
 何度か呼び出すとオンラインでは耐えられない
 AP側からの呼び出しを最小限に抑えるために
独自にzbxapiを拡張しキャッシングを実装
 リクエストJSONをハッシュ化したものをキー、レスポ
ンスをバリューにしてKVS的なDBに保持・取得

http://qiita.com/bounscale/items/ffb7d8eba3833f1e3cf6
 ZabbixAPIのPHPにアクセラレータAPCを適用
 ロードアベレージが8.8→3.4に改善

http://qiita.com/bounscale/items/4cc65e628e54c06a60f3

34. ワールドワイド
 世界中のサービスで利用されている
 アメリカ、カナダ・・・
 イギリス、フランス、スペイン・・・
 日本、台湾、インド・・・
 オーストラリア、グルジア・・・

35. ご静聴ありがとうございました
Bounscale使ってみてください！！
$ heroku addons:add bounscale
https://devcenter.heroku.com/articles/bounscale * マニュアル