fabric + amazon ec2で快適サポート生活 #pyfes

Fabric + Amazon EC2で快適サポート生活

2013/07/27  @shiumachi  

アジェンダ  

•  前回のおさらい:  Fabric  とは  •  サポートにおける課題  •  EC2  を使った検証環境の構築  

お前誰よ？  

•  Sho  Shimauchi    (  @shiumachi  )  •  Cloudera  の問い合わせ担当  

←付録B、C、D書きました  

おことわり  

•  今日話す内容は、私が個人で行っているもので、会社全体でやってるわけじゃないです  

•  あくまでこういうやり方もありますよ、というアイデア程度のものと認識してください  

2013.03  

drillbitsによる  Fabric  の紹介  

Fabric  

•  Python製デプロイ・システム管理支援ツール  •  アプリケーションのデプロイやシステム管理

のコマンドをSSHで実行  •  作成したスクリプトはコマンドラインから実行

可能  

特長    

特長  マジ簡単  

Fabricスクリプトの例  

from  fabric.api  import  run    def  host_type():          run('uname  -­‐s')  

Fabricスクリプトの例  

from  fabric.api  import  run    def  host_type():          run('uname  -­‐s')  

関数名  =    実際のコマンド  

Fabricスクリプトの例  

from  fabric.api  import  run    def  host_type():          run('uname  -­‐s')  

関数名  =    実際のコマンド  

リモートマシンで  実行するコマンド  

Fabricコマンドの実行例  

$  fab  -­‐H  localhost,linuxbox  host_type  

Fabricコマンドの実行例  

$  fab  -­‐H  localhost,linuxbox  host_type  

ターゲットのホスト名  “localhost”  と  “linuxbox”  

Fabricコマンドの実行例  

$  fab  -­‐H  localhost,linuxbox  host_type  

ターゲットのホスト名  “localhost”  と  “linuxbox”  

関数をコマンド  として実行  

Fabricコマンドの実行例  $  fab  -­‐H  localhost,linuxbox  host_type  [localhost]  run:  uname  -­‐s  [localhost]  out:  Darwin  [linuxbox]  run:  uname  -­‐s  [linuxbox]  out:  Linux    Done.  DisconnecUng  from  localhost...  done.  DisconnecUng  from  linuxbox...  done.  

Fabricコマンドの実行例  $  fab  -­‐H  localhost,linuxbox  host_type  [localhost]  run:  uname  -­‐s  [localhost]  out:  Darwin  [linuxbox]  run:  uname  -­‐s  [linuxbox]  out:  Linux    Done.  DisconnecUng  from  localhost...  done.  DisconnecUng  from  linuxbox...  done.  

localhost  

linuxbox  

Fabricコマンドの実行例  $  fab  -­‐H  localhost,linuxbox  host_type  [localhost]  run:  uname  -­‐s  [localhost]  out:  Darwin  [linuxbox]  run:  uname  -­‐s  [linuxbox]  out:  Linux    Done.  DisconnecUng  from  localhost...  done.  DisconnecUng  from  linuxbox...  done.  

localhost  

linuxbox  

リモートマシンで コマンドが実行された  

マジ簡単  

2013.04  

マジ大人気  

話は変わって、サポートの話  

•  ベンダーサポートのメイン業務は障害対応  •  障害対応のキモは現象再現  •  現象再現のキモは環境再現  

理想  全てのお客様の環境の複製を  

社内に持っている  

理想  全てのお客様の環境の複製を  

社内に持っている  

現実  そんなの無理  

サポートの観点からの検証環境  種類   長所   短所  

ローカルマシンのVM   手軽に使える  (VM起動ソフト以外は)無料  

リソースの制約が厳しい(CPU、メモリ、ディスク全て)  

社内共有サーバ   比較的豊富なリソースを確保できる  全員で共有するので1人当たりの設備投資は比較的安価  

サーバ自体の専有が難しい  破壊的な検証ができない  長期的に見れば安くても、イニシャルコストは結構かかる  

クラウド環境   手軽に使える  イニシャルコストがかからない  破壊的な検証も容易    

ネットワークがない環境だと使用不能  ランニングコストは結構かかる  

サポート用環境と他の環境の違い  構築期間   運用期間   環境の種類  

Webサービスの環境  

数日〜数週間   1年〜数年  (ただし頻繁に更新する)  

そこそこ多い  

エンタープライズシステム  

数ヶ月〜数年   数年以上   ほとんどない  

サポート用環境              

サポート用環境と他の環境の違い  構築期間   運用期間   環境の種類  

Webサービスの環境  

数日〜数週間   1年〜数年  (ただし頻繁に更新する)  

そこそこ多い  

エンタープライズシステム  

数ヶ月〜数年   数年以上   ほとんどない  

サポート用環境   数分〜数時間  (設計含む)  

数時間〜数日   コンポーネントの組み合わせ数だけある(事実上無限)        

サポート用環境と他の環境の違い  構築期間   運用期間   環境の種類  

Webサービスの環境  

数日〜数週間   1年〜数年  (ただし頻繁に更新する)  

そこそこ多い  

エンタープライズシステム  

数ヶ月〜数年   数年以上   ほとんどない  

