作られては消えていく泡のように儚いクラスタの運用話

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

状況を完璧に再現したい

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

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

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

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

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

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

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

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

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

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

サービス言語デプロイ／スケール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

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

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

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

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

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

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

イメージ保存
• 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

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

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作成する時にこれらを適用する

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

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

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>

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

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>

タスク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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

作られては消えていく泡のように儚いクラスタの運用話

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to 作られては消えていく泡のように儚いクラスタの運用話

Similar to 作られては消えていく泡のように儚いクラスタの運用話 (20)

Recently uploaded

Recently uploaded (8)

作られては消えていく泡のように儚いクラスタの運用話

Editor's Notes