小さく始めて後で困らないためのVPCとChefを使ったAWS運用

小さく始めて後で困らないための
VPCとChefを使ったAWS運用
2013/11/23
第5回関西ソーシャルゲーム勉強会
すずな株式会社代表取締役中村悟

目次
• 自己紹介
• 小さく始めて後で困らないために
•Amazon VPCを利用する
•Chefでサーバーを管理する
•Chefの導入に失敗しないために

Twitter @cloned
自己紹介

営業マン
派遣エンジニア
株式会社アスクドットジェーピー
ウノウ株式会社
ジンガジャパン株式会社
すずな株式会社代表取締役中村悟
http://www.suzna.com/

代表作
自己紹介

まちつく！ (ウノウ/ジンガジャパン)

すずなのゲームについて
自己紹介

インサイドクリプト
https://play.google.com/store/apps/details?id=com.suzna.labyrinth.android

2013/4/25 リリース（Android 2.3 〜 4.3）
サクサク快適にプレイできるシミュレーションゲームを舞台
に、盗まれた国家機密が保存された暗号化ディスクに潜入する
ミステリアスなストーリー、友達と一緒に遊ぶ・他プレイヤー
を倒すソーシャル性、ゲームを盛り上げるゲームミュージック
が魅力なゲームです。

弊社ゲームのサーバー構成例

AWSを利用しています

利用しているサービス

• Amazon VPC (Amazon Virtual Private Cloud)
• Amazon EC2 (Amazon Elastic Compute Cloud)
• Elastic Load Balancing
• EBS (Amazon Elastic Block Store)
• Elastic IP
• Amazon S3 (Amazon Simple Storage Service)
• Amazon Route 53


Amazon S3

VPC 10.0.0.0/24
HTTPS Elastic Load HTTP
Balancing

VPC 10.0.1.0/24
E
C
2

Apache
E
C
2

SSH

E
C
2

E
C
2

踏み台
Nagios
Capistrano

E
C
2

MySQL

Memcached

NAT

※構成は若干省略。台数・IPアドレスはイメージです。

もしVPCを使っていないと？

Amazon S3

インターネット
Elastic Load
Balancing

E
C
2

Apache
E
C
2

SSH

E
C
2

Nagios
Capistrano

E
C
2

MySQL

Memcached

全てのインスタンスがインターネットから接続可能

Amazon VPCとは？
Amazon VPCを利用する

•仮想ネットワークが構築可能
•IPアドレス範囲の選択
•サブネットの作成
•ルートテーブル、ネットワークゲートウェイの設定
•EC2の使用料以外の追加料金はなし

なぜVPCが必要か？

Amazon VPCトレーニング-VPCの説明 P6 より引用
http://www.slideshare.net/AmazonWebServicesJapan/amazon-vpcvpc

•ネットワークセキュリティを高める
•きめ細かなアクセス制御が可能
•Security Group, NACL, Route Table, etc
•VPN, DXを使って完全に外部と閉じた環境を実現
•自由なネットワーク設計が可能
•既存のネットワークルールを適用可能
•ローカルIPを固定で使用可能

VPCはいつ導入すべきか

サービス開始時点！

なぜサービス開始時点？

•クラウドを利用する動機の一つとして
•サービス規模に見合ったコストにしたい
•小規模で始めたい
•負荷が上がればサーバーを増やしたい


!
•負荷が上がればサーバーを増やしたい

•負荷が上がるのはどういう時？
•サービスに人気が出た時
•プロモーションを行った時
•プログラムが変更された時


•負荷が上がってしまうと？
•サービス人気　 → 一刻も早くサーバーを増設したい！
•プロモーション → 落ちると困るから増設して対応しよう！
•プログラム変更 → 改修は時間がかかるからまずは増設で！※注1
•VPCのことなど忘れてEC2インスタンスがどんどん増える・・・
•気付いた時にはインターネット上に大量のEC2インスタンスが・・・
•規模大きくなってからのVPC移行は大変

注1 本来的には増設を行わずに原因を修正するべきですが、運用上の可能性として

インターネットにEC2を増やすと

