泥臭い運⽤から、プログラマブ
ルインフラ構築(に⾏きたい)

   株式会社サイバーエージェント
   アメーバ事業本部プラットフォームディビジョン
   システムディベロップメントグループ
   CA Developers Connect
                           桑野   章弘
自己紹介

桑野章弘
 インフラエンジニア
   アメーバピグ/ピグライフのインフラを担当
 Twitter
   http://twitter.com/kuwa_tw
 Blog
   http://d.hatena.ne.jp/akuwano/
 著書/活動
   「MySQLによるタフなサイトの作り方」
   勉強会(hbstudy, qpstudyほか)などでの発表など
 qpstudy
   普段は「キユーピー3分インフラクッキング -初心者にも優しいイン
   フラ勉強会」で活動しております。


                                      2
自己紹介

qpstudyって?
 「キユーピー3分インフラクッキング -初心者にも優し
 いインフラ勉強会」ですw
 https://sites.google.com/site/qpportal/
 今までやったこと
   より対選手権
   インフラ本当にあった怖い話
   インフラクイズ王決定戦
 なんでインフラのなのにここにいるんでしょう?
   わかりません。
   ぱぱんださんの性^Hおかげです。




                                           3
自己紹介

あだ名「銀河さん」
「なんで?」
たまに聞かれる
 なんでか世界の桑野さんと呼ばれる
 →宇宙の桑野さんになる
 →銀河の歌姫桑野さん
 →めんどくさいから銀河でいいんじゃね?
 →やーい!銀河!銀河!
 →・゚・(つД`)・゚・ ウェ―ン
 Twitterで盛り上がるとその後の人生に影響するのでユメユメ
 お気をつけ下さい




                                   4
自己紹介

今回はDevLoveさんということで
 ⾃重せずにインフラの話全開で⾏きたいと思い
 ますw
 ピグライフの運⽤を題材にしていきます。




                         5
ピグライフ




  ピグライフって?




             6
ピグライフ

ピグライフって?
箱庭系サービス
アメーバピグのキャラクターで⾃分だけの庭を
つくろう!




                        7
ピグライフ




        8
ピグライフ

ピグライフって?
 ガーデニング
 裁縫
 料理
 ティーパーティー
 羊がモッフモフ!、、、じゃなくて動物飼ったり




            モッフモフ状態→
 して楽しめます!

                          9
ピグライフ:サービス概要




   サービス概要




               10
ピグライフ:サービス概要

サービス規模
トラフィック - 1.3Gbps
総コネクション数 - 18万
サーバ台数 – 200台弱
主な使⽤ミドルウェア
 Node.js
 Nginx
 MongoDB




                   11
ピグライフ:アーキテクチャ概要
                                      BackEnd
            FrontEnd

                                                 ユーザ/エリ
                                                 ア等の状態
   staticサーバ             Node.jsサーバ
                         Socketサーバ
                                                  データ


                                        mongodbサーバ
       Flashデータ            必要なデータ
       →リクエスト               の取得
          /取得
HTTP

           WebSocket接続


                  ・ユーザ情報
                   ・チャット
                    データ
                  →リクエスト
                    /取得
 ユーザ
(ブラウザ)


                                                          12
ピグライフ:アーキテクチャ概要
                                      BackEnd
            FrontEnd

                                                 ユーザ/エリ
                                                 ア等の状態
   staticサーバ             Node.jsサーバ
                         Socketサーバ
                                                  データ


                                        mongodbサーバ
       Flashデータ            必要なデータ
       →リクエスト               の取得
          /取得
HTTP

           WebSocket接続


                  ・ユーザ情報
                   ・チャット
                    データ
                  →リクエスト
                    /取得
 ユーザ
(ブラウザ)


                                                          13
ピグライフ:現サーバ構成
                     リリース時切替




          ×7            ×7                  ×15             ×15
                                                           Node.jsサーバ_B系
                                   mongos         mongos

Staticサーバ_A系 Staticサーバ_B系    Node.jsサーバ_A系




                                                       3台1セット *
                                                       45 = 135台
                                 ・・・・・




                    MongoDB


                                                                           14
ピグライフ:サービス概要

かなり大規模なサービスになってきていま
す
サーバ規模にして8倍
そうなるとリリース当初とは事業軸として
の位置づけも変わってきました。




                      15
ピグライフ




 サービスエンジニア




             16
サービスの事業軸

サービスエンジニア
というか、サービスを提供するエンジニアとし
て何を重視するべきでしょうか。
やはりおまんま食べれてるのは⾃分の事業です
よね。事業軸を整理してみます。




                        17
サービスの事業軸

安定運⽤ or 様々な挑戦
 新しい技術や、機器にチャレンジ
 1度のダウンが⾊々な物に影響することになる
事業継続(スピード感)
 新しい物を素早くリリースする必要がある
 そのためのインフラも整えないと⾏けない
 作業も増える、サーバも増える




                         18
サービスの事業軸

       安定運⽤   技術的挑戦 スピード感



サービス   ケースバイ 重視    重視
規模 小   ケース


サービス   重視     慎重   重視
規模 大



                            19
サービスの事業軸

開発のスピード感はどのフェイズにおいて
も大事
インフラとしては必要な作業を各サーバでの作
業として必要となります。
 クラウドでも、オンプレミスでも変わらない
大量のサーバで作業するためのフレームワーク
を考えていきたいと思います




                        20
各種自動化の方法

⾃動化の方法
幾つかあります
よく使われる方法を紹介して⾏きます




                    21
自動化その1

カッタンカッタン




           22
自動化その1

はた織り(勝手に名づけました)




                  23
はた織りの特徴

右手と左手の連携が試される
Enterキーのタイミングを間違えると大変なこ
とに
熟練のはた織り職人はこれで100台以上のサー
バ管理もこなすと⾔われます。
 かつての僕です。
これは⾃動化ではありませんw
が、今やらなきゃいけない作業とかの場合には
仕方なしにやらないと⾏けない場合も。。。場
合も。。。。゚(゚´Д`゚)゚。


                          24
