プロビジョニング&デプロイ on AWSのキホン #jawsdays – JAWS DAYS 2014 参加レポート Vol.12

プロビジョニング&デプロイ on AWSのキホン #jawsdays – JAWS DAYS 2014 参加レポート Vol.12

Clock Icon2014.03.17

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

レポート

くどうです。

さて、Jaws Days 2014に参加したレポートになります。

参加したセッションの情報は以下です。

プロビジョニング&デプロイ on AWSのキホン

吉羽 龍太郎(よしば りゅうたろう)

AWSを利用すると伸縮自在なインフラストラクチャを構築することが可能です。 このような環境では頻繁にインスタンスが入れ替えられたり、アプリケーションをデプロイしなおしたりする必要がありますので、自動化が必須です。本セッションではAWS環境におけるプロビジョニングやデプロイの自動化におけるキホンについて解説します。

こんな話しでした

  • Immutable Infrastructure はすぐに実現できる?
    • できない
  • 基本:自動化する
    • ライフサイクルを含めて
  • 基本:ビックバンを避ける
    • 小さくリリース
  • インフラもソフトウェア
    • コードでインフラを書く
    • 構築に時間がかからない
    • コード=手順書
    • 同じコードで同じサーバー
    • 再利用
    • 使いまわし
  • 基本:連続体としてとらえる
    • インフラのプロビジョニング
    • AWSでは1時間で1000回のデプロイが行われている
  • 自動化しないリスク
    • 作業は繰り返し
    • 手順書がメンテされないリスク
    • マニュアル作業によって間違うリスク
    • 職人芸依存へのリスク
    • リリースに失敗するリスク
    • 戻れないリスク
    • 対象が増えると作業時間と失敗リスクが増加
    • コスト流失のリスク
    • 結果的に自信が持てない
    • プロセスが重くなるリスク
    • 時間がないので人海戦術
  • 自動化に向けて
    • なぜ?
  • 自動化に投資するか慎重な判断が必要な領域
    • 小規模キャンペーン
    • 使い捨てアプリ
    • 納品して終わり物
  • 基本:自動化の5R
    • Rapid
    • Reliable
    • Repeatable
    • Reduce Risk
    • Roll ack
  • プロジェクトの最初から始める
    • 顧客や上司の理解を得る
    • こっそりは無理
    • 説明責任
    • 便利ツールとは次元のちがう話し
  • 継続的に改善できる仕掛けを作る
  • デプロイの自動化
  • デプロイしやすいアーキテクチャの維持
  • AWSでのアーキテクティング
    • 故障のための設計
    • 疎結合なコンポーネント
    • 弾力性のある実装
    • 前例やでセキュリティ担保
    • 並列処理の実装
    • 異なるストレージの使い分け
  • デプロイに自動化に必要な要素
    • バージョン管理システム
    • 自動化されたテスト
    • マイグレーション
    • 継続的インテグレート
    • デプロイツール
    • 静的解析・コードレビュー
  • バージン管理
    • 全ての基本
    • チーム全員が使い方を理解するのが当たり前
    • しつけの問題
    • コードの共同所有
    • 環境の再現ができる
    • コレができなければ先に進む意味がない
  • 自動化されたテスト
    • 速度維持と品質維持
    • どこまでテストを用意する
    • テストのしやすさ=デプロイのしやすさ
  • マイグレーション
    • 人が判断しない原則
  • 継続的インテグレーション
    • プロジェクトの生命製
  • アンチパターン
  • デプロイ自動化
    • デプロイプロセスの設計
    • 実現方法は変化する
  • デプロイのパターン
  • アンチパターン
    • 手作業混合
  • ツールの選択
    • Beanstalk&OpsWorks
  • ブルーグリーンデプロイ
  • デプロイ失敗の検知
  • あとからデプロイ自動化する場合
    • プロビジョニング
    • プロビジョニング自動化の進め方
    • デプロイとプロビジョニングは連続体
  • AWSのプロダウとの位置づけ
    • サービス型
      • Elastic Beanstalk
      • OpsWorks
    • 自己管理型
      • CloudFormation
      • EC2
  • AMI作成の3つの選択肢
    • 全部いり
    • サードパーティ
    • OS
    • Packer+Chef-Soloなんかで→自動化できればCIできる
  • 自動化しやすいものを選択性よ自動化できなければ継続的インテグレーションができる
  • Sensu
  • ベストプラクティス
    • プロジェクトの最初から始める
  • アンチパターン:手作業との併用
  • アンチパターン:テストがない
  • 途中からの環境構築自動化
  • まとめ
    • 自動化には順番がある
    • やるならプロジェクトの最初から
    • プロセス設計する
    • APIを活用
    • 継続的インテグレーション重要
    • 手作業をまぜない
    • 適切なツールを使う

ざっとメモをしてきたことを dump したのですが、
吉羽さんのスライドの特徴として量多いんですよね( ;´Д`)
そして、写真を全面的に使う手法。インパクトありますよね。

今回、聞いたのはプロビジョニング・デプロイの自動化のお話しでした。
自分は主にインフラ部分を担当しているわけですが、自動化の重要性は理解しているつもりです。
手動作業とか面倒ですもん。
そして、よく間違える。

サーバー監視、運用のところで説明があったのですが自身はSensuを推しているそうです。
Zabbixなどよりも使いやすいらしいです。
どうしてもこういう方が興味わいちゃいます。

以上、レポートみたいなレポートでした。

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.