自前でcloud foundryを構築してgooのビッグサービスをカットオーバーした話

Copyright:(C) 2017 NTT Resonant Inc. All Rights Reserved.
自前でCloudFoundryを構築してgooの
ビッグサービスをカットオーバーした話
NTTレゾナント株式会社
ビジネスプラットフォーム事業部サービス基盤部門
2017/8/10

Copyright:(C) 2013 NTT Resonant Inc. All Rights Reserved.Copyright:(C) 2013 NTT Resonant Inc. All Rights Reserved.Copyright:(C) 2017 NTT Resonant Inc. All Rights Reserved.
アジェンダ
1. CloudFoundryについて
2. CloudFoundryに既存サービスを載せ替えた
3. CloudFoundryの監視をどうやったか
4. まとめ
2

NTTレゾナントの事業
個人のお客様
法人のお客様
ポータルサイト等
スマホアプリ
goo milk feeder goo防災アプリ
スマホアプリ試験環境災害時安否情報まとめて検索ヘルスケア
Webサイト開発・運営他
3

登壇者
大木和也通山和裕
4
NTTレゾナント株式会社
ビジネスプラットフォーム事業部サービス基盤部門
社内のアプリ開発者にプライベートクラウドを提供する部門
• 社内基盤の運用企画、統制など
• 監視基盤の設計、実装、運用
• 前職：OCN ISP NW開発
• 育児クエスト中(0歳児)
• 社内基盤の運用企画
• 前職：ログ検索ソリューション
• 前々職：グループ内NW開発
• 最近はドラクエ11
社内のアプリ開発者にプライベートクラウドを提供する部門

登壇者の立場
5
サービス担当サービス担当
NTTレゾナント
over 100サービス
社内基盤提供
5
サービス担当
(アプリ開発)
…
ビジネスプラットフォーム事業部
サービス基盤部門
プライベートIaaS, PaaSなど
アプリ開発に必要なしくみを
社内向けに提供する部隊

CloudFoundryについて
6

PaaS導入の経緯
物理マシン
IaaS
PaaS
2017年
CloudFoundry導入
2014年
OpenStack導入
それ以前
暗黒の物理マシン時代
• 故障したら勝手に復旧
• 脆弱性の対応しなくていい
• ワンポチでスケール
• 監視が楽
• ワンポチでリリース
• とにかくしんどい
• 物理マシン故障めんどい
• 脆弱性の対応めんどい
• スケール・サイジングめんどい
• 監視めんどい
• リリースめんどい
インフラ管理がとにかくめんどい
アプリ開発者をインフラ管理から解放
より開発に専念できる環境を作りたい
7

CloudFoundryについて
他社の導入状況
エヌ・ティ・ティ・コミュニケーションズ株式会社：Enterprise Cloudに導入
「Cloud Foundry Certified プロバイダ」認定
ヤフー株式会社：プライベートPaaSにCloudFoundryを採用
楽天株式会社：プライベートPaaSとしてCloudFoundryを利用中
コードを
deploy(push)
言語・プラット
フォームを検知
対応するアプリコ
ンテナを自動構築
実行環境一式
(コンテナ)が完成
アプリを搭載した
コンテナを実行
軽量なコンテナなので
スケールアウトも
容易かつ高速
Ruby?
Rails? Sinatora?
※slideshare https://www.slideshare.net/jacopen/paas-for-beginners より転載・改変
アプリケーションコードをdeployするだけで、Webサービスが稼働する環境を提供（PaaS）
8

CloudFoundry本体および稼働するアプリの構成
※模式図のため一部正確ではありません
URL
VM
App App
VM
App
VM
App
…
…
Scale out
Scale out
L7LB
URL http://hoge.goo.ne.jp
BOSH
CF API
API
VM, Process info
URLマッピング
App稼働状況
The internet
ソース
コード
CloudFoundryの各種コンポー
ネントを生成、監視、オートリ
ザレクションまでカバーするす
ごいやつ
CloudFoundryに収容されるア
プリケーションへのAPI経由で
のL7ルーティング制御、コンテ
ナの死活監視
までカバーするすごいやつ
アプリケーションはコンテナとして
IaaSのVM上に配置される
♥ ♥
etc.
Microsoft Azure等でも稼働します
9

CloudFoundryに既存サービスを載せ替えた
10

