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

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

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

4. 代表作
自己紹介
まちつく！ (ウノウ/ジンガジャパン)

5. すずなのゲームについて
自己紹介
インサイド クリプト
https://play.google.com/store/apps/details?id=com.suzna.labyrinth.android
2013/4/25 リリース（Android 2.3 〜 4.3）
サクサク快適にプレイできるシミュレーションゲームを舞台
に、盗まれた国家機密が保存された暗号化ディスクに潜入する
ミステリアスなストーリー、友達と一緒に遊ぶ・他プレイヤー
を倒すソーシャル性、ゲームを盛り上げるゲームミュージック
が魅力なゲームです。

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

7. 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

8. 弊社ゲームのサーバー構成例
弊社ゲームのサーバー構成例
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アドレスはイメージです。

9. もしVPCを使っていないと？
弊社ゲームのサーバー構成例
Amazon S3
インターネット
Elastic Load
Balancing
E
C
2
Apache
E
C
2
SSH
E
C
2
Nagios
Capistrano
E
C
2
MySQL
Memcached
全てのインスタンスがインターネットから接続可能

10. Amazon VPCを利用する

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

12. なぜVPCが必要か？
Amazon VPCを利用する
Amazon VPCトレーニング-VPCの説明 P6 より引用
http://www.slideshare.net/AmazonWebServicesJapan/amazon-vpcvpc
•ネットワークセキュリティを高める
•きめ細かなアクセス制御が可能
•Security Group, NACL, Route Table, etc
•VPN, DXを使って完全に外部と閉じた環境を実現
•自由なネットワーク設計が可能
•既存のネットワークルールを適用可能
•ローカルIPを固定で使用可能

13. VPCはいつ導入すべきか
Amazon VPCを利用する
サービス開始時点！

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

15. なぜサービス開始時点？
Amazon VPCを利用する
!
•負荷が上がればサーバーを増やしたい
•負荷が上がるのはどういう時？
•サービスに人気が出た時
•プロモーションを行った時
•プログラムが変更された時

16. なぜサービス開始時点？
Amazon VPCを利用する
•負荷が上がってしまうと？
•サービス人気 → 一刻も早くサーバーを増設したい！
•プロモーション → 落ちると困るから増設して対応しよう！
•プログラム変更 → 改修は時間がかかるからまずは増設で！※注1
•VPCのことなど忘れてEC2インスタンスがどんどん増える・・・
•気付いた時にはインターネット上に大量のEC2インスタンスが・・・
•規模大きくなってからのVPC移行は大変
注1 本来的には増設を行わずに原因を修正するべきですが、運用上の可能性として

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

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

19. Chefでサーバーを管理する

20. 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のみを利用

21. 手作業で構築すると？
Chefでサーバーを管理する
•インスタンス起動
•アカウント作成（SSH公開鍵を配備）
•パッケージをインストール
•ディレクトリ/ファイルの配備
•設定ファイル修正
•iptables
•logrotate
•crontab
•ミドルウェア（Apacheなど）
•etc…

22. もしくは…
Chefでサーバーを管理する
•インスタンス起動
•アカウント作成（SSH公開鍵を配備）
•(手作業を部分的に自動化する必殺の) 一子相伝☆秘伝のシェル

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

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

25. 自動化すれば
Chefでサーバーを管理する
•手順が多い
•→ 手順はChefを実行するだけ
•同じ作業をサーバーN台分繰り返し
•→ 各サーバー（ノード）がどのレシピを使うか設定する
•確認項目が多い（目視！ 目視！ 目視！）
•→ Chefには冪等（べきとう）性があり同じ状態になる筈
•ただし、レシピが正しい前提にはなるので serverspec を使ってさらに確
認するケースもあるようです
•一子相伝☆秘伝のシェル
•→ Chefはオープンソースでノウハウも公開されている

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

27. そして時代は自動化の流れ
Chefでサーバーを管理する
http://itpro.nikkeibp.co.jp/article/COLUMN/20131002/508384/

28. Chefの設定はどんな感じ？
Chefでサーバーを管理する
•レシピ（という名のRubyコード）にサーバーの設定を書く
•レシピはクックブックという単位でまとめられている
•クックブックはコミュニティに配布されているものもある

29. レシピ例 パッケージインストール
Chefでサーバーを管理する
# 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

30. レシピ例 crontab設定
Chefでサーバーを管理する
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/

31. 詳しくは入門Chef Soloがお勧め
Chefでサーバーを管理する
入門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 のアーキテクチャや思想までを
実例を通して説明します。

32. 参考: 弊社Chef管理対象
Chefでサーバーを管理する
•インスタンス起動
•アカウント作成（SSH公開鍵を配備） → YES
•パッケージをインストール → YES
•ディレクトリ/ファイルの配備 → YES
•設定ファイル修正 → YES

33. 弊社Chef設定ファイル管理対象
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…

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

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

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

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

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

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

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