TeraTermPro アシスタント

TeraTermPro アシスタント




                      25
TeraTermPro アシスタントの特徴

複数のTeraTermProに同時に同一コマン
ドを送るアプリケーション
 便利っちゃ便利。
 でも、画面小さくて確認できなくないすかw
 余り良くない
 これも⾃動化ではない




                          26
tomahawk

tomahawk




            27
tomahawkの特徴

サーバリストのIP、ホスト名のサーバに対
してSSH、rsyncするWrapper
 管理サーバから一括して作業を⾏うことが可能
  ログ収集
  ファイル配布
  サーバ停止、起動
  などほぼすべて
  手作業にはなる
 シェルスクリプト等と併⽤することで⾃動化す
 ることが可能
  SSHのノンパスの設定等を入れる必要あり
 デモ

                         28
tomahawkの特徴




kuwano@kuwano03:~$ tomahawk -p 4 -t 120 -c -f webserver.list -l -u kuwano "uptime"
Enter a password for ssh authentication:PASSWORD

kuwano@192.168.100.146 % uptime
 15:42:01 up 19 days, 3:57, 1 user, load average: 0.02, 0.03, 0.03

kuwano@192.168.101.45 % uptime
 15:42:04 up 11 days, 12:27, 2 users, load average: 0.01, 0.03, 0.00

kuwano@kuwano03:~$




                                                                                     29
tomahawkの特徴


kuwano@kuwano03:~$ tomahawk-rsync -f webserver.list -l -m push -u kuwano_akihiro ¥
                        /src/test.txt /dst/test.txt
Enter a password for ssh authentication:PASSWORD

% rsync -av /src/test.txt kuwano_akihiro@192.168.100.146:/dst/test.txt
building file list ... done
test.txt
sent 2674 bytes received 42 bytes 1810.67 bytes/sec
total size is 2547 speedup is 0.94

% rsync -av /src/test.txt kuwano_akihiro@192.168.100.147:/dst/test.txt
building file list ... done
test.txt
sent 2674 bytes received 42 bytes 1810.67 bytes/sec
total size is 2547 speedup is 0.94

kuwano@kuwano03:~$




                                                                                 30
chef

chef




        31
chef

chef




        32
chefの特徴

Opscode社製のサーバ構築⾃動化ツール
recipeと呼ばれるDSLを使ってサーバに⾏
う処理を定義する
 DSLはRubyを基本とした記述が可能