ターゲット
いまトピ
• すごい好奇心のサイト
• https://ima.goo.ne.jp
でかいサービスをCloudFoundry上でリリースしようぜ！
• レゾナントはいいものはボトムアップで声を上げていく文化
• gooビッグサービスをCloudFoundry上でリリースすれば、他のサービスも興味を持つ
• 話に行ったら担当エンジニアのノリがよかった
2017年7月24日にカットオーバー。現在もCloudFoundry上で稼働中。
いますぐアクセス！
11

なにをすればいいのか
既存アプリをCloudFoundryに載せかえたことは社内では前例がない
• 大体の人は「CloudFoundryってなに？」
• CloudFoundry上で既存のアプリを動作させるには、
CloudFoundryの作法に則ったコーディングが必要（≒12Factor）
• ログの調査やデバッグの手法が従来と違う例)sshログインしてデバックができない
• アプリに負荷をかけた際にどこがボトルネックになるか知見がない
なにをすればいいのか？！
12

やることは一杯ある（ような気がする）
12Factorに従
え！
監視ってどうする
の？！
ミドルウェアの脆
弱性対応は？
Apacheの自社モ
ジュールってどう
つかう？
誰に説明すればい
いのか！
ログは？！
静的ファイル
は？！
リリース判断
は！？
負荷試験は？！
13

みんなでやることにした
基盤担当者とアプリ開発者がお互いの情報や課題を共有する体制を構築
• 基盤担当者はアプリの構造を理解し、実装の提案や負荷試験をサポート
• 開発担当者はCloudFoundryの性質を理解し、実装方針や開発フローを改革
やることが自ずと見えてきた！
関係する部門の担当者を巻き込み、
CloudFoundryを理解し・推進していく仲間を増やす
ことが重要！ 14

やることが具体化した
Apacheの独自モジュールってどう使う？
アプリのログってどうやってとるの？
このWebフレームワーク使いたい
ミドルウェアの脆弱性対応ってどうするの？
15

アプリデプロイのキモ、buildpack
CloudFoundryではbuildpackが採用されている
• buildpack
– Herokuが開発したしくみ
– プログラミング言語を自動判別し、アプリの稼働環境を構築する土台
– 各言語に対応したbuildpackが存在する
• php_buildpack
• ruby_buildpack
• java_buildpack
• go_buildpack
• python_buildpack
• nodejs_buildpack
• dotnet-core_buildpack
• staticfile_buildpack
• binary_buildpack
16

buildpackの仕組み
渡された必要なミドルウェアの資材ソースコードを組み合わせ、
コンテナ上で実行可能なバイナリ一式を作成する
php7.x
httpd
php 5.x
モジュール類
nginx
php buildpack
合体
実行用バイナリ一式
（Dropletと呼ばれる）
ソース
コード
アプリ
push
VM
バイ
ナリ
コンテナ
バイ
ナリ
コンテナ
VM
バイ
ナリ
コンテナ
ソース
コード
17

buildpackでインフラ管理から解放できる
1. buildpackに含まれるミドルウェアの脆弱性対応
2. 自社モジュールの追加対応
3. 他、アプリ開発者が要求する改造
buildpackはミドルウェアの集合体
基盤担当者がbuildpackの管理を行えば、
アプリ開発者をインフラ管理から解放できる！
必要なこと
基盤担当者が
buildpackの管理・統制を行うことに、価値がある。
18

php-buildpackをいじったら想像以上に大変だった
モジュールのバージョンとmd5値がコードにべた書きされてる！！！
怒涛のcpとsed
言語色々使いすぎです
19

php-buildpackを運用する
運用には、
正確かつ迅速にbuildpackを提供できるしくみが必要
モジュールを追加するだけでも
Linuxに詳しいエンジニアが数日がかりで対応…
buildpackの作成・テストを自動化したい！
20

Concourseを使ってみた
CI/CDをPipelineで視覚化・自動化できる素敵ツール。素敵。
生成したbuildpack
を適用&テスト
結果をslackに通知
• buildpackをいじって運用するなら自動化はほぼ必須
• 新しいアップデートがでたら自動的に回るようにしたい（野望）
Pullリクを検知
資材を取得
21

CloudFoundryの監視をどうやったか
22

CloudFoundryの監視
1. CloudFoundry上のアプリの監視を社内に提供する
– アプリ開発者が監視を実装する手間を省く
2. CloudFoundry本体の監視も実現する
– 運用する以上は必要
どう実現したか？
23

