【20-E-5】実践！Infrastructure as a Codeの取り組みと改善

「実践！Infrastructure as Codeの取り組みと改善」

Copyright 2015 CYBIRD Co., Ltd. All Rights Reserved.

株式会社サイバード藤原涼本田恭

Infrastructure as Code

Agenda〜問題編〜　インフラの歴史とサーバ構築概念化

〜改善編〜　サーバ構築実践とAuto Scaling

Agenda 〜問題編〜

1: サービスの特徴

2: インフラの歴史

3: サーバ構築の概念化

自己紹介

● 藤原　涼● 2012年新卒入社 (3年目)● Twitter @megadreams14● エンジニア

○ ソーシャルゲームの開発・運用○ サーバ運用からフロントエンド開発まで幅広く担当

サービスの特徴

ソーシャルゲームの開発・運用

〜女性向け恋愛ソーシャルゲーム〜

恋愛ソーシャルゲームとは

華やかで

甘いストーリーが

楽しめる

http://ikemen.cybird.ne.jp/of/play.html

恋愛ソーシャルゲームとは

アバターなどを

着せ替えて可愛く

コーディネイト出来る

http://ikemen.cybird.ne.jp/of/play.html

私達が皆様にお約束すること

http://ikemen.cybird.ne.jp/of/message.html

リリース一覧

イケメンシリーズ

イケメン大奥イケメン清盛イケメン王宮

新章イケメン大奥イケメン夜曲イケメン幕末

イケメン王宮２ラブセン

眠り姫イケメン王国

急激なアクセス増加による

サーバ負荷に耐える必要がある

恋愛ソーシャルゲームのインフラ事情

恋愛ソーシャルゲームのインフラ事情2013年

2014年

2015年

夏

基本的に手動でサーバ構築

運用管理サービス


2014年

2015年

夏


Chefの導入とサーバ構築自動化


ミドルウェアのインストール環境に合わせた設定適用

ソースコードのデプロイ画像のデプロイ

Zabbix Serverに追加LBへの追加

https://www.chef.io/http://jenkins-ci.org/

Chefが全体管理を行う




Chefを導入することで

● サーバ構築を自動化

● 構築手順の明確化

● 迅速なスケールアウト

サーバの自動構築が出来たAuto Scaling対応したい！！


2014年

2015年

夏


Chefの導入とサーバ構築自動化秋

Auto Scaling導入


Auto Scaling運用当初

これまでのAuto Scaling

負荷情報を送信

http://www.blog.drvoip.com/wp-content/uploads/2015/01/awss31.png



負荷検知アラート発動




AMIから起動



AMIから起動連携しながら構築




AMIから起動連携しながら構築本番稼働





起動用AMIの作成




オートスケールで起動したサーバに実行

これまでのオートスケール



連携しながら構築 AMIを定期的に更新本番稼働

Auto Scalingを導入することで

● 負荷に合わせて自動でサーバを増減○ 急激な負荷にも耐えられる

● スケジュール機能を利用したサーバ増減○ スケジュールでサーバ増減

Auto Scalingを導入することで

運用効率化と機会損失の削減

● 負荷に合わせて自動でサーバを増減○ 急激な負荷にも耐えられる

● スケジュール機能を利用したサーバ増減○ スケジュールでサーバ増減

恋愛ソーシャルゲームインフラ事情2013年

2014年

2015年

夏



Auto Scaling導入冬

サーバ構築自動化とAuto Scaling本格運用


slideshare autoscale ゲーム

http://goo.gl/i0cXfH


2014年

2015年

夏




サーバ構築自動化とAuto Scaling本格運用夏

サーバ構築の運用上の課題と改善


Chefによる

サーバ構築自動化での様々な問題

Chefが全体管理を行う




再　掲

１：構成管理ツールに全てを任せている

● Chefのレシピのコードの複雑化○ Chefの役割が集中している○ Cookbook同士が疎結合になっていない○ 冪等性が担保されていない

