Embed Size (px)
DESCRIPTION
TISにて推進しているOSSミドルウェアスタックISHIGAKIテンプレートではChefを使っています。ISHIGAKIテンプレートで使っているChefの事例紹介です。 http://www.tis.jp/service_solution/ossmigration/#tabitem_3
Citation preview
TIS株式会社 戦略技術センター秋穂 賢
2014/9/18(Thu) @ データセンター管理者必見！セミナー【SDN/SDI】Arista x Chefで実現するデータセンター自動化への展開
Chefのエンタープライズ事例～OSSミドルウェアスタック ISHIGAKIテンプレートにおける事例～
TIS株式会社 戦略技術センター所属
自己紹介
秋穂 賢（あきほ すぐる）名前
Chef, Zabbix, JobScheduler, OTRSなど仕事
http://www.atmarkit.co.jp/ait/articles/1310/17/news006.html http://codezine.jp/article/detail/7767
TISに帰任。同じく金融系の超大規模システムのシステム運用に従事 ※会社のセキュアルームで夜を明かすことが何度も...
2011年 〜2013年
自己紹介 続き（略歴）
入社後、いきなりシステム運用専門の子会社への出向命令。2年間、金融系の超大規模システムのシステム運用に従事 ※データセンターで夜を明かすことが何度も...
2009年 〜2011年
社内のR&D部門に異動し、OSSの運用周りのツール調査やISHIGAKIテンプレートの開発に従事OSSの活動の中でChefに出会う
2013年 〜
[宣伝]TIS OSSプロダクトサポートサービス
対象OSS
インフラ基盤
運用基盤
アプリケーション
稼働基盤
OSSの調査・検証などの活動は自分が入社する前から実施していた
その成果の一環としてOSSプロダクトサポートビジネスを開始！
推奨OSSスタック ISHIGAKIテンプレート
TISの顧客は大企業が多く、非機能要件（性能や可用性など）が厳しいケースが多い
エンタープライズ環境でOSSを利用するためには厳しい非機能要件を満たすことが必須
エンタープライズWebで多く利用されているJavaのWebアプリケーション稼働基盤に対象を絞り、独自の検証・チューニングを実施
ここで得た知見を組み合わせてテンプレート化
テンプレート化による利点
従来型のSI● 個々の顧客ごとの要件に合ったイ
ンフラ構成（ミドルウェア）を選定
● ベンダー支援のもとで検証を実施し、構成を決定
● ミドルウェアのインストールから設定まで全て手作業で実施
● 顧客ごとのインフラ環境を個別にサポートする必要がある
テンプレートを利用したSI● 要件に合うテンプレートを選択
● 検証済みの構成から、要件に合うものを選択
● スクリプトで設定済みのテンプレートを自動インストール
● テンプレート構成のサポートを集約して管理可能
テンプレート化による利点
従来型のSI● 個々の顧客ごとの要件に合ったイ
ンフラ構成（ミドルウェア）を選定
● ベンダー支援のもとで検証を実施し、構成を決定
● ミドルウェアのインストールから設定まで全て手作業で実施
● 顧客ごとのインフラ環境を個別にサポートする必要がある
テンプレートを利用したSI● 要件に合うテンプレートを選択
● 検証済みの構成から、要件に合うものを選択
● スクリプトで設定済みのテンプレートを自動インストール
● テンプレート構成のサポートを集約して管理可能
テンプレートとしての決まった構成
Chefによる自動化を実現
ISHIGAKIテンプレートの構成要素
ISHIGAKIテンプレートは大きく2つのOSSミドルウェア群で成り立つ● JavaのWebアプリケーションを稼働させるための基盤
○ Apache / Tomcat / JBoss / PostgreSQL● 運用監視基盤
○ Chef / Zabbix / Amanda / JobScheduler
ISHIGAKIテンプレートは大きく4つの構成を提供
● 単一のサーバで構成される Single Edition.● Active / Standbyで冗長化した HA Edition.● Active / Activeで冗長化した高可用性の Cluster Edition.● AWS環境で高可用性クラスタを実現した AWS Edition.
Single Edition
Apache or
● 冗長化をしていない、シンプルな構成● 小規模案件向け● chef-solo / knife-soloを用いて自動化
HA Edition● Active / Standbyで冗長化された構成● 冗長化にはDRBD / Pacemakerを用いている● Active系が停止した場合はStandby系を自動でActiveにする● 運用サーバがあり、ここにChef Serverを導入
Standbyサーバ
システム運用者
情報
収集
ApacheJBoss AS
Activeサーバ
死活監視 データ同期
JBoss ASApache
リソース監視リソース監視
運用サーバ
Cluster Edition● Active / Activeで冗長化された構成● 冗長化にはミドルのレプリケーション機能を用いている● 1台停止しても大きな影響はなく運用可能● 各ミドルウェアの構成台数は柔軟に変更可能● 運用サーバがあり、ここにChef Serverを導入
マスター
スレーブ
スレーブ
JBoss AS pgpool-Ⅱ
セッションレプリケーション 参照負荷分散 DBレプリケーション
JBoss AS pgpool-Ⅱmod_jk
mod_jk
mod_jk JBoss AS pgpool-Ⅱ
負荷分散
情報収
集
運用サーバ
システム運用者
AWS Edition
マスター
スレーブ
スレーブ
JBoss AS
pgpool-Ⅱ
セッションレプリケーション 参照負荷分散DBレプリケーション
JBoss AS
pgpool-Ⅱmod_jk
mod_jk
mod_jk JBoss AS
pgpool-Ⅱ
負荷分散
情報収
集
運用サーバ
GElastic Load
Balancer
AWS Cloud
システム運用者
● Active / Activeで冗長化された構成● Cluster EditionをAWS向けにカスタマイズ● フロントにELBを配置● 各ミドルウェアの構成台数は柔軟に変更可能● 運用サーバがあり、ここにChef Serverを導入
ISHIGAKIテンプレートの自動化
Single Edition. HA Edition.
AWS Edition. Cluster Edition.
による自動化を実現
ISHIGAKIにおけるChef 〜Chef実行〜
setup.sh config.yml
インストーラとしてChefを利用Chefのラッパーとしてスクリプトを定義
①OSの初期設定（ssh / firewall など）
②管理サーバにChef Server / Chef Clientをインストール
③Chef Serverの初期設定
④Cookbook / RoleをChef Serverにアップロード
⑤Databagの作成＆Chef Serverへのアップロード
⑥各ノードへのChef Clientインストール＆run_listの設定
⑦Chef Clientの実行
ISHIGAKIにおけるChef 〜具体例〜
setup.sh config.yml〜〜base: session_replication: true〜〜
Cluster EditionでのAP間セッションレプリケーションの設定例
ruby script Yaml => Hash変換後params[:tomcat][:env][:session_replication] = config['base']['session_replication']
ruby script JSON変換＆databagとしてアップロード
server.xml.erb<% if @node[:tomcat][:env] [:session_replication] == true -%>
ISHIGAKIにおけるChef 〜Attribute活用〜
Attributeの優先度を考慮してパラメータを設定
https://docs.getchef.com/essentials_cookbook_attribute_files.html
インストールした際の初期値 検証で得られた、
各エディションのミドル毎に設定すべき最適値
・ 各ノード固有の設定値（ ipアドレスなど）・ ノード間で共有すべき設定値（エディション名など）
ISHIGAKIにおけるChef 〜supermarcket〜
ISHIGAKIではChef Supermarketにあるコミュニティで作成されたcookbookは使っていない
● 開発当初はコミュニティcookbook数が少なかった● お客様への納品が必須
○ 正式なサポートがなく（有志でのCookbook提供）内容を全て把握することが難しい
○ 変更履歴を常にウォッチするのが難しい
コミュニティのCookbookは実装時に参考にするのみ
ISHIGAKIにおけるChef 〜構築時間〜
Single Edition ・・・ 約20分程度（1 / 1 / 1 / 0）HA Edition ・・・ 約40分程度（1 / _ / _ / 1）Cluster Edition ・・・ 約60分程度（2 / 2 / 2 / 1）
Chef導入前にCluster構成を構築すると、慣れている人が実施しても半日仕事（設定ミスの調査含む）
構築時間が劇的に短くなった！設定ミスがなくなった！
（Web / AP / DB / OP）
※ 人手が必要な時間は設定ファイルを書いて、 shellを実行する時間のみ
ISHIGAKIにおけるChef 〜開発スタイル〜
開発者④最新のコードを取得⑤開発対象チケット番号のブランチ作成⑥開発＆開発ブランチへのpush
リーダ
①プロダクトバックログの登録②開発担当者の割当
③担当機能の確認、チケットの更新 Git / Redmine連携
リーダ
⑦開発コードのレビュー
開発者⑧プロダクトブランチへマージ Redmineのチケットは自動でクローズ
Chef導入によるメリット
● 構築作業の短時間化○ Chef導入前後で４，５時間の作業 => 1時間程度に
● コード化による見える化○ 個々人が暗黙的に有していたノウハウがコードとして形
式知化され、ノウハウの共有がしやすくなった
● アプリ開発のノウハウを使った開発○ GitやRedmineを使ったレビューにて、設計から実装ま
でレビューが出来る○ チケットでの問題管理や変更履歴管理が出来る
Chef導入後の課題
● Chefを使ってインフラをコード化することで様々なメリットが得られた
But…● 構築後の確認は手作業で実施していた
○ 初期設定パラメータやRoleで指定した通りの設定になっ
ているか？など
● Chefで享受出来るメリットが半減
インフラテストの自動化を推進
インフラテストの導入
● テスティングフレームワークは当時、公開されて間もないserverspecを導入○ 静的テストではなく、サーバ構築後の実際の状態をテス
トしたかった
● テストはやり過ぎないように注意した○ テストし過ぎると変更に弱くなる
○ プロセスが動いているか、適切なポートでリッスンしてい
るか、といった基本的な内容をチェック
○ 設定ファイルはRoleで上書きしている値を中心にチェッ
クし、デフォルト値はチェックしない
serverspecの紹介
● 2013年3月末にリリース
● RSpecでサーバの状態をテスト
● 本質はサーバの状態を記述したコードをテスト○ PuppetマニフェストやChefレシピなど
● インフラコードの開発やリファクタリングを効率よく行うためのツール
https://speakerdeck.com/mizzy/serverspec-at-jtf2014 より抜粋
serverspecの例
Apacheがインストールされてて、80番でリッスンしてるか
describe package('httpd') do it { should be_installed }end
describe port(80) do it { should be_listening }end
内部的には、sshで対象サーバにログインして
rpm -q httpdを打ってパッケージがインストールされているか
内部的には、sshで対象サーバにログインして
netstat -tunl | grep -- :80\を打って80ポートがリッスンしているか
http://tech-sketch.jp/2014/04/serverspec.html
テストの自動化
serverspecでのテスト実装後、毎日自動で構築とテストを稼働させるように
インフラCIの導入
● Single / HA / Cluster構成から毎日1Editionのテストを夜間に実行
● VMWareのスナップショット機能を活用● 最新のコードにてテストを実施
テストの自動化の構成
Cluster WebCluster Web Cluster APCluster AP Cluster DBCluster DB
snapshot
snapshot
snapshot
Cluster APHA
snapshot
Single
snapshot
①VSphereAPIにて初期設定済みのスナップショットから初期化
管理サーバ
夜間実行
②リポジトリより最新のコードを取得
③ISHIGAKI構築用のChefを実行④テスト用のserverspecを実行
⑤テスト結果をAPIにてRedmineに登録 ＆メールにてテストレポートを送信
インフラCI導入による効果
● 開発時に混入した不具合を早期に検知○ 4つのEditionを1つのchef-repoにて開発しているため、
開発時に不具合が混入する可能性
● 自然に発生する不具合を早期に検知○ インフラ構築時に外部のリポジトリに依存
○ リポジトリが突然消えることがあったが、早期に検知出
来るように
● 構築時の最新データを常に保持可能○ 実行時のattributeを保持しておくことで、最新の設定の
生データを保持出来る
インフラCI導入による効果
● 開発時に混入した不具合を早期に検知○ 4つのEditionを1つのchef-repoにて開発しているため、
開発時に不具合が混入する可能性
● 自然に発生する不具合を早期に検知○ インフラ構築時に外部のリポジトリに依存
○ リポジトリが突然消えることがあったが、早期に検知出
来るように
● 構築時の最新データを常に保持可能○ 実行時のattributeを保持しておくことで、最新の設定の
生データを保持出来る
Chefを使った開発では自動テストは必須！
テストを書いたらインフラCIを推奨！
インフラCIの課題と対応
● Vagrantを導入することで、OSの立ち上げ・初期設定から自動化
● VMWareにしばられず、AWSやOpenStackなどの環境でもテスト可能な仕組みに
VMWareのsnapshotに依存している課題
インフラCIの課題と対応
● Jenkinsを導入することで、構築時ログの保管やレポーティングをより柔軟に
● JenkinsとRedmineを使うことでバグの検知から修正まで一気通貫で管理出来るように
レポーティングや通知が独自の仕組み課題
Chefを導入して辛いと感じること①
● Cookbook作成の学習コスト・実装コスト○ アプリとインフラが分業していることが多く、インフラエンジ
ニアにはハードルがやや高い○ 一度実装すれば便利だが、実装するまでに時間がかかる○ attributeを多段に重ねた場合のデバッグがしづらい
■ 今後のツールに期待
テンプレート化することで、Chef開発を集約
shell開始設定ファイルから生成
Attribute遷移
WebサーバのRole実行
APサーバのRole実行
DBサーバのRole実行
管理サーバのRole実行
※各Roleにて個別のRecipeを実行
Chefを導入して辛いと感じること②
● 個別のSI案件ではChefを活用しきれない○ テンプレートが適用出来ないようなシステムは個別に構
築を実施
○ テンプレートを使っても、運用フェーズからChefスクリプ
トやChef Serverのメンテナンスが出来ない■ 実質、構築時にChefを使っているのみ■ 運用フェーズからは手作業によるメンテナンス
Chef Serverによって享受できるメリット
Chef Serverを使うまでの手間
まとめ
● ISHIGAKIにChefを採用したことで、様々なメリットを享受できた○ ノウハウ共有・開発手法・短時間化...etc…
● Chefでインフラをコード化したら必ずテストコードは書くべき○ Chefでのコード化だけではメリット半減○ 更にインフラCIまで実践するとメリット大
● Chef Serverの使いどころが難しい○ SIでの活用場面が難しい...
