1.
作られては消えていく
泡のように儚いクラスタの運用話
2014/08/29 YAPC Asia 2014
Tsuyoshi Torii (@toritori0318)
Bascule Inc.

2.
自己紹介
• 鳥居剛司Tsuyoshi Torii
• @toritori0318
• 株式会社バスキュール
• Node.js / Python / Perl / Ruby
• 二児の父

3.
DEV Ops

4.
主にTVとスマートフォンを
同期して云々〜
といった仕事をしています

5.
一部事例紹介

6.
Work

7.
BloodyTube
血液型対抗レースに視聴者が参加して番組を構成する完全インタラクティブTV
バスキュールの企画・提供・制作
視聴者のスマホからの参加状況がテレビに反映される
優勝チームにはリアル店舗で利用できるPontaポイントが提供される
B2O2O(Broadcast to Online to Offline)マーケティング施策にもチャレンジ
http://pieces.bascule.co.jp/2014/bloodytube/en/

8.
https://www.bascule-go.com/product/

9.
About MIES
• Sonischooter
– リアルタイム同期／タイムライン／Elastic Socket.ioクラスタ
• Harvestmoon
– ユーザアクション（投票／投稿など）を受付／集計
• Persona
– MIES／コンシューマユーザ統合
– SNS連携
• Kanten(tofuクローン)
– 画像変換
• ELF
– 視聴ログ集計／解析
• Punisher
– TV案件用ベンチマーククラスタ

10.
今日話すこと

11.
• TV案件の特徴
• 性能評価とか監視とか
• 運用改善の話その１
• 運用改善の話その２
• 今後改善していきたいこと

12.
今日話さないこと

13.
• フロントエンドの話
• アプリケーションレイヤの話
• 闇
– キャパシティガ〜
– クラウドフロントガ〜
– イーエルビーガ〜
– ジーエーイーガ〜

14.
TV案件の特徴

15.
運用サイクル

16.
運用例
• １週間前にティザーサイト公開
– ロールごとに最小インスタンス数で構築
• 放送日前日〜当日
– インスタンスを数十台〜数百台起動
– 放送時間に張り付き監視
– 終了後バックアップ
• 当日〜数日後
– 全てのインスタンスを一括削除

17.
TV連動運用
• 基本は「放送時間」
– 案件によって異なる
• ティザーサイトがある場合も
• １回きり／２−３回／毎日／毎週
• 想定ユーザ数バラバラ
• コストも割とシビア
• 本番稼働しているサーバ（特に放送時間中）
に対して変更を行うことはあまりない(*1)
(*1)サーバに限るかつ条件付き

18.
負債回収

19.
• 特に忙しい時期
– 期末期初／年末年始
• 作ったものは本番終了後に削除
• ０から作り直す／まとまって空いている期間
があるので技術的負債を返済しやすい環境
であるといえる
※あくまで現時点の話

20.
ここまでが
TV案件の特徴に
ついて

21.
性能評価／監視の話

22.
性能評価

23.
アクセスパターンについて

24.
• 曜日／時間帯／企画内容からユーザ規模が
ある程度想定できる
• アクセスパターンをある程度把握できるので、
どの部分に負荷が集中しやすいか事前に特
定できる
• 本番怖い

25.
本番怖い

26.
一発勝負

27.
Punisher

28.
Punisher
• NodeJS製ベンチマーククラスタ
• スクリプトをJavascriptで記述
• 機能
– リアルタイムで開始／停止が可能
– リアルタイム集計（タスク集計のみ）
– AWS全リージョン対応
• １コマンドでAWS全リージョンのインスタンスを起動／
分散デプロイ
– スポットインスタンス(半)自動入札

29.
書いた理由

30.
状況を完璧に再現したい

31.
シナリオ例
• 30分間に30万人が以下の処理を行う
1. ログイン
• 内８割がゲストユーザ／２割がSNS接続ユーザ
2. APIサーバに情報取得
3. 非同期で30秒ごとにhogehogeAPI実行
4. Socketサーバに接続
• 内８割がwebsocket／２割がxhr-polling
• 30万接続した状態でブロードキャスト送信
1. 5-15秒後にAPIサーバに対して投票処理
2. etc…

32.
（良い）副作用
シナリオを書くことによって
事前にあぶない部分が
判明する

33.
負荷が原因のトラブルは
ほぼ０に

34.
安心感

35.
監視

36.
監視（放送当日以外）
• Nagios／Munin
• インスタンスのタグから自動でコンフィグファ
イルを作成するような自前ツール
• メール＆ IRC > HipChat > Slack
• もう少しオシャレにしたい
– Sensu〜♪

37.
監視（放送日当日）
• 負荷が来る日時が予めわかっている
– 放送時間に張り付き監視
• 全体的な監視
– CloudWatch
– Proteus-Monitor
– ソケットクラスタ管理ツール（独自）
• ロールごとの個別監視
– top
– vmstat
– tail –f error.log
– App::RedisTop(*1)
(*1)https://github.com/toritori0318/p5-App-RedisTop

38.
Proteus-Monitor