Zabbixを使うのをやめた

前提
26
※模式図のため一部正確ではありません
URL
VM
App App
VM
App
VM
App
…
…
Scale out
Scale out
L7LB
BOSH
CF API
VM,プロセス管理
Monitoringsystem
• CloudFoundry(Community版)に、本格的な監視システムは付属しない
– 自前で構築する必要がある
The internet

よくあるPaaS上のアプリ監視
27
例) Heroku: NewRelic Add-on
• サービスレベルの監視がメイン
– URL単位の死活、応答遅延状況
– HTTP応答時間、アクセス数、HTTPレスポンスコード統計
– アプリコンテナ単位の障害は、PaaS側が勝手に復旧する

CloudFoundryでアプリ監視をどう実現するか？
※模式図のため正確ではありません
URL
VM
App App
VM
App
VM
App … Scale out
L7LB
URL増減、
マッピング変更
は日常動作
firehose
CF API
App稼働状況
HTTPレスポンスログ
Monitoringsystem
Appは
高頻度に増減
JSON
Log
Stream
• CF API, firehose から必要な情報が取得できる
– firehose：CF内のログをpub/subモデルで出力するCFのしくみ
• URL単位のHTTPレスポンス数、応答時間…
– CF API
• Appごとのコンテナ数、URLの内訳、コンテナのリソース状況…
ZabbixでJSON,ログを解析して構成変更に追従するのはしんどい
28

CloudFoundry本体の監視
29
• BOSHにCloudFoundryを自動復旧する機能がある
– なら、監視しなくてよい？ ⇒No!
– BOSHは構成VM ＆構成プロセス死活の監視が本職
CF全体のパフォーマンス、キャパシティまでは担保しない
⇒適切な監視、可視化が必須
– Pivotal社のドキュメントに要監視ポイントの記載有り
• https://docs.pivotal.io/pivotalcf/1-11/monitoring/
– BOSH API, firehoseから必要な情報を取得できる
VM
App App
VM
App
VM
App
… Scale out
L7LB
BOSH
API
VMリソース状況, プロセスの稼働状況
Monitoringsystem
構成VMは
簡単に増設
勝手に再作成
JSON
※模式図のため正確ではありません
zabbix-agentをしこむ
≒CF本体の改造※
⇒避けたい
firehose
Log
Stream
CFコンポーネントの稼働状況
ZabbixでJSON,ログを解析して構成変更に追従するのはしn
※厳密にはbosh-releaseの自作が必要で、CF本体のコードではない

※ZabbixにはIaaS環境監視で大変お世話になっております

こんにちは。Zabbix 警察です。
それ、ZabbixのLLDでできますよ。
Low Level Discoveryは、動的に変化する監視対象や、監視ホストに
よって内訳が異なるアイテムを自動かつ統一的に監視できるしくみです。
まずbosh APIから得たJSONを解析して、監視対象VMの情報をZabbixがLLDで受信可能な
JSONとして整形します。Zabbix上ではホストのプロトタイプを定義しておき、JSONから
得た情報を使って動的に監視ホストがZabbix上に作成されるようにします。なお、これは監
視の起点となる仮想的な監視ホスト上のLLDとして設定します。
各VMのリソース監視は、自動作成されたホストに紐付けたテンプレート内のLLDを使って

それ、Prometheus+Grafanaでできたよ！
33
URL単位の
HTTP統計
URLに紐付いた
コンテナの
リソース状況

それ、Prometheus+Grafanaでできたよ！
34
HTTPアクセスの
応答時間
HTTPアクセス数
/sec
HTTPレスポンス
コード統計
URLのマッピングに
自動追従して
セレクタの表示も変動

Prometheus とは
35
• クラウドネイティブ(?)監視OSS
• CNCFの登録OSSのひとつ

Prometheus とは
36
• 多次元の時系列データを利用する監視OSS
• PromQLを書けば、ラベルを使った集計ができる(≒ベクトル計算)
• 監視対象の増減＝ラベルのvalueが変わるだけ⇒環境変動に追従
• zabbix-agentに相当するExporterから値を収集する
• 探したらCF API, firehose, BOSH用のExporterがあった
Grafana
container_memory_bytes{app_id=“xxxx”,container_id=“1”} 375570432 @1502193161.123
container_memory_bytes{app_id=“yyyy”,container_id=“1”} 95821824 @1502193161.123
container_memory_bytes{app_id=“yyyy”,container_id=“2”} 76496896 @1502193161.123
メトリック名ラベル(多次元) メトリック値タイムスタンプ
JSON
firehose
CF API
JSON
Log stream
Prometheus
firehose_exporter
cf_exporter
bosh_exportre BOSH API
連携
グラフ描画を担当
Exporter
https://github.com/cloudfoundry-community/firehose_exporter
https://github.com/fstab/grok_exporter
https://github.com/cloudfoundry-community/cf_exporter
https://github.com/cloudfoundry-community/bosh_exporter
grok_exporter
Data
※firehose-to-syslog経由

