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