•並列にインスタンスが存在するため、インスタンスの把握が難しい
•グローバルIPを持ったインスタンスが大量になる
•ネットワークを利用したセキュリティを確保できない ※注1
•例: 3306(MySQL)を自分の管理するサーバーのみにアクセス制限
•適切なIPアドレスの範囲を指定できない・・・
•セキュリティグループが複雑怪奇に・・・
•再起動毎にグローバルIPが変わりメンテナンス地獄
•Elastic IP付与したとしても大量のElastic IPが必要になる
注1 ここではネットワークのみ言及しておりMySQLによるアカウント制限やOSの機能には触れていません

まとめ

•EC2を使う場合は最初からVPCにした方が良い
•VPCが不要かもしれないケース
•インスタンス1台で運用を始めたい
•サービス用途ではなく今すぐ立ち上げたい

Chefでサーバーを管理する

Chefとは？

Chef
http://www.opscode.com/chef/
Chef is an automation platform that transforms
infrastructure into code.
Chefはインフラをコードに変える自動化プラットフォーム

•Server + Nodes + Workstation
•Server(クライアント管理)とNodes(管理対象サーバー)
とWorkstation(操作端末)の3つで構成される基本構成

•chef-solo
•サーバーアクセス不要でローカルホストのみで動作可能
•弊社では今のところchef-soloのみを利用

手作業で構築すると？

•インスタンス起動
•アカウント作成（SSH公開鍵を配備）
•パッケージをインストール
•ディレクトリ/ファイルの配備
•設定ファイル修正
•iptables
•logrotate
•crontab
•ミドルウェア（Apacheなど）
•etc…

もしくは…

•アカウント作成（SSH公開鍵を配備）
•(手作業を部分的に自動化する必殺の) 一子相伝☆秘伝のシェル

手作業の問題点

•手順が多い
•ミスが発生しやすい
•同じ作業をサーバーN台分繰り返し
•作業者のモチベーションが撃沈墜落
•確認項目が多い（目視！目視！目視！）
•見逃す可能性が高い
•一子相伝☆秘伝のシェル
•ノウハウが個人依存なことが多い
•（経験的にですが）大抵はメンテ不能のスパゲティ🍴

構築を自動化する

•[Chefで自動化] アカウント作成（SSH公開鍵を配備）
•[Chefで自動化] パッケージをインストール
•[Chefで自動化] ディレクトリ/ファイルの配備
•[Chefで自動化] 設定ファイル修正
•iptables
•logrotate
•crontab
•ミドルウェア（Apacheなど）
•[Chefで自動化] etc…

自動化すれば

•手順が多い
•→ 手順はChefを実行するだけ
•同じ作業をサーバーN台分繰り返し
•→ 各サーバー（ノード）がどのレシピを使うか設定する
•確認項目が多い（目視！目視！目視！）
•→ Chefには冪等（べきとう）性があり同じ状態になる筈
•ただし、レシピが正しい前提にはなるので serverspec を使ってさらに確
認するケースもあるようです

•一子相伝☆秘伝のシェル
•→ Chefはオープンソースでノウハウも公開されている

Chefも最初から導入すべき？

• 小規模だからこそ
• サーバーが増えれば増えるほど恩恵が得られる
• 最初から導入していれば
• Chefのレシピを修正して反映 → 日常的な運用の一つ
• 最初から導入していないと
• Chefそのものを導入する → 試験のコスト、導入のリスクが大きい
• 最初にChefを導入する時は、手動構築よりコスト増では？
• Chefのノウハウは次のサービスでも利用できる
• 構成の修正がある度に使えるので、すぐに元は取れると思われる

そして時代は自動化の流れ

http://itpro.nikkeibp.co.jp/article/COLUMN/20131002/508384/

Chefの設定はどんな感じ？

•レシピ（という名のRubyコード）にサーバーの設定を書く
•レシピはクックブックという単位でまとめられている
•クックブックはコミュニティに配布されているものもある

レシピ例パッケージインストール
# Packages

パッケージを
インストール

%w{httpd24 httpd24-devel httpd24-tools}.each do |pkg|
package pkg do
action :install
end
end

!
# Service

サービスに登録
サービスを起動

service "httpd" do
supports :status => true, :restart => true, :reload => true
action [ :enable, :start ]
end

!
# Configuration

