Chefを利用した運用省力化とDevOpsの取り組みについて

- DevLove Conference 2012 -

Chefを利⽤した運⽤省⼒化と
DevOpsの取り組みについて

並河祐貴 (Yuuki NAMIKAWA)
id:rx7 / @namikawa

1

自己紹介
並河祐貴 (a.k.a. id:rx7)

(株)サイバーエージェント所属
エンジニア
Blog: http://d.hatena.ne.jp/rx7/
Twitter: @namikawa

著書・寄稿多数

2

これまでのキャリア
海岸沿いのSIer (2004〜2008)
先端技術調査・導入(R&D)、現場PJ支援(SI)
社内システム企画・運用、社内教育

SonicGarden (2008〜2010)
B2B/B2C向けWebサービス、クラウド導入支援
企画/営業/PR/サービス構築/運用/顧客サポート

CyberAgent (2010〜)
Webサービス構築/運用/いわゆるマネジメント

3

今日の話は・・・
弊社のサービスとそれらの運用について
最近のアメーバピグのシステム構成とか
DevOpsの話はあまりしませんごめんなさい

Chefを利用したプログラマブルなシステム基盤
実際に使ってどうだったか

つまり主に「Chef」の話をしに来ました！

4

アメーバピグ (Ameba Pigg)

5

アメーバピグ (Ameba Pigg)
アバター仮想空間サービス
きせかえ、おでかけ、ゲーム
– カジノ、つり、ライフ(庭)、アイランド(島)、カフェ(店)、
ワールド(街)

ユーザ数
1300万人 (2012/09, Amebaユーザの約半数)

トラフィック (アバター/ゲーム)
約7〜8Gbps / ピーク帯

同時接続ユーザ数 (アバター/ゲーム)
約40万ユーザ / ピーク帯
6

アメーバピグのアーキテクチャ

Other...

HTTP

Web

User TCP memcached
Socket (or none)

Socket
(Java or node.js...)

アバターサービスとゲームで
DB
実装言語やミドルウェアは (MySQL or MongoDB...)
異なりますが、基本的な構成は
同一となります。
7

これまでの(主にシステムの)変遷
本体(アバターサービス)だけでも・・・
自作サーバ導入
DBにFusion-ioのハードウェアを採用
Chefの導入
ネットワーク回線・LBの統合
データセンター移設
2系統化によるメンテナンス時間短縮

8

ピグでのシステム運用スタイル
職種は一応存在する
アプリエンジニア(Dev?)
インフラエンジニア(Ops?)...

チーム・体制
各施策ごとに機能開発を担当するチーム
非機能部分(性能・安定・効率化)を担当するチーム

基本的にシステム運用は全員プレイ
モニタリングも
障害対応も
リリースやサーバ設定も
当番はありますが、基本的にエンジニア全員で担当します

9

システム運用する上で
運用改善の過程でツールによる作業効率化
アプリケーションのデプロイ
サーバを増設する
設定変更を反映する
...etc

アプリ/インフラ双⽅の協⼒が必要
セットアップ、パフォーマンスチューニング、トラブ
ルシューティング...

DevとOpsで作業の境界は一切設けていないです
タッグを組まないと解決できない課題が多数

10

僕が今の会社に入って
一番最初にやった仕事

12

ピグのWeb/APサーバを3台増設
その時に渡された手順書(1台分)

13

アメーバピグの規模感
アメーバピグ
サーバ台数: 約270台
– Web/APサーバ40台、Socketサーバ70台
– DB(MySQL+FIO)サーバ6台 x 2(スタンバイ)
– API, Storage, Hadoop Cluster, Mobile, Smart Phone
– Auth, Ranking, Backup etc

ピグライフ
サーバ台数: 約280台
– Socket(node.js)サーバ80台、DB(MongoDB)サーバ150台
– Statサーバ20台、Log管理・解析、Smart Phone…etc

ピグアイランド・ピグカフェ・ピグワールド
ライフとほぼ同等のシステム構成
サーバ台数は、3サービスで約440台
(テスト環境もあわせると) サーバ台数は、ざっと1000台超の規模
15

1000台規模のサーバ群
DCは3箇所に分散 ⇒ 1箇所へ集約中

ほぼ物理サーバ + 一部社内クラウド + CDN
次は、パブリッククラウドも

監視はmon + munin
monにはかなり限界を感じているのでリプレースを検
討中...

全サーバを「Chef」で管理

16

ピグのサーバ増設・運用管理
サービス・システム規模、共に右肩上がり