サポート用環境   数分〜数時間  (設計含む)  

数時間〜数日   コンポーネントの組み合わせ数だけある(事実上無限)  しかも、「間違った」環境を構築する必要もある  

サポート対象のソフト  

•  約20種類  •  メジャーバージョン2つ、それぞれにマイナー

バージョンが5つ、計10バージョン  •  これらのバージョンが組み合わせて使用され

る  

Hadoop:  サーバの数が多い  

マスタ1   マスタ2   マスタ3  

スレーブ  スレーブ  

スレーブ  スレーブ  

スレーブ  スレーブ  

スレーブ  スレーブ  

クライアント  

管理  サーバ  

解決策:  fabric  +    EC2  スポットインスタンス  

•  環境の組み合わせ数が多く、しかも毎回異なる  – chef  /  ansible  などよりも毎回カスタマイズして構

築する方が速い  

•  環境は使い捨て  – スポットインスタンスなら安く済ませられる  

Amazon  EC2  スポットインスタンス  

•  安い  – m1.large  だと価格は通常の20%以下  – 1時間あたり6.7円  

•  永続化できない  – 停止したら削除  

m1.large  通常のインスタンス  

35円  /  時間  

m1.large  スポットインスタンス  

6.7円  /  時間  

基本戦略  

•  ローカル環境(VMなど)で再現できるなら、極力そちらを使う  

•  EC2  を使うのは必要な場合だけ(サーバ間の通信の問題やソフトウェアの組み合わせ時の調査など)  

基本戦略  

•  ローカル環境(VMなど)で再現できるなら、極力そちらを使う  

•  EC2  を使うのは必要な場合だけ(サーバ間の通信の問題やソフトウェアの組み合わせ時の調査など)  

•  手動でやった方が早いかどうかのトリアージが重要  – サポートは1分1秒を争う仕事  

現象再現までの流れ  

インスタンスの起動  

OS周りの構築  

ソフトウェアの環境構築  

現象再現の試行開始  

テストデータの投入  

現象再現までの流れ  

インスタンスの起動  

OS周りの構築  

ソフトウェアの環境構築  

現象再現の試行開始  

テストデータの投入  

手動で起動している  毎回必要な数も違うた

め、スクリプト化するより手動の方が速い  

頻度が上がったら自動化するかも  

現象再現までの流れ  

インスタンスの起動  

OS周りの構築  

ソフトウェアの環境構築  

現象再現の試行開始  

テストデータの投入  

Fabric  で構築スクリプトを保持  

作成後はAMI(EC2上のディスクイメージみたい

なやつ)として保存  ここは  Chef  /  ansible  を

使ってもいいかも  

現象再現までの流れ  

インスタンスの起動  

OS周りの構築  

ソフトウェアの環境構築  

現象再現の試行開始  

テストデータの投入  

どのコンポーネントをインストールするか、などをFabric

コマンドから選択  インストール後の設定もここ

で行う  バージョンの違いはここで吸

収する  

現象再現までの流れ  

インスタンスの起動  

OS周りの構築  

ソフトウェアの環境構築  

現象再現の試行開始  

テストデータの投入  

調査対象のソフトや、お客様のユースケースによってテストデータの種類が異な

る  まだ自動化できてないので、データ生成から自動化した

い  

現象再現までの流れ  

インスタンスの起動  

OS周りの構築  

ソフトウェアの環境構築  

現象再現の試行開始  

テストデータの投入  

多くの場合手動での作業  同一の手順が増えたら自動

化する  

実際のスクリプトはこんな感じ  

サポートとしてのFabricの使い方  

•  「手順書書くよりFabric」  •  「メモ帳に残すよりFabric」  •  大抵は同じ環境は二度と使わない  •  しかし、場合によっては一週間後に使うかもし

れない  •  サポートは救急隊員  – 手動の方が早い場合も多い  – 自動・手動のバランスをとりましょう  

よくある質問  Q.  冪等性はどうなるの？  A.  Chef  とか Ansible  を使ってください    Q.  インストールにも  Fabric  は使えるの？  A.  以下の場合は最初から  Chef  /  Ansible  を使いましょう。  -­‐  環境の再利用性が高い  -­‐  そこそこ複雑な構成  これらのツールは学習コストが高いので考えなしに突撃するのはおすすめしない  

よくある質問  

Q.  実運用するときにfabfileを1つだけ作るのか、それとも分けた方がいいのか  A.  場合によりますが、今後修正・拡張するなら分けた方がいいかと    Q.  fabtool  とか  cuisine  はいつ使えばいいの？  A.  fabric  だけで書くのがめんどくなったと感じたときに調べればいいと思います  

よくある質問  Q.  sudo  するときにパスワード入れるのめんどくさい  A.  /etc/sudoers  に NOPASSWD  追加してください  

Q.  同じIPを env.host  に設定するとどうなるの？  A.  ダブりは削除されます  

Q.  標準出力のサイズが大きいとどうなるの？  A.  プロセスが止まって結果が返ってこなくなるかも  

Q.  SSHのポートが22番と異なるときはどうすればいい？  A.  host:port  で普通に指定できます    

おしまい