● 外部サービスとの連携○ サーバ内で完結しない処理もレシピ化○ デプロイやロードバランサへの追加

２：運用上の課題

● Chef Serverとの接続エラー○ 単一障害点、同時接続数問題

● Chefの実行結果を追跡しずらい○ 実行したサーバに入らないとログが確認できない

問題点

● 構成管理ツールに全てを任せている

● 運用上の問題

Chefの役割を明確化し、

サーバ構築をもっと単純化したい

サーバ構築の理想イメージ図

他サービスと連携

？サーバ内で完結

全体管理

？

サーバ構築の概念

Provisioning Toolchain

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

http://kentana20.hatenablog.com/entry/2014/02/15/023158

Provisioning Toolchain● Bootstrapping

● Configuration

● Orchestration

Bootstrapping

● OSのインストールとサーバ起動● Configurationを実行するための準備

OSのプロビジョニング

BootstrappingConfigurationOrchestration

Configuration

● ミドルウェアのセットアップ● 対象サーバの役割に応じた設定● サーバ単体で完結するような処理

システム構成のプロビジョニング

構成管理ツールが得意な領域BootstrappingConfigurationOrchestration

Orchestration

● サーバ単体では完結しない処理を担う○ GlusterFSのClusterに追加○ Jenkinsからソースコードデプロイ○ zabbix-agentの起動など

アプリケーションのプロビジョニング


デプロイツールなどが得意な領域

サーバ構築における４つ目のレイヤー

Releasalization（造語）

● Orchestrationの処理内容をテスト○ Serverspec

● サーバを本番環境に投入○ LBに追加

サービス提供のプロビジョニング

ConfigurationBootstrapping

ReleasalizationOrchestration

Bootstrapping

Releasalization

Orchestration

Configuration

Bootstrapping

Releasalization

Orchestration

Configuration単純化・明確化




全体管理

？

再　掲

Bootstrapping

ReleasalizationOrchestrationConfiguration

Bootstrapping


Jenkinsが全体制御

Bootstrapping


Jenkinsが全体制御

シンプルかつレジリエント


2014年

夏






サーバ構築の概念化2015年秋

冬


slideshare jenkins 役割 2015

http://goo.gl/dQozKz


2014年

2015年

夏






サーバ構築の概念化秋

Auto Scaling見直し冬


これまでのAuto Scalingの問題点

これまでのAuto Scalingの問題点

● 起動スクリプトで制御しなければいけない

● Auto Scaling機能で起動後すぐにELBに追加

● 起動用AMI作成の手間

起動スクリプトで制御しなければいけない

〜問題１〜

本番稼働




起動スクリプトで制御

● /etc/init.dでやっていること○ サーバのホスト名の決定○ Chefの実行制御（失敗制御など）○ メール通知

● 手動起動の際にもChefが流れる○ 間違って起動するとサービスに組み込まれる危険性○ サーバ再起動で毎回処理が走る

起動スクリプトで制御

Auto Scaling機能では起動後すぐにELBに追加される

〜問題２〜

起動したらELBに組み込まれる


サーバの状態 AMIから起動


サーバの状態

起動したタイミングでELBに組み込まれる


AMIから起動


サーバの状態

起動したタイミングでELBに組み込まれる


AMIから起動設定前に組み込みたくない


サーバの状態


起動後、ELBから外す処理

AMIから起動


サーバの状態


AMIから起動

起動後、ELBから外す処理


サーバの状態




サーバの状態



変則的なフローに嫌悪感

起動用AMI作成の手間

〜問題３〜



連携しながら構築 AMIを定期的に更新本番稼働


● 起動AMI用のレシピをメンテナンスしていない○ 基本的に初回作成時のみ○ 随時手動で設定変更

● リソースデータの最新化の手間○ 予め画像ファイルなどをダウンロード○ 本番稼働前は、差分のみを適用○ 画像の更新が多いため、差分がすぐに多くなる





Auto Scalingの３つの問題

AMIは自動で定期的に更新

起動スクリプト以外で構築フローの実施