急な増設を求められることもあります
ビッグイベントにあわせて30台入れちゃうとか
想定を超えるスピードでサービスが成⻑するとか

数十台のサーバに同じ設定を入れたりも

そこで「Chef」を使ってみました

17

それ、
クラウド使ったら
でｋ（ｒｙ
クラウドも、運用を効率化する1要素

ミドルウェアの設定管理や、プロセスの状態管理も
含めて今回は「Chef」で自動化する話をします

18

Chefの概要

http://www.flickr.com/photos/jonathanbeard/3307862620/ 19

「Chef」とは
サーバの構築作業やシステム管理のツール
システムのあるべき状態を設定する
オープンソース、Ruby製

利用実績
37signals
Engine Yard
Rackspace hosting
etc…


サーバ構築・システム管理自動化の必要性

手作業では、そもそも時間がかかる
数十台、数百台のレベルになると・・・
同じ役割のサーバごとに環境差異が発⽣したりとか
サーバ投入までのリードタイムが⻑くなることで
機会損失を発⽣させることは避けたい

人為的なミスを抑えたい
作業漏れ、ルーチン作業でのオペミス
作業者によって、スキルにバラつき
運用中のサーバでのミスは特に無くしたい
設定に間違いがあっても自動化しておく事で即修正可能


それ、シェルスクリプトでよくね？
サーバの状態が記述できるフレームワーク
基本的なタスクが備わっている
管理タスクの品質をできるだけ揃える

Chefでは内部DSLを採用
Rubyでの柔軟な記述ができる

プラットフォームの差異が吸収できる
ディストリビューションによってコマンドに差異
yumとaptとか

http://www.flickr.com/photos/photomequickbooth/4062072718/ 22

Chefのシステムアーキテクチャ

Ruby
CouchDB Solr
Merb(Rack)
CouchDB
Chef-Solr
Indexer
Solr
RabbitMQ
Chef-Server
RabbitMQ (Java)
API
(Erlang)
Chef-Server
HTTP(REST)
WebUI JSON
Chef-Client
Chef-Client Knife
Chef-Client
Client


Chefでの”主な”登場人物
Node
Role
Cookbook
Recipe
Template
Attribute

時間の都合上、基本を簡単にご紹介します


Node, Role, Cookbook の関連(例)

nginxのCookbook

サーバA
APサーバの
Passengerの
Role
Cookbook

サーバB
RubyのCookbook

サーバC gitのCookbook

Node Role Cookbook

管理対象の管理対象のシステムのあるべき形を
サーバグルーピング定義する設定


Recipe、Templateの一例
./recipe/default.rb ./templates/default/ports.conf.erb
package "apache2" do Listen <%= port %>
action :install NameVirtualHost *:<%=port %>
end

template "/etc/apache2/ports.conf" do
source "ports.conf.erb" ./attributes/default.rb
owner "root"
default[:port] = “8080"
group "root"
mode 0644
variables(
:port => node[:port]
)
end
“port”:”80” “node A”の情報を保持
[Node Attribute],
service "apache2" do
[Run List] 等
action [ :enable, :start ] 実⾏するrecipeの設定
end

chef-client
node A 実⾏ Chef-Server


Chefで利用できるResource
Cookbook File Mount
Cron Ohai
Deploy Package
Directory PowerShell Script
Erlang Call Remote Directory
Execute Remote File
File Route
Git Ruby Block
Group SCM
HTTP Request Script
Ifconfig Service
Link Subversion
Log Template
Mdadm User


Chefのちょっとイケていないところ
サーバのセットアップが面倒くさい
サーバセットアップは最初だけなので許容できる
Ubuntuだと割と楽かも。クライアントは簡単

名前がSEO的に致命的
Chef, Cookbook, Recipe, knife...
リアルに調べ物をする時に困ります

(dry-runができない)
テスト環境が必須 (クラウド・仮想化が最適)
10.14系から利用可能に！
http://www.flickr.com/photos/photomequickbooth/4062072718/ 29

Chefの運用


Chefを活用したサーバ増設
PXE + kickstart + Chef
1. 事前に chef-server 側でNodeの設定が必要
2. サーバに線を繋ぎ電源ON、PXEブート開始
3. Label No.とNode名を入⼒し、OSインストール開始
4. 同時に chef-client のインストールと設定
5. kickstart の %post で chef-client を実⾏
kickstartのcfgファイル

通常のOS
インストールタスク通信
client PXE+ksサーバ
chef-clientのインストール

OSインストール後通信
chef-clientの設定
は直接通信
chef-clientの実⾏
Chef-Server


