Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

3,802 views

Published on

儚い

Published in: Technology
  • Be the first to comment

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

  1. 1. 作られては消えていく 泡のように儚いクラスタの運用話 2014/08/29 YAPC Asia 2014 Tsuyoshi Torii (@toritori0318) Bascule Inc.
  2. 2. 自己紹介 • 鳥居剛司Tsuyoshi Torii • @toritori0318 • 株式会社バスキュール • Node.js / Python / Perl / Ruby • 二児の父
  3. 3. DEV Ops
  4. 4. 主にTVとスマートフォンを 同期して云々〜 といった仕事をしています
  5. 5. 一部事例紹介
  6. 6. Work
  7. 7. BloodyTube 血液型対抗レースに視聴者が参加して番組を構成する完全インタラクティブTV バスキュールの企画・提供・制作 視聴者のスマホからの参加状況がテレビに反映される 優勝チームにはリアル店舗で利用できるPontaポイントが提供される B2O2O(Broadcast to Online to Offline)マーケティング施策にもチャレンジ http://pieces.bascule.co.jp/2014/bloodytube/en/
  8. 8. https://www.bascule-go.com/product/
  9. 9. About MIES • Sonischooter – リアルタイム同期/タイムライン/Elastic Socket.ioクラスタ • Harvestmoon – ユーザアクション(投票/投稿など)を受付/集計 • Persona – MIES/コンシューマユーザ統合 – SNS連携 • Kanten(tofuクローン) – 画像変換 • ELF – 視聴ログ集計/解析 • Punisher – TV案件用ベンチマーククラスタ
  10. 10. 今日話すこと
  11. 11. • TV案件の特徴 • 性能評価とか監視とか • 運用改善の話その1 • 運用改善の話その2 • 今後改善していきたいこと
  12. 12. 今日話さないこと
  13. 13. • フロントエンドの話 • アプリケーションレイヤの話 • 闇 – キャパシティガ〜 – クラウドフロントガ〜 – イーエルビーガ〜 – ジーエーイーガ〜
  14. 14. TV案件の特徴
  15. 15. 運用サイクル
  16. 16. 運用例 • 1週間前にティザーサイト公開 – ロールごとに最小インスタンス数で構築 • 放送日前日〜当日 – インスタンスを数十台〜数百台起動 – 放送時間に張り付き監視 – 終了後バックアップ • 当日〜数日後 – 全てのインスタンスを一括削除
  17. 17. TV連動運用 • 基本は「放送時間」 – 案件によって異なる • ティザーサイトがある場合も • 1回きり/2−3回/毎日/毎週 • 想定ユーザ数バラバラ • コストも割とシビア • 本番稼働しているサーバ(特に放送時間中) に対して変更を行うことはあまりない(*1) (*1)サーバに限るかつ条件付き
  18. 18. 負債回収
  19. 19. • 特に忙しい時期 – 期末期初/年末年始 • 作ったものは本番終了後に削除 • 0から作り直す/まとまって空いている期間 があるので技術的負債を返済しやすい環境 であるといえる ※あくまで現時点の話
  20. 20. ここまでが TV案件の特徴に ついて
  21. 21. 性能評価/監視の話
  22. 22. 性能評価
  23. 23. アクセスパターンについて
  24. 24. • 曜日/時間帯/企画内容からユーザ規模が ある程度想定できる • アクセスパターンをある程度把握できるので、 どの部分に負荷が集中しやすいか事前に特 定できる • 本番怖い
  25. 25. 本番怖い
  26. 26. 一発勝負
  27. 27. Punisher
  28. 28. Punisher • NodeJS製ベンチマーククラスタ • スクリプトをJavascriptで記述 • 機能 – リアルタイムで開始/停止が可能 – リアルタイム集計(タスク集計のみ) – AWS全リージョン対応 • 1コマンドでAWS全リージョンのインスタンスを起動/ 分散デプロイ – スポットインスタンス(半)自動入札
  29. 29. 書いた理由
  30. 30. 状況を完璧に再現したい
  31. 31. シナリオ例 • 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…
  32. 32. (良い)副作用 シナリオを書くことによって 事前にあぶない部分が 判明する
  33. 33. 負荷が原因のトラブルは ほぼ0に
  34. 34. 安心感
  35. 35. 監視
  36. 36. 監視(放送当日以外) • Nagios/Munin • インスタンスのタグから自動でコンフィグファ イルを作成するような自前ツール • メール& IRC > HipChat > Slack • もう少しオシャレにしたい – Sensu〜♪
  37. 37. 監視(放送日当日) • 負荷が来る日時が予めわかっている – 放送時間に張り付き監視 • 全体的な監視 – CloudWatch – Proteus-Monitor – ソケットクラスタ管理ツール(独自) • ロールごとの個別監視 – top – vmstat – tail –f error.log – App::RedisTop(*1) (*1)https://github.com/toritori0318/p5-App-RedisTop
  38. 38. Proteus-Monitor
  39. 39. Proteus-Monitor • リアルタイムで各サーバの CPU/Load/Mem/Net/etc…が確認できる • サーバ一覧で確認できる • 設定がお手軽 • Nodeが動的に追加/削除される • 過去の指標は残らない • 名前でフィルタできるようにパッチをあててい る
  40. 40. ソケットクラスタ管理ツール
  41. 41. ここまでが 性能評価/監視の話
  42. 42. 運用改善の話 その1
  43. 43. その前にMIESの話 • 最初から「MIESを作るぞ!」という目的があった わけではない • 案件をこなしていくうちに「この部分は共通化で きそう」「この部分は汎用化しておくと開発楽だよ ね」といった感じでエンジニアが自発的にアイデ アを出し、一つ一つカタチにしていったら自然に 出来上がっていた • 当初は機能重視で開発 • 一つ一つのサービスは独立していて疎結合
  44. 44. Server Team • 3人 –TD or 独自アプリケーション(1名) –TD or MIESコア開発運用(1名) –MIESコア開発運用(1名)
  45. 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. 46. 俺が、俺がSPOFだ!
  47. 47. 問題 • サービス毎の秘伝のタレ – 開発環境/デプロイ/構築/スケール管理 • 1サービス毎に運用出来る人が一人 • 運用コスト – スクリプト化してはいるが手順がバラバラ – 他の人が手順を知らないor 知るのが大変 – 工数がかかる – お金がかかる
  48. 48. 解決したいこと • 全てのサービスで仕組みを共通化 – 開発フロー/デプロイ/クラスタ構築/スケール管理 • これらを同じインタフェース(コマンド)で統一したい • 引き継ぎしやすくなる • CIしやすくなる • 誰でもミス無く簡単に運用できる • コストダウンに繋がる
  49. 49. 解決策
  50. 50. • 開発フロー/デプロイ – Vagrant + vagrant-aws + chef-deploy • プロビジョニングツール – Chef+Berkshelf • クラスタ管理 – AWS CloudFormation • スケールコントロール – AWS AutoScaling
  51. 51. MIES-Provision-Task
  52. 52. MIES-Provision-Task • Rakeタスク – 基本的にはvagrant/aws-cliのラッパー • Vagant + vagrant-aws + vagrant-amiで統一化 • プロビジョニングはVagrant-chef-solo-provisioner • デプロイはchef-deployリソース • クラスタ管理はCloudFormation • スケール管理はAutoScaling
  53. 53. ざっくり補足
  54. 54. 開発フロー
  55. 55. 開発フロー • VagrantfileにVMのリストを設定(*1) • Chefレシピ(nodes)もVMに合わせて作成(*1) • vagrantコマンド(Rakeでラップ)でVM起動/プロビジョニング/ssh /削除/イメージ保存を行う • 複数サーバへのデプロイは行わず、AMIを作るだけの操作を行う (CloudFomation用のAMI) • CloudFormationテンプレートはロール毎に用意しておき、Rakeタス ク内でマージ • クラスタへの反映はCloudFormationでAMIを更新することで行う (*1) 管理単位は「環境(+ロール)」
  56. 56. VM管理例 • local • aws_hm_dev • aws_hm_stg • aws_hm_prd_wap • aws_hm_prd_redis Chefレシピ/AMIもこの単位で管理
  57. 57. イメージ保存
  58. 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. 59. スケール管理
  60. 60. スケール管理 • CloudFormationのパラメータで指定 • Rakeタスクでも用意しておく(後述)
  61. 61. インフラ共通化
  62. 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. 63. Supervisor • Python製デーモン管理ツール • 一度に複数デーモンを操作/自動リスタートな ど対応 • グループ機能を利用 – 例 • supervisorctl restart all # supervisor全管理プロセス • Supervisorctl restart wap: # nginx / webapp • Supervisorctl restart redis: # redis_6379 / redis_6380 / … • Supervisorctl restart worker: # ワーカー全般
  64. 64. 補足終わり
  65. 65. Rakeタスク
  66. 66. Local VM Task • rake local:up • rake local:provision [deploy=1] • rake local:spec • rake local:destroy • rake local:ssh
  67. 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. 68. AWS Task • rake aws:fakepacker vm=<vmname> – up > provision > spec > create_ami > destroy
  69. 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. 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. 71. タスクTips • rake vms
  72. 72. 解決
  73. 73. ここまでが 運用改善の話 (その1)
  74. 74. 運用改善の話 その2
  75. 75. 問題 • 同時並行案件が増えてきた… – アプリレイヤーでは複数対応しているが、インフラ は…?
  76. 76. 問題 • 案件による規模の違い – 案件A:ティザー2週間+本番2回:規模10万人 – 案件B:毎週金曜レギュラー:規模1万人 – 案件C:本番1回:規模100万人 • コスト問題 • 単発番組/レギュラー番組 – 他の案件用に改修入りそうだけどレギュラー番組 で動いてるのに影響出たらどうしよう…
  77. 77. 解決案 • AWSアカウントを案件毎に分けて、別クラスタ を構築出来るようにする – 1クラスタにしない理由 • 規模によって別構築したい • 一度本番稼働している環境をいじるのが怖い – 1アカウントで管理しない理由 • オペレーションまざるのが怖い
  78. 78. 手順共通化したし 行けるのでは…!
  79. 79. 現実 • AMI移動( or BaseAMI作り直し) • Keypair設定 • AWSキー更新(*1) • アプリケーションの改修 – MySQL/Redisサーバ/インスタンスの数 • 案件/インスタンスタイプに合わせたワーカー数設定 – アプリケーション(gunicorn/cluster/starman)・SQSワーカー など • これらの再設定が終わったらchef実行し直す… • まーめんどい (*1) IAMロールは使わない
  80. 80. さらなる解決案
  81. 81. 案件ごとのコンフィグレーションを 一元管理してしまおう
  82. 82. Omniscient
  83. 83. Omniscient • サービス全体のコンフィグレーションを管理 • 管理軸 – 案件毎/環境毎(dev/staging/stress/production) • アプリケーションコンフィグ(おまけ) – サービス毎のエンドポイント – サービス毎のオプション設定 • インフラコンフィグ – AWS情報 – キャッシュ/Redis/RDS/などDBのエンドポイント – ワーカープロセスの数 – 自社製RedisClusterのコンフィグ設定
  84. 84. Omniscient概要図 クラスタ起動。同時に インスタンスの情報を Omniscientに登録定期的にOmniscientの 情報をPullし、更新され たらサーバに反映 クラスタ起動。同時にイ ンスタンスの情報を Omniscientに登録。 アプリ側は取得して反映
  85. 85. 移行コスト改善〜♪
  86. 86. Serfも検討したが… • Serf – オーケストレーションツール – ゴシッププロトコロルを用い、クラスタ全体に何ら かのメッセージを伝搬 • 検証 – 複数軸で管理しようとした時、逆に複雑に • よい方法があれば〜
  87. 87. ここまでが 運用改善の話 (その2)
  88. 88. さらに改善して いきたいこと
  89. 89. やりたいこと一覧 • Docker化 – 開発環境配布 – サービス環境配布 – プロダクション? • MIESサービス統合管理 • Omniscientゲートウェイ計画 • RakeタスクのGolang化
  90. 90. まとめ
  91. 91. • TV案件では24時間365日稼働サー ビスとはがんばるところ/手を抜け るところが違う • 要件に合った運用改善〜 • まだまだ改善したい〜 • 本番怖い
  92. 92. おまけ情報 • Rakeタスク/サンプルファイルなどブログにお いてありますのでご参照下さい(若干古い) – http://d.hatena.ne.jp/toritori0318/20130916/1379355060 – https://github.com/toritori0318/vagrant-aws-sample
  93. 93. ご清聴ありがとう ございました

×