More Related Content
Similar to 作られては消えていく泡のように儚いクラスタの運用話 (20)
作られては消えていく泡のように儚いクラスタの運用話
- 2. 自己紹介
• 鳥居剛司Tsuyoshi Torii
• @toritori0318
• 株式会社バスキュール
• Node.js / Python / Perl / Ruby
• 二児の父
- 9. About MIES
• Sonischooter
– リアルタイム同期/タイムライン/Elastic Socket.ioクラスタ
• Harvestmoon
– ユーザアクション(投票/投稿など)を受付/集計
• Persona
– MIES/コンシューマユーザ統合
– SNS連携
• Kanten(tofuクローン)
– 画像変換
• ELF
– 視聴ログ集計/解析
• Punisher
– TV案件用ベンチマーククラスタ
- 11. • TV案件の特徴
• 性能評価とか監視とか
• 運用改善の話その1
• 運用改善の話その2
• 今後改善していきたいこと
- 13. • フロントエンドの話
• アプリケーションレイヤの話
• 闇
– キャパシティガ〜
– クラウドフロントガ〜
– イーエルビーガ〜
– ジーエーイーガ〜
- 16. 運用例
• 1週間前にティザーサイト公開
– ロールごとに最小インスタンス数で構築
• 放送日前日〜当日
– インスタンスを数十台〜数百台起動
– 放送時間に張り付き監視
– 終了後バックアップ
• 当日〜数日後
– 全てのインスタンスを一括削除
- 18. TV連動運用
• 基本は「放送時間」
– 案件によって異なる
• ティザーサイトがある場合も
• 1回きり/2−3回/毎日/毎週
• 想定ユーザ数バラバラ
• コストも割とシビア
• 本番稼働しているサーバ(特に放送時間中)
に対して変更を行うことはあまりない(*1)
(*1)サーバに限るかつ条件付き
- 20. • 特に忙しい時期
– 期末期初/年末年始
• 作ったものは本番終了後に削除
• 0から作り直す/まとまって空いている期間
があるので技術的負債を返済しやすい環境
であるといえる
※あくまで現時点の話
- 29. Punisher
• NodeJS製ベンチマーククラスタ
• スクリプトをJavascriptで記述
• 機能
– リアルタイムで開始/停止が可能
– リアルタイム集計(タスク集計のみ)
– AWS全リージョン対応
• 1コマンドでAWS全リージョンのインスタンスを起動/
分散デプロイ
– スポットインスタンス(半)自動入札
- 32. シナリオ例
• 30分間に30万人が以下の処理を行う
1. ログイン
• 内8割がゲストユーザ/2割がSNS接続ユーザ
2. APIサーバに情報取得
3. 非同期で30秒ごとにhogehogeAPI実行
4. Socketサーバに接続
• 内8割がwebsocket/2割がxhr-polling
• 30万接続した状態でブロードキャスト送信
1. 5-15秒後にAPIサーバに対して投票処理
2. etc…
- 40. 監視(放送日当日)
• 負荷が来る日時が予めわかっている
– 放送時間に張り付き監視
• 全体的な監視
– CloudWatch
– Proteus-Monitor
– ソケットクラスタ管理ツール(独自)
• ロールごとの個別監視
– top
– vmstat
– tail –f error.log
– App::RedisTop(*1)
(*1)https://github.com/toritori0318/p5-App-RedisTop
- 46. その前にMIESの話
• 最初から「MIESを作るぞ!」という目的があった
わけではない
• 案件をこなしていくうちに「この部分は共通化で
きそう」「この部分は汎用化しておくと開発楽だよ
ね」といった感じでエンジニアが自発的にアイデ
アを出し、一つ一つカタチにしていったら自然に
出来上がっていた
• 当初は機能重視で開発
• 一つ一つのサービスは独立していて疎結合
- 47. Server Team
• 3人
–TD or 独自アプリケーション(1名)
–TD or MIESコア開発運用(1名)
–MIESコア開発運用(1名)
- 48. サービス言語デプロイ/スケール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
- 50. 問題
• サービス毎の秘伝のタレ
– 開発環境/デプロイ/構築/スケール管理
• 1サービス毎に運用出来る人が一人
• 運用コスト
– スクリプト化してはいるが手順がバラバラ
– 他の人が手順を知らないor 知るのが大変
– 工数がかかる
– お金がかかる
- 51. 解決したいこと
• 全てのサービスで仕組みを共通化
– 開発フロー/デプロイ/クラスタ構築/スケール管理
• これらを同じインタフェース(コマンド)で統一したい
• 引き継ぎしやすくなる
• CIしやすくなる
• 誰でもミス無く簡単に運用できる
• コストダウンに繋がる
- 54. • 開発フロー/デプロイ
– Vagrant + vagrant-aws + chef-deploy
• プロビジョニングツール
– Chef+Berkshelf
• クラスタ管理
– AWS CloudFormation
• スケールコントロール
– AWS AutoScaling
- 56. MIES-Provision-Task
• Rakeタスク
– 基本的にはvagrant/aws-cliのラッパー
• Vagant + vagrant-aws + vagrant-amiで統一化
• プロビジョニングはVagrant-chef-solo-provisioner
• デプロイはchef-deployリソース
• クラスタ管理はCloudFormation
• スケール管理はAutoScaling
- 59. 開発フロー
• VagrantfileにVMのリストを設定(*1)
• Chefレシピ(nodes)もVMに合わせて作成(*1)
• vagrantコマンド(Rakeでラップ)でVM起動/プロビジョニング/ssh
/削除/イメージ保存を行う
• 複数サーバへのデプロイは行わず、AMIを作るだけの操作を行う
(CloudFomation用のAMI)
• CloudFormationテンプレートはロール毎に用意しておき、Rakeタス
ク内でマージ
• クラスタへの反映はCloudFormationでAMIを更新することで行う
(*1) 管理単位は「環境(+ロール)」
- 60. VM管理例
• local
• aws_hm_dev
• aws_hm_stg
• aws_hm_prd_wap
• aws_hm_prd_redis
Chefレシピ/AMIもこの単位で管理
- 62. イメージ保存
• 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
- 67. 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作成する時にこれらを適用する
- 68. Supervisor
• Python製デーモン管理ツール
• 一度に複数デーモンを操作/自動リスタートな
ど対応
• グループ機能を利用
– 例
• supervisorctl restart all # supervisor全管理プロセス
• Supervisorctl restart wap: # nginx / webapp
• Supervisorctl restart redis: # redis_6379 / redis_6380 / …
• Supervisorctl restart worker: # ワーカー全般
- 72. Local VM Task
• rake local:up
• rake local:provision [deploy=1]
• rake local:spec
• rake local:destroy
• rake local:ssh
- 73. 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>
- 74. AWS Task
• rake aws:fakepacker vm=<vmname>
– up > provision > spec > create_ami > destroy
- 75. 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>
- 76. タスク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
- 83. 問題
• 案件による規模の違い
– 案件A:ティザー2週間+本番2回:規模10万人
– 案件B:毎週金曜レギュラー:規模1万人
– 案件C:本番1回:規模100万人
• コスト問題
• 単発番組/レギュラー番組
– 他の案件用に改修入りそうだけどレギュラー番組
で動いてるのに影響出たらどうしよう…
- 87. 現実
• AMI移動( or BaseAMI作り直し)
• Keypair設定
• AWSキー更新(*1)
• アプリケーションの改修
– MySQL/Redisサーバ/インスタンスの数
• 案件/インスタンスタイプに合わせたワーカー数設定
– アプリケーション(gunicorn/cluster/starman)・SQSワーカー
など
• これらの再設定が終わったらchef実行し直す…
• まーめんどい
(*1) IAMロールは使わない
- 91. Omniscient
• サービス全体のコンフィグレーションを管理
• 管理軸
– 案件毎/環境毎(dev/staging/stress/production)
• アプリケーションコンフィグ(おまけ)
– サービス毎のエンドポイント
– サービス毎のオプション設定
• インフラコンフィグ
– AWS情報
– キャッシュ/Redis/RDS/などDBのエンドポイント
– ワーカープロセスの数
– 自社製RedisClusterのコンフィグ設定
- 94. Serfも検討したが…
• Serf
– オーケストレーションツール
– ゴシッププロトコロルを用い、クラスタ全体に何ら
かのメッセージを伝搬
• 検証
– 複数軸で管理しようとした時、逆に複雑に
• よい方法があれば〜
- 97. やりたいこと一覧
• Docker化
– 開発環境配布
– サービス環境配布
– プロダクション?
• MIESサービス統合管理
• Omniscientゲートウェイ計画
• RakeタスクのGolang化
- 100. おまけ情報
• Rakeタスク/サンプルファイルなどブログにお
いてありますのでご参照下さい(若干古い)
– http://d.hatena.ne.jp/toritori0318/20130916/1379355060
– https://github.com/toritori0318/vagrant-aws-sample
Editor's Notes
- 二児の父です。
途中、素材として子供がちょいちょい出演します。
- セカンドスクリーンと言われる事例
- こちらは実際に担当した案件の一部。
投票を受け付けて、リアルタイムに反映したり
診断を行ってユーザ同士の相性を表示したり
リアルタイムにTVとスマホが同期してゲームのようなことを行ったり
コインを消費してブックメークのような事を行ったり
このような案件を担当してきました.
自分のチームはこちらを中心に仕事しています。
- コードネーム「MIES」と呼ばれているセカンドスクリーン用のプラットフォーム。
ユーザ管理/リアルタイムメッセージ/アンケート/ログ を TVに加工して表示
みたいなところをひと通り網羅したプラットフォーム。こちらの開発運用を担当しています。
- ★4分
- ※補足 本番稼働サーバの変更について
理由1 本番稼働している期間が短いのが多い
理由2 元々、BAASとして汎用的な機能を提供しているので、機能変更が少ない(案件特有のアプリケーションサーバはたまにあったりするけど)
変更あるとしても大抵結合テスト時に完了しているし、ティザー期間であればその期間中でデプロイなど行うことができる。
- ★8分
- 本番に起こりえるクライアントと全く同じ挙動を模倣したかった。
そのためNode.JSを採用していたり、大量のサーバを手軽に起動して大量ユーザを模倣したりしたかった
- こういうことが事前にわかるように。
これが出来る前は本番時に「あー、ここで予想以上の負荷が来てしまった!!!!」というトラブルにも襲われたが、
これが出来てからは負荷でトラブル発生することがほぼ0に。
- だいぶ安心感して本番を迎えられるようになった
- ★15分
- Vagrant
当初の目的としてはVagrantでローカル開発環境の配布とAWS操作を共通化するのに適しているのでは、ということで採用
プロビジョニングツール
Chef(全盛の頃だった、というのが一番の理由)
クラスタ管理
ElasticBeanstalkやOpsWorksもあるが、複数のロールを「一度に構築」「更新」「一括削除」が出来るのと、汎用性が高いのと、
JSONなのでいざという時にだれでも触れるというのと、ポータビリティが高い、というので採用
スケールコントロール
自動スケールはおまけ程度で、スケールコントロールを手軽に行えるところで採用。
CloudFormationと組み合わせると割と簡単にスケールアウト/イン/アップ/ダウンがお手軽に出来る。
つまりAWSの管理画面からでも行えるので共通化という面では良いと思った
- つまるところ、「環境+ロール」のイメージを作ることだけ行い、
あとはAMIを反映するだけ
-
packerも検討していたが細かい制御がしずらかったのと、vagrant-amiを使うとvagrant-awsの設定をそのまま使えるので楽だった
- プロビジョン時、ロール毎のミドルウェアをインストール
ロール毎に変更したい部分があればnodesのattributesやsite-cookbooksで上書きする
- ※補足 この運用ができるのは「稼働し続けるサーバに対してデプロイする」という行為がほとんど無いため。
- CloudFormationを管理するためのタスク群
- 運用手順の共通化に成功〜
- ★30分
- 全ての規模を案件Cによせると金額が膨大になる
お金かかる!!!!
- まーめんどい。
最初はスクリプト化でお茶を濁そうかなと思っていたが、
サービスが複数あるので結局手作業が増えてしまう。
※補足 AWSキー更新
IAMロールで行う予定だったが、キーが一定期間でリフレッシュされてしまう。本番中にリフレッシュされることを恐れた
HTTPリクエストを受け取ってAWSにアクセスするようなのはコネクションキャッシュしているが、そういうの。
※補足 ワーカープロセスの設定
プロビジョニングで設定?
プロビジョニングする時と実際に運用するときでワーカー数設定するのがウザかったのもある
CPUコア数から自動設定?
案件が利用する機能によってワーカー数を微調整することもあり全部に対応するのは難しかった
(この案件はSNS OAuth使うからワーカー数多め/フレンド更新多いからこのSQSワーカーを多めにする/etc)
- アプリケーションコンフィグ
サービス毎のエンドポイント
サービス毎のオプション設定(Kantenのリサイズコマンドなど)
インフラ
動的に変わるようなロールを管理
AWS情報
RedisClusterの設定/Redisサーバ・インスタンス管理
キャッシュサーバ
webappのワーカープロセス数
sqsのワーカープロセス数
CloudFormationで起動した時にエンドポイント/RedisClusterの規模を自動登録
アプリケーションのプロセスは、起動時にOmniscientの設定を元に起動する
AWS情報
ワーカー数
RedisCluster
- 移行コストだけではなく、普段の運用コストについても改善
- Omniscient、絶賛開発中なので他に良い方法やソリューションがあれば教えて下さい〜
- ★38分
- 配布に関してはVMでやろうとしていたけど重いし断念。Docker化を目論んでいる
- TV案件では一気にインスタンスを起動し、終わったら捨てるという運用が多いので、
それに合わせた運用改善を行いました。という話をしました。
24時間365日運用と違って、定期的に空いた期間を用いて運用改善を行いました。
今回行った改善も、実は要件によっては合わないこともあると思いますが
我々の運用フローにはハマっているし、いまのところ成功している。
まだまだ改善したいこともあったり〜
なにか良い方法があればお話きかせて下さい〜
- ★0分