Kickstartでの %post スクリプト
1. Chef Clientのインストール
2. /etc/chef/client.rb の配置
3. “node_name”を取得・上記ファイルに設定
4. /etc/chef/validation.pemを配置
5. chef-clientコマンドを実⾏
実際のOSインストール時にPXE Boot時に⼊⼒するラベル例

boot: 1 node=chef-test01


Chefを活用したサーバ増設
今はオンプレミスな物理環境を想定

クラウド環境でも応用可能
EC2だと、事前にAMIを作成しておいて、user-dataに
Node名を指定して...
(弊社のOpenStackクラウド基盤を活用)


Cookbookの使い⽅
Cookbookの例
ネットワーク設定
H/Wに必要な設定
– 主にH/W固有で必要なドライバやRAIDチェックスクリプト等
各サーバ共通で必要な設定
– DNS, NTP, LDAP, 監視ライブラリ, 鍵交換等
各Roleで必要な設定

NodeへのCookbook設定例 RoleへのCookbook設定例
{ {
"run_list": [ "run_list": [
"recipe[network::xxxxx]", "recipe[ameba-common::pigglife]",
"recipe[hw::dell_r310]", "recipe[pigglife-mongodb::mongod]"
“role[pigglife-mongodb]" ]
] }
}


Chefを使う上でやっていること
Script Resource は基本的に使わない
何度でも実⾏される
chef-client実⾏時のチェック・運用が面倒
何度実⾏しても問題ないものしか使わない

過去、こんな感じで書いていました...
script “script_name" do
interpreter "bash"
user “username"
creates comp_dir + “script_name.done"
code <<-EOH
command
......
......
EOH
end


各nodeのChef適用は、chef-clientを実⾏
tomahawk: 複数のサーバで同じコマンドを実⾏
“knife ssh”, “knife ssh_cheto” 等も

NodeのAttributeの登録
JSONファイルを自動⽣成して登録・バージョン管理
RoleもJSONファイル形式でバージョン管理

アンインストール・削除等の処理も忘れずに

Environment(0.10〜)の活用
development, staging, productionの分別


verbose_logging false
デフォルトではInfoログが出過ぎる
影響のあった変更処理のみロギング

why-run (0.10.14〜)
Chefでの処理をnodeに反映しないテストモード

CouchDBのバックアップ
Chefサーバのバックアップ、/etc/chef 以下も
– (Chefリポジトリをバージョン管理していて、そちらのバック
アップがあれば特に必要ないかも)


Chefを運用する上での課題
Recipeが正しいことを保障するには？
仮想マシン等を活用してテスト
– VirtualBoxの制御ができるVagrantが便利
– 本当に正しい処理が⾏われているかは人手での確認が必要

why-run
– これも人手での判断が必要

Recipeのユニットテスト
– 場合によっては十分、nodeが正しい状態を保障しきれない

nodeでの自作チェックスクリプト・F/W


Cookbookでのコミュニケーション
セットアップ手順のチェックをRecipe
(Cookbook)という名のコードベースで
DevとOpsのクロスチェック

Cookbook/Node/Role等、バージョン管理して
いるので、過去との差分も確認しやすい

誰でもRead/Writeできる場所にあるので、みん
なでメンテナンスできる

DevとOpsの新しいコミュニケーションツール


これからChefを勉強する⽅へ
chef-solo が便利
chef-server を必要とせず、ローカルにCookbookを
適用できる
小環境ならこれで十分
他にも、VMとかでテストとか練習とか

Chefのインタラクティブシェル
“shef”

Opscode Platform (Hosted Chef)
Chefのホスティング環境 (サーバ)
5 nodes までなら、無料で試せる


まとめと今後の展望
Chefを活用することで多くのサーバの増設・管理
にかかる負担を軽減
あるべき状態に自動で設定・維持できる
ルールを少し覚えれば、誰でも簡単に設定が書ける
内部DSLなので、Rubyを覚えれば処理も柔軟に書ける

クラウド等の基盤サービスと連携して、インフラ
構築/運用の完全オートメーションができる仕組
みにしたい


Chefでサーバ管理の省⼒化
をはじめてみませんか？


Chefを利用した運用省力化とDevOpsの取り組みについて

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie Chefを利用した運用省力化とDevOpsの取り組みについて

Ähnlich wie Chefを利用した運用省力化とDevOpsの取り組みについて (20)

Mehr von Yuuki Namikawa

Mehr von Yuuki Namikawa (11)

Chefを利用した運用省力化とDevOpsの取り組みについて