39.
Proteus-Monitor
• リアルタイムで各サーバの
CPU/Load/Mem/Net/etc…が確認できる
• サーバ一覧で確認できる
• 設定がお手軽
• Nodeが動的に追加／削除される
• 過去の指標は残らない
• 名前でフィルタできるようにパッチをあててい
る

40.
ソケットクラスタ管理ツール

41.
ここまでが
性能評価／監視の話

42.
運用改善の話
その１

43.
その前にMIESの話
• 最初から「MIESを作るぞ！」という目的があった
わけではない
• 案件をこなしていくうちに「この部分は共通化で
きそう」「この部分は汎用化しておくと開発楽だよ
ね」といった感じでエンジニアが自発的にアイデ
アを出し、一つ一つカタチにしていったら自然に
出来上がっていた
• 当初は機能重視で開発
• 一つ一つのサービスは独立していて疎結合

44.
Server Team
• ３人
–TD or 独自アプリケーション（１名）
–TD or MIESコア開発運用（１名）
–MIESコア開発運用（１名）

45.
サービス言語デプロイ／スケールPerson
Sonicshooter
（リアルタイム同期系）
Node.js App::Rad(*1) +
Capistrano
Harvestmoon
（アンケート受付）
Python Fabric
Persona
（認証）
Python App::Rad + Capistrano
Kanten
（画像変換）
Perl Yoga(*2)
(*1) http://d.hatena.ne.jp/tori243/20120622/1340386116
(*2) https://github.com/toritori0318/p5-Yogafire

46.
俺が、俺がSPOFだ!

47.
問題
• サービス毎の秘伝のタレ
– 開発環境／デプロイ／構築／スケール管理
• １サービス毎に運用出来る人が一人
• 運用コスト
– スクリプト化してはいるが手順がバラバラ
– 他の人が手順を知らないor 知るのが大変
– 工数がかかる
– お金がかかる

48.
解決したいこと
• 全てのサービスで仕組みを共通化
– 開発フロー／デプロイ／クラスタ構築／スケール管理
• これらを同じインタフェース（コマンド）で統一したい
• 引き継ぎしやすくなる
• CIしやすくなる
• 誰でもミス無く簡単に運用できる
• コストダウンに繋がる

49.
解決策

50.
• 開発フロー／デプロイ
– Vagrant + vagrant-aws + chef-deploy
• プロビジョニングツール
– Chef+Berkshelf
• クラスタ管理
– AWS CloudFormation
• スケールコントロール
– AWS AutoScaling

51.
MIES-Provision-Task

52.
MIES-Provision-Task
• Rakeタスク
– 基本的にはvagrant／aws-cliのラッパー
• Vagant + vagrant-aws + vagrant-amiで統一化
• プロビジョニングはVagrant-chef-solo-provisioner
• デプロイはchef-deployリソース
• クラスタ管理はCloudFormation
• スケール管理はAutoScaling

53.
ざっくり補足

54.
開発フロー

55.
開発フロー
• VagrantfileにVMのリストを設定(*1)
• Chefレシピ（nodes）もVMに合わせて作成(*1)
• vagrantコマンド(Rakeでラップ)でVM起動／プロビジョニング／ssh
／削除／イメージ保存を行う
• 複数サーバへのデプロイは行わず、AMIを作るだけの操作を行う
（CloudFomation用のAMI）
• CloudFormationテンプレートはロール毎に用意しておき、Rakeタス
ク内でマージ
• クラスタへの反映はCloudFormationでAMIを更新することで行う
(*1) 管理単位は「環境（＋ロール）」

56.
VM管理例
• local
• aws_hm_dev
• aws_hm_stg
• aws_hm_prd_wap
• aws_hm_prd_redis
Chefレシピ／AMIもこの単位で管理

57.
イメージ保存

58.
イメージ保存
• vagrant-ami
– vagrant-awsの設定を共有できる
– Packerは不採用
– fakepackerというRakeタスクを作成（後述）
% vagrant create-ami --name my-ami
--desc "My AMI” --tags role=test,environment=dev
*参考http://d.hatena.ne.jp/toritori0318/20130820/1377018423

59.
スケール管理

60.
スケール管理
• CloudFormationのパラメータで指定
• Rakeタスクでも用意しておく(後述)

61.
インフラ共通化

62.
Chef cookbooks
• 全サービスである程度共通化したbase-cookbookを用意
– ユーザ周り
– openssh/ntp/timezone/nrpe/etc…
– ssh周りの設定
– Alias or symlink( sv=“supervisorctl” / dstat-full=“dstat –Tclmdrn” )
– 最低限のカーネルパラメータ
– xbuild (node/python/perl/ruby) / fluentd / munin-node /
supervisord
– ディレクトリ（アプリケーション／アプリケーションログ／etc…）
• ベースAMI作成する時にこれらを適用する

63.
Supervisor
• Python製デーモン管理ツール
• 一度に複数デーモンを操作／自動リスタートな
ど対応
• グループ機能を利用
– 例
• supervisorctl restart all # supervisor全管理プロセス
• Supervisorctl restart wap: # nginx / webapp
• Supervisorctl restart redis: # redis_6379 / redis_6380 / …
• Supervisorctl restart worker: # ワーカー全般

