OpsJAWS#7 20160729 SIerにおけるDevOpsの現状　～terraformを使ったAWS開発～

Transcript

1. 1.

   SIerにおけるDevOpsの現状 ～Terraformを使ったAWS開発～ 2016/07/29 OpsJAWS #7

2. 2.

   Agenda 1. 私なりのDevOpsの理解 • DevOpsとは • エンタープライズでDevOpsって…みたいな話 2. Terraformを使ったAWSインフラ開発の紹介

3. 3.

   DevOpsとは？ • 「開発チーム（Development）と運用チーム（Operations）がお互いに 協調し合うことで、開発・運用するソフトウェア／システムによってビジ ネスの価値をより高めるだけでなく、そのビジネスの価値をより確実かつ 迅速にエンドユーザーに届け続ける」という概念 • Devの役割が“システムに新しい機能を追加する”である一方、Opsの役割 は“システムの安定稼働”である。そのため、Devが新しい機能を追加した くても、Opsはシステムの安定稼働のために変更を加えたがらない、とい

   う対立構造が作られてしまっていた • 「10+ Deploys Per Day: Dev and Ops Cooperation at Flickr（1日10回以上のデプロイ： Flickrにおける開 発と運用の協力）」
4. 4.

   SoE？？　SoR？？ • スタートアップ、Web系企業 • ビジネスの価値に直結するようなシステム、サイトがほとんど • 細かい機能追加・カイゼンがビジネスに直結していくので、そのサイ クルタイムを短縮することが至上命題 • エンタープライズ（≒基幹系）

   • もともと（事務的な）業務効率を上げるためであり、ビジネスに直結 するようなものではないという性質 • コストカット目的 • デジタル・トランスフォーメーション by 斎藤様
5. 5.

   エンタープライズでDevOps? • Web系が積極的に採用した“クラウド”が、エンタープライズへ 浸透していったことで、Web系からバズりだしたDevOpsもエ ンタープライズが興味を示し始めるようになった • 最初は単純移行した基幹システムも、クラウドの進化に合わせ て継続的な最適化が求められるように • Blackbeltでも紹介あり「失敗例を成功に変える

   AWSアンチパターン のご紹介 2016 」 http://www.slideshare.net/AmazonWebServicesJapan/aws-black-belt-online-seminar-antipattern
6. 6.

   DevとOpsの分業制は悪か？ • エンタープライズにおけるDevとOpsは別企業であることが多い • しっかりとしたインターフェースを持ち、統率されている分業制は、 それはそれでのDevOps • 安全性が保たれてさえいれば、自動化・効率化がKPIにならない場合 • 求められるサイクルタイムがそんなに早くない場合

   • システムの特性に合わせて、目的に合わせて選択していくべき
7. 7.

   • 先日お話させていただきました。※OpsJAWS Meetup#5 • 背伸びをしないAWS構成管理 • https://speakerdeck.com/kaojiri/opsjaws-number-5-20160420-bei-shen-biwosinaiawsgou-cheng-guan-li • ここでは稼働中の安全性を高めるアプローチを紹介 •

   作った環境をどう安全に可視化・維持するか、みたいな話 • 今回は、どうやって作ればいいか？みたいな話
8. 8.

   カイゼンの道筋（イメージ） CI/CD DevOps アジャイル （攻めのIT） 画面・手作業系 （とりあえずやってみた） 最初は ここ 理想

   現実路線 ビ ジ ネ ス ス ピ ー ド 安全性 前回 今回
9. 9.

   （今回）Devよりな話。安全性とちょっとだけスピードアップを意識 × Tfstate （Staging） Tfstate （Production） Staging Production plan plan

   pull/push pull/push apply + test *.tf , tfvars etc…
10. 10.

    Terraform • HashiCorp社が開発した、クラウドっぽい環境に対するオーケスト レーションツール • AWSの他にAzure等のクラウド、OpenStack、VMwareなど十数種 類の環境について統合的に記述可能 • AWSにはCloudFormationが用意されているが、下記点を評価して Terraformを採用

    • 各リソースのidを動的に解決し、さらに変数名で容易に参照出来るなど表現 力の高さ • いわゆるDryRunの機構が優れており、ミスに容易に気づける。多人数で一 つのインフラ環境を構築したり、更新したりする場合に特に安心感が高まる • シェルスクリプトによる運用フローのカスタマイズが容易 • コメントが書ける
11. 11.

    Staging Production レビュー Tfstate （Staging） Tfstate （Staging） Tfstate （Production） Pull/Push

    開発者による plan確認 CIによる plan結果 共有 apply+ テスト レビュー 開発者による plan確認 CIによる plan結果 共有 apply+ テスト Tfstate （Production） Pull/Push トピック ブランチ Staging ブランチ Master マージ リクエスト マージ リクエスト マージ マージ
12. 12.

    工夫点 • 変数は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
13. 13.

    これから • AWS上でインフラを安全に開発して、少しだけ開発スピードを アップできる手法と、それらを維持・可視化するための手法が なんとなく見えてきたので、これらを融合するフローや組織・ 文化を浸透させる！！！ • これができ始めると本当のDevOpsのスタート

14. 14.

    カイゼンの道筋（イメージ） CI/CD DevOps アジャイル （攻めのIT） 画面・手作業系 （とりあえずやってみた） 最初は ここ 理想

    現実路線 ビ ジ ネ ス ス ピ ー ド 安全性 前回 これから 今回
15. 15.

    まとめ • DevとOpsの対立構造を解決するのはツール“だけ“じゃない • エンタープライズにおけるDevOps採用は、求められるサイクルタ イムを鑑みて • とはいうものの、エンタープライズがクラウド浸透してきた以上、避けては 通れない道 •

    Terraformでインフラ周りのCIが可能 • 今後は技術的な話だけでなく、文化を醸成していきたい • 次回をお楽しみに
16. 16.

    Let’s share the tips later!!