Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

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

2 633 vues

Publié le

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

Publié dans : Technologie
  • Identifiez-vous pour voir les commentaires

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

×