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

1

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

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

- DevLove Conference 2012 -

2

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

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

� 著書・寄稿多数

3

これまでのキャリアこれまでのキャリア� 海岸沿いのSIer (2004〜2008)

�先端技術調査・導入(R&D)、現場PJ支援(SI)�社内システム企画・運用、社内教育

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

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

4

今日の話は・・・今日の話は・・・� 弊社のサービスとそれらの運用について

�最近のアメーバピグのシステム構成とか�DevOpsの話はあまりしません�ごめんなさい

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

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

5

アメーバピグアメーバピグ (Ameba(Ameba PiggPigg))

6

アメーバピグアメーバピグ (Ameba(Ameba PiggPigg))� アバター仮想空間サービス

�きせかえ、おでかけ、ゲーム– カジノ、つり、ライフ(庭)、アイランド(島)、カフェ(店)、

ワールド(街)

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

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

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

7

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

User

Web

Socket(Java or node.js...)

memcached(or none)

DB(MySQL or MongoDB...)

HTTP

TCPSocket

Other...

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

8

これまでのこれまでの((主にシステムの主にシステムの))変遷変遷� 本体(アバターサービス)だけでも・・・

�自作サーバ導入�DBにFusion-ioのハードウェアを採用�Chefの導入�ネットワーク回線・LBの統合�データセンター移設� 2系統化によるメンテナンス時間短縮

9

ピグでのシステム運用スタイルピグでのシステム運用スタイル� 職種は一応存在する

� アプリエンジニア(Dev?)� インフラエンジニア(Ops?)...

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

� 基本的にシステム運用は全員プレイ� モニタリングも� 障害対応も� リリースやサーバ設定も

当番はありますが、基本的にエンジニア全員で担当します

10

システム運用する上でシステム運用する上で� 運用改善の過程でツールによる作業効率化

�アプリケーションのデプロイ�サーバを増設する�設定変更を反映する� ...etc

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

ルシューティング...

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

11

少し昔の話

12

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

13

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

15

アメーバピグの規模感アメーバピグの規模感� アメーバピグ

� サーバ台数: 約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台超の規模

16

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

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

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

討中...

� 全サーバを「Chef」で管理

17

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

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

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

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

18

それ、クラウド使ったらでｋ（ｒｙ

クラウドも、運用を効率化する1要素

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

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

Chefの概要


「「ChefChef」とは」とは� サーバの構築作業やシステム管理のツール

�システムのあるべき状態を設定する� オープンソース、Ruby製

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


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

� 手作業では、そもそも時間がかかる�数十台、数百台のレベルになると・・・�同じ役割のサーバごとに環境差異が発⽣したりとか

サーバ投入までのリードタイムが⻑くなることで機会損失を発⽣させることは避けたい

運用中のサーバでのミスは特に無くしたい設定に間違いがあっても自動化しておく事で即修正可能

� 人為的なミスを抑えたい�作業漏れ、ルーチン作業でのオペミス�作業者によって、スキルにバラつき

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

それ、シェルスクリプトでよくそれ、シェルスクリプトでよくねね？？� サーバの状態が記述できるフレームワーク

�基本的なタスクが備わっている�管理タスクの品質をできるだけ揃える

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

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


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

� Ruby� Merb(Rack)� CouchDB� Solr� RabbitMQ� (Java)� (Erlang)� HTTP(REST)� JSON

Chef-Server

API

Chef-Server

WebUI

RabbitMQ

CouchDB Solr

Chef-Solr

Indexer

Chef-ClientChef-ClientChef-Client Knife

Client


ChefChefでのでの””主な主な””登場人物登場人物� Node� Role� Cookbook

�Recipe�Template�Attribute

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


NodeNode, , RoleRole, , CookbookCookbook のの関連関連((例例))

サーバA

サーバB

サーバC

nginxのCookbook

PassengerのCookbook

RubyのCookbook

gitのCookbook

APサーバのRole

Node Role Cookbook

管理対象のサーバ

管理対象のグルーピング

システムのあるべき形を定義する設定


RecipeRecipe、、TemplateTemplateの一例の一例

package "apache2" doaction :install

end

template "/etc/apache2/ports.conf" dosource "ports.conf.erb"owner "root"group "root"mode 0644variables(:port => node[:port]

)end

service "apache2" doaction [ :enable, :start ]

end

Listen <%= port %>NameVirtualHost *:<%=port %>

