Downloaded 68 times
Uploaded byDevelopers Summit
5,192 views
デブサミ2014【13-E-3】クラウド時代の環境構築・デプロイ自動化戦略
ビジネスの速度にあわせて頻繁にインフラストラクチャーを伸縮させたりアプリケーションをデプロイするためには、不安定なマニュアルプロセスではなく、再現可能な自動化されたプロセスを作り上げていかなければなりません。本セッションではこれからクラウド環境上での自動化を進めていくことを検討されている方のために、自動化の始め方や戦略、そして具体的なケーススタディを紹介いたします。
Recommended
![夏サミ 2012 [B-2]エンタープライズ開発におけるコラボレーション - JIRAによる顧客と開発チームのつなぎ方](/image.pl?url=https%3a%2f%2fcdn.slidesharecdn.com%2fss_thumbnails%2fdvsumi12natsumib2share-120727064447-phpapp02-thumbnail.jpg%3fwidth%3d640%26amp%3bheight%3d640%26amp%3bfit%3dbounds&f=jpg&w=240)
![[devsumi2013]【15-D-7】実演！現場の悩みをTOCfEで考え抜く！](/image.pl?url=https%3a%2f%2fcdn.slidesharecdn.com%2fss_thumbnails%2fdevsumi2013tocfe-130217055825-phpapp01-thumbnail.jpg%3fwidth%3d640%26amp%3bheight%3d640%26amp%3bfit%3dbounds&f=jpg&w=240)
More Related Content
What's hot
Viewers also liked
![[HQ Nacional] Street Fighter II Ano I - Número 1 - parte 1](/image.pl?url=https%3a%2f%2fcdn.slidesharecdn.com%2fss_thumbnails%2fstreetfighterii-anoi-nmero1-parte1-110702164425-phpapp02-thumbnail.jpg%3fwidth%3d640%26amp%3bheight%3d640%26amp%3bfit%3dbounds&f=jpg&w=240)
Similar to デブサミ2014【13-E-3】クラウド時代の環境構築・デプロイ自動化戦略
More from Developers Summit
デブサミ2014【13-E-3】クラウド時代の環境構築・デプロイ自動化戦略
- 1.
- 2.⾃自⼰己紹介! 名前：吉⽻羽⿓龍龍太郎郎• アマゾン データ サービス ジャパン株式会社• シニア・コンサルタント! ソーシャル• @ryuzee• www.ryuzee.com2個⼈人の著作・翻訳
- 3.
- 4.
- 5.
- 6.
- 7.
- 8.
- 9.
- 10.
- 11.Amazonの3つのコアビジネスセラー向けビジネスコンシューマ向けビジネス1億を超えるアクティブなアカウント８カ国で展開 :⽶米国, 英国, ドイツ, ⽇日本, フランス, カナダ, 中国, イタリアアマゾンのウェブサイト上で販売⾃自社⼩小売ウェブサイトにAmazonの技術を利利⽤用アマゾンフルフィルメントセンター（物流流センター）の活⽤用IT インフラストラクチャ11ITインフラビジネススケーラビリティ2006年年開始ウェブスケールでのクラウド基盤の提供⾼高可⽤用性190以上の国において、数⼗十万に及ぶ登録アカウント
- 12.
- 13.ビジネスはうまくいかないこともある! 1発1中は⽬目指さない! うまくいっていないことを把握できる仕掛け! ダメなものをやめる選択肢13
- 14.
- 15.フィードバックループ! 顧客とビジネスの間のフィードバックループを加速する! 顧客の期待に応え続ける15
- 16.
- 17.
- 18.DEPLOYMENTS ATAMAZON.COM11.6s1,079Mean timebetweendeployments(weekday)Max number ofdeployments in asingle hour10,000 30,000Mean number ofhostssimultaneouslyreceiving adeploymentMax number ofhostssimultaneouslyreceiving adeployment
- 19.
- 20.
- 21.
- 22.マニュアル作業によって間違うリスク! いままで何度度デプロイしているか覚えているか？! いままで間違えたことはないのか？22
- 23.
- 24.リリースに失敗するリスク/戻れないリスク! ⼿手作業で⼤大変なので慎重にレビューが必要! なので、複数をまとめてリリース! ビッグバンリリース! さらに失敗しやすく! しかも戻せない24
- 25.
- 26.
- 27.
- 28.そしてさらにプロセスが重くなるリスク! リスクを恐れてチェックリストが増える! トラブルごとに増える! ⼆二重チェック、三重チェック…! ⼀一時的には問題が発⽣生しなくなるかもしれないが…! 持続可能性に問題28
- 29.でも時間がないので⼈人海戦術…! 単なる問題の先送り。あとになってもっと⼤大変! ⼀一時的に負債を許容しても、すぐに返済すべき29
- 30.
- 31.
- 32.
- 33.基本的な考え⽅方! ⾃自動化にはコストがかかる! 基本ができていない場合は達成まで時間もかかる! ⼿手作業でやった場合と⽐比較してどちらが安いか! 実⾏行行回数や問題が発⽣生した場合(リスク顕在化)の対処コスト等を含めて考える! ただし、損益分岐点は思った以上に早い! 顧客が要求するスピードやアプリケーションのライフサイクルを踏まえる33
- 34.⾃自動化に投資するか慎重な判断が必要な領領域! たとえば、⼩小規模なキャンペーンサイト! 使い捨てのアプリケーション! 納品したら終わりのモノ34
- 35.
- 36.
- 37.
- 38.
- 39.顧客や上司の理理解を得る! 黙ってこっそりやるのは無理理! 説明責任! 個⼈人の便便利利ツール構築とは次元の違う話39
- 40.
- 41.
- 42.
- 43.プロジェクトの最初から始める! プロジェクト期間中は何度度もテスト環境にデプロイするはずなのでコスト効率率率が⾼高くなる! 何度度もテストされ信頼性向上43
- 44.デプロイしやすいアーキテクチャーの維持! アプリケーションを常にデプロイしやすいように維持! 疎結合アーキテクチャー44
- 45.
- 46.
- 47.バージョン管理理! 全ての基本! ブランチ、マージを含めて、チーム全員が使い⽅方を理理解するのが当たり前。躾の問題! コードの共同所有! 設定ファイルやアセット含めて、いつでも環境を再現できるようにしなければならない! ここがちゃんとできずに先に進む意味がない47
- 48.ブランチの戦略略がチーム全員で理理解できているか？ブランチの戦略略はデプロイの戦略略と密接な関係A successful Git branching modelより図を引⽤用http://nvie.com/posts/a-‐‑‒successful-‐‑‒git-‐‑‒branching-‐‑‒model/48
- 49.
- 50.どこまでテストを⽤用意するか？! ユニットテスト、結合テスト、受け⼊入れテスト、スモークテスト! それはプロセスとして設計50
- 51.
- 52.マイグレーション! 設定ファイルやアセット含めて、いつでも環境を再現できるようにしなければならない原則! いつの時点のリリースにも戻せるようにする原則! 依存関係・前後関係は⼈人が判断しない原則! →マイグレーションの活⽤用52
- 53.継続的インテグレーション! バージョン管理理、テスト⾃自動化、マイグレーションが実現できていれば継続的インテグレーションの実現が可能! 常にリリース可能かどうかを検証し続ける! プロジェクトの⽣生命線53
- 54.継続的インテグレーションアンチパターン!!!!!!!!!!!!!!!!!!54 テストコードがないテストコードと製品コードを同時にコミットしない定時ビルドのみでコミットビルドがない・夜間ビルドしかない帰り際にコミットしてそのままCIの結果を⾒見見ずに帰るCIでテストを通すために⼿手作業の準備が必要メインラインのみで⼤大きなブランチをCI対象にしていない様々な種類のテストをまとめて⾏行行っているビルドの失敗に気付かない / ビルドに失敗しても放置しているビルドの失敗に気づいても、修正コード以外のコードをコミットする何も変更更していないのにビルドが落落ちたり落落ちなかったり頻繁にビルドが失敗するので、失敗するのが普通だと思うCIからの通知メッセージが⼤大量量すぎる / CIが落落ちても何も通知しない CIサーバのリソースが貧弱ビルドが肥⼤大化して結果が出るまでに時間がかかる本番環境やステージング環境と⼤大幅に環境が異異なるコードの静的解析をCIで⾏行行わずに⼈人⼿手で⾏行行うCIサーバがおかしくなったときに直せる⼈人がいないずっとCIでのチェック内容が変わらない、プロセスが変わらない
- 55.デプロイ⾃自動化! ここまで出来ていればデプロイ⾃自動化まであとちょっと! まずデプロイプロセスの設計を55
- 56.
- 57.
- 58.
- 59.
- 60.
- 61.デプロイアンチパターン：様々な⽅方法! パターンを多くし過ぎるとデプロイの信頼性が低下• 各パターンが⼗十分にテストされない! ⼀一般的には以下の2種類• ⼤大規模リリース⽤用• ⼩小規模リリース⽤用61
- 62.
- 63.ツールの選択! 専⽤用のツールを使うことを強く推奨! Capistrano、Fabric、Maven・・・・などなど! デプロイスクリプトの可読性と保守性は重要! これがリリース⼿手順書の代わりになるので、担当者が変わっても保守できるものを選択! シェルスクリプトは複雑化しやすく保守しにくい63
- 64.デプロイ失敗の検知! スモークテストの実⾏行行! 監視システムによるログ監視やプロセス監視64
- 65.あとからデプロイ⾃自動化する場合ーバジーシンーン管理理テスト⾃自動化マイグレ継続的インテグレシデプロイ⾃自動化ン! 各ステップが実現できているか確認! アプリケーションのアーキテクチャー修正が必要になる可能性も65
- 66.
- 67.環境構築⾃自動化の進め⽅方! 基本的な考え⽅方はデプロイ⾃自動化と同じ! プロセスの設計! ベストなツールの選択。! デプロイツールとは違うツールを使った⽅方が良良い! ⾃自動化しやすいアーキテクチャー67
- 68.
- 69.
- 70.こんな環境の作成を⾃自動化できるAvailability Zone -‐‑‒ APublic Subnet 10.0.0.0/24EC2 InstancePrivate Subnet 10.0.1.0/24Amazon RDSAZ-‐‑‒A-‐‑‒WP110.0.0.6AnyoneAMIInternetInternet GatewayAZ-‐‑‒B-‐‑‒WP210.0.2.8EC2 InstancePublic Subnet 10.0.2.0/24Amazon RDSPrivate Subnet 10.0.3.0/24Availability Zone -‐‑‒ CVPC 10.0.0.0/1670
- 71.CloudFormation! JSONで環境を記述! このテンプレートを使って何個でも同じ環境をつくれる! テキストファイルなのでバージョン管理理システムにも登録可能71
- 72.
- 73.
- 74.
- 75.
- 76.IF YOU CANPROGRAM ITYOU CAN AUTOMATE IT⾃自動化しやすいものを選択せよ⾃自動化できれば継続的インテグレーションできる
- 77.
- 78.インフラCI構成例例! Amazon EC2• インスタンスストレージにSSDがあるものを選択! Ubuntu 12.04 LTS! Jenkins! Vagrant• vagrant-‐‑‒lxcプラグイン! LXC• インスタンスストレージ上に仮想マシンを作成し⾼高速化! Chef• Test-‐‑‒Kitchen、Berkshelf• CookbookはGitHubに! Serverspec78
- 79.環境構築の3つの選択肢 (クラウドの場合)! 全部⼊入り仮想マシンイメージを作成し維持! OSおよびベースとなるソフトウェアを導⼊入した仮想マシンイメージを作成し、初回作成時に追加部分のみプロビジョニング! OSの仮想マシンイメージを起動し、初回作成時に、必要な全てをプロビジョニング79
- 80.
- 81.アンチパターン：⼿手作業との併⽤用! ⾃自動化されているサーバに⼊入って⼿手作業で変更更…! 次回にロールバックされたりする81
- 82.アンチパターン：テストがない! ⾃自動化スクリプトは⼿手順書と同等! 常時テストしていなければ、次回使う時に正しく動くかわからない82
- 83.途中からの環境構築⾃自動化! デプロイ⾃自動化に較べると、既に存在する環境に対して途中から適⽤用するのは難易易度度が⾼高い! 途中からの場合はまず開発環境から⾃自動化! サービス系のようにサーバの台数が増えるものについては、追加分のみ⾃自動化機構で管理理し、徐々に⼊入れ替える83
- 84.実例例VPCAvailability Zone -‐‑‒ APublic SubnetPrivate SubnetAmazon RDSAMIAnyoneInternetInternet GatewayAmazon RDSPublic Subnet Private SubnetAvailability Zone -‐‑‒ C84
- 85.実例例VPCAvailability Zone -‐‑‒ APrivate SubnetPublic SubnetAmazon RDSAMIAnyoneInternetInternet GatewayCloudFormationで環境を定義Amazon RDSPublic Subnet Private SubnetAvailability Zone -‐‑‒ C85
- 86.実例例VPCAvailability Zone -‐‑‒ APrivate SubnetPublic SubnetAmazon RDSAMIAnyoneInternetInternet GatewayコードはGitHubへPublic Subnet Amazon RDSPrivate SubnetAvailability Zone -‐‑‒ C86
- 87.実例例VPCAvailability Zone -‐‑‒ APublic SubnetPrivate SubnetAmazon RDSAMIAnyoneInternetInternet GatewayAmazon RDSPublic Subnet コードがコミットされるPrivate SubnetとCI実⾏行行Availability Zone -‐‑‒ C87
- 88.実例例VPCAvailability Zone -‐‑‒ APublic SubnetPrivate SubnetAmazon RDSAMIAnyoneInternetInternet Gatewayサーバ⼀一覧をAPI経由でPublic Subnet 取得しデプロイしつつS3にアーカイブ配置88Amazon RDSPrivate SubnetAvailability Zone -‐‑‒ C
- 89.実例例EC2起動時にAMIとChef VPCServer利利⽤用。⾃自動で最新Availability Zone -‐‑‒ AコードをS3から取得Public SubnetPrivate SubnetAmazon RDSAMIAnyoneInternetInternet GatewayAmazon RDSPublic Subnet Private SubnetAvailability Zone -‐‑‒ C89
- 90.実例例VPCAvailability Zone -‐‑‒ APublic SubnetPrivate SubnetAmazon RDSAMIAnyoneInternetInternet Gatewayサーバ⼀一覧をAPI経由でPublic Subnet 取得しデプロイしつつS3にアーカイブ配置90Amazon RDSPrivate SubnetAvailability Zone -‐‑‒ C
- 91.まとめ! デプロイ⾃自動化・環境構築の⾃自動化には順番がある! やるならプロジェクトの最初から! プロセス設計をする! 適切切なツールを使う! APIを活⽤用する! 継続的インテグレーション重要! ⾃自動化された作業と⼿手作業を混ぜない91