設定完了後にELBに組込

Auto Scaling理想イメージ図

？


2014年

2015年

夏






サーバ構築の概念化秋

Auto Scaling見直し冬

運用管理サービスAuto Scaling運用とコスト削減取り組み

ここから「改善編」です

Agenda〜問題編〜　インフラの歴史とサーバ構築概念化

〜改善編〜　サーバ構築実践とAuto Scaling

自己紹介

● 本田恭 (ほんだたかし)● 2012年新卒入社 (3年目)● Twitter: @Altsencturely● インフラ系男子

Agenda 〜改善編〜

1: 各レイヤーの実践方法

2: Auto Scalingについて

3: やってみた結果

Bootstrapping

Releasalization

Orchestration

Configuration

再　掲

レイヤー

● Bootstrapping

● Configuration

● Orchestration

● Releasalization

Bootstrapping

● OSのインストールとサーバ起動● Configurationを実行するための準備

OSのプロビジョニング


再　掲

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が実行できる状態にするだけ

レイヤー

● Bootstrapping

● Configuration

● Orchestration

● Releasalization

Configuration

● ミドルウェアのセットアップ● 対象サーバの役割に応じた設定● サーバ単体で完結するような処理

システム構成のプロビジョニング

構成管理ツールが得意な領域BootstrappingConfigurationOrchestration

再　掲

Configuration実践

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上で見られる

レイヤー

● Bootstrapping

● Configuration

● Orchestration

● Releasalization

Orchestration

● サーバ単体では完結しない処理を担う○ GlusterFSのClusterに追加○ Jenkinsからソースコードデプロイ○ zabbix-agentの起動など

アプリケーションのプロビジョニング


デプロイツールなどが得意な領域

再　掲

Orchestration実践

http://pocketstudio.jp.s3.amazonaws.com/log3/wp-content/uploads/2013/11/serf-logo.png

S E R F

Serfって何?

● Go言語製オーケストレーションツール○ メンバーシップ○ 障害検知と復旧○ カスタムイベント伝播○ https://serfdom.io/

● ゴシッププロトコル

これまでのSerfの利用方法

http://4.bp.blogspot.com/-XvJgBCygSCo/UxRl_TMQNlI/AAAAAAAAAWc/-ui0-NKM_70/s1600/logo.png

S E R F

slideshare autoscale ゲーム

http://goo.gl/MKgQPA

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



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実践

Orchestration実践

Orchestrationジョブ実行

Orchestration実践

SerfのTagでジョブ内容切り分け

Orchestration実践

【query】httpd start

※-nodeで対象指定

Orchestration実践


Orchestration実践

● SerfでConfigurationとOrchestrationを連携○ ChefでSerfのインストールと起動

● JenkinsでOrchestration処理実行○ Queryを使って成功/失敗の判断○ 処理内容はTagsで分岐

レイヤー

● Bootstrapping

● Configuration

● Orchestration

● Releasalization

Releasalization（造語）

● Orchestrationの処理内容をテスト○ Serverspec

● サーバを本番環境に投入○ LBに追加

サービス提供のプロビジョニング

ConfigurationBootstrapping

ReleasalizationOrchestration

再　掲

Serverspecって何？

● サーバ環境の自動テストフレームワーク○ RSpecの機能を使って書ける

○ http://serverspec.org/

Orchestration実践


再　掲

Releasalization実践

Serverspec

● Orchestrationの処理内容をテスト○ Serfでhttpd起動 => httpdが起動しているか

● Configurationのテストは別途実施○ Auto Scalingの話で紹介

Serverspecのテスト


LB追加


すべて成功したら本番環境投入


● Serverspecによるテスト○ 中途半端なサーバを本番投入しなくてすむ○ Orchestration処理の品質向上

● 全レイヤーの処理が成功すると本番投入

Bootstrapping AMI/Kickstart

ReleasalizationJOB JOB

OrchestrationJOB JOB

ConfigurationJOB JOB





Serf

serf-members