default[:port] = “8080"

./recipe/default.rb ./templates/default/ports.conf.erb

./attributes/default.rb

node A Chef-Server

“node A”の情報を保持[Node Attribute],

[Run List] 等

chef-client実⾏

“port”:”80”

実⾏するrecipeの設定


ChefChefで利用できるで利用できるResourceResource� Cookbook File� Cron� Deploy� Directory� Erlang Call� Execute� File� Git� Group� HTTP Request� Ifconfig� Link� Log� Mdadm

� Mount� Ohai� Package� PowerShell Script� Remote Directory� Remote File� Route� Ruby Block� SCM� Script� Service� Subversion� Template� User

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

ChefChefのちょっとイケのちょっとイケてていないところいないところ� サーバのセットアップが面倒くさい

�サーバセットアップは最初だけなので許容できる�Ubuntuだと割と楽かも。クライアントは簡単

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

� (dry-runができない)�テスト環境が必須 (クラウド・仮想化が最適)� 10.14系から利用可能に！


Chefの運用


ChefChefを活用したサーバ増設を活用したサーバ増設� 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インストールタスク

chef-clientのインストール

chef-clientの実⾏

chef-clientの設定

client

Chef-Server

通信PXE+ksサーバ

通信OSインストール後は直接通信


KickstartKickstartでのでの %post %post スクリプトスクリプト1. Chef Clientのインストール2. /etc/chef/client.rb の配置3. “node_name”を取得・上記ファイルに設定4. /etc/chef/validation.pemを配置5. chef-clientコマンドを実⾏

boot: 1 node=chef-test01

実際のOSインストール時にPXE Boot時に⼊⼒するラベル例


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

� クラウド環境でも応用可能� EC2だと、事前にAMIを作成しておいて、user-dataに

Node名を指定して...� (弊社のOpenStackクラウド基盤を活用)


CookbookCookbookの使い⽅の使い⽅� Cookbookの例

�ネットワーク設定�H/Wに必要な設定

– 主にH/W固有で必要なドライバやRAIDチェックスクリプト等�各サーバ共通で必要な設定

– DNS, NTP, LDAP, 監視ライブラリ, 鍵交換等�各Roleで必要な設定

{"run_list": ["recipe[ameba-common::pigglife]","recipe[pigglife-mongodb::mongod]"

]}

{"run_list": ["recipe[network::xxxxx]","recipe[hw::dell_r310]",“role[pigglife-mongodb]"

]}

NodeへのCookbook設定例 RoleへのCookbook設定例


ChefChefを使う上でやっていることを使う上でやっていること� Script Resource は基本的に使わない

�何度でも実⾏される� chef-client実⾏時のチェック・運用が面倒�何度実⾏しても問題ないものしか使わない

script “script_name" dointerpreter "bash"user “username"creates comp_dir + “script_name.done"code <<-EOHcommand............

EOHend

過去、こんな感じで書いていました...


ChefChefを使う上でやっていることを使う上でやっていること� 各nodeのChef適用は、chef-clientを実⾏

� tomahawk: 複数のサーバで同じコマンドを実⾏� “knife ssh”, “knife ssh_cheto” 等も

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

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

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


ChefChefを使う上でやっていることを使う上でやっていること� verbose_logging false

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

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

� CouchDBのバックアップ�Chefサーバのバックアップ、/etc/chef 以下も

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


ChefChefを運用する上での課題を運用する上での課題� Recipeが正しいことを保障するには？

�仮想マシン等を活用してテスト– VirtualBoxの制御ができるVagrantが便利– 本当に正しい処理が⾏われているかは人手での確認が必要

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

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

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


CookbookCookbookでのコミュニケーションでのコミュニケーション� セットアップ手順のチェックをRecipe

(Cookbook)という名のコードベースで�DevとOpsのクロスチェック

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

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

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


これからこれからChefChefを勉強する⽅へを勉強する⽅へ� chef-solo が便利

� chef-server を必要とせず、ローカルにCookbookを適用できる

�小環境ならこれで十分�他にも、VMとかでテストとか練習とか

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

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


まとめと今後の展望まとめと今後の展望� Chefを活用することで多くのサーバの増設・管理

にかかる負担を軽減�あるべき状態に自動で設定・維持できる�ルールを少し覚えれば、誰でも簡単に設定が書ける�内部DSLなので、Rubyを覚えれば処理も柔軟に書ける

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


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

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

Technology

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