ERBで書かれた
設定ファイルを
指定の権限で配置

template "httpd.conf" do
path "/etc/httpd/conf/httpd.conf"
source "httpd.conf.erb"
owner "root"
group "root"
mode 0644
end

レシピ例 crontab設定

crontabを設定

cron "sync-s3" do
user "suzna"
weekday "*"
day "*"
hour "4"
minute "00"
command "s3cmd sync /home/suzna/backups s3://com.example/"
action :create
end

/var/spool/cron/suzna

# Chef Name: sync-s3
00 4 * * * s3cmd sync /home/suzna/backups s3://com.example/

詳しくは入門Chef Soloがお勧め

入門Chef Solo - Infrastructure as Code [Kindle版]
http://www.amazon.co.jp/入門Chef-Solo-Infrastructure-as-Code-ebook/dp/B00BSPH158

@naoya_ito さんによるChef解説本
サーバー状態管理フレームワークChef、そのスタンドアロ
ン版であるChef Soloの使い方について、はじめの一歩から
実戦投入レベルに至るまでを解説。試験環境の構築方法、自
動化コードの書き方、Chef のアーキテクチャや思想までを
実例を通して説明します。

参考: 弊社Chef管理対象

•アカウント作成（SSH公開鍵を配備） → YES
•パッケージをインストール → YES
•ディレクトリ/ファイルの配備 → YES
•設定ファイル修正 → YES

弊社Chef設定ファイル管理対象

•SSH /home/<USER>/.ssh/
•Apache /etc/httpd/
•MySQL /etc/my.cnf, /var/lib/mysql/
•Memcached /etc/sysconfig/memcached
•Nagios /etc/nagios/
•logrotate /etc/logrotate.d/
•crontab /var/spool/cron/
•etc…

まとめ
•サーバー構築を自動化して手作業のコストとリスクを減らす
•時代は自動化の流れ
•入門Chef Soloがお勧め

Chefの導入に失敗しないために

× Chef実験環境 → 本番導入

•[問題] 実験用インスタンスで試しただけですぐに本番導入
•実験のみだと「実験が成功 = レシピが完成 = 実験終了」
•レシピが枯れていない → 本番で思わぬエラーなどに出会う可能性
•とはいえ、実験用の同じ構成で何回実行しても結果は同じ
•[解決] 開発環境をChefで管理するところから始める
•プログラムと同じように開発 -> ステージング -> 本番の流れにする
•できるだけ開発環境と本番環境のレシピを共通化
•開発環境で普段からChefを実行 → レシピが枯れる
•logrotateなども実際に歳月を重ねつつ動作を検証できる

× いきなりコミュニティのレシピ

•[問題] いきなりコミュニティのレシピのみで構築しようとする
•コミュニティのレシピは巨大で一見複雑なことが多い ※注1
•RoleやAttributeなどの知識がないとまともに運用できない
•OS別の分岐なども多く何が起こっているのか把握しずらい
•[解決] 自分たちに必要最低限の記述をしたレシピから始める
•インフラは作ったら終わりではない
•運用こそ重要 = レシピを自分たちで修正できることが大切

注1 コミュニティのレシピが悪い訳ではなく、コミュニティのものが優れていたとしても、という意味です

× 最初から完全自動化を目指す

•[問題] 最初から完全に自動でサーバー構築することを目指してしまう
•Chefは最初の一歩は簡単だが、複雑なことをするにはまだ情報が少ない
•ちょっとしたことがエレガントにできず挫折する可能性
•導入までのコストが大きすぎて導入メリットを見失う
•部長『それ、いつまでやってるの？』
•C子『すすすみません、これを導入すればコスト削減がががが』
•[解決] 部分的にChefで管理するところから始める
•新規サーバー構築時に毎回実行するものだけでも十分価値がある
•管理サーバーが少なければchef-soloだけで構築するのもあり

まとめ
•開発環境をChefで管理するところから始める
•自分たちに必要な最低限のみ記述したレシピから始める
•部分的にChefで管理するところから始める
•部長と仲良くする

ご清聴ありがとうございました

小さく始めて後で困らないためのVPCとChefを使ったAWS運用

More Related Content

小さく始めて後で困らないためのVPCとChefを使ったAWS運用