どんなに頑張ったって運用の自動化もDevOpsも進まない…そう、テストがなければね #jtf2017 #a50

どんなに頑張ったって運用の自動化もDevOpsも進まない…そう、テストがなければね #jtf2017 #a50

1. 1. どんなに頑張ったって 運⽤の⾃動化もDEVOPSも進まない そう、テストがなければね 株式会社あくしゅ ⼭崎泰宏 y-yamazaki@axsh.net
2. 2. 運⽤の⾃動化 進んでいますか？
3. 3. ⼩さな⾃動化から 導⼊を始める
4. 4. 効果も⼩さいが そこそこ役には⽴つ
5. 5. ⾃動化を強く推し進めたい …が、実態は異なっている
6. 6. 複雑な運⽤スクリプトを 本番環境で実⾏できますか？
7. 7. 「本番のネットワークルータに BGP設定を⾃動投⼊するプログラムを 作った！」 事例
8. 8. これまでは⼿順書を しっかりレビューしてきた
9. 9. みんなが良いと⾔うものは良いはずだ
10. 10. 物理ネットワーク アプライアンス 設定変更 複雑な ネットワーク 複雑な ネットワーク 設定 こんな設定 入れます OK
11. 11. Internet Webサーバ群 設定 こんな設定… 入れ…られます？ あ、え、OK? WAF IDS/IPS Firewall 設定変更
12. 12. 物理ネットワーク アプライアンス 設定変更 複雑な ネットワーク 複雑な ネットワーク 設定 失われていく時間 これが 本番環境だから 慎重にならざるをえない
13. 13. どうして そのような仕事の仕⽅になるのか
14. 14. 本番環境 私達が扱う「環境」は 全て少しずつ異なっている ステージング環境 試験環境、etc...
15. 15. 異なる環境で動作確認をしたものが 本番環境でも動作するとは限らない 開発 環境1 開発 環境2 開発 環境3 ステージング 環境1 ステージング 環境2 本番環境 共有DB DB DB DB Master DB Backup
16. 16. ならば同じものを⽤意しよう
17. 17. 物理ネットワーク アプライアンス 複雑な ネットワーク 複雑な ネットワーク 物理ネットワーク アプライアンス 複雑な ネットワーク 複雑な ネットワーク 試験 本番 ≒ 同じ環境を作るのは カネがかかり過ぎる!
18. 18. 全て仮想化すれば 良いんじゃないだろうか
19. 19. 物理ネットワーク アプライアンス 複雑な ネットワーク 複雑な ネットワーク SDNは良いアイディアだけど 仮想にすることで 挙動が異なってしまっては意味がない 試験SDN環境
20. 20. 仮想基盤 解決の基本アイディア: 物理リソースへのバイパスを可能に 仮想アプライアンス 仮想LAN 社内システム (VMのクラスタ) 仮想基盤 物理機器 仮想LAN 社内システム (VMのクラスタ) 物理機器 Patch機能 ネットワーク機器は物理でしか存在しないものも多い他、 仮想アプライアンスとして提供されているものも動作が異なるケースがある。 そのため、実際の物理機器を仮想基盤内でプロビジョニング & バイパスするような仕組みを設ける
21. 21. これに必要なOSS (LGPL3.0) も スクラッチから開発済み https://wakame-vdc.org/ https://openvnet.org/ & OpenVDC https://github.com/axsh/openvdc
22. 22. INFRASTRUCTURE AS CODE オーケストレーションで環境を⾃動構築 仮想基盤 物理機器 仮想LAN 社内システム (VMのクラスタ) 物理機器 OpenVNet Patch機能 Terraform など ネットワーク 構成図 テスト スクリプト 作成作成 ネットワーク 管理者 環境構築 設定投⼊ 実⾏
23. 23. 物理と仮想が混在した構成を作れる
24. 24. 物理ネットワーク アプライアンス 複雑な ネットワーク 複雑な ネットワーク 物理ネットワーク アプライアンス 複雑な ネットワーク 複雑な ネットワーク 試験 本番 ≒
25. 25. 「環境の複製が重要」 Clone / Reproduce
26. 26. Demonstration Juniper SSG 5 Test Example
27. 27. KCCS様 GREENOFFICE UNIFIED CLOUD 商⽤のクローン環境構築事例 2013年〜2015年の実績
28. 28. 新規DCサービスの開発と運⽤ • 法人向けサービス • パブリッククラウド • オンデマンド操作 • 充実した監視機能 • 基盤側の動作と Issueトラッキングが連動 • DC拠点間での レプリケーション • 東京と京都の２拠点DCへ 常時安定的にデプロイ • 新規機能のリリース毎 • 並行した複数の機能開発
29. 29. ⼀⼈に⼀つずつ クローン環境(本番環境の複製) 開発者 恒久的な 機能開発 ⼀時的な 運⽤スクリプト開発 運⽤者 クローン 環境 クローン 環境 環境構築 ステージング 環境 本番環境 デプロイ テスト 機能開発や改善は、 1⾏でもコードを直したら 全テストを通す
30. 30. 運⽤スクリプトは本番環境でも 修正せずにそのまま動作する DC物理環境 KVM仮想化基盤 Wakame-vdc⽤ 仮想マシン 仮想DC物理環境 KVM仮想化基盤 Wakame-vdc⽤ 仮想マシン テスト⽤物理環境 DCの層も仮想化していて ネットワークやサーバの内部構造が 本番と同⼀に保たれている クローン環境 本番環境 運⽤スクリプトが 実⾏される層
31. 31. ⼤⼿美容サロン様 DR可能なAZURE全⾯移⾏プロジェクト 2016年〜2017年の実績
32. 32. オンプレミスからAZUREへの移⾏ 店舗 約200拠点 東京 本社 DC 予約システム Internet お客様 予約 来店 店舗 約200拠点 東京 本社 DC Internet お客様 予約 来店 Azure 東⽇本DC Azure ⻄⽇本DC 予約システム 同期された データ いつでもDRが可能 常時レプリケーション VPN 縮⼩
33. 33. 環境構築をワンクリックで →DRへ応⽤する 店舗 約200拠点 東京 本社 都内 DC Internet お客様 予約 来店 東⽇本DC⻄⽇本DC VPN Web API Azure 予約システム 同期された データ CI/CD⽤サーバ Jenkins 2 DB DB 予約システム同期された データ DBDB DB DB
34. 34. “複製できる環境”がある世界 • 本番環境以外は必要な時に作れば良くなる • いらなくなったら破棄する 本番環境 DB Master DB Backup 運用テスト用 環境 DB Master DB Backup 負荷試験 環境 DB Master DB Backup バグ再現用 環境 DB Master DB Backup
35. 35. コストダウンと テスト精度の向上を同時に実現 本番 環境 ステージング 環境 x 24h x 24h コスト 本番 環境 x 24h x 10h コスト ステージング 環境 これまで これから 本番環境 ≠ ステージング環境 テストの精度は低い 本番環境 ≒ ステージング環境 テストの精度は高い
36. 36. 運⽤の⾃動化とは テストできるソフトウェアを書くこと 開発チーム 運用チーム プログラムを 書いて コンピュータに 作業をやらせる 手順書を読んで 手作業をやる プログラムは 事前にテストする 手順書は事前に チェックはされるが 基本的に本番で 初めて実行される プログラムを書く テストをする
37. 37. 開発と運用が 同じプロセスに ⾃信を持って 作業の全てをプログラムにできる 開発 運用 プログラムを 書いて コンピュータに 作業をやらせる プログラムは 事前にテストする これが DevOpsには必要
38. 38. ⾃動化を推進するためのDEVOPS 変更を記述 適用前の検査 変更の適用 開発 (Dev) アプリケーションの コードを記述する テストケースを記述し 実行する デプロイした コードが実行される 運用 (Ops) 手順書を記述する 手順書をレビューする 本番環境で 手順書を見ながら 作業を実施する 変更を記述 適用前の検査 変更の適用 開発 (Dev) アプリケーションの コードを記述する テストケースを記述し 実行する デプロイした コードが実行される 運用 (Ops) 作業のための コードを記述する テストケースを記述し 本番同等の複製環境で 実行する 本番環境で コードが実行される 今後 • DevとOpsは基本的に異なる作業プロセスにある • Opsは有識者のレビューに頼っている • DevとOpsは統合された作業プロセスにあり DevOpsを実現する共通のツールに乗る • Opsは環境に依存する作業が多いが 本番同等の環境を複製し その場で網羅的に事前検証ができる • 運用の自動化のトレンドでは 変更の適用部分だけが議論されることが多いが それでは効果は薄い「運用のテスト」が重要になる 運用の自動化のトレンドは この部分を言っていることが多い
39. 39. DEVOPSも テスト無しには成り⽴たない • 開発者(Dev)と運⽤者(Ops)が… • システム開発に対する 共通の考え⽅や⽂化を持っていること • 両者が分断されていない共通のプロセスで 協⼒して仕事ができる体制のこと • どちらもプログラムを書き、 テストできる仕組みを持っていること • 特に運⽤のテストができること • 開発と運⽤で共通のツールセットが整っていること
40. 40. 仮想基盤 or クラウド CI/CD用 インスタンス Jobs Git リポジトリ Jenkins Push Access 単体テスト RPM作成 RPM Repo RPM チャット ツール Post参加 Image 作成 Image Repo Image テンポラリ インスタンス Install Store 環境構築 インスタンス インスタンス インスタンス Launch 結合テスト 実行 リリース 運⽤のテストのための CI/CD環境構成例 46 Launch Access
41. 41. 徹底的に複製せよ • クラウドと仮想基盤の持つマルチテナントの機能をフル活⽤すること • 仮想サーバ • 仮想の多重化 • Nested KVM • KVM on LXC 等のあわせ技 • 仮想ネットワーク • OpenVNet • ブロードキャストドメイン制御(MAC2MAC)、GRE • AWS の VPC、Azure の VNet • Kubernetes的なもの • 特に運⽤上必要なレイヤより上を同⼀にしておくのが⼤切 • MACアドレス、IPアドレス… 同じになればなるほど、テストの精度は上がる
42. 42. まとめ 運⽤の⾃動化、DevOpsの実現、これらに必要な最後のピースは… (1) 運⽤のテスト 環境の差異が運⽤のテストを阻む要因であったため… (2) 環境の複製が重要 複製をキーとした技術的なアプローチとして… (3) クラウドや仮想化をフル活⽤
43. 43. Axsh Co. Enlightened Enterprise Computing Inquiries: email: info@axsh.net Tel.: +81-3-6300-7624 どんなに頑張ったって、運⽤の⾃動化も DevOps も進まない… そう、テストがなければね 1. Azure / AWS等クラウドの活⽤や最適化 2. 運⽤の⾃動化・改善 3. スピードと品質を両⽴する CI/CD, DevOpsの実現 ご相談ください