Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Application Deployment on AWS

2,410 views

Published on

AWS CodeDeploy, AWS Elastic Beanstalks, AWS OpsWorks, AWS CloudFormation のご紹介およびAWS CodePipelineとの連携方法に関する解説

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Application Deployment on AWS

  1. 1. Application Deployment on AWS Amazon  Web  Services  Japan  篠原英治 2015年年12⽉月8⽇日
  2. 2. {        "Name"  :  "篠原英治",        "Twitter"  :  "@shinodogg",        "Blog"  :  "http://shinodogg.com",        "Profile"  :  {                "Role"  :  "Solutions  Architect",                "Market":  "Startup",                "Subject  Matter  Expert"  :  [                          "Amazon  CloudSearch",                        "Amazon  Elasticsearch  Service",                        "Amazon  Simple  Workflow  Service",                        "AWS  Elastic  Beanstalk"                ]        } }
  3. 3. Agenda •  AWSのデプロイメントサービス –  AWS  CodeDeploy –  AWS  Elastic  Beanstalk –  AWS  OpsWorks –  AWS  CloudFormation •  Accelerating  Software  Delivery  on  AWS –  AWS  CodePipeline
  4. 4. Deploy? •  アプリケーションやア セットの更更新をサーバ に反映させること •  実際には、更更新された ファイル群を対象の サーバ群に配布する Availability Zone Availability Zone v2
  5. 5. デプロイとビルド・プロビジョニングの違い •  ビルド –  ソースコードから配布すべ き成果物を⽣生成する •  プロビジョニング –  サーバにソフトウェアをイ ンストール&設定 •  オーケストレーション –  DBやLBとのつなぎ込み •  デプロイ –  アセットの更更新をサーバに 反映 ソース コード ビルド ex.  mvn,  bundle プロビジョニング ex.  chef,  puppet オーケスト レーション デプロイ Apache,   Nginx Ruby,  JDK Config,   etc. WEB LB DB Amazon   Linux
  6. 6. デプロイとビルド・プロビジョニングの違い •  ビルド –  ソースコードから配布すべ き成果物を⽣生成する •  プロビジョニング –  サーバにソフトウェアをイ ンストール&設定 •  オーケストレーション –  DBやLBとのつなぎ込み •  デプロイ –  アセットの更更新をサーバに 反映 ソース コード ビルド ex.  mvn,  bundle プロビジョニング ex.  chef,  puppet オーケスト レーション デプロイ Apache,   Nginx Ruby,  JDK Config,   etc. WEB LB DB Amazon   Linux
  7. 7. よくあるデプロイ⼿手法と課題 •  Push型  –  デプロイ元からデプロイ先へ –  FTP,  rsync,  git  pull –  Capistrano,  Fabric •  課題 –  ⾃自動化できていない •  ⼈人間がサーバにログインしてコマンドを⼿手動で実⾏行行している –  デプロイサーバの負荷、シングルポイント –  新規サーバ構築時にデプロイ対象がわからない –  複数⼈人でデプロイがぶつからない様に管理理するのが⾯面倒
  8. 8. デプロイの効率率率化・安定化 •  質の⾼高いリリースのためには、必要不不可⽋欠 •  効率率率的で安定している仕組みがあるなら、それ を使わない⼿手はない AWS  CodeDeployが選択肢
  9. 9. AWS  CodeDeploy •  1台も数千台も同じやり⽅方で •  開発環境もステージング環境もプロダクションも同じやり⽅方で •  ダウンタイム無くデプロイ •  中央でデプロイをコントロール・モニタリング Staging AWS  CodeDeployv1,  v2,  v3 Production Dev ⾃自動デプロイのコーディネートを、Amazonの様に Application revisions Deployment  groups
  10. 10. AWS  CodeDeploy概要 •  デプロイに特化したサービス –  指定したグループに、指定したファイ ルを、指定した割合ずつ –  TagやAuto  Scaling  Groupでグループ 指定 •  エージェントを⼊入れれば利利⽤用可能 –  Pull型のデプロイ、EC2以外でも –  Linux  &  Windows対応 •  関連する処理理をフックで実⾏行行可能 –  アプリ再起動なども⾃自動化できる Staging Production Dev Deployment  groups Agent Agent Agent Agent Agent Agent Agent AWS  CodeDeployv1,  v2,  v3
  11. 11. AWS  CodeDeployの動作 1.  配布物をアップロード –  Amazon  S3  /  GitHub 2.  デプロイを指⽰示 –  配布物ダウンロード –  files:  所定の場所に配置 –  hooks:  任意の処理理実⾏行行 Deployment   group Agent Agent Agent … or Amazon   S3 Application 1.  Upload files hooks /dst 2.  Deploy Downloa d Polling
  12. 12. Deployment  config  –  デプロイのスピード v2 v1 v1 v1 v1 v1 v1 v1 v2 v2 v2 v2 v1 v1 v1 v1 v2 v2 v2 v2 v2 v2 v2 v2 OneAtATime  (1台ずつ) HalfAtATime  (半分ずつ) AllAtOnce  (全て⼀一度度に) ※任意の割合のconfigも作成可能
  13. 13. AppSpec  File  –  デプロイの⼿手順書 •  files –  どのファイルをどこに 配置するか指定 •  hooks –  以下の⻩黄⾊色のEventで 実⾏行行する処理理を指定 version: 0.0 os: linux files: - source: config destination: /etc/app - source: target/hello.war destination: /var/lib/tomcat6/webapps hooks: ApplicationStop: - location: deploy_hooks/stop-tomcat.sh ApplicationStart: - location: deploy_hooks/start-tomcat.sh
  14. 14. Application  –  成果物  +  AppSpec  File   •  フォルダ構成 –  appspec.yml  (必須) –  ビルド済の成果物 –  その他配布物 –  hookスクリプト •  アップロード –  Amazon  S3のObject •  zip/tar/tgz形式対応 –  GitHubのRepository •  zip形式でダウンロードされる / !"" appspec.yml !"" config/ #   %"" config.xml !"" deploy_hooks/ #   !"" start-tomcat.sh #   %"" stop-tomcat.sh %"" target/ %"" hello.war or Amazon  S3 注:  ソースコードではなくmavenやbundle後の ファイル群をput/pushすることをオススメ
  15. 15. AWS  CodeDeployでやること、やらないこと やること •  ファイルをサーバに配る •  hookスクリプトの実⾏行行 –  アプリ再起動 –  オーケストレーション •  ELB付け外し等 •  これらの実⾏行行を中央管理理 –  進捗やエラーログが、ブラ ウザやAPIで確認可能 やらないこと •  ビルド •  プロビジョニング ※  いずれもhookスクリプ トで実⾏行行できなくはないが、 効率率率や安定性の⾯面で オススメしない
  16. 16. AWS  CodeDeployとAuto  Scaling  Group(ASG)   •  スケールアウト時に最新のリビ ジョンが⾃自動でデプロイされる –  ASGのLifecycle  Hookを利利⽤用 –  追加インスタンスのみにデプロイ •  Deployment  GroupにASGを指定 するだけで利利⽤用可能 デプロイに成功した最新の リビジョンが⾃自動でデプロイ
  17. 17. AWS  ElasticBeanstalk •  特徴  (http://aws.amazon.com/jp/elasticbeanstalk/) –  速く簡単にアプリケーションをデプロイ可能 –  インフラストラクチャの準備&運営からアプリ ケーションスタックの管理理まで⾃自動化 –  Auto  Scaling  によりコストを抑えながらスケー ラビリティを確保 –  Java,  PHP,  Ruby,  Python,  Node.js,  .NET,   Docker  などに対応 •  価格体系  (http://aws.amazon.com/jp/elasticbeanstalk/pricing/) –  追加料料⾦金金なし –  アプリケーションの保存、実⾏行行に必要なAWSリ ソース  (EC2,  S3,  RDS,  DynamoDB  など)  に対 してのみ課⾦金金 インフラ構成の構築・アプリデプロイの⾃自動化サービス
  18. 18. Elastic  Beanstalk  vs.  Do  It  Yourself On-‐‑‒instance  configuration Your  code HTTP  Server Application  Server Language  Interpreter Operating  System Host
  19. 19. On-‐‑‒instance  configuration Your  code HTTP  Server Application  Server Language  Interpreter Operating  System Host アプリケーションの開発 ”だけ”にフォーカス Elastic  Beanstalkにお任せ! Elastic  Beanstalk  vs.  Do  It  Yourself
  20. 20. •  あらかじめ定義されたインフラストラクチャ •  Single  instance  (開発環境,  ローコスト) •  Load  balancing,  Auto  Scaling  (本番環境) •  Web  Tier  と  Worker  Tier •  リソースのプロビジョニング •  Load  Balancer •  Auto  Scaling  group •  Security  groups •  Database  (optional) •  ユニークなドメイン名の提供 •  例例)  yourapp.elasticbeanstalk.com Infrastructure  stack Elastic  Beanstalk  vs.  Do  It  Yourself
  21. 21. •  アプリケーションを簡単にデプロイ •  複数バージョンの切切り替え •  複数環境の切切り替え Easy  Deployment Elastic  Beanstalk  vs.  Do  It  Yourself
  22. 22. Elastic  Beanstalkでアプリケーションを デプロイするのに必要なこと 1 2 3 4 Region Stack  (container)  type Single-‐‑‒Instance Load  Balanced   w/  Autoscaling or Database  (RDS) optional Your  code Supported  Platforms
  23. 23. 1 2 3 4 Region Stack  (container)  type Single-‐‑‒Instance Load  Balanced   w/  Autoscaling or Database  (RDS) optional Your  code ■  デプロイを⾏行行う⽅方法 1. AWS  Management  Console  を使う 2. AWS  Toolkit  for  Eclipse/Visual  Studio  IDEを使う 3. EB  Command  Line  Interface(EB  CLI)  を使う $  eb  deploy Elastic  Beanstalkでのデプロイ
  24. 24. Elastic  Beanstalkでのデプロイ 1 2 3 4 Region Stack  (container)  type Single-‐‑‒Instance Load  Balanced   w/  Autoscaling or Database  (RDS) optional Your  code ■  デプロイを⾏行行う⽅方法 1. AWS  Management  Console  を使う 2. AWS  Toolkit  for  Eclipse/Visual  Studio  IDEを使う 3. EB  Command  Line  Interface(EB  CLI)  を使う $  eb  deploy 今回は上記3.のEB  CLIを使ったデプロイ⽅方法をご紹介します
  25. 25. サンプルアプリケーション •  Node.js  +  Expressな会員登録アプリケーション –  ソースコードは↓から⼊入⼿手可能 –  https://github.com/awslabs/eb-‐‑‒node-‐‑‒express-‐‑‒sample  
  26. 26. サンプルアプリケーションのデプロイ 1.  EB  CLIのインストール: $  pip  install  -‐‑‒-‐‑‒upgrade  awsebcli 2.  サンプルアプリケーションのダウンロード: $  git  clone  https://github.com/awslabs/eb-‐‑‒node-‐‑‒express-‐‑‒ sample.git 3.  Elastic  Beanstalk  applicationの作成: $  eb  init 4.  プロンプトに従って環境の設定 5.  リソースの作成およびアプリケーションのローンチ: $  eb  create
  27. 27. サンプルアプリケーションのデプロイ •  eb  initのプロンプト:  リージョンの選択 Select  a  default  region 1)  us-‐‑‒east-‐‑‒1  :  US  East  (N.  Virginia) 2)  us-‐‑‒west-‐‑‒1  :  US  West  (N.  California) 3)  us-‐‑‒west-‐‑‒2  :  US  West  (Oregon) 4)  eu-‐‑‒west-‐‑‒1  :  EU  (Ireland) 5)  eu-‐‑‒central-‐‑‒1  :  EU  (Frankfurt) 6)  ap-‐‑‒southeast-‐‑‒1  :  Asia  Pacific  (Singapore) 7)  ap-‐‑‒southeast-‐‑‒2  :  Asia  Pacific  (Sydney) 8)  ap-‐‑‒northeast-‐‑‒1  :  Asia  Pacific  (Tokyo) 9)  sa-‐‑‒east-‐‑‒1  :  South  America  (Sao  Paulo) 10)  cn-‐‑‒north-‐‑‒1  :  China  (Beijing) (default  is  3):
  28. 28. サンプルアプリケーションのデプロイ •  eb  initのプロンプト:  アプリ名/スタック/SSH/Keypair Enter  Application  Name (default  is  "eb-‐‑‒node-‐‑‒express-‐‑‒sample"):   It  appears  you  are  using  Node.js.  Is  this  correct? (y/n):  y Do  you  want  to  set  up  SSH  for  your  instances? (y/n):  y Select  a  keypair. 1)  oregon 2)  [  Create  new  KeyPair  ] (default  is  2):  1
  29. 29. サンプルアプリケーションのデプロイ •  eb  initのプロンプト:  スタック Select  a  platform. 1)  Node.js 2)  PHP 3)  Python 4)  Ruby 5)  Tomcat 6)  IIS 7)  Docker 8)  Multi-‐‑‒container  Docker 9)  GlassFish 10)  Go 11)  Java
  30. 30. サンプルアプリケーションのデプロイ •  eb  createのプロンプト:  Environment/CNAME/Deploy Enter  Environment  Name (default  is  eb-‐‑‒node-‐‑‒express-‐‑‒sample):   Enter  DNS  CNAME  prefix (default  is  eb-‐‑‒node-‐‑‒express-‐‑‒sample):   Creating  application  version  archive  "5529". Uploading  eb-‐‑‒node-‐‑‒express-‐‑‒sample/5529.zip  to  S3.  This   may  take  a  while. Upload  Complete. Environment  details  for:  eb-‐‑‒node-‐‑‒express-‐‑‒sample    Application  name:  eb-‐‑‒node-‐‑‒express-‐‑‒sample    Region:  us-‐‑‒west-‐‑‒2    Deployed  Version:  5529    Environment  ID:  e-‐‑‒ufxx79fmkc
  31. 31. サンプルアプリケーションのデプロイ •  EB  CLIを使ってブラウザで表⽰示 $  eb  open
  32. 32. サンプルアプリケーションのデプロイ •  UIを変更更 $  vim  views/index.ejs $  git  commit  –am  “modify  UI” $  eb  deploy $  eb  open
  33. 33. サンプルアプリケーションのデプロイ •  サンプルアプリケーションを動かす
  34. 34. .ebextensions  を活⽤用した環境のカスタマイズ –  Elastic  Beanstalkの定義されたテンプレートのカスタマイズ –  例例えば、”サーバー監視のサービスをインストールしたい” 本番運⽤用の際はバージョンを明記しま しょう http://www.slideshare.net/shotaumeda1/aws-‐‑‒startuptechsummer2015/15   Retty  梅⽥田さんのスライド .ebextensionsでMackerelの ⾃自動インストールを実現
  35. 35. デプロイしたサンプルアプリケーションの詳細 •  resources.config  –  追加のリソース定義 本番運⽤用の際はバージョンを明記しま しょう Resources:  StartupSignupsTable:        Type:  AWS::DynamoDB::Table        Properties:            KeySchema:                HashKeyElement:  {AttributeName:  email,  AttributeType:  S}            ProvisionedThroughput:  {ReadCapacityUnits:  1,  WriteCapacityUnits:  1}    NewSignupQueue:          Type:  AWS::SQS::Queue      NewSignupTopic:        Type:  AWS::SNS::Topic        Properties:            Subscription:            -‐‑‒  Endpoint:                    Fn::GetOptionSetting:  {DefaultValue:  xxx@xxx.com,  OptionName:  NewSignupEmail}                Protocol:  email            -‐‑‒  Endpoint:                    Fn::GetAtt:  [NewSignupQueue,  Arn]                Protocol:  sqs
  36. 36. .ebextensions •  .ebextensions  を活⽤用してElastic  Beanstalkに集約 –  option_̲settings  セクション •  環境内のAWSリソース、アプリケーションを実⾏行行するソフトウエアの 設定 –  resources  セクション •  CloudFormationがサポートするあらゆるリソースの追加および設定 –  環境を起動する際に使うCloudFormationテンプレートに追加 –  その他のセクション •  packages、sources、files、users、groups、commands、 container_̲commands、services •  起動されるEC2インスタンスの設定 •  セクション毎にファイルを分割するのを推奨 ※  設定ファイルはアルファベット順に処理理される
  37. 37. •  packages –  yum/rpm/rubygems等を利利⽤用したパッケージのインストール –  例例)  yumから最新、rpmでURL指定、rubygemsでchef  0.10.2 .ebextensions packages:      yum:        libmemcached:  []          ruby-‐‑‒devel:  []        gcc:  []    rpm:        epel:  http://download.fedoraproject.org/pub/epel/5/i386/ epel-‐‑‒release-‐‑‒5-‐‑‒4.noarch.rpm    rubygems:          chef:  '0.10.2'
  38. 38. •  sources –  外部からのアーカイブをダウンロードして指定した場所に展開 •  tar、tar+gzip、tar+bz2、zip  をサポート –  例例)  S3にあるアーカイブファイルを指定したディレクトリに展開 .ebextensions sources:        /etc/myapp:  http://s3.amazonaws.com/mybucket/my.tgz
  39. 39. •  files –  EC2上にファイルを作成。外部からファイルを取得することも可能 –  例例)  ファイルをコピーしてrootだけ書き込める権限で配置 –  例例)  シンボリックリンク  myfile1.txt  を参照する  myfile2.txt .ebextensions files:    "/home/ec2-‐‑‒user/myfile"  :        mode:  "000755"        owner:  root        group:  root        source:  http://foo.bar/myfile files:    "/tmp/myfile2.txt"  :        mode:  "120400"        content:  "/tmp/myfile1.txt"
  40. 40. •  groups –  グループを作成 –  例例)  groupOneはグループIDなし、groupTwoのグループIDは45 .ebextensions groups:    groupOne:    groupTwo:        gid:  "45"
  41. 41. •  users –  ユーザーを作成 –  例例)  ユーザーID、グループ名、ホームディレクトリの設定 .ebextensions users:    myuser:        groups:            -‐‑‒  group1            -‐‑‒  group2        uid:  "50"        homeDir:  "/home/myuser"
  42. 42. •  commands –  サーバー設定後、バージョンファイルが抽出される前に実⾏行行されるコマンド –  例例)  pythonスクリプトを実⾏行行 .ebextensions commands:    python_̲install:          command:  myscript.py        cwd:  /home/ec2-‐‑‒user        env:              myvarname:  myvarvalue        test:  '[  !  /usr/bin/python  ]  &&  echo  "python  not  installed"'
  43. 43. •  container_̲commands –  サーバー設定後、バージョンファイルが抽出された後に実⾏行行されるコマンド •  AWSセキュリティ認証情報などの環境変数にもアクセス可能 •  leader_̲only(option):  AutoScalingグループのリーダーにするインスタンスのみ –  例例)  Djangoの管理理タスクを実⾏行行 .ebextensions container_̲commands:    01collectstatic:        command:  "django-‐‑‒admin.py  collectstatic  -‐‑‒-‐‑‒noinput”    02syncdb:        command:  "django-‐‑‒admin.py  syncdb  -‐‑‒-‐‑‒noinput"        leader_̲only:  true    03migrate:        command:  "django-‐‑‒admin.py  migrate"        leader_̲only:  true
  44. 44. •  services –  インスタンス起動時に開始/停⽌止する必要のあるサービスを定義 –  例例)  起動時にサービスサービスが⾃自動的に開始される .ebextensions services:      sysvinit:        myservice:            enabled:  true
  45. 45. Elastic  Beanstalkにおけるデプロイの選択肢 •  Rolling  Deploy 現 現 現 現
  46. 46. •  Rolling  Deploy 現 現 現 現 Elastic  Beanstalkにおけるデプロイの選択肢
  47. 47. •  Rolling  Deploy 新 現 現 現 Elastic  Beanstalkにおけるデプロイの選択肢
  48. 48. Elastic  Beanstalkにおけるデプロイの選択肢 •  Rolling  Deploy 新 現 現 現
  49. 49. Elastic  Beanstalkにおけるデプロイの選択肢 •  Rolling  Deploy 新 現 現 現
  50. 50. Elastic  Beanstalkにおけるデプロイの選択肢 •  Rolling  Deploy 新 新 現 現
  51. 51. Elastic  Beanstalkにおけるデプロイの選択肢 •  Rolling  Deploy 新 新 現 現
  52. 52. Elastic  Beanstalkにおけるデプロイの選択肢 •  Rolling  Deploy 新 新 現 現
  53. 53. Elastic  Beanstalkにおけるデプロイの選択肢 •  Rolling  Deploy 新 新 新 現
  54. 54. Elastic  Beanstalkにおけるデプロイの選択肢 •  Rolling  Deploy –  Batch  type:  Auto  Scaling  グループ内のインスタンスの割合もしくは⼀一定数 –  Batch  size:  割合(%)もしくはインスタンス数(AutoScaling設定の最⼤大数まで) –  2台ずつデプロイする場合の設定は  Batch  type:  Fixed,  Batch  size:  2 –  例例)  30%ずつRolling  Deploy
  55. 55. Elastic  Beanstalkにおけるインスタンス置換え •  Rolling  Updates –  アプリケーションデプロイではなくインスタンスの置換え •  内部的にはCloudFromationのUpdate  Policyを利利⽤用 –  VPC設定やAuto  ScalingのLaunch  Configurationの設定変更更 ⼀一度度に⼊入れ替えるインスタンスの最⼤大数 最低限維持すべきインスタンス数 各Update操作間のPause時間
  56. 56. Elastic  Beanstalkにおけるデプロイの選択肢 •  Blue/Green  Deploy 現 現 現 現
  57. 57. Elastic  Beanstalkにおけるデプロイの選択肢 •  Blue/Green  Deploy 現 現 現 現 新 新 新 新
  58. 58. Elastic  Beanstalkにおけるデプロイの選択肢 •  Blue/Green  Deploy 現 現 現 現 新 新 新 新
  59. 59. Elastic  Beanstalkにおけるデプロイの選択肢 •  Blue/Green  Deploy 新 新 新 新
  60. 60. v1.1 v1.1 v1.1 v1.1 v1.1 v1.1 v1.1 v1.1 v1.2 v1.2 v1.2.1 v1.2.1 v1.2.2 v1.2.2 DNS (Amazon  route  53) Webサーバー群 (Amazon  EC2) データベースサーバ群 (Amazon  RDS) ロードバランサー 90% 5% 3% 2% Elastic  Beanstalkにおけるデプロイの選択肢
  61. 61. Elastic  Beanstalkにおけるデプロイの選択肢 •  Rolling  Deploy?  Blue/Green  Deploy? –  Rolling  Deploy •  新しくサーバーを⽴立立てるわけではないのでデプロイにかかる時 間が短い •  新しいバージョンにバグ等があった場合にRollbackに⼿手間がか かる –  Blue/Green •  新しくサーバーを⽴立立てるので環境作成に時間がかかる •  Rollbackが容易易 •  Elastic  BeanstalkのDNSのTTLはデフォルト60秒であるが、 接続元のデバイスによってDNSがキャッシュされてしまうよう な場合デプロイが反映されない場合がある
  62. 62. Elastic  Beanstalkにおけるモニタリング •  EB  CLIでモニタリング $  eb  health  -‐‑‒-‐‑‒refresh
  63. 63. Elastic  Beanstalkにおけるモニタリング •  マネージメントコンソール上でモニタリング
  64. 64. Elastic  Beanstalkにおけるモニタリング •  マネージメントコンソール上でモニタリング カスタマイズ可能!
  65. 65. Elastic  Beanstalkにおけるモニタリング •  マネージメントコンソールでの拡張ヘルスレポート
  66. 66. Elastic  Beanstalkにおけるモニタリング •  マネージメントコンソールでの拡張ヘルスレポート –  メトリクス •  EnvironmentHealth –  OK –  Warning –  Degraded –  Severe –  Info –  Pending –  Unknown http://docs.aws.amazon.com/ja_̲jp/elasticbeanstalk/latest/dg/health-‐‑‒enhanced-‐‑‒cloudwatch.html#health-‐‑‒ enhanced-‐‑‒cloudwatch-‐‑‒metrics  
  67. 67. Elastic  Beanstalkにおけるモニタリング •  マネージメントコンソールでの拡張ヘルスレポート –  メトリクス:  該当のインスタンスの数を表⽰示 •  InstancesSevere •  InstancesDegraded •  InstancesWarning •  InstancesInfo •  InstancesOk •  InstancesPending •  InstancesUnknown •  InstancesNoData http://docs.aws.amazon.com/ja_̲jp/elasticbeanstalk/latest/dg/health-‐‑‒enhanced-‐‑‒cloudwatch.html#health-‐‑‒ enhanced-‐‑‒cloudwatch-‐‑‒metrics  
  68. 68. Elastic  Beanstalkにおけるモニタリング •  マネージメントコンソールでの拡張ヘルスレポート –  メトリクス:  リクエスト総数および各レスポンスコード毎の数 •  ApplicationRequestsTotal •  ApplicationRequests5xx •  ApplicationRequests4xx •  ApplicationRequests3xx •  ApplicationRequests2xx http://docs.aws.amazon.com/ja_̲jp/elasticbeanstalk/latest/dg/health-‐‑‒enhanced-‐‑‒cloudwatch.html#health-‐‑‒ enhanced-‐‑‒cloudwatch-‐‑‒metrics  
  69. 69. Elastic  Beanstalkにおけるモニタリング •  マネージメントコンソールでの拡張ヘルスレポート –  メトリクス:  xパーセントの完了了にかかった平均時間 •  ApplicationLatencyP10 •  ApplicationLatencyP50 •  ApplicationLatencyP75 •  ApplicationLatencyP85 •  ApplicationLatencyP90 •  ApplicationLatencyP95 •  ApplicationLatencyP99 •  ApplicationLatencyP99.9 http://docs.aws.amazon.com/ja_̲jp/elasticbeanstalk/latest/dg/health-‐‑‒enhanced-‐‑‒cloudwatch.html#health-‐‑‒ enhanced-‐‑‒cloudwatch-‐‑‒metrics  
  70. 70. Elastic  Beanstalkにおけるモニタリング •  マネージメントコンソールでの拡張ヘルスレポート –  メトリクス •  LoadAverage1min:  1分間のLoad値の平均値 •  InstanceHealth:  現在のインスタンスのヘルスステータス •  RootFilesystemUtil:  使⽤用ディスク容量量の割合 http://docs.aws.amazon.com/ja_̲jp/elasticbeanstalk/latest/dg/health-‐‑‒enhanced-‐‑‒cloudwatch.html#health-‐‑‒ enhanced-‐‑‒cloudwatch-‐‑‒metrics  
  71. 71. Elastic  Beanstalkにおけるモニタリング •  マネージメントコンソールでの拡張ヘルスレポート –  メトリクス:  過去1分間のCPU使⽤用状況 •  CPUIrq •  CPUUser •  CPUIdle •  CPUSystem •  CPUSoftirq •  CPUIowait •  CPUNice http://docs.aws.amazon.com/ja_̲jp/elasticbeanstalk/latest/dg/health-‐‑‒enhanced-‐‑‒cloudwatch.html#health-‐‑‒ enhanced-‐‑‒cloudwatch-‐‑‒metrics  
  72. 72. 時間指定のスケーリング •  Time-‐‑‒based  Scaling –  時間設定でスケールアウト/インを制御 本番運⽤用の際はバージョンを明記しま しょう
  73. 73. Environment間リンク機能 •  SQSのキューを介して疎結合なアーキテクチャを実現 –  Environment  Manifest  (env.yaml) 本番運⽤用の際はバージョンを明記しま しょう AWSConfigurationTemplateVersion:  1.1.0.0 EnvironmentLinks:    "WORKERQUEUE":  "worker"
  74. 74. AWS  OpsWorks •  特徴  (http://aws.amazon.com/jp/opsworks/) –  Chefのレシピを使って、デプロイや運⽤用タス クを⾃自動化可能 –  ライフサイクルイベントにより動的な構成変 更更への対応が可能 –  継続的な構成管理理 •  価格体系  (http://aws.amazon.com/jp/elasticloadbalancing/pricing/) –  AWS  OpsWorks⾃自体の利利⽤用は無料料 –  (OpsWorksエージェントをオンプレミス サーバで利利⽤用する場合はその起動時間) アプリケーションのデプロイ・管理理サービス AWS OpsWorks スタック LBレイヤー Webレイヤー DBレイヤー EC2インスタンス上の OpsWorksエージェント
  75. 75. AWS  OpsWorks §  アプリケーションのライフサイクル管理理サービス §  デプロイを頻繁に、早く、セキュアに実⾏行行可能 §  スケーラブルで複雑なインフラストラクチャの構成を管理理、モデル化、 ⾃自動化することが可能 §  ビルトイン構成を使って簡単に開始可能 §  追加コストは不不要
  76. 76. OpsWorksインスタンスの構築例例 インスタンス起動 ソフトウェアインストール・構 成⽤用のChefレシピを実⾏行行 アプリケーションのデプロイ⽤用 のChefレシピを実⾏行行 OpsWorksのAPIで ⾃自動化が可能
  77. 77. なぜ、OpsWorksでインスタンス内部のChefレシピをリ モートからOpsWorks  APIで実⾏行行可能か? OpsWorksインスタンス内で、 OpsWorksエージェントがインストール・動作 しているため
  78. 78. OpsWorksの基本的な仕組み(1) EC2インスタンス上の OpsWorksエージェント OpsWorks talks  with OpsWorks  エージェントから OpsWorks  エンドポイントに対して Polling(アウトバウンド通信)
  79. 79. OpsWorksの基本的な仕組み(2) OpsWorksによって発⾏行行された⼀一連の コマンドを取得 AgentがChef  Clientのローカルモード でレシピを実⾏行行 EC2インスタンス上の OpsWorks  Agent インスタンスにSSH  /  RDPログインも可能 Chef  Server  /  Chef  Clientの構築は不不要 お客様はChefのレシピの作成に集中可能
  80. 80. OpsWorks利利⽤用の流流れ User AWS  Management   Console
  81. 81.      Stack OpsWorks利利⽤用の流流れ User AWS  Management   Console 構成情報 (JSON) ①スタックの作成
  82. 82.      Stack OpsWorks利利⽤用の流流れ User AWS  Management   Console Load  Balancerレイヤー App  Serverレイヤー Databaseレイヤー 構成情報 (JSON) ①スタックの作成 ②レイヤーの作成
  83. 83.      Stack OpsWorks利利⽤用の流流れ User AWS  Management   Console Load  Balancerレイヤー App  Serverレイヤー Databaseレイヤー レシピ レシピ レシピ 構成情報 (JSON) ①スタックの作成 ②レイヤーの作成 ③レシピの設定(Appの設定)
  84. 84.      Stack OpsWorks利利⽤用の流流れ User AWS  Management   Console Load  Balancerレイヤー App  Serverレイヤー Databaseレイヤー レシピ レシピ レシピ 構成情報 (JSON) ①スタックの作成 ②レイヤーの作成 ③レシピの設定(Appの設定) ④レイヤーに   インスタンス追加・起動
  85. 85.      Stack OpsWorks利利⽤用の流流れ User AWS  Management   Console Load  Balancerレイヤー App  Serverレイヤー Databaseレイヤー レシピ レシピ レシピ DB Web /App LB ①スタックの作成 ②レイヤーの作成 ③レシピの設定(Appの設定) ④レイヤーに   インスタンス追加・起動 ⑤ライフサイクルイベントによ り、レシピが⾃自動実⾏行行される 構成情報 (JSON) Web /App
  86. 86. スタックとは •  OpsWorksのトップエンティティ •  属する全インスタンスの構成を管理理 –  OSの種類、リージョン、インスタンスのIPアドレスなど •  カスタムレシピを保存する任意のリポジトリを指定可能 •  VPC内部に作成可能 •  スタックごとに構成情報をJSON形式で保持 –  構成変更更のたびにJSONが更更新される –  ChefレシピからJSON内の変数を読み込み可能 •  スタックをコピー可能 –  リージョン間でも可能
  87. 87. レイヤーとは •  インスタンス構築のための⻘青写真(設計図) レシピを指定して、パッケージインストール などの必要な処理理を定義 カスタムレシピも定義可能 追加のEBSボリュームの指 定。RAID指定も可能
  88. 88. ビルトインレイヤーの種類 •  Load  Balancer –  HAProxy (ELBは各レイヤーに個別に アタッチ可能) •  App  Server –  Static  Web  Server –  Rails  App  Server –  PHP  App  Server –  Node.js  App  Server –  Java  App  Server –  AWS  Flow  (Ruby) •  DB –  MySQL –  RDS •  ECS(EC2  Container   Service)  Cluster •  Other –  Memcached –  Ganglia –  Custom ビルトインレイヤー以外にもカスタムレイヤーを使って任意の 役割を持つレイヤーを作成可能(Jenkinsレイヤーなど) NEW
  89. 89. インスタンスとは •  アプリケーションを提供するための EC2インスタンスのこと •  起動時にインスタンスサイズや AZ(VPC内の場合はサブネット) を指定 •  インスタンス内部にOpsWorks   Agentが動作している
  90. 90. インスタンスのスケーリングタイプ •  インスタンスを(⾃自動)追加起動・終了了する⽅方 法として以下の3パターンがある –  24/7  インスタンス •  常時稼働 –  負荷ベースのインスタンス –  時間ベースのインスタンス
  91. 91. Appとは •  アプリケーションサーバーにデプロイする アプリケーションのこと •  利利⽤用可能なアプリケーションの種類(標準 のアプリケーションサーバーレイヤーに相 当する) –  Ruby  on  Rails  /  PHP  /  Node.js(JavaScript)  /   Static(HTML)  /  Java  /  AWS  Flow(Ruby)  /  Other •  サポートするリポジトリ –  Git  /  Subversion  /  HTTP  archive  /  S3  Archive  /  Other –  GithubやBitBucketも使⽤用可能
  92. 92. スタックコマンドを使ってリモートから任意のタイミング でインスタンスにコマンドを実⾏行行可能 スタックコマンド 内容 Install  Dependencies 全てのパッケージをインストールする Update  Dependencies 全てのパッケージをアップデートする Update  Custom   Cookbooks リポジトリにある更更新されたCookbookをそれぞれのインスタンスに展開する Execute  Recipes 指定したレシピを指定したインスタンス上で実⾏行行する Setup Setupのレシピを実⾏行行する。(Setupを実⾏行行するとDeployもその後で実⾏行行さ れる) Configure Configureのレシピを実⾏行行する。 AWS  Management   Console 管理理者 AWS  OpsWorks Instances Execute  Recipes コマンド等を実⾏行行 OpsWorksエージェ ントがChefレシピを 実⾏行行
  93. 93. OpsWorksの  5  つのライフサイクルイベント Setup Configure Deploy Undeploy Shutdown
  94. 94. OpsWorks   Auroraの接続先をClusterエンドポイントへ
  95. 95. AWS  CloudFormation •  EC2やELBといったAWSリソースの環境構築を、設定ファイル(テン プレート)を元に⾃自動化できるサービス •  テンプレートを⾃自由に作成できるため、⾃自分好みのシステム構成を⾃自 動的に構築できる •  テンプレートには起動すべきリソースの情報をJSONフォーマットのテ キスト形式で記述する テンプレートベースの プロビジョニング インフラを コード化 宣⾔言・柔軟性 簡単に利利⽤用可能
  96. 96. スタック S3 CloudWatch Elastic  Load  Balancing EC2 EC2 Auto  Scaling SNS テンプレート Cloud Formation テンプレートに基づき 各リソースが起動 AWS  CloudFormationのイメージ
  97. 97. AWS  CloudFormationがサポートする主なサービス Ø  Amazon  EC2 Ø  Amazon  EC2  Container  Service Ø  AWS  Lambda  (including  event  sources  –  New) Ø  Auto  Scaling  (including  Spot  Fleet  -‐‑‒  New) Ø  Amazon  VPC Ø  Elastic  Load  Balancing Ø  Amazon  Route  53 Ø  Amazon  CloudFront Ø  Amazon  RDS Ø  Amazon  Redshift Ø  Amazon  DynamoDB Ø  Amazon  ElastiCache Ø  Amazon  RDS  for  Aurora  (New) Ø  Amazon  S3 Ø  AWS  IAM  (including  managed  policies) Ø  Simple  AD  (New) Ø  Amazon  Kinesis Ø  Amazon  SNS Ø  Amazon  SQS Ø  AWS  CloudFormation Ø  AWS  CloudTrail Ø  Amazon  CloudWatch Ø  AWS  Data  Pipeline Ø  AWS  Elastic  Beanstalk Ø  AWS OpsWorks Ø  AWS CodeDeploy (New) Ø  Amazon WorkSpaces (New) http://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/aws-template-resource-type-ref.html
  98. 98. AWS  CloudFormation テンプレートの例例① {    "AWSTemplateFormatVersion"  :  "2010-‐‑‒09-‐‑‒09",        "Resources"  :  {                "HelloBucket"  :  {                        "Type"  :  "AWS::S3::Bucket"                }        } } HelloBucketというAmazon  S3バ ケットを作るテンプレート
  99. 99. AWS  CloudFormation テンプレートの例例② {    "AWSTemplateFormatVersion"  :  "2010-‐‑‒09-‐‑‒09",        "Resources"  :  {                "HelloBucket"  :  {                        "Type"  :  "AWS::S3::Bucket",                        "Properties"  :  {                              "AccessControl"  :  "PublicRead"                          }                }        } } HelloBucketというAmazon  S3バ ケットを作るテンプレート     ↓ AccessControlに「PublicRead」 を指定。
  100. 100. AWS  CloudFormation テンプレートの例例③ {    "AWSTemplateFormatVersion"  :  "2010-‐‑‒09-‐‑‒09",        "Resources"  :  {                "HelloBucket"  :  {                        "Type"  :  "AWS::S3::Bucket",                        "Properties"  :  {                              "AccessControl"  :  "PublicRead",                              "WebsiteConfiguration"  :  {                                        "IndexDocument"  :  "index.html",                                        "ErrorDocument"  :  "error.html"                                                  }                                                      }                }        } } HelloBucketというAmazon  S3バ ケットを作るテンプレート     ↓ AccessControlに「PublicRead」 を指定。     ↓ Webサイトとして公開するために、 index.htmlと、ErrorDocumentの 設定を⾏行行う。
  101. 101. では、どういう時に何を使えば良良いの?? •  Accelerating  Software  Delivery  on  AWS
  102. 102. では、どういう時に何を使えば良良いの?? •  Accelerating  Software  Delivery  on  AWS
  103. 103. では、どういう時に何を使えば良良いの?? •  Accelerating  Software  Delivery  on  AWS "Lean  Startupメソッドにおいて鍵となるのは、適切切な機能を持った適切切なプロ ダクトを、build-‐‑‒measure-‐‑‒learnフィードバックループと共にイテレーティブ なプロセスで開発し続けることで、このプロセスの中⼼心はminimum  viable   product(MVP)である" "限られた機能しかもたいなプロダクトでも、それをShipすることで、アーリーア ダプターの元に届き、少なくとも何⼈人かのユーザーからは共鳴を受け、ユーザー はお⾦金金を払い、ユーザーからのフィードバックを受け取れるようになる" ⾃自動化+素早いデリバリ!
  104. 104. では、どういう時に何を使えば良良いの?? •  パイプラインの⾃自動化
  105. 105. では、どういう時に何を使えば良良いの?? •  パイプラインの⾃自動化 –  Githubにコミットされたらパイプラインをキック –  Jenkinsを使ってビルド –  Staging環境にデプロイしてUAT、Stressテスト –  Production環境へRolling  Deploy
  106. 106. AWS  CodePipeline
  107. 107. 開発のスタイルにあったワークフローを⾃自由に 例例えば ソースコード ビルド ユニット テスト ステージ デプロイ 本番 デプロイ A機能画⾯面 テスト CodePipeline ステージ デプロイ B機能画⾯面 テスト
  108. 108. 開発のスタイルにあったワークフローを⾃自由に
  109. 109. AWS  CodePipeline  パートナー連携
  110. 110. Custom  Action 開発者が コミット CodePipeline S3 カスタムアクションリソース カスタムジョブワーカー カスタムビルドアクション 1.  エージェントでポーリング 2.  ジョブの詳細 4.  ビルドの実⾏行行 3.  ジョブのAck 5.  ジョブの成功
  111. 111. AWS  CodePipeline •  Source  -‐‑‒>  Build  -‐‑‒>  Load  Testing
  112. 112. AWS  CodePipeline •  Load  Testing  w/  Apica
  113. 113. AWS  CodePipelineとの連携 •  Elastic  Beanstalk –  ビルトインサポート –  プロビジョニングも含めてお任せ •  CodeDeploy –  ビルトインサポート –  プロビジョニングは⾃自分で •  OpsWorks –  EBのスタックに合わない場合など –  ビルトインサポート無いのでcustom  action

×