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

2,900 views

Published on

Published in: Technology
0 Comments
25 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,900
On SlideShare
0
From Embeds
0
Number of Embeds
81
Actions
Shares
0
Downloads
24
Comments
0
Likes
25
Embeds 0
No embeds

No notes for slide

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

  1. 1. 小さく始めて後で困らないための VPCとChefを使ったAWS運用 2013/11/23   第5回  関西ソーシャルゲーム勉強会   すずな株式会社  代表取締役  中村  悟
  2. 2. 目次 • 自己紹介   • 小さく始めて後で困らないために   •Amazon  VPCを利用する   •Chefでサーバーを管理する   •Chefの導入に失敗しないために
  3. 3. Twitter @cloned 自己紹介 営業マン 派遣エンジニア 株式会社アスク  ドット  ジェーピー ウノウ株式会社 ジンガジャパン株式会社 すずな株式会社  代表取締役  中村  悟 http://www.suzna.com/
  4. 4. 代表作 自己紹介 まちつく!  (ウノウ/ジンガジャパン)
  5. 5. すずなのゲームについて 自己紹介 インサイド  クリプト https://play.google.com/store/apps/details?id=com.suzna.labyrinth.android 2013/4/25  リリース(Android  2.3  〜  4.3)   サクサク快適にプレイできるシミュレーションゲームを舞台 に、盗まれた国家機密が保存された暗号化ディスクに潜入する ミステリアスなストーリー、友達と一緒に遊ぶ・他プレイヤー を倒すソーシャル性、ゲームを盛り上げるゲームミュージック が魅力なゲームです。
  6. 6. 弊社ゲームのサーバー構成例
  7. 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. 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. 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. 10. Amazon  VPCを利用する
  11. 11. Amazon  VPCとは? Amazon  VPCを利用する •仮想ネットワークが構築可能   •IPアドレス範囲の選択   •サブネットの作成   •ルートテーブル、ネットワークゲートウェイの設定   •EC2の使用料以外の追加料金はなし
  12. 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. 13. VPCはいつ導入すべきか Amazon  VPCを利用する サービス開始時点!
  14. 14. なぜサービス開始時点? Amazon  VPCを利用する •クラウドを利用する動機の一つとして   •サービス規模に見合ったコストにしたい   •小規模で始めたい •負荷が上がればサーバーを増やしたい
  15. 15. なぜサービス開始時点? Amazon  VPCを利用する ! •負荷が上がればサーバーを増やしたい •負荷が上がるのはどういう時?   •サービスに人気が出た時   •プロモーションを行った時   •プログラムが変更された時
  16. 16. なぜサービス開始時点? Amazon  VPCを利用する •負荷が上がってしまうと?   •サービス人気   →  一刻も早くサーバーを増設したい!   •プロモーション  →  落ちると困るから増設して対応しよう!   •プログラム変更  →  改修は時間がかかるからまずは増設で!※注1   •VPCのことなど忘れてEC2インスタンスがどんどん増える・・・   •気付いた時にはインターネット上に大量のEC2インスタンスが・・・   •規模大きくなってからのVPC移行は大変 注1 本来的には増設を行わずに原因を修正するべきですが、運用上の可能性として
  17. 17. インターネットにEC2を増やすと Amazon  VPCを利用する •並列にインスタンスが存在するため、インスタンスの把握が難しい   •グローバルIPを持ったインスタンスが大量になる   •ネットワークを利用したセキュリティを確保できない  ※注1   •例:  3306(MySQL)を自分の管理するサーバーのみにアクセス制限   •適切なIPアドレスの範囲を指定できない・・・   •セキュリティグループが複雑怪奇に・・・   •再起動毎にグローバルIPが変わりメンテナンス地獄   •Elastic  IP付与したとしても大量のElastic  IPが必要になる 注1 ここではネットワークのみ言及しておりMySQLによるアカウント制限やOSの機能には触れていません
  18. 18. まとめ Amazon  VPCを利用する •EC2を使う場合は最初からVPCにした方が良い   •VPCが不要かもしれないケース   •インスタンス1台で運用を始めたい   •サービス用途ではなく今すぐ立ち上げたい
  19. 19. Chefでサーバーを管理する
  20. 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. 21. 手作業で構築すると? Chefでサーバーを管理する •インスタンス起動   •アカウント作成(SSH公開鍵を配備)   •パッケージをインストール   •ディレクトリ/ファイルの配備   •設定ファイル修正   •iptables   •logrotate   •crontab   •ミドルウェア(Apacheなど)   •etc…
  22. 22. もしくは… Chefでサーバーを管理する •インスタンス起動   •アカウント作成(SSH公開鍵を配備)   •(手作業を部分的に自動化する必殺の)  一子相伝☆秘伝のシェル
  23. 23. 手作業の問題点 Chefでサーバーを管理する •手順が多い   •ミスが発生しやすい   •同じ作業をサーバーN台分繰り返し   •作業者のモチベーションが撃沈墜落   •確認項目が多い(目視!  目視!  目視!)   •見逃す可能性が高い   •一子相伝☆秘伝のシェル   •ノウハウが個人依存なことが多い   •(経験的にですが)大抵はメンテ不能のスパゲティ🍴
  24. 24. 構築を自動化する Chefでサーバーを管理する •インスタンス起動   •[Chefで自動化]  アカウント作成(SSH公開鍵を配備)   •[Chefで自動化]  パッケージをインストール   •[Chefで自動化]  ディレクトリ/ファイルの配備   •[Chefで自動化]  設定ファイル修正   •iptables   •logrotate   •crontab   •ミドルウェア(Apacheなど)   •[Chefで自動化]  etc…
  25. 25. 自動化すれば Chefでサーバーを管理する •手順が多い   •→  手順はChefを実行するだけ   •同じ作業をサーバーN台分繰り返し   •→  各サーバー(ノード)がどのレシピを使うか設定する   •確認項目が多い(目視!  目視!  目視!)   •→  Chefには冪等(べきとう)性があり同じ状態になる筈   •ただし、レシピが正しい前提にはなるので  serverspec  を使ってさらに確 認するケースもあるようです   •一子相伝☆秘伝のシェル   •→  Chefはオープンソースでノウハウも公開されている
  26. 26. Chefも最初から導入すべき? Chefでサーバーを管理する • 小規模だからこそ   • サーバーが増えれば増えるほど恩恵が得られる   • 最初から導入していれば   • Chefのレシピを修正して反映  →  日常的な運用の一つ   • 最初から導入していないと   • Chefそのものを導入する  →  試験のコスト、導入のリスクが大きい   • 最初にChefを導入する時は、手動構築よりコスト増では?   • Chefのノウハウは次のサービスでも利用できる   • 構成の修正がある度に使えるので、すぐに元は取れると思われる
  27. 27. そして時代は自動化の流れ Chefでサーバーを管理する http://itpro.nikkeibp.co.jp/article/COLUMN/20131002/508384/
  28. 28. Chefの設定はどんな感じ? Chefでサーバーを管理する •レシピ(という名のRubyコード)にサーバーの設定を書く   •レシピはクックブックという単位でまとめられている   •クックブックはコミュニティに配布されているものもある
  29. 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. 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. 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. 32. 参考:  弊社Chef管理対象 Chefでサーバーを管理する •インスタンス起動   •アカウント作成(SSH公開鍵を配備)  →  YES   •パッケージをインストール  →  YES   •ディレクトリ/ファイルの配備  →  YES   •設定ファイル修正  →  YES
  33. 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. 34. まとめ •サーバー構築を自動化して手作業のコストとリスクを減らす   •時代は自動化の流れ   •入門Chef  Soloがお勧め
  35. 35. Chefの導入に失敗しないために
  36. 36. ×  Chef実験環境  →  本番導入 Chefの導入に失敗しないために •[問題]  実験用インスタンスで試しただけですぐに本番導入   •実験のみだと「実験が成功  =  レシピが完成  =  実験終了」   •レシピが枯れていない  →  本番で思わぬエラーなどに出会う可能性   •とはいえ、実験用の同じ構成で何回実行しても結果は同じ   •[解決]  開発環境をChefで管理するところから始める   •プログラムと同じように開発  ->  ステージング  ->  本番の流れにする   •できるだけ開発環境と本番環境のレシピを共通化   •開発環境で普段からChefを実行  →  レシピが枯れる   •logrotateなども実際に歳月を重ねつつ動作を検証できる
  37. 37. ×  いきなりコミュニティのレシピ Chefの導入に失敗しないために •[問題]  いきなりコミュニティのレシピのみで構築しようとする   •コミュニティのレシピは巨大で一見複雑なことが多い  ※注1   •RoleやAttributeなどの知識がないとまともに運用できない   •OS別の分岐なども多く何が起こっているのか把握しずらい   •[解決]  自分たちに必要最低限の記述をしたレシピから始める   •インフラは作ったら終わりではない   •運用こそ重要  =  レシピを自分たちで修正できることが大切 注1 コミュニティのレシピが悪い訳ではなく、コミュニティのものが優れていたとしても、という意味です
  38. 38. ×  最初から完全自動化を目指す Chefの導入に失敗しないために •[問題]  最初から完全に自動でサーバー構築することを目指してしまう   •Chefは最初の一歩は簡単だが、複雑なことをするにはまだ情報が少ない   •ちょっとしたことがエレガントにできず挫折する可能性   •導入までのコストが大きすぎて導入メリットを見失う   •部長『それ、いつまでやってるの?』   •C子『すすすみません、これを導入すればコスト削減がががが』   •[解決]  部分的にChefで管理するところから始める   •新規サーバー構築時に毎回実行するものだけでも十分価値がある   •管理サーバーが少なければchef-soloだけで構築するのもあり
  39. 39. まとめ •開発環境をChefで管理するところから始める   •自分たちに必要な最低限のみ記述したレシピから始める   •部分的にChefで管理するところから始める   •部長と仲良くする
  40. 40. ご清聴ありがとうございました

×