楽勝！

楽勝！ ……？？？？
38
PromQL

(sum(rate(cf_application_response_time_sec_bucket
{host_domain=“hoge.goo.ne.jp",http_status=~"^4..$
",le="+Inf"}[3m])) by (organization_name,
space_name, host_domain) /
sum(rate(cf_application_response_time_sec_bucket{
host_domain=“hoge.goo.ne.jp",le="+Inf"}[3m])) by
(organization_name, space_name, host_domain) ) *
100 > 10

(1 - ( sum
( rate(cf_application_response_time_sec_bucket{hos
t_domain=“hoge.goo.ne.jp”, le=“2.0”}[3m]) )
by (organization_name, space_name, host_domain) /
ignoring(le) sum
( rate(cf_application_response_time_sec_buc
ket{host_domain=“hoge.goo.ne.jp",
le="+Inf"}[3m]) ) by (organization_name,
space_name, host_domain) ) ) * 100
> 20
avg(cf_application_info{application_name=~"front",o
rganization_name=~"imatopi-
12",space_name=~"pro"} * on(application_id)
group_right (application_name, buildpack,
deployment, environment, instance, job,
organization_id, organization_name, space_id,
space_name,stack_id, state)
(firehose_container_metric_memory_bytes/firehose_
container_metric_memory_bytes_quota) ) by
(application_name, organization_name, space_name)
* 100 > 80

楽勝じゃない！

でも

Z〇bbixより
圧倒的に見やすい！
使いやすい！
導入後のアプリ開発担当者の声

CFを監視してみて
44
• Prometheus
– 発展途上のため、課題がないとは言えない
• 冗長化、DBバックアップ、Exporterごとの挙動の違い etc.
– どろくさい工夫もいろいろやった
– 自サービスを自前で監視する目的なら十分に使える感触
• CF
– 複雑な監視系統を理解すればあとは何とかなってるはず
• クラウドネイティブなアプリの監視
– 「正解」を完全に確定させた監視が難しい
• 例）どこに何のプロセスがいくつあれば正解なの？
– 今までとは考え方を変えないとダメかも
– サービスの健全性・パフォーマンス監視が大切

まとめ

まとめ
46
• アプリ開発に集中できるよう、CloudFoundryを導入
– buildpackを活用してアプリ開発者をインフラ管理から解放
– アプリ監視をPrometheus+Grafanaで提供
– アプリのデプロイ、運用は明らかに迅速化・簡単化された
• 自社にPaaSを導入する際のポイント
– PaaSに載せやすいもの、従来構成が向いているものの区別
– アプリ開発者をどうやってやる気にさせるか
CloudFoundryいいよ！
ところどころしんどいけど

参考資料

CloudFoundryの監視系統
48
• BOSH,CFの監視系統は全体が見えづらい
– BOSHはCFと別のOSSなので、そもそも別ドキュメントだったり
https://docs.cloudfoundry.org/loggregator/architecture.html
例）CFのログ経路他は…？

CloudFoundryの監視系統
49
メトリクス
死活
ログ
VM
CFプロセスメトリクス
死活
ログ
メトリクス
死活
ログ
アプリ
bosh
Component Syslog Drain
×
各VMそれぞれからrsyslogで吐き出す
各VMのローカルログ
を見に行くしかない
Droppler TrafficController FireHose
metron agent経由
カテゴリ手段内容
死活コマンド bosh vms, bosh events(過去イベント)
外部出力 Bosh health monitor からEメール送信など
Bosh ResurrectorによるVM自動再作成も対応
メトリク
ス
コマンド bosh vms –vitals
外部出力 Bosh health monitor から OpenTSDB/Graphite へ, director
API
死活コマンド Bosh instances –ps, Bosh API 直接操作
Bosh ssh ->monit summaryコマンド
外部出力 Bosh health monitor からEメール送信など
Bosh ResurrectorによるVM自動再作成も対応
ログコマンド Bosh ssh -> cat /var/vcap/sys/log
外部出力各VMそれぞれのComponent Syslog Drainからrsyslogプロ
トコルで出力可能
メトリク
ス
コマンド (あまり想定されていない)
Firehoseによるcf nozzleコマンドでの取得など
外部出力 Firehoseからcf nozzle→firehost-to-syslog→syslogサーバ等
App Syslog Drain
死活コマンド Cf apps, CF API直接利用, cf curl /v2/apps/$(cf app [アプリ
名] --guid)/stats, cf events(過去イベント)
外部出力 App Syslog Drainからrsyslogプロトコルで出力可能
メトリク
ス
コマンド基本(CPU, memory, disk): cf app [app name]
詳細: CF API直接利用, cf curl /v2/apps/$(cf app [アプリ名] -
-guid)/stats
外部出力 Firehoseからcf nozzle→firehost-to-syslog→syslogサーバ等
ただしCFのadmin権限がないと実行不可
ログコマンド Bosh ssh -> cat /var/vcap/sys/log
外部出力 App Syslog Drainからrsyslogで出力可能
AdminはFirehoseから全アプリ分が出力可能
boshの世界
CFの世界
CFプロセスの死活は
CFプロセス自身で監視できない→boshへ
boshで作成
されたもの
syslogサーバ等
OpenTSDB/Graphite
Eメール等health monitor経由
• 監視設計前に整理したもの
：今回利用したもの
※CF APIは図に記載されていません

ZabbixでCF本体の監視を実現すると
50
BOSHDirectorAPI
API死活監視
ホストプロトタイプと応
答結果から監視対象登録
Cloud Foundry VM用
監視テンプレート
リンクされた監視テンプ
レートの設定を元に、
VM情報をリクエスト
登録時に自動適用
API応答結果
VM情報
DB格納
閾値による監視アラート発報
メトリクスグラフ描画
（キャッシュ）
LLDリクエスト
API死活監視で得られる
JSONデータをローカル
キャッシュすることで、
APIサーバの負荷を軽減し、
監視性能も安定化
つらい
※一例

bosh director API
51
# curl -k -L -v
'https://admin:admin@xxx.xxx.xxx.xxx:25555/tasks/111/output?ty
pe=result' | jq .
{
"ignore": false,
"bootstrap": true,
“job_state”: “running”, ★VMのステータス
“index”: 0, ★VMの種別毎の番号
“job_name”: “router”, ★VMの種別
"agent_id": "e0856f74-5ca3-4142-8513-a9ac0b25a0c7",
"dns": [],
"ips": [
“yyy.yyy.yyy.yyy"
],
"disk_cid": null,
"vm_cid": "7d358cf5-5aff-4de1-9c8e-e8b8461a37c5",
"state": "started",
"resource_pool": "exlarge",
"vm_type": "exlarge",
"vitals": {
"swap": {
"percent": "0",
"kb": "0"
},
“mem”: { ★メモリ
"percent": "1",
"kb": "528936"
},
"load": [ ★CPU load
"0.00",
"0.00",
"0.00"
],
“disk”: { ★ディスク
"system": {
"percent": "47",
"inode_percent": "34"
},
"ephemeral": {
"percent": "0",
"inode_percent": "0"
}
},
"cpu": {
"wait": "0.0",
"user": "0.0",
"sys": "0.0"
}
},
"processes": [
{
"cpu": {
"total": 0
},
"mem": {
"percent": 0,
"kb": 24600
},
"uptime": {
"secs": 1271553
},
"state": "running", ★プロセスの状態
"name": "consul_agent“ ★プロセス名
},
{
"cpu": {
"total": 0
},
"mem": {
"percent": 0,
"kb": 17420
},
"uptime": {
"secs": 1271551
},
"state": "running",
"name": "metron_agent"
},
…
Zabbixで
これ(ら)を扱うのは
ちょっと…

自前でcloud foundryを構築してgooのビッグサービスをカットオーバーした話

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a 自前でcloud foundryを構築してgooのビッグサービスをカットオーバーした話

Semelhante a 自前でcloud foundryを構築してgooのビッグサービスをカットオーバーした話 (20)

Último

Último (10)

自前でcloud foundryを構築してgooのビッグサービスをカットオーバーした話