Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

Chefのエンタープライズ事例 ossミドルウェアスタックishigakiテンプレートにおける事例-

2.633 Aufrufe

Veröffentlicht am

TISにて推進しているOSSミドルウェアスタックISHIGAKIテンプレートではChefを使っています。ISHIGAKIテンプレートで使っているChefの事例紹介です。
http://www.tis.jp/service_solution/ossmigration/#tabitem_3

Veröffentlicht in: Technologie
  • Loggen Sie sich ein, um Kommentare anzuzeigen.

Chefのエンタープライズ事例 ossミドルウェアスタックishigakiテンプレートにおける事例-

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

×