環境差異を排除することのメリットとTips July Tech Festa 2017 ( #jtf2017 #A50 )での発表資料

1. どんなに頑張ったって
運⽤の⾃動化もDEVOPSも進まない
そう、テストがなければね
株式会社あくしゅ ⼭崎泰宏
y-yamazaki@axsh.net

2. 運⽤の⾃動化
進んでいますか？

3. ⼩さな⾃動化から
導⼊を始める

4. 効果も⼩さいが
そこそこ役には⽴つ

5. ⾃動化を強く推し進めたい
…が、実態は異なっている

6. 複雑な運⽤スクリプトを
本番環境で実⾏できますか？

7. 「本番のネットワークルータに
BGP設定を⾃動投⼊するプログラムを
作った！」
事例

9. これまでは⼿順書を
しっかりレビューしてきた

10. みんなが良いと⾔うものは良いはずだ

11. 物理ネットワーク
アプライアンス
設定変更
複雑な
ネットワーク
複雑な
ネットワーク
設定
こんな設定
入れます OK

12. Internet
Webサーバ群
設定
こんな設定…
入れ…られます？ あ、え、OK?
WAF
IDS/IPS
Firewall
設定変更

13. 物理ネットワーク
アプライアンス
設定変更
複雑な
ネットワーク
複雑な
ネットワーク
設定
失われていく時間
これが
本番環境だから
慎重にならざるをえない

15. どうして
そのような仕事の仕⽅になるのか

16. 本番環境
私達が扱う「環境」は
全て少しずつ異なっている
ステージング環境
試験環境、etc...

17. 異なる環境で動作確認をしたものが
本番環境でも動作するとは限らない
開発
環境1
開発
環境2
開発
環境3
ステージング
環境1
ステージング
環境2
本番環境
共有DB DB DB
DB
Master
DB
Backup

18. ならば同じものを⽤意しよう

19. 物理ネットワーク
アプライアンス
複雑な
ネットワーク
複雑な
ネットワーク
物理ネットワーク
アプライアンス
複雑な
ネットワーク
複雑な
ネットワーク
試験 本番
≒
同じ環境を作るのは
カネがかかり過ぎる!

20. 全て仮想化すれば
良いんじゃないだろうか

21. 物理ネットワーク
アプライアンス
複雑な
ネットワーク
複雑な
ネットワーク
SDNは良いアイディアだけど
仮想にすることで
挙動が異なってしまっては意味がない
試験SDN環境

22. 仮想基盤
解決の基本アイディア:
物理リソースへのバイパスを可能に
仮想アプライアンス
仮想LAN
社内システム
(VMのクラスタ)
仮想基盤
物理機器
仮想LAN
社内システム
(VMのクラスタ)
物理機器
Patch機能
ネットワーク機器は物理でしか存在しないものも多い他、
仮想アプライアンスとして提供されているものも動作が異なるケースがある。
そのため、実際の物理機器を仮想基盤内でプロビジョニング & バイパスするような仕組みを設ける

23. これに必要なOSS (LGPL3.0) も
スクラッチから開発済み
https://wakame-vdc.org/ https://openvnet.org/
&
OpenVDC
https://github.com/axsh/openvdc

24. INFRASTRUCTURE AS CODE
オーケストレーションで環境を⾃動構築
仮想基盤
物理機器
仮想LAN
社内システム
(VMのクラスタ)
物理機器
OpenVNet
Patch機能
Terraform など
ネットワーク
構成図
テスト
スクリプト
作成作成
ネットワーク
管理者
環境構築
設定投⼊
実⾏

25. 物理と仮想が混在した構成を作れる

26. 物理ネットワーク
アプライアンス
複雑な
ネットワーク
複雑な
ネットワーク
物理ネットワーク
アプライアンス
複雑な
ネットワーク
複雑な
ネットワーク
試験 本番
≒

27. 「環境の複製が重要」
Clone / Reproduce

29. Demonstration
Juniper SSG 5 Test Example

31. KCCS様 GREENOFFICE UNIFIED CLOUD
商⽤のクローン環境構築事例
2013年〜2015年の実績

32. 新規DCサービスの開発と運⽤
• 法人向けサービス
• パブリッククラウド
• オンデマンド操作
• 充実した監視機能
• 基盤側の動作と
Issueトラッキングが連動
• DC拠点間での
レプリケーション
• 東京と京都の２拠点DCへ
常時安定的にデプロイ
• 新規機能のリリース毎
• 並行した複数の機能開発

33. ⼀⼈に⼀つずつ
クローン環境(本番環境の複製)
開発者
恒久的な
機能開発
⼀時的な
運⽤スクリプト開発
運⽤者
クローン
環境
クローン
環境
環境構築
ステージング
環境
本番環境
デプロイ テスト
機能開発や改善は、
1⾏でもコードを直したら
全テストを通す

34. 運⽤スクリプトは本番環境でも
修正せずにそのまま動作する
DC物理環境
KVM仮想化基盤
Wakame-vdc⽤
仮想マシン
仮想DC物理環境
KVM仮想化基盤
Wakame-vdc⽤
仮想マシン
テスト⽤物理環境
DCの層も仮想化していて
ネットワークやサーバの内部構造が
本番と同⼀に保たれている
クローン環境 本番環境
運⽤スクリプトが
実⾏される層

36. ⼤⼿美容サロン様
DR可能なAZURE全⾯移⾏プロジェクト
2016年〜2017年の実績

37. オンプレミスからAZUREへの移⾏
店舗
約200拠点
東京
本社
DC
予約システム
Internet
お客様
予約
来店
店舗
約200拠点
東京
本社
DC
Internet
お客様
予約
来店
Azure
東⽇本DC
Azure
⻄⽇本DC
予約システム
同期された
データ
いつでもDRが可能
常時レプリケーション
VPN
縮⼩

38. 環境構築をワンクリックで
→DRへ応⽤する
店舗
約200拠点
東京
本社
都内
DC
Internet
お客様
予約
来店
東⽇本DC⻄⽇本DC
VPN
Web API
Azure
予約システム 同期された
データ
CI/CD⽤サーバ
Jenkins 2
DB DB
予約システム同期された
データ
DBDB
DB DB

39. “複製できる環境”がある世界
• 本番環境以外は必要な時に作れば良くなる
• いらなくなったら破棄する
本番環境
DB
Master
DB
Backup
運用テスト用
環境
DB
Master
DB
Backup
負荷試験
環境
DB
Master
DB
Backup
バグ再現用
環境
DB
Master
DB
Backup

40. コストダウンと
テスト精度の向上を同時に実現
本番
環境
ステージング
環境
x 24h
x 24h
コスト
本番
環境 x 24h
x 10h
コスト
ステージング
環境
これまで これから
本番環境 ≠ ステージング環境
テストの精度は低い
本番環境 ≒ ステージング環境
テストの精度は高い

42. 運⽤の⾃動化とは
テストできるソフトウェアを書くこと
開発チーム 運用チーム
プログラムを
書いて
コンピュータに
作業をやらせる
手順書を読んで
手作業をやる
プログラムは
事前にテストする
手順書は事前に
チェックはされるが
基本的に本番で
初めて実行される
プログラムを書く
テストをする

43. 開発と運用が
同じプロセスに
⾃信を持って
作業の全てをプログラムにできる
開発 運用
プログラムを
書いて
コンピュータに
作業をやらせる
プログラムは
事前にテストする
これが
DevOpsには必要

44. ⾃動化を推進するためのDEVOPS
変更を記述 適用前の検査 変更の適用
開発
(Dev)
アプリケーションの
コードを記述する
テストケースを記述し
実行する
デプロイした
コードが実行される
運用
(Ops)
手順書を記述する 手順書をレビューする 本番環境で
手順書を見ながら
作業を実施する
変更を記述 適用前の検査 変更の適用
開発
(Dev)
アプリケーションの
コードを記述する
テストケースを記述し
実行する
デプロイした
コードが実行される
運用
(Ops)
作業のための
コードを記述する
テストケースを記述し
本番同等の複製環境で
実行する
本番環境で
コードが実行される
今後
• DevとOpsは基本的に異なる作業プロセスにある
• Opsは有識者のレビューに頼っている
• DevとOpsは統合された作業プロセスにあり
DevOpsを実現する共通のツールに乗る
• Opsは環境に依存する作業が多いが
本番同等の環境を複製し
その場で網羅的に事前検証ができる
• 運用の自動化のトレンドでは
変更の適用部分だけが議論されることが多いが
それでは効果は薄い「運用のテスト」が重要になる 運用の自動化のトレンドは
この部分を言っていることが多い

45. DEVOPSも
テスト無しには成り⽴たない
• 開発者(Dev)と運⽤者(Ops)が…
• システム開発に対する
共通の考え⽅や⽂化を持っていること
• 両者が分断されていない共通のプロセスで
協⼒して仕事ができる体制のこと
• どちらもプログラムを書き、
テストできる仕組みを持っていること
• 特に運⽤のテストができること
• 開発と運⽤で共通のツールセットが整っていること

46. 仮想基盤 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

47. 徹底的に複製せよ
• クラウドと仮想基盤の持つマルチテナントの機能をフル活⽤すること
• 仮想サーバ
• 仮想の多重化
• Nested KVM
• KVM on LXC 等のあわせ技
• 仮想ネットワーク
• OpenVNet
• ブロードキャストドメイン制御(MAC2MAC)、GRE
• AWS の VPC、Azure の VNet
• Kubernetes的なもの
• 特に運⽤上必要なレイヤより上を同⼀にしておくのが⼤切
• MACアドレス、IPアドレス…
同じになればなるほど、テストの精度は上がる

48. まとめ
運⽤の⾃動化、DevOpsの実現、これらに必要な最後のピースは…
(1) 運⽤のテスト
環境の差異が運⽤のテストを阻む要因であったため…
(2) 環境の複製が重要
複製をキーとした技術的なアプローチとして…
(3) クラウドや仮想化をフル活⽤

49. Axsh Co.
Enlightened Enterprise Computing
Inquiries:
email: info@axsh.net Tel.: +81-3-6300-7624
どんなに頑張ったって、運⽤の⾃動化も DevOps も進まない…
そう、テストがなければね
1. Azure / AWS等クラウドの活⽤や最適化
2. 運⽤の⾃動化・改善
3. スピードと品質を両⽴する CI/CD, DevOpsの実現
ご相談ください