イチ個人の見解であり、所属会社や組織とは関係はありません。
SIerにおけるDevOpsの現状~Terraformを使ったAWS開発~2016/07/29OpsJAWS #7
View Slide
Agenda1. 私なりのDevOpsの理解• DevOpsとは• エンタープライズでDevOpsって…みたいな話2. Terraformを使ったAWSインフラ開発の紹介
DevOpsとは?• 「開発チーム(Development)と運用チーム(Operations)がお互いに協調し合うことで、開発・運用するソフトウェア/システムによってビジネスの価値をより高めるだけでなく、そのビジネスの価値をより確実かつ迅速にエンドユーザーに届け続ける」という概念• Devの役割が“システムに新しい機能を追加する”である一方、Opsの役割は“システムの安定稼働”である。そのため、Devが新しい機能を追加したくても、Opsはシステムの安定稼働のために変更を加えたがらない、という対立構造が作られてしまっていた• 「10+ Deploys Per Day: Dev and Ops Cooperation at Flickr(1日10回以上のデプロイ: Flickrにおける開発と運用の協力)」
SoE?? SoR??• スタートアップ、Web系企業• ビジネスの価値に直結するようなシステム、サイトがほとんど• 細かい機能追加・カイゼンがビジネスに直結していくので、そのサイクルタイムを短縮することが至上命題• エンタープライズ(≒基幹系)• もともと(事務的な)業務効率を上げるためであり、ビジネスに直結するようなものではないという性質• コストカット目的• デジタル・トランスフォーメーション by 斎藤様
エンタープライズでDevOps?• Web系が積極的に採用した“クラウド”が、エンタープライズへ浸透していったことで、Web系からバズりだしたDevOpsもエンタープライズが興味を示し始めるようになった• 最初は単純移行した基幹システムも、クラウドの進化に合わせて継続的な最適化が求められるように• Blackbeltでも紹介あり「失敗例を成功に変える AWSアンチパターンのご紹介 2016 」http://www.slideshare.net/AmazonWebServicesJapan/aws-black-belt-online-seminar-antipattern
DevとOpsの分業制は悪か?• エンタープライズにおけるDevとOpsは別企業であることが多い• しっかりとしたインターフェースを持ち、統率されている分業制は、それはそれでのDevOps• 安全性が保たれてさえいれば、自動化・効率化がKPIにならない場合• 求められるサイクルタイムがそんなに早くない場合• システムの特性に合わせて、目的に合わせて選択していくべき
• 先日お話させていただきました。※OpsJAWS Meetup#5• 背伸びをしないAWS構成管理• https://speakerdeck.com/kaojiri/opsjaws-number-5-20160420-bei-shen-biwosinaiawsgou-cheng-guan-li• ここでは稼働中の安全性を高めるアプローチを紹介• 作った環境をどう安全に可視化・維持するか、みたいな話• 今回は、どうやって作ればいいか?みたいな話
カイゼンの道筋(イメージ)CI/CD DevOps アジャイル(攻めのIT)画面・手作業系(とりあえずやってみた)最初はここ理想現実路線ビジネススピード安全性前回今回
(今回)Devよりな話。安全性とちょっとだけスピードアップを意識×Tfstate(Staging)Tfstate(Production)StagingProductionplanplanpull/pushpull/pushapply + test*.tf , tfvarsetc…
Terraform• HashiCorp社が開発した、クラウドっぽい環境に対するオーケストレーションツール• AWSの他にAzure等のクラウド、OpenStack、VMwareなど十数種類の環境について統合的に記述可能• AWSにはCloudFormationが用意されているが、下記点を評価してTerraformを採用• 各リソースのidを動的に解決し、さらに変数名で容易に参照出来るなど表現力の高さ• いわゆるDryRunの機構が優れており、ミスに容易に気づける。多人数で一つのインフラ環境を構築したり、更新したりする場合に特に安心感が高まる• シェルスクリプトによる運用フローのカスタマイズが容易• コメントが書ける
Staging ProductionレビューTfstate(Staging)Tfstate(Staging)Tfstate(Production)Pull/Push開発者によるplan確認CIによるplan結果共有apply+テストレビュー開発者によるplan確認CIによるplan結果共有apply+テストTfstate(Production)Pull/PushトピックブランチStagingブランチMasterマージリクエストマージリクエストマージマージ
工夫点• 変数はtfvarsで• ステージング、本番は変数ファイルだけ入れ替えればOK• tfstateをS3に保管• 複数人で同じ状態の構成を管理できるように• GitLabで管理する方法もあるが、特定のブランチを見続けるのは困難なため、あえてS3で• plan、applyはシェルスクリプトで• 上記stateファイルの自動取得、Up• GitLabにはapplyした後にマージ• Terraformのvalidateだけでは不十分だったり、実際にモノがないとテストできないため• ここをみれば全部書いてありますwww• http://made.livesense.co.jp/entry/2016/07/12/083000
これから• AWS上でインフラを安全に開発して、少しだけ開発スピードをアップできる手法と、それらを維持・可視化するための手法がなんとなく見えてきたので、これらを融合するフローや組織・文化を浸透させる!!!• これができ始めると本当のDevOpsのスタート
カイゼンの道筋(イメージ)CI/CD DevOps アジャイル(攻めのIT)画面・手作業系(とりあえずやってみた)最初はここ理想現実路線ビジネススピード安全性前回これから今回
まとめ• DevとOpsの対立構造を解決するのはツール“だけ“じゃない• エンタープライズにおけるDevOps採用は、求められるサイクルタイムを鑑みて• とはいうものの、エンタープライズがクラウド浸透してきた以上、避けては通れない道• Terraformでインフラ周りのCIが可能• 今後は技術的な話だけでなく、文化を醸成していきたい• 次回をお楽しみに
Let’s share the tips later!!