Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

AWS上でのWebアプリケーションデプロイ

47 991 vues

Publié le

AWS上でのWebアプリケーションデプロイ

  1. 1. AWS上でのWebアプリケーションデプロイアマゾン データサービス ジャパン株式会社2013/05/06
  2. 2. 本資料の対象はじめにデプロイとはパターン1: AWSでのベーシックなデプロイ1. AMI+SCMでデプロイ2. Auto Scalingを適用してみる3. 更にデプロイツールで自動化してみるパターン2: Elastic Beanstalkを使ったデプロイまとめ
  3. 3. 本資料の対象はじめにデプロイとはパターン1: AWSでのベーシックなデプロイ1. AMI+SCMでデプロイ2. Auto Scalingを適用してみる3. 更にデプロイツールで自動化してみるパターン2: Elastic Beanstalkを使ったデプロイまとめ
  4. 4. 本資料の対象現在AWSでシステムを運用中のWebサービス開発者の方複数台のアプリケーションサーバーへのコードのデプロイをどうすべきか悩んでいる方
  5. 5. 本資料の対象はじめにデプロイとはパターン1: AWSでのベーシックなデプロイ1. AMI+SCMでデプロイ2. Auto Scalingを適用してみる3. 更にデプロイツールで自動化してみるパターン2: Elastic Beanstalkを使ったデプロイまとめ
  6. 6. よく聞くデプロイまわりの問題
  7. 7. 時間がかかる• 1回のデプロイに2時間かかるとすると、1日にデプロイができるのはせいぜい3回。それよりもリリースしたい機能が多かったらどうする?• かといってリリースするコードの単位を大きくしてしまうと問題がおきたときの対応が難しくなる。• 更に、バグがあったときにも切り戻しに2時間も待たなきゃいけないのは致命的
  8. 8. ロールバックできない• バグは発生するもの。デプロイ後、バグが発見されたときに戻す手順がないと悲惨なことに。• そういう状況が続くと、そもそもデプロイがリスクに見えてきて「リリースは危険なので時期をみて慎重に判断しましょう」とかなって本末転倒!• DB関連の変更を伴うときはより注意を払うこと。スキーマ等の変更は必ず後半互換性を持たせる!
  9. 9. 前後条件や環境条件が多い• 「この作業は別の作業Aをやったあとじゃないとうまく動かない」とか「この作業をやってしまうと元のコードは動かなくなる」みたいなのは事故の温床。• 本番環境と開発環境ではコード内の定数を変えないといけない、みたいなのも事故の温床。• デプロイは何度やっても同じ結果になるようにするべき。
  10. 10. こういった罠にはまらないように適切なデプロイワークフローをつくりましょう
  11. 11. 本資料の対象はじめにデプロイとはパターン1: AWSでのベーシックなデプロイ1. AMI+SCMでデプロイ2. Auto Scalingを適用してみる3. 更にデプロイツールで自動化してみるパターン2: Elastic Beanstalkを使ったデプロイまとめ
  12. 12. 新しいコードをサーバーに配って有効化したり、サーバーを新規に配置してサービスに付け加えたり、構成変更やバージョンアップを実施すること。この資料では主にアプリケーションコードのデプロイについて扱います。ChefやPuppetなどを使ったインフラのデプロイ自動化についてはこの資料では扱いません。
  13. 13. デプロイどうやってますか?
  14. 14. rsyncでコードを配る?gitでpullする?AMIにコードを埋め込む?Elastic Beanstalk使う?Capistrano使ってデプロイ?いろいろあってどれが最適なのか…
  15. 15. 素早くできること• 1回2時間かかったら1日に何回デプロイできる?ロールバックできること• バグがあったらすぐにもどせないと致命的条件を少なくすること• いつだれが何度やっても同じ結果になるようにするデプロイで大事なこと
  16. 16. 本資料の対象はじめにデプロイとはパターン1: AWSでのベーシックなデプロイ1. AMI+SCMでデプロイ2. Auto Scalingを適用してみる3. 更にデプロイツールで自動化してみるパターン2: Elastic Beanstalkを使ったデプロイまとめ
  17. 17. AMIとSCMでデプロイ17コードコード コードコードはgitなどのSCM、サーバー構成はAMIで管理する開発環境と本番環境などにおいてサーバー構成を揃えやすいのがメリットデプロイされた後、コードはSCMを使って最新化するコード以外を更新する際はAMIを作り直す①EC2をAMI化②コードはSCMへコミット③AMIから新しいEC2を起動④起動したEC2にSCMからコードをデプロイ
  18. 18. SCMをつかってコードを最新化AMIとSCMでデプロイ18コード コードコードごとAMI化新規サーバーをデプロイ新規にサーバーをデプロイするときはこの手順をすべて実施コードだけのデプロイの場合はここだけやればOK例えばSSHでデプロイ対象にログインして$ git pull$ sudo apachectl restart
  19. 19. 新しいサーバー追加したら• SSHでログインしてgit pull & apachectl restartコードを新しくするときも• SSHでログインしてgit pull & apachectl restartこの方式の問題点は?• それぞれデプロイ対象のサーバーにログインしてデプロイ作業をしなければいけない• 台数が増えてくるとつらい!19AMIとSCMでデプロイ まとめると
  20. 20. デプロイツールで作業を自動化しましょう
  21. 21. 前述の2つの方式で課題になっていた「各サーバーにSSHでログインしてコードの最新化やロールバックする」というような作業を自動化してくれるツール有名どころとしてはCapistrano、Fabric、Mavenなどデプロイツールとは?デプロイ対象のサーバー群すべてに対して自動的にこういった作業を実施してくれる。
  22. 22. デプロイツールを組み合わせる22コード コード新規サーバーをデプロイデプロイツールでコードをデプロイサーバーに関しては、前述の「AMI」もしくは「Auto Scaling」を使って管理・デプロイするこの部分を手動ではなくデプロイツールで実施する
  23. 23. デプロイツールを組み合わせる23Capistranoでデプロイするなら・・• Capistranoはもともとrailsアプリケーションのデプロイ用に作られたものだが、rails以外でも使える。(ただし、その場合はrailsless-deployというプラグインが必要)• インストールはgemで。• 次のページに続く$ gem install capistrano$ gem install capistrano_colors #あると便利$ gem install capistrano-ext #あると便利$ gem install railsless-deploy #rails以外に使うときに必要
  24. 24. デプロイツールを組み合わせる24Capistranoでデプロイするなら・・• 設定ファイルをつくる。デプロイ対象のアプリのルートディレクトリで下記を実行。設定ファイル等が生成される。• そうすると以下の様な設定ファイル群が生成される• 次のページに続く$ capify$ tree.├── Capfile├── config│ └── deploy.rb
  25. 25. デプロイツールを組み合わせる25Capistranoでデプロイするなら・・• config/deploy.rbを修正する• 設定項目はアプリケーション名、SCM種別、SCMリポジトリURL、ブランチ、デプロイ対象サーバーのログインユーザーやドキュメントルートなど。• roleを利用することによって複数サーバーのグループ化と一斉デプロイができるhttps://gist.github.com/imaifactory/5613219
  26. 26. デプロイツールを組み合わせる26Capistranoでデプロイするなら・・• deployの準備コマンドを実行。デプロイ対象のサーバーに必要なディレクトリ等が生成される。• デプロイ!• ロールバックも容易$ cap deploy:setup$ cap deploy$ cap deploy:rollback
  27. 27. 新しいサーバー追加したら• デプロイツールで新しいサーバーに個別にデプロイ• その上で、デプロイツールの設定に新しいサーバーを追加コードを新しくするときは• 対象サーバーに対して一斉にデプロイこの方式の問題点は?• サーバー追加時にまだ手動の手間が残る• 例えばAuto Scalingの時などは困る27デプロイツールで自動化 まとめると
  28. 28. Auto Scalingと組み合わせるには
  29. 29. 29Auto Scalingとは?負荷や時間に合わせてサーバーの台数を増減することのできる仕組みELBの配下でも利用可能。Auto scaling GroupCloudWatchAlarm Auto Scaling
  30. 30. サーバーの起動のタイミングを完全にコントロール出来ない(負荷などに合わせて自動的に立ち上がってくる)起動時のデプロイも自動化する必要がある!30Auto Scalingにすると・・
  31. 31. AMIの中にコードの最新化を自動的にやってくれる仕組みを実装する必要がある。(詳細は次のページで)Auto Scalingでデプロイ31コード コード新規サーバーをデプロイAuto ScalingではAMIからサーバーをデプロイするところまで面倒見てくれるAuto Scalingでは自分でAMIを用意する必要がある。
  32. 32. apache + mod_php + githubの環境でやるなら・・• 例えばUser Dataを利用して、起動時に以下のような処理を実行する。• capistrano ready(setup相当)なディレクトリを作成し、githubからリポジトリをクローンしてきてapacheを起動する32Auto Scalingでデプロイhttps://gist.github.com/imaifactory/5612971
  33. 33. apache + mod_php + githubの環境でやるなら・・• User Dataとは、EC2起動時にテキスト情報をインスタンスに渡す仕組み。前ページのようなシェルスクリプトを渡すと起動時にルート権限で実行してくれる。• gitをインストールしたり、httpd.confの設定を調整するなどについてはインフラ側で調整する(AMI化しておいたり、Chef等で管理) 33Auto Scalingでデプロイ
  34. 34. apache + mod_php + githubの環境でやるなら・・• User Dataで渡されたスクリプトが実行されることによって、新しく起動してくるEC2は”cap deploy:setup”まで終わった状態で、最新のコードが配置された状態でapacheが起動してきてくれる。• 前ページの画面イメージはマネジメントコンソールでの設定だが、実際にはAuto ScalingのLaunch Configurationに対してUser Dataを設定する• あとは必要に応じてcap deloyすればコードの更新が可能。• 新しく起動したEC2をどうやってcapistranoで管理するかについては次のページで。34Auto Scalingでデプロイ
  35. 35. Auto Scalingを利用すると、デプロイ対象のサーバーがダイナミックに変わっていくことになる静的なConfigファイルでは管理できないcapistrano-ec2groupやcapistrano-autoscalingなどのプラグインを使ってデプロイ対象のサーバーを動的に管理他のデプロイツールを使う際にも同様なアプローチで35Auto Scaling + Capistrano
  36. 36. 新しいサーバー追加したら• 自動的に最新のコードをデプロイコードを新しくするときは• 対象サーバーに対して一斉にデプロイデプロイがだいぶ自動化された!36起動時のデプロイも自動化すると
  37. 37. 本資料の対象はじめにデプロイとはパターン1: AWSでのベーシックなデプロイ1. AMI+SCMでデプロイ2. Auto Scalingを適用してみる3. 更にデプロイツールで自動化してみるパターン2: Elastic Beanstalkを使ったデプロイまとめ
  38. 38. Elastic Beanstalkでもデプロイ管理できます
  39. 39. InstanceAmazon RDS(OPTION)Elastic LoadBalancerInstanceAuto scaling GroupCloudWatchdeploy!AWS上のおすすめ構成を自動作成コードをデプロイするだけで、Webアプリケーションを開始Elastic Beanstalkとは?※gitが使えるのはnode.js, PHP, Python Rubyのみ
  40. 40. 新しいサーバー追加したら• 自動的に最新のコードをElastic Beanstalkがデプロイしてくれるコードを新しくするときは• これもElastic Beanstalkが自動的にデプロイしてくれる複数バージョンのコードを管理・デプロイ可能なのでロールバックも容易40Elastic Beanstalkを使うと
  41. 41. Beanstalkでは言語ごとにAMIが予め用意されている。カスタマイズも可能。http://bit.ly/YyDNeMElastic Beanstalkでデプロイ41コード新規サーバーをデプロイBeanstalkからコードが配布されるElastic Beanstalkでは言語ごとに予め決まった構成のAMIがデプロイされるBeanstalkへpushしたコードをそのままデプロイしたり、pushされたコードの中から任意のものをデプロイできる開発したコードはBeanstalkへpush
  42. 42. apache + mod_phpの環境でやるなら・・• ebというElastic BeanstalkのCLIツールを使って作業する。http://amzn.to/dSdtGP から取得可能。42Elastic Beanstalkでデプロイ#gitとebの初期化$ cd /your/app/path$ git init$ eb init #プロンプトが立ち上がっていくつかのQAで設定が進む#コミット$ git add .$ git commit -a -m ‘first commit’#Beanstalkへpush. ebの設定が済んでいればこのコマンドが使える。#これだけでコードがサーバーにデプロイされる!$ git aws.push• git aws.pushを実行すると、Beanstalkへコードがpushされた上、対象のenvironmentにコードがデプロイされる
  43. 43. ロールバックするなら・・• Elastic Beanstalkではアプリケーションのバージョンを管理してくれるので、前のバージョンをデプロイしなおせばOK43Elastic BeanstalkでデプロイApplicationEnvironment VersionWAR/ZIPURL Environment ConfigurationConfiguration TemplateEnvironmentURL Environment ConfigurationWAR/ZIPWAR/ZIPWAR/ZIPWAR/ZIPEnvironmentURL Environment Configurationコンソール上から別バージョンをデプロイ可能Elastic Beanstalkではアップロードされたコードをバージョン管理してくれる
  44. 44. 本資料の対象はじめにデプロイとはパターン1: AWSでのベーシックなデプロイ1. AMI+SCMでデプロイ2. Auto Scalingを適用してみる3. 更にデプロイツールで自動化してみるパターン2: Elastic Beanstalkを使ったデプロイまとめ
  45. 45. どの方法をとるべきか• これがベスト、というデプロイ方法は存在しない。• 自分たちの運用フローに最適なものを選択する早いうちにコストをかけてつくろう• 「規模が大きくなってきたらやろう」みたいなのもアンチパターン• 圧倒的に開発のスピードが上がるしコストも下がる開発も本番も同じ環境、同じ手順でやろう• 「開発環境はまあいいよね」もよくあるアンチパターン• 本番だけ特別な環境・手順にしておくといざというときにハマるサーバーは出来る限りステートレスに• 負荷に合わせてサーバーを増減などを想定すると、サーバーはどんどん新しいものを足したり捨てたりすることになる。この時にサーバー単体にデータを貯めこんでしまうアーキテクチャは成り立たない。• データはDBに、ログはS3に追いだそう45

×