More Related Content Similar to ドリコムのInfrastructure as code Similar to ドリコムのInfrastructure as code (20) ドリコムのInfrastructure as code1. Copyright Drecom Co., Ltd. All Rights Reserved. 1
ドリコムの
Infrastructure as Code
2014.05.23
最新インフラエンジニア技術勉強会
2. Copyright Drecom Co., Ltd. All Rights Reserved. 2
名前
ひらしー(とか狂犬?とか)
出身:グンマー
所属
サービス基盤本部 サービス基盤部 インフラグループ
職種
インフラエンジニア
4. Copyright Drecom Co., Ltd. All Rights Reserved. 4
ドリコムのインフラ規模
⁃ 1日の全アプリ合計PV
⁃ 1日の全アプリ合計DAU
1億以上
100万以上
11. Copyright Drecom Co., Ltd. All Rights Reserved. 11
Chefの運用方法
米国Chef社(旧: Opscode社)が開発
オープンソースとして公開されている
サーバの構成管理を行うフレームワーク
12. Copyright Drecom Co., Ltd. All Rights Reserved. 12
Chefの運用方法
⁃ 特徴
Rubyで書ける(内部DSL)
べき等性という考え方
Rubyエンジニアが多いため、
構築状況が共有しやすい
13. Copyright Drecom Co., Ltd. All Rights Reserved. 13
Chefの運用方法
何度実行しても”nginx.conf.src”というChef管理のファイルと等しくなるべき
べき等性に沿った記述
18. Copyright Drecom Co., Ltd. All Rights Reserved. 18
Chefの運用方法
⁃ Why
以前はChef-Server構成だったが
クライアント100台を超えたあたりからCouchDB
がボトルネックになった
※Chef11からPostgreSQLが採用された
Chef-ServerとChef-Client連携による定期的収束
を既存サーバに適用できなかった
19. Copyright Drecom Co., Ltd. All Rights Reserved. 19
Chefの運用方法
⁃ Why
プロビジョニング処理とサーバ情報の取得と
いう観点ではChef-Serverが必要ない
現状Chef-Soloとシェルスクリプト
の組み合わせで十分
26. Copyright Drecom Co., Ltd. All Rights Reserved. 26
Chefの運用方法
Vagrant
vagrant snapshot back
OSインストール直後のスナップショット
vagrant provision
Chefの実行
29. Copyright Drecom Co., Ltd. All Rights Reserved. 29
29
CI
DC
DC
DC
本番環境
GitLab
Jenkins Vagrant
Chefの運用方法
インフラメンバ
30. Copyright Drecom Co., Ltd. All Rights Reserved. 30
30
CI
DC
DC
DC
本番環境
GitLab
Jenkins Vagrant
Chefの運用方法
インフラメンバ
31. Copyright Drecom Co., Ltd. All Rights Reserved. 31
31
CI
DC
DC
DC
本番環境
インフラメン
バ
GitLab
Jenkins Vagrant
Chefの運用方法
git push
32. Copyright Drecom Co., Ltd. All Rights Reserved. 32
32
CI
DC
DC
DC
本番環境
インフラメン
バ
GitLab
Jenkins Vagrant
Chefの運用方法
33. Copyright Drecom Co., Ltd. All Rights Reserved. 33
Rundeck
ホスト名やIPアドレスを正規表現で検索
Chefの運用方法
Zabbix-APIにて取得済のホスト情報
35. Copyright Drecom Co., Ltd. All Rights Reserved. 35
35
CI
DC
DC
DC
本番環境
インフラメン
バ
GitLab
Jenkins Vagrant
Chefの運用方法
43. Copyright Drecom Co., Ltd. All Rights Reserved. 43
テスト駆動インフラ
serverspecで作業項目を記載
GitLabを使ってコードレビュー
開発環境で実行・テスト
本番環境で実行・テスト
44. Copyright Drecom Co., Ltd. All Rights Reserved. 44
44
テストシナリオ(yaml)
drecom-serverspec
実行するserverspecファイルパス
テスト対象ホスト
テスト駆動インフラ
45. Copyright Drecom Co., Ltd. All Rights Reserved. 45
45
drecom-serverspec
テスト結果(コマンド出力)
テスト項目(describe)
テスト対象サーバ
テスト駆動インフラ
48. Copyright Drecom Co., Ltd. All Rights Reserved. 48
⁃ 早
⁃ 正確
Chefによるプロビジョニング自動化
CIツールとserverspecによるテスト自動化
PDCAサイクルによる品質管理
49. Copyright Drecom Co., Ltd. All Rights Reserved. 49
49
Plan
Do
Check
Action
Chef,serverspecのコードレビュー
Chef,Rundeckによる実行
serverspec実行
Chef,serverspecコード修正
51. Copyright Drecom Co., Ltd. All Rights Reserved. 51
⁃ Chef-Server
Chef-Serverを有効に活用できている事例ってある?
⁃ Rundeck
リモートサーバのオペレーション管理が便利すぎるのに無名
53. Copyright Drecom Co., Ltd. All Rights Reserved. 53
会社概要
社名:
証券コー
ド:
本社:
電話番号:
社員数:
設立年月
日:
資本金:
事業内容:
株式会社ドリコム
3793 東証マザーズ
〒153-0064
東京都目黒区下目黒1丁目8-1 アルコタワー17F
TEL:03-6682-5700 FAX:03-6682-5711
239名 (正社員・契約社員のみ)
2001年11月13日
1,124百万円
(2014年3月末現在)
ソーシャルゲーム事業
ソーシャルラーニング事業
アドソリューション事業
Copyright Drecom Co., Ltd. All Rights Reserved.
Editor's Notes はい。ではドリコムのInfrastructure as Code というタイトルで初めさせて頂きます 名前はひらしーとか暴力的なことは全くせずに寧ろおとなしいのですが狂犬と呼ばれています
出身は後ろを延ばさない方の”群馬”です。Google画像検索で表示されるこのような場所ではありません
所属・職種は世間一般的なWEBサービス会社のインフラ部署のインフラエンジニアです まずはドリコムのインフラ規模です PVとDAUですが
1日の全アプリ合計は=> 1億以上
1日の全アプリ合計は=>100万以上
となっております サーバ台数ですが全て仮想サーバ換算で
ホスティングしているものが300台以上
イアースのクラウドで1000台以上
となっています そして1ヶ月に増加する台数は現在30台程度となっています これを診るインフラエンジニアの人数ですが 現在3人で回しています この人数で早く、安く、正確なインフラ構築をするためにインフラストラクチャのコード化をどのように活用しているかをお話していきます Chefの運用方法 既に皆さんご存知かと思いますがChefはサーバの構成管理を行うオープンソースのフレームワークですね 特徴としてRubyで書けるという点がRuby on Railsの会社であることと親和性が高く情報共有しやすいということととべき等性という考え方を元にした記述ができるという点があります 例えばこのようなnginxの設定ファイルを配布する例ですと、何度実行してもファイルの内容が同じになるということを保証する書き方ができます Chefには大きく分けて2つの構成がありまして 1つはこのように各サーバ情報を集約・管理するサーバを置き 各サーバのローカルでのみ動作する構成です ドリコムではChef-Soloのほうを採用しています。 以前はChef-Server構成でしたが、クライアント100台超えたあたりからCouchDBがボトルネックになりました。今はPostgreSQLなのでこれは改善されたとは思いますが
他にChef-Serverで管理している情報を変更することによりChef-Clientになんらかの影響をあたえるという機能を既存サーバに適用できなかったという点があります また、プロビジョニングとサーバ情報の取得という観点ではChef-Serverが必要ないので
現状はシェルスクリプトの組み合わせで十分足りると判断しています 実際のChef開発フローですが 例えばこのようにプロビジョニングするサーバのnginxの設定ファイルを変更するレシピを編集するとしますと まずCI環境にあるgitサーバにpushを行います 社内のほぼ全てのソースはGitLabサーバにて管理しています。
Chefのレシピのほうもこちらに含まれております PushするとGitLabによるWeb hook機能によりhttpリクエストが飛びまして そのhttp通信をJenkinsのGitlab Hook Pluginで拾いまして 仮想マシンにはベイグラントを使用して、いつでもOSインストール直後の状態のスナップショットからChefの実行ができるようにしています Chefのレシピの品質を上げるためにFoodcriticというコード規約をチェックするツールを使い また、テストにRubyでこのようにrspec風にテストを実行できるserverspecを使用します テストが全て完了するとインフラメンバに結果とgitlogの内容をメールします テストに失敗したら
このように再度ソースコードを編集して、gitpushしテストが成功するまでCIをまわします その内容に問題なければインフラメンバが本番環境に反映するのですが こちらは数が多い時はRundeckというGUIでオペレーションの履歴とタスクの管理ができるツールで効率的に回しています
ホスト一覧はZabbixにて管理しているホスト情報をZabbix-API経由で定期的に取得して更新しています 当初chefやcapistranoを使っていたのですが、サーバ数が多くなりすぎてタスクと実行履歴の管理ができなくなり、
RundeckというGUIでオペレーションの履歴とタスクの管理ができるツールで効率的に回しています そしてRundeckを使用して本番環境にChefとserverspecを使用します
試験環境でserverspecを使用しているので本番環境でserverspecを使用する必要ないと言う意見もありますが
全てのネットワーク環境、ハードウェア環境と同一のテスト環境をエミュレートするのは厳しいと考えていまして、毎回serverspecを実行しています 次にコード管理についてお話したいと思います 先程コード管理にgitlabを使用しているとお話しましたが、弊社ではgitlabを最大限に活用して3つのインフラとしてのコード運用をしております 1つはイシュードリブンインフラストラクチャと称しましてまずインフラの状態に変更を加えて欲しい人が要望を投げ、インフラメンバがこれに対応する方法
この運用方法であればChefやserverspecのコードがわからなくてもインフラメンバがgitlab上でコミュニケーションを取って依頼できますね もう1つはプルリクエストドリブンインフラストラクチャと称しまして、gitlabではMerge Requestなのですがgithubのプルリクエストと同じ機能なのでプロリクエストの名前を使ってます
これはある程度Chefやserverspecに詳しい人やパラメータの変更のような簡単な部分であれば自ら進んで実施してもらっています。これを使う人はインフラやコードに対して意識が高いということが分かりますね もう1つは勝手にマサカリドリブンインフラストラクチャと読んでいるんですが、
gitlabであらゆるコミットに対してコメントが付けられるのでそれに対して意識の高いモヒカンが4方8方からマサカリが飛んでくるので
インフラメンバがそれに対応するということをしています
ここでは、メムキャッシュディーのサイズを間違えてマサカリが飛んできて修正したら別のモヒカンからマサカリが飛んで来たところですね 最後にテスト駆動インフラについてお話したいと思います インフラ作業といえば
こんなテスト項目書であったり
こんな作業手順書のような
開くのに時間がかかるエクセルが典型的ですが
これでは1000台規模のサーバを作業するのはあまりにも厳しいので Rspecを知っている人はご存知ですけども、作業項目の階層をコードに記載したサーバスペックを作りまして
これをGitlabでコードレビューします
そして開発環境で作業とテストをしまして
問題なければ本番環境で作業とテストを実行します serverspec単体では機能が足りないので拡張したコマンドツールを使っています
このように実行するserverspecファイルパスと対象ホストを指定したシナリオファイルを用意しまして
実行するとこのようにserverspecコード内でdescribeで指定した項目ごとに結果が表示されます
このようにして大量のサーバとテスト項目を効率的に処理できるツールを用意しています serverspec単体では機能が足りないので拡張したコマンドツールを使っています
このように実行するserverspecファイルパスと対象ホストを指定したシナリオファイルを用意しまして
実行するとこのようにserverspecコード内でdescribeで指定した項目ごとに結果が表示されます
このようにして大量のサーバとテスト項目を効率的に処理できるツールを用意しています まとめになりますが 少人数で早く正確なインフラを回すには?という冒頭の問いの答えの1つになりますが 早さは
Chefによるプロビジョニング自動化と
serverspecによるテスト自動化
そして正確さは
PDCAサイクルに沿った品質管理が失敗のないインフラにつながると思います 品質管理の一般的な手法にPDCAサイクルというものがありますがこれに準じたものになっていまして
Plan がChef,serverspecのコードレビュー
Do がChef,Rundeckによる実行
Checkがserverspec
ActionがChef,serverspecコード修正
という形で進めるのが確実かと思います
最後にその他所感になりますが Chef-Serverを有効に活用できている事例を知らないので、
あったらこっそり教えて下さい
Capistranoのタスク管理や履歴に残せないところが駄目で変えたんですが、大量のサーバをオペレーションするのが便利すぎるのに全く活用されている情報がないので
他社さんがどうやっているか気になります
サーバースペックはコマンドを抽象化して、テストの振る舞いをコードに掛けるだけなんですが、色々な所に活用できるのでこれなしにはもういられないですね