【20-e-5】実践!infrastructure as a codeの取り組みと改善
TRANSCRIPT
「実践!Infrastructure as Codeの取り組みと改善」
Copyright 2015 CYBIRD Co., Ltd. All Rights Reserved.
株式会社サイバード藤原 涼本田 恭
自己紹介
● 藤原 涼● 2012年新卒入社 (3年目)● Twitter @megadreams14● エンジニア
○ ソーシャルゲームの開発・運用○ サーバ運用からフロントエンド開発まで幅広く担当
ミドルウェアのインストール環境に合わせた設定適用
ソースコードのデプロイ画像のデプロイ
Zabbix Serverに追加LBへの追加
https://www.chef.io/http://jenkins-ci.org/
Auto Scalingを導入することで
運用効率化と機会損失の削減
● 負荷に合わせて自動でサーバを増減○ 急激な負荷にも耐えられる
● スケジュール機能を利用したサーバ増減○ スケジュールでサーバ増減
恋愛ソーシャルゲームインフラ事情2013年
2014年
2015年
夏
基本的に手動でサーバ構築
Chefの導入とサーバ構築自動化秋
Auto Scaling導入冬
サーバ構築自動化とAuto Scaling本格運用
運用管理サービス
恋愛ソーシャルゲームインフラ事情2013年
2014年
2015年
夏
基本的に手動でサーバ構築
Chefの導入とサーバ構築自動化秋
Auto Scaling導入冬
サーバ構築自動化とAuto Scaling本格運用夏
サーバ構築の運用上の課題と改善
運用管理サービス
1:構成管理ツールに全てを任せている
● Chefのレシピのコードの複雑化○ Chefの役割が集中している○ Cookbook同士が疎結合になっていない○ 冪等性が担保されていない
● 外部サービスとの連携○ サーバ内で完結しない処理もレシピ化○ デプロイやロードバランサへの追加
Orchestration
Configuration
Bootstrapping
Application ServiceDeployment
System Configuration
Cloud or VMImageLaunch
OSInstall
[Provisioning Toolchain by Lee Thompson at Velocity 2010]
参考:http://kentana20.hatenablog.com/entry/2014/02/15/023158
CapistranoFabric
PuppetChef
EC2OpenStack
Bootstrapping
● OSのインストールとサーバ起動● Configurationを実行するための準備
OSのプロビジョニング
BootstrappingConfigurationOrchestration
Configuration
● ミドルウェアのセットアップ● 対象サーバの役割に応じた設定● サーバ単体で完結するような処理
システム構成のプロビジョニング
構成管理ツールが得意な領域BootstrappingConfigurationOrchestration
Orchestration
● サーバ単体では完結しない処理を担う○ GlusterFSのClusterに追加○ Jenkinsからソースコードデプロイ○ zabbix-agentの起動など
アプリケーションのプロビジョニング
BootstrappingConfigurationOrchestration
デプロイツールなどが得意な領域
Releasalization(造語)
● Orchestrationの処理内容をテスト○ Serverspec
● サーバを本番環境に投入○ LBに追加
サービス提供のプロビジョニング
ConfigurationBootstrapping
ReleasalizationOrchestration
恋愛ソーシャルゲームインフラ事情2013年
2014年
夏
基本的に手動でサーバ構築
Chefの導入とサーバ構築自動化秋
Auto Scaling導入冬
サーバ構築自動化とAuto Scaling本格運用夏
サーバ構築の運用上の課題と改善
サーバ構築の概念化2015年秋
冬
運用管理サービス
恋愛ソーシャルゲームインフラ事情2013年
2014年
2015年
夏
基本的に手動でサーバ構築
Chefの導入とサーバ構築自動化秋
Auto Scaling導入冬
サーバ構築自動化とAuto Scaling本格運用夏
サーバ構築の運用上の課題と改善
サーバ構築の概念化秋
Auto Scaling見直し冬
運用管理サービス
● /etc/init.dでやっていること○ サーバのホスト名の決定○ Chefの実行制御(失敗制御など)○ メール通知
● 手動起動の際にもChefが流れる○ 間違って起動するとサービスに組み込まれる危険性○ サーバ再起動で毎回処理が走る
起動スクリプトで制御
● 起動AMI用のレシピをメンテナンスしていない○ 基本的に初回作成時のみ○ 随時手動で設定変更
● リソースデータの最新化の手間○ 予め画像ファイルなどをダウンロード○ 本番稼働前は、差分のみを適用○ 画像の更新が多いため、差分がすぐに多くなる
起動用AMI作成の手間
恋愛ソーシャルゲームインフラ事情2013年
2014年
2015年
夏
基本的に手動でサーバ構築
Chefの導入とサーバ構築自動化秋
Auto Scaling導入冬
サーバ構築自動化とAuto Scaling本格運用夏
サーバ構築の運用上の課題と改善
サーバ構築の概念化秋
Auto Scaling見直し冬
運用管理サービスAuto Scaling運用とコスト削減取り組み
Bootstrapping
● OSのインストールとサーバ起動● Configurationを実行するための準備
OSのプロビジョニング
BootstrappingConfigurationOrchestration
再 掲
Bootstrapping実践 -物理-
● Kickstartで実行○ OSインストール○ ディスクのパーティション設定○ NICやRoutingの設定○ SELinux無効化○ 管理ユーザーの作成 (Chef実行ユーザー)
■ useradd■ authorized_keys
Bootstrapping実践 -クラウド-
● Kickstartの内容を実行しイメージ化○ OSの選択○ Volume設定○ Network Interface設定○ SELinux無効化○ 管理ユーザーの作成 (Chef実行ユーザー)
■ useradd■ authorized_keys
物理 クラウド
共通● SELinux無効化● 管理ユーザーの作成 (Chef実行ユーザー)
● OSインストール● パーティション● NICやRouting
● OSの選択● Volume設定● Network設定
Bootstrapping実践
● Kickstartをベースに作業○ 物理とクラウド両方で同じように考えられるように
● 最低限の作業のみ行う○ ミドルウェアのインストールや設定は他のレイヤー○ Chefが実行できる状態にするだけ
Configuration
● ミドルウェアのセットアップ● 対象サーバの役割に応じた設定● サーバ単体で完結するような処理
システム構成のプロビジョニング
構成管理ツールが得意な領域BootstrappingConfigurationOrchestration
再 掲
Configuration実践
http://www.levihackwith.com/wp-content/uploads/2011/10/github-logo.png
【実行レシピ(例)】
host名 [設定]iptables [設定]User [設定]PHP [インストール]ImageMagick [インストール]Apache httpd [インストール]GlusterFS [インストール]Zabbix Agent [インストール]Fluentd [インストール]Serf [設定][起動]
ChefRepository
Configuration実践
● Chef Soloの利用○ Chef Server運用の問題を解決
● Jenkinsからknife solo実行○ Chefの実行がより簡単になった○ Chef実行結果ログがJenkins上で見られる
Orchestration
● サーバ単体では完結しない処理を担う○ GlusterFSのClusterに追加○ Jenkinsからソースコードデプロイ○ zabbix-agentの起動など
アプリケーションのプロビジョニング
BootstrappingConfigurationOrchestration
デプロイツールなどが得意な領域
再 掲
Orchestration実践
http://pocketstudio.jp.s3.amazonaws.com/log3/wp-content/uploads/2013/11/serf-logo.png
S E R F
これまでのSerfの利用方法
http://4.bp.blogspot.com/-XvJgBCygSCo/UxRl_TMQNlI/AAAAAAAAAWc/-ui0-NKM_70/s1600/logo.png
S E R F
Orchestration実践
● Serf○ イベントを受けて各Nodeでやりたい処理を実行
● Jenkins○ サーバのSerfクラスタ参加イベントを検知○ Serf経由でOrchestration処理イベント発火
Serfの便利機能
● Query○ 実行結果をイベント発火者が取得できる○ JenkinsがOrchestration処理の失敗を判定
● Tags○ ‘KEY=VALUE’形式でNodeに情報を持たせる○ ChefのRoleの要約を記述している
Serfの便利機能
● Query○ 実行結果をイベント発火者が取得できる○ JenkinsがOrchestration処理の失敗を判定
● Tags○ ‘KEY=VALUE’形式でNodeに情報を持たせる○ ChefのRoleの要約を記述している
ジョブの分岐と失敗判定
Configuration実践
http://www.levihackwith.com/wp-content/uploads/2011/10/github-logo.png
【実行レシピ(例)】
host名 [設定]iptables [設定]User [設定]PHP [インストール]ImageMagick [インストール]Apache httpd [インストール]GlusterFS [インストール]Zabbix Agent [インストール]Fluentd [インストール]Serf [設定][起動]
ChefRepository
再 掲
Configuration実践
【実行レシピ(例)】
host名 [設定]iptables [設定]User [設定]PHP [インストール]ImageMagick [インストール]Apache httpd [インストール]GlusterFS [インストール]Zabbix Agent [インストール]Fluentd [インストール]
ChefRepository
Serf [設定][起動]
Orchestration実践
serf-members
serf join
Serf ClusterSerf
http://s3-blog.the-new-it.com.s3.amazonaws.com/wp-content/uploads/2014/01/WPandS3Logos.png
Orchestration実践
● SerfでConfigurationとOrchestrationを連携○ ChefでSerfのインストールと起動
● JenkinsでOrchestration処理実行○ Queryを使って成功/失敗の判断○ 処理内容はTagsで分岐
Releasalization(造語)
● Orchestrationの処理内容をテスト○ Serverspec
● サーバを本番環境に投入○ LBに追加
サービス提供のプロビジョニング
ConfigurationBootstrapping
ReleasalizationOrchestration
再 掲
● Orchestrationの処理内容をテスト○ Serfでhttpd起動 => httpdが起動しているか
● Configurationのテストは別途実施○ Auto Scalingの話で紹介
Serverspecのテスト
Releasalization実践
● Serverspecによるテスト○ 中途半端なサーバを本番投入しなくてすむ○ Orchestration処理の品質向上
● 全レイヤーの処理が成功すると本番投入
ReleasalizationJOB JOB
OrchestrationJOB JOB
ConfigurationJOB JOB
Bootstrapping AMI/Kickstart
Serf
serf-members
ReleasalizationJOB JOB
OrchestrationJOB JOB
ConfigurationJOB JOB
【query】httpd start
Bootstrapping AMI/Kickstart
ReleasalizationJOB JOB
OrchestrationJOB JOB
ConfigurationJOB JOB
Serverspec
Bootstrapping AMI/Kickstart
Chef/Serverspec
AMI作成編
【実行レシピ(例)】
host名 [設定]iptables [設定]User [設定]PHP [インストール]ImageMagick [インストール]Apache httpd [インストール]GlusterFS [インストール]Zabbix Agent [インストール]Fluentd [インストール]Serf [設定][起動]
Chef/Serverspec
AMI作成編
【実行レシピ(例)】
host名 [設定]iptables [設定]User [設定]PHP [インストール]ImageMagick [インストール]Apache httpd [インストール]GlusterFS [インストール]Zabbix Agent [インストール]Fluentd [インストール]Serf [設定][起動]Chefはインストールと設定だけ
【AMI作成時(例)】
host名 [設定]iptables [設定]User [設定]PHP [インストール]ImageMagick [インストール]Apache httpd [インストール]GlusterFS [インストール]Zabbix Agent [インストール]Fluentd [インストール]Serf [設定][起動]
Configurationの時間短縮
【AMI作成時(例)】
host名 [設定]iptables [設定]User [設定]PHP [インストール]ImageMagick [インストール]Apache httpd [インストール]GlusterFS [インストール]Zabbix Agent [インストール]Fluentd [インストール]Serf [設定][起動]
【Auto Scaling(例)】
host名 [設定]iptables [設定]User [設定]PHP [インストール]ImageMagick [インストール]Apache httpd [インストール]GlusterFS [インストール]Zabbix Agent [インストール]Fluentd [インストール]Serf [設定][起動]
Configurationの時間短縮
Configurationの時間短縮
【AMI作成時(例)】
host名 [設定]iptables [設定]User [設定]PHP [インストール]ImageMagick [インストール]Apache httpd [インストール]GlusterFS [インストール]Zabbix Agent [インストール]Fluentd [インストール]Serf [設定][起動]
【Auto Scaling(例)】
host名 [設定]iptables [設定]User [設定]PHP [インストール]ImageMagick [インストール]Apache httpd [インストール]GlusterFS [インストール]Zabbix Agent [インストール]Fluentd [インストール]Serf [設定][起動]
時間がかかる(10 - 15分)
すぐに終わる(1 - 2分)
【AMI作成時(例)】
host名 [設定]iptables [設定]User [設定]PHP [インストール]ImageMagick [インストール]Apache httpd [インストール]GlusterFS [インストール]Zabbix Agent [インストール]Fluentd [インストール]Serf [設定][起動]
【Auto Scaling(例)】
host名 [設定]iptables [設定]User [設定]PHP [インストール]ImageMagick [インストール]Apache httpd [インストール]GlusterFS [インストール]Zabbix Agent [インストール]Fluentd [インストール]Serf [設定][起動]
Configurationの時間短縮
なるべく事前にやっておく
AMI問題の解決で得たこと
● Infrastructure as Codeの実現○ AMIをChefで管理可能○ テストも実行してChefのCIが可能
● Auto Scalingの失敗時の予防線○ AMI自体のバージョン管理○ 各種サービスを起動させれば本番と同じ
やってみた結果 -概念化-
● Chefが本番に影響しない○ 他サービスと連携しないからテストやCIもできる
● Serfの機能でフローの制御○ 失敗したら先に進まないようにできる
● 本番投入前にServerspecでテスト○ 不完全なサーバは本番稼働させない
● Chefが本番に影響しない○ 他サービスと連携しないからテストやCIもできる
● Serfの機能でフローの制御○ 失敗したら先に進まないようにできる
● 本番投入前にServerspecでテスト○ 不完全なサーバは本番稼働させない
サーバ構築の安定化
やってみた結果 -概念化-
やってみた結果 -Auto Scaling-
● 起動スクリプトの制御不要○ JenkinsとLifecycle Hookの連携
● ChefとAMIで差分がなくなった○ 手動で行っていたことのコード化○ AMI自体のバージョン管理
● ChefのCIができるようになった
● 起動スクリプトの制御不要○ JenkinsとLifecycle Hookの連携
● ChefとAMIで差分がなくなった○ 手動で行っていたことのコード化○ AMI自体のバージョン管理
● ChefのCIができるようになった
やってみた結果 -Auto Scaling-
Infrastructure as Code
やってみた結果 -改善について-
● 時間置いてからの改善大事○ 運用していると不満や改善案がたくさん出る○ 技術が進歩している
● 開発・運用とインフラで仲良くするの大事○ インフラ側視点だけだと運用面で難あり
○ 開発・運用チーム視点だけだと他で使いまわせない
● 時間置いてからの改善大事○ 運用していると不満や改善案がたくさん出る○ 技術が進歩している
● 開発・運用とインフラで仲良くするの大事○ インフラ側視点だけだと運用面で難あり
○ 開発・運用チーム視点だけだと他で使いまわせない
やってみた結果 -改善について-
チーム間の連携は大事