Serverspec





全体管理

？

再　掲


他サービスと連携サーバ内で完結

全体管理




Auto Scalingの３つの問題再　掲

再　掲





？





？

Auto ScalingでELBに入る前に何か処理がしたい

Lifecycle Hook

Lifecycle Hook

● Auto Scalingの新機能の1つ○ 2014年8月発表

● Auto ScalingのLifecycle内でインスタンスの状態の制御と通知

http://docs.aws.amazon.com/AutoScaling/latest/DeveloperGuide/images/as-lifecycle-basic-diagram.png

Custom Action

Custom Action

Lifecycle Hook機能まとめ

● Auto Scalingの遷移でユーザーに通知

● 通知を受けてインスタンスへの処理が可能

● APIで終了を通知しAuto Scalingの処理継続

Lifecycle Hookと

4つのレイヤー

Auto ScalingGroup

Auto Scalingで起動開始

起動通知

SQS

SQS

取得

● Configuration○ Chef

● Orchestration○ デプロイ○ サービス起動

● Releasalization○ Serverspec

完了通知

グループへ追加

サーバ追加

サーバ追加

ELB追加はAuto Scalingの機能

Lifecycle Hookのメリット

● JenkinsがAuto Scalingの発動を取れる○ 各レイヤーの処理を自動化

● JenkinsとAWSの様々なプロダクトで完結

Lifecycle Hookにより解決したこと

● 起動スクリプトで制御

● 起動後すぐにELBに追加される

● 起動スクリプトで制御

● 起動後すぐにELBに追加される

Lifecycle Hookにより解決したこと

Auto Scalingを自然な形に




？

Auto Scaling理想イメージ図再　掲




再　掲

ChefとAMI連携の自動化と

Auto Scalingの高速化

AMI作成編

Plug-in

AMI作成編

起動

AMI作成編

Chef/Serverspec

AMI作成編

Configurationのテストを実施

Chef/Serverspec

Chef/Serverspec

AMI作成編



Chef/Serverspec

AMI作成編


host名 [設定]iptables [設定]User [設定]PHP [インストール]ImageMagick [インストール]Apache httpd [インストール]GlusterFS [インストール]Zabbix Agent [インストール]Fluentd [インストール]Serf [設定][起動]Chefはインストールと設定だけ

AMI作成編

ミドルウェア(インストールと設定)

AMI作成編

デプロイ

AMI作成編

ミドルウェア(インストールと設定)

リソース(実行時の最新状態)

AMI作成編

AMI作成

AMI作成編

Auto Scaling設定更新

【AMI作成時(例)】


Configurationの時間短縮



【Auto Scaling(例)】








時間がかかる(10 - 15分)

すぐに終わる(1 - 2分)






なるべく事前にやっておく

AMI問題の解決で得たこと

● Infrastructure as Codeの実現○ AMIをChefで管理可能○ テストも実行してChefのCIが可能

● Auto Scalingの失敗時の予防線○ AMI自体のバージョン管理○ 各種サービスを起動させれば本番と同じ




設定完了後にELBに組込自然な形でAuto Scalingの実装

やってみた結果 -概念化-

● 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

やってみた結果 -改善について-

● 時間置いてからの改善大事○ 運用していると不満や改善案がたくさん出る○ 技術が進歩している

● 開発・運用とインフラで仲良くするの大事○ インフラ側視点だけだと運用面で難あり

○ 開発・運用チーム視点だけだと他で使いまわせない

● 時間置いてからの改善大事○ 運用していると不満や改善案がたくさん出る○ 技術が進歩している

● 開発・運用とインフラで仲良くするの大事○ インフラ側視点だけだと運用面で難あり

○ 開発・運用チーム視点だけだと他で使いまわせない

やってみた結果 -改善について-

チーム間の連携は大事

Growth!

【20-E-5】実践！Infrastructure as a Codeの取り組みと改善

Documents

Transcript of 【20-E-5】実践！Infrastructure as a Codeの取り組みと改善