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

2014年YAPCで発表した資料です

Transcript

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