64.
補足終わり

65.
Rakeタスク

66.
Local VM Task
• rake local:up
• rake local:provision [deploy=1]
• rake local:spec
• rake local:destroy
• rake local:ssh

67.
AWS Task
• rake aws:create_baseami
• rake aws:up vm=<vm_name>
• rake aws:provision vm=<vm_name> [deploy=1]
• rake aws:spec vm=<vm_name>
• rake aws:destroy vm=<vm_name>
• rake aws:ssh vm=<vm_name>
• rake aws:create_ami vm=<vm_name>
• rake aws:link_instance vm=<vmname> id=<instance_id>
• rake aws:unlink_instance vm=<vmname>

68.
AWS Task
• rake aws:fakepacker vm=<vmname>
– up > provision > spec > create_ami > destroy

69.
AWS CloudFormation Task
• rake aws_cf:generate_cf_json env=<env_name>
• rake aws_cf:create_stack env=<env_name>
• rake aws_cf:update_stack env=<env_name> [<key>=<value>]
• rake aws_cf:delete_stack env=<env_name>

70.
タスクTips
• 任意のクックブックを指定
– rake aws:provision vm=hoge chef_json=nodes/base.json
• 差分実行
– rake aws:up vm=hoge ami=ami-xxxxxxxxx
• 複数タスク実行
– rake aws:up aws:provision aws:create_ami vm=hoge
– rake aws:up aws:ssh vm=hoge

71.
タスクTips
• rake vms

72.
解決

73.
ここまでが
運用改善の話
（その１）

74.
運用改善の話
その２

75.
問題
• 同時並行案件が増えてきた…
– アプリレイヤーでは複数対応しているが、インフラ
は…？

76.
問題
• 案件による規模の違い
– 案件A：ティザー２週間＋本番２回：規模１０万人
– 案件B：毎週金曜レギュラー：規模１万人
– 案件C：本番１回：規模１００万人
• コスト問題
• 単発番組／レギュラー番組
– 他の案件用に改修入りそうだけどレギュラー番組
で動いてるのに影響出たらどうしよう…

77.
解決案
• AWSアカウントを案件毎に分けて、別クラスタ
を構築出来るようにする
– １クラスタにしない理由
• 規模によって別構築したい
• 一度本番稼働している環境をいじるのが怖い
– １アカウントで管理しない理由
• オペレーションまざるのが怖い

78.
手順共通化したし
行けるのでは…！

79.
現実
• AMI移動( or BaseAMI作り直し)
• Keypair設定
• AWSキー更新(*1)
• アプリケーションの改修
– MySQL／Redisサーバ／インスタンスの数
• 案件／インスタンスタイプに合わせたワーカー数設定
– アプリケーション(gunicorn/cluster/starman)・SQSワーカー
など
• これらの再設定が終わったらchef実行し直す…
• まーめんどい
(*1) IAMロールは使わない

80.
さらなる解決案

81.
案件ごとのコンフィグレーションを
一元管理してしまおう

82.
Omniscient

83.
Omniscient
• サービス全体のコンフィグレーションを管理
• 管理軸
– 案件毎／環境毎(dev/staging/stress/production)
• アプリケーションコンフィグ(おまけ)
– サービス毎のエンドポイント
– サービス毎のオプション設定
• インフラコンフィグ
– AWS情報
– キャッシュ／Redis／RDS／などDBのエンドポイント
– ワーカープロセスの数
– 自社製RedisClusterのコンフィグ設定

84.
Omniscient概要図
クラスタ起動。同時に
インスタンスの情報を
Omniscientに登録定期的にOmniscientの
情報をPullし、更新され
たらサーバに反映
クラスタ起動。同時にイ
ンスタンスの情報を
Omniscientに登録。
アプリ側は取得して反映

85.
移行コスト改善〜♪

86.
Serfも検討したが…
• Serf
– オーケストレーションツール
– ゴシッププロトコロルを用い、クラスタ全体に何ら
かのメッセージを伝搬
• 検証
– 複数軸で管理しようとした時、逆に複雑に
• よい方法があれば〜

87.
ここまでが
運用改善の話
（その２）

88.
さらに改善して
いきたいこと

89.
やりたいこと一覧
• Docker化
– 開発環境配布
– サービス環境配布
– プロダクション？
• MIESサービス統合管理
• Omniscientゲートウェイ計画
• RakeタスクのGolang化

90.
まとめ

91.
• TV案件では24時間365日稼働サー
ビスとはがんばるところ／手を抜け
るところが違う
• 要件に合った運用改善〜
• まだまだ改善したい〜
• 本番怖い

92.
おまけ情報
• Rakeタスク／サンプルファイルなどブログにお
いてありますのでご参照下さい(若干古い)
– http://d.hatena.ne.jp/toritori0318/20130916/1379355060
– https://github.com/toritori0318/vagrant-aws-sample

93.
ご清聴ありがとう
ございました