各サーバでchef-clientを実⾏する事で
recipeを適⽤する




                          33
chefの特徴




          34
chef の実⾏例

レシピ実⾏例
yumのRPMインストール
# - web serverの場合 -
$ sudo yum install httpd

# - DB serverの場合 -
$ sudo yum install mysql-server




                                  35
chef の実⾏例

レシピ実⾏例
  yumのRPMインストール
# web-server
if node[:user_attr][:socket_server_type] == "web" then
  # 必要パッケージのインストール
  %w{httpd java}.each do |package_name|
   package package_name do
    action :install
   end
  end

# db-server
elif node[:user_attr][:socket_server_type] == "db" then
 # 必要パッケージのインストール
 %w{mysql-server mysql-client}.each do |package_name|
   package package_name do
     action :install
   end
 end
end


                                                          36
chef の実⾏例

レシピ実⾏例
Hostsファイルの変更(本番とステージングで
異なるファイルにする)
# - ステージングサーバの場合-
$ sudo scp kuwano@remoteserver:/hogehoge/hosts_staging /etc/hosts

# - 本番サーバの場合 -
$ sudo scp kuwano@remoteserver:/hogehoge/hosts_product /etc/hosts




                                                                    37
chef の実⾏例

レシピ実⾏例
Hostsファイルの変更(本番とステージングで
異なるファイルにする)
# hostsのコピー
# - ステージング環境の場合
if node[:user_attr][:product] == "stging" then
  template "/etc/hosts" do
   source "hosts_stagins.erb"
   mode "644"
  end
# - 本番環境の場合
elif node[:user_attr][:product] == "product" then
  template "/etc/hosts" do
   source "hosts_product.erb"
   mode "644"
  end
end




                                                    38
chef の実⾏例

レシピ実⾏例
ファイルのリリースSVNからの
CheckOut/Deploy(ちょっとダサいです)
# チェックアウト
$ svn co http://subversion.example.com/repos/ameba/trunk ¥
/opt/ameba/apps/




                                                             39
chef の実⾏例

レシピ実⾏例
ファイルのリリースSVNからの
CheckOut/Deploy


# アプリケーションのDeploy
subversion "Ameba Apps" do
 repository "http://subversion.example.com/repos/ameba/trunk"
 revision "HEAD"
 destination "/opt/ameba/apps"
 action :sync
end




                                                                40
アプリエンジニア?インフラエンジニア?

アプリエンジニアはインフラをやらない?




                      41
アプリエンジニア?インフラエンジニア?

アプリエンジニアはインフラをやらない?




                      42
アプリエンジニア?インフラエンジニア?

アプリエンジニアでもできることがあります
 手や、Teraterm
   ちょっと⾃動化はできない
 Tomahawk
   シェルスクリプト等と組み合わせることで⾃動化可能
 Chef
   各種DSLを使⽤することでプログラマブルにインフラ構築が可能

アプリエンジニアの方が得意かもしれません。




                                    43
アプリエンジニア?インフラエンジニア?

アプリエンジニアはインフラができない?
 アプリエンジニアがインフラエンジニアと⼒をあわせる
 事(その逆も)でよりよいシステム構築を⾏う
 それが今よく⾔われているDevOpsにつながります。
 DevOps=「開発者と運⽤者の間の壁を取り払うための
 ベストプラクティス」という考え方といえます
 そしてサーバを直接入って作業をするような泥臭い作業
 を減らす事が目標です。




                           44
ピグライフ:まとめ

まとめ
 インフラ構築/作業も開発者の皆様の協⼒でより良い
 ものができます!
 ココではChef等を例に取りましたが、クラウド等を使
 う場合も同様です
 是非一度DevもOpsを⾒て、OpsもDevを⾒れるよう
 な環境を目指してみると幸せな環境になるかもしれま
 せん。
 一緒に頑張って⾏きましょう!




                                45
まとめ




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


             46
ピグライフ:参考

Chef
 http://www.opscode.com/chef/
tomahawk
 https://github.com/oinume/tomahawk
TeraTermPro アシスタント
 http://www.vector.co.jp/soft/win95/n
 et/se276622.html
はた織り技法
 @kuwa_twまで。

                                        47

泥臭い運用から、プログラマブルインフラ構築(に行きたい)