(株)dts 大西正太 · バッチでruby側のdbにデータを転送・保持...

Post on 29-May-2020

0 Views

Category:

Documents

0 Downloads

Preview:

Click to see full reader

TRANSCRIPT

(株)DTS 大西正太

About this talk

DTSにて取り組んでいるBounscaleについてご紹介します

Zabbixを利用して動いているサービスです

Me

大西正太

(株)DTS

保有資格

ビアテイスター

オイスターマイスター

Ruby(Rails) Programmer / Architect / PM

2005~

発表・記事など

Bounscaleとは

Webアプリの負荷が高まったら、

自動的に計算能力を高めて、

サービスのレスポンス低下を抑止する、

Heroku(PaaS)上のアドオンです

Bounscale利用の何がいいのか

オペレータの人件費発生

不十分なレスポンス改善

従来のリソース管理 Bounscale導入後

Webシステム インターネット

スパイクトラフィック

監視ツール

オペレータ 手作業

自動化による人件費削減

レスポンスの即時改善

Webシステム インターネット

スパイクトラフィック

Bounscale

自動

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

サービスのレスポンスを維持してくれる

緑のグラフがレスポンスタイム

青い点が計算能力 (Dyno)

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

PaaSの範囲

IaaS(HW/OS) Infrastructure as a service

PaaS(ミドル/ 言語/フレームワーク) Platform as a service

SaaS(App) Software as a service

PaaS Players

PaaSを使うと

開発時 サーバ構築省略 プログラムを書いて

アップロードすれば

ブラウザから利用できる

運用時 インフラ保守の省略化 プロセス監視省略

フェイルオーバー省略

セキュリティパッチ省略

性能が落ちてきたらワンクリックでリソース追加 Bounscaleを使うとワンクリックも不要

アプリ engineer

PaaS App

インフラengineer

App

Herokuの特徴

Salesforce社が買収(2011)

RubyのPaaSとしてスタート

今はマルチ言語対応(Java,Scala,node・・・)

Rubyの生みの親、まつもと氏やRubyVM開発者のささだ氏が在籍

300万以上のサービス

最小プランは無料

Heroku add-ons

ワンクリックでアプリに機能追加できる機構

サーバ版のAppStoreのイメージ

Heroku社~サービサ~アドオンのエコシステム

Herokuが課金を実施しレベニューシェア

現在100前後のアドオンが公開されている

Bounscaleはこのアドオンとして公開している

Heroku add-onsのイメージ

①カタログトップ

②Bounscaleトップ →適用App選択

③Appトップ →Bounscaleアイコン クリック

④Bounscale画面

詳細なアーキテクチャ

大体こんな感じ

Zabbix

API カスタム

Item カスタム Action

Trigger

アプリ アプリ Bounscale

Agent gem

ログ参照WebAPI

スケールWebAPI

zbxapi

gem

History

リソース 情報出力

スケールイン・アウト +

User

開発者 設定

リリース

利用

Item,Action,Trigger設定

History取得

リソース 情報取得

カスタム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の値として記録する

カスタムItemで取得するリソース

アプリレイヤから取得した結果を出力しているため低~高レイヤな情報を取得可能 CPU時間

メモリ

スループット 1分辺りのリクエスト数

ビジー率 直近10秒のうちリクエスト処理している時間の割合

レスポンスタイム

Herokuは仮想化(AWS)+コンテナ化(LXC)されているので低レイヤな情報はあまりあてにならない レスポンスタイム+ビジー率の利用を推奨

カスタムActionの実現方法

普通にZabbixのActionからcommand実行

TriggerがアラートをあげたらAction実行しているだけ

特にトリッキーなことはしていません

スケールアウトしたらアラートをacknowledgeして対応済みとして取り扱うようにしている

acknowledgeのコメント欄にスケール数などの詳細情報を記録。Webコンソールの履歴表示に情報を活用したりしている。

Zabbix使ってよかったところ

とにかく安定している

ZabbixServerもAgentも全然落ちない

メモリが増えていく事もない

古いデータが増加し続けることもない

黙々と作業を続けてくれる

大変だったこと(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

大変だったこと(2)Trend APIがない

History:全Item値履歴 / Trend:丸めたもの

Historyがあるんだから、Trend APIは必要ないとフォーラムに書いてある・・・

Historyはデータが多いので性能対策必要

バッチでRuby側のDBにデータを転送・保持

Zabbix側のHistoryは24時間で自動削除設定

ただし結果的に全体の性能に適したアーキテクチャになったとも考えられる

ZabbixのMySQLはスキーマが1つしかない

Ruby側は各利用者ごとにスキーマを分けている

大変だったこと(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

ワールドワイド

世界中のサービスで利用されている

アメリカ、カナダ・・・

イギリス、フランス、スペイン・・・

日本、台湾、インド・・・

オーストラリア、グルジア・・・

ご静聴ありがとうございました

Bounscale使ってみてください!!

$ heroku addons:add bounscale https://devcenter.heroku.com/articles/bounscale * マニュアル

top related