Cloud Native Days Tokyo 2018

1. インフラCI/CDの勘所
Azureのアーキテクトが語る
真壁 徹
日本マイクロソフト株式会社
2018/08/02
Cloud Native Days Tokyo 2018
C-1-5

2. 自己紹介
{
“名前” : “真壁 徹(まかべ とおる)”,
“所属” : “日本マイクロソフト株式会社”,
“部署” : “クラウドアーキテクト技術本部”,
“役割” : “クラウド ソリューションアーキテクト”,
“経歴” : “大和総研 → HP Enterprise”,
“特技” : “クラウド & オープンソース”,
“Twitter” : “@tmak_tw”
}

3. お伝えしたいこと
今日は中の人というより、ユーザーと一緒にAzureを使う人として
「インフラの」CI/CDの現状
教科書的ではなく、身近な話
ズバリな答えはないけど、ヒントになりそうな話
バリバリ系というより、しみじみ系の話
(これからの人、立ち止まっている人寄り)
Azureの他でも使える話

4. Agenda
インフラって何
人と組織
ツールとテクノロジー
戦略とデザイン

5. インフラって何
Part 1

6. インフラCI/CDの話をする前に
みなさんのイメージする「インフラ」の範囲は？
データセンター (空調・発電設備含む)
ハードウェア
インフラソフトウェア・API
OS・仮想マシン
コンテナー
ライブラリ・パッケージ
アプリケーション

7. インフラCI/CDの話をする前に
みなさんのイメージする「インフラ」の範囲は？
データセンター (空調・発電設備含む)
ハードウェア
インフラソフトウェア・API
OS・仮想マシン
コンテナー
ライブラリ・パッケージ
アプリケーション
アプリから見たら
こうなりがち

8. インフラCI/CDの話をする前に
みなさんのイメージする「インフラ」の範囲は？
データセンター (空調・発電設備含む)
ハードウェア
インフラソフトウェア・API
OS・仮想マシン
コンテナー
ライブラリ・パッケージ
アプリケーション
ネットワークや
ストレージの
専門家タイプ

9. インフラCI/CDの話をする前に
みなさんのイメージする「インフラ」の範囲は？
データセンター (空調・発電設備含む)
ハードウェア
インフラソフトウェア・API
OS・仮想マシン
コンテナー
ライブラリ・パッケージ
アプリケーション
ガチ

10. インフラCI/CDの話をする前に
みなさんのイメージする「インフラ」の範囲は？
データセンター (空調・発電設備含む)
ハードウェア
インフラソフトウェア・API
OS・仮想マシン
コンテナー
ライブラリ・パッケージ
アプリケーション
インフラ
フルスタッ(

11. • 話がかみ合わない問題
• 人によって「インフラ」の範囲は違う

12. インフラCI/CDの話をする前に
みなさんのイメージする「インフラ」の範囲は？
データセンター (空調・発電設備含む)
ハードウェア
インフラソフトウェア・API
OS・仮想マシン
コンテナー
ライブラリ・パッケージ
アプリケーション
本日の範囲

13. インフラCI/CDパイプライン
本日の定義
コミュニケー
ション支援
タスク・イ
シュー管理
コード管理
Continuous
Integration
成果物 (コード)
Continuous
Delivery (*)
インフラ (本番)
インフラ (ス
テージング)
インフラ (開
発・検証)コード
(*)”Continuous”にしないこともある
インフラ
オーナー
インフラ
技術者
• 構文チェック
• テスト
• シミュレーション
• デプロイ用
コード生成・配置
監視
デプロイ
インフラ (サン
ドボックス)
バグ、不具合、考慮漏れ

14. なぜインフラCI/CDに取り組むのか?

15. インフラCI/CDの目的は何か
コスト削減以外の目的がありますか
インフラCI/CDの代表的な効果 -> インフラ構築・変更時の検証、デプ
ロイの工数削減と時間短縮
工数削減 -> コスト削減 というロジックが典型的だが…
そもそもインフラの検証やデプロイのコストを把握しているか？
それだけで投資効果を説明できるか？

16. • 目的があいまい問題
• 進まない、続かない

17. あくまでビジネスが先
困ってなければ価値はない
困っていることは、インフラの検証やデプロイにかかる時間、工数？
それがビジネスにインパクトを与えていれば、取り組む価値がある
(アプリやサービスをタイムリーにリリースできていない、など)
作業ミスの削減は、目的としてはインパクトが弱め
(単純な作業ミスは減るかもしれないが、新たなリスクが生まれる)
コスト削減は目的ではなく、他の目的を達成した上での成功指標
(短納期でのデリバリーを実現し、「加えて」低コスト、など)
インフラチームに閉じる効果は投資を得にくい

18. でもリーダー次第です
ビジネス的な妥当性だけでもない
意欲と行動力のあるリーダーのもとではじまり、育つ
試行錯誤をよしとするリーダー、評価者はいますか？
「挑戦」であれば人に依存して当然
仮にそのリーダーが辞めても動く組織づくりは、さらに上の人の仕事
そんなリーダーを求めて動くか、自分がリーダーになるか

19. 人と組織
Part 2

20. 誰がCI/CDパイプラインを作り、維持するのか
インフラのCI/CDであれば、Ops？
Dev
Ops
アプリ
インフラ
？

21. 誰がCI/CDパイプラインを作り、維持するのか
アプリとインフラ、それぞれにDevとOpsがいる どっちもやる人も
アプリ
インフラ
作る(Dev) 維持する(Ops)
アプリ
開発者
インフラ開発者、
SRE
アプリ
運用者
インフラ
運用者

22. 誰がCI/CDパイプラインを作り、維持するのか
CI/CDパイプラインの視点では
アプリの
CI/CDパイプライン
インフラの
CI/CDパイプライン
アプリ
開発者
インフラ開発者、
SRE
アプリ
運用者
インフラ
運用者
作る(Dev) 維持する(Ops)

23. 誰がCI/CDパイプラインを作り、維持するのか
従来の枠におさまらない役割、まだできる人が少ない
インフラが分かって、コードを書ける人
アプリの話が分かる人
ツールの目利きができる人
パイプラインの開発だけではなく維持も
SREを組織化し、そこで担当するケースも増えている
受託開発との相性は微妙 (エンドユーザーの内製中心 + 委任 はある)

24. • 少数精鋭すぎる問題
• いつもカツカツ

25. 誰かが辞めたら回らない
できる人は辞めやすい
ビジネス側が少数精鋭を期待するのは仕方ない
が、できる人が少ないだけに市場価値があり、転職しやすい
誰かが辞めた瞬間に、まずレビューが破綻
(誰も +1 してくれない)
「レビューし合える」メンバーが、3人以上は必要か
ビジネス側の期待は受け止めたうえで、現実は理解してもらう
(か、理解がある場に行く)

26. テクノロジーとツール
Part 3

27. ツール先行になりやすい
楽しいからしょうがないですよね
Ansible? Terraform? Chef? CircleCI? Jenkins? Concourse CI? VSTS?
GitHub? GitLab? Bitbucket?
流行り廃りが激しい
使ってみて「当面」信じられると感じたツールを使う
どれを使っても苦労する時は苦労するし、急に下火になりうる
「使わせる人」じゃなく、使う人が選ぶ、使う人を選定に巻き込む
選んだ人を後から非難しない

28. • Git難しい問題
• 完全に理解した -> さっぱりわからない の繰り返し

29. コード管理と共同作業は最重要課題
Your infrastructure depend on your code & collaboration
コードでインフラを表現するなら、コードの管理は最重要テーマ
現在Gitがデファクトスタンダード、が、正直難しい
多くのインフラ技術者がここでつまづく
ぼっちGit -----(高い壁、そしてマサカリ)----- チームGit
手を動かし、小さな成功体験を積んで学ぶしかない
チームは”ダイバーシティ & インクルージョン”を大切に

30. これまでの経験や経歴、得意な分野、発想、仕事に対する考
え方、価値観、ライフステージなどは十人十色。誰一人とし
て同じではないからこそ、その力を結集したときの可能性は
未知数であり無限大です。
マイクロソフトの ダイバーシティ & インクルージョン
https://www.microsoft.com/ja-jp/mscorp/diversity/default.aspx

31. コード管理: ブランチとフロー
唯一の解はない
Git Flow? GitHub Flow? GitLab Flow?
良し悪し以前にコンセプトの理解、周知が難しい
チームメンバーが理解できることが重要
(みんなが腹落ちするなら独自のやり方でもOK)
コードと環境が一致することがポイント
例: リリースバージョンごとにブランチを作り、変数で環境を分ける

32. デプロイ: 冪等性の幻滅期
理想ではあるが
冪等性はツール本体より管理対象とプラグインに依存することが多い
プラグインの中身を理解しているか？
管理対象もプラグインも人が作ったロジックの塊
管理対象の状態を内部に持つツールでは、その状態が壊れることも
リカバリー手段は用意する
新機軸: リスク高い変更時は、新しいインフラを作って切り替え

33. 戦略とデザイン
Part 4

34. ドキュメント不要論
半分賛成
コードでインフラを表現する -> ドキュメント要らないのでは？
確かに、コマンドやスクショを並べた「手順書」は要らないかも
だがコードに表現しにくいこともある、ドキュメントは必要
(設計や実装の背景や判断基準、前提条件、全体像や外部との関係は
コードで表現しにくい)
なぜこうしたか？を残すにはタスクトラッキングとコードの改変履歴
も重要
(コメントが “bug fix” だけじゃ つらい)

35. 「アジリティ」に期待してしまうこと
気持ちはわかりますが
変化を受け入れ、継続的に改善するから
さらにクラウドを使うから
「よくわからない」「決めにくい」ことは後回しでいい？
規模感、ネットワーク要件、など

36. • 決めなくていいんでしょ問題
• そんなことはありません

37. 決めることは決めましょう
はじめが肝心です
特にネットワークは設計次第ですぐに破綻
(サブネットの重複、アドレス不足、ルーティングなど)
クラウドでもキャパシティは無限ではない
(後から足しづらいリソースがあります)
規模感を合意できていないプロジェクトは、インフラだけオートス
ケールしても性能が伸びない印象
(アプリを含めた”良い”アーキテクチャは、規模感によって変わる)

38. アプリCI/CDとの大きな違い
単体テストとデプロイ時間
単体テストが難しい
変更部分に絞ったテストが難しい要素がある ネットワークが代表的
たとえばサブネットのパケットフィルタルールを変えたら、どうテストする？
(そのサブネットで動いているすべてのサービスに影響がないと言い切るには
すべてのサービスでテストしなければならない)
デプロイに時間がかかる
待ち時間が無駄なだけでない
長いデプロイ時間 -> 失敗時の戻しもそれだけ時間がかかる -> リスク

39. Subnet
監視をテストの一部とする
変更点ではなくアプリ、サービス視点でチェックする
アプリ、サービスとして正しく動いているかを監視
もし変更点が影響すれば検知できる
ステージングや開発・検証環境で影響を洗い出す
Service A
Service B
Service C
Packet Filtering
Rules
User Defined
Routes
この変更点が、動いているサー
ビスにどんな影響を与えるか、
簡単にはテストできない…
Monitoring
ポート監視
コンテンツ監視
フロー監視

40. ネットワークの「継続的」デリバリは現実的か
リスクは高い
仮想マシンやコンテナーは、デプロイに失敗しても戻しやすい、が
動いているネットワークを変更して失敗した場合、すぐに戻せるか？
仮想マシンやコンテナーの失敗は局所的だが、ネットワークは広範囲
に影響
データストアも同様
リスクを取って得られる効果とのバランス
(IaaS事業者であればとるべきリスクかもしれないが)

41. Continuous “Delusion” at the Infrastructure Layer
“Infrastructure is more sensitive to a
catastrophic change because if the
infrastructure fails, everything fails.”
Randy Bias
(http://cloudscaling.com/blog/devops/continuous-delusion-at-the-infrastructure-layer/)
Delusion = 妄想, Continuous Delusion = 継続的妄想

42. やるなら相応の投資が必要
MicrosoftはAzureの本番ネットワークを再現するシミュレータを開発
https://www.microsoft.com/en-us/research/blog/eliminating-network-downtime/
動いているネットワークの設定変更、機能追加はリスクが高い
シミュレータを使ってテストし、リスクを軽減する

43. ├── dynamic
│ ├── container.code
│ └── vm.code
└── static
├── network.code
└── datastore.code
管理単位を分ける
DynamicとStaticを分ける
頻度やライフサイクル、リスクを考慮してパイプラインを分割する
仮想マシンやコンテナーと、ネットワークやデータストアを分ける
デプロイ時間が長ければ、さらにその中で分割する

44. 基盤のアップグレード
インプレースアップグレードの是非
基盤ソフトウェアのアップグレード、どうしてますか
(OpenStack、Kubernetes、etc)
インプレースアップグレードツール、信用してますか
アップグレード作業に成功しても、新バージョンで致命的な(
影響範囲はクラスター全体になりうる
有事に誰かのせいにしても、失われたあれこれは戻ってきません

45. コアインフラの破壊的変更や
アップグレード問題を
解決する戦略

46. 基盤の維持ではなく 新に作って切り替える
「データは王様」戦略
最も動かしにくいのはデータ
データストアは独立させる
アプリもインフラも
CI/CDパイプラインがあれば
再現、テストできる
リスクある継ぎ足しCDや
インプレースアップグレードではなく
新規作成し、切り替える
王様
Current Network New Network
Traffic
Control
(例: DNS応用)
切り替え
アプリ & インフラ
CI/CD
パイプラインCluster
VM/
Containers
Cluster
VM/
Containers

47. 外部とのインターフェイスを絞る
Hub & Spoke 戦略
IPアドレスを直に使わず名前解決 絶対
外部とつなぐネットワークを集約する
ゲートウェイの類をハブに集約する
ハブにプロジェクトをつなぐ
仮想ネットワークアドレス空間が
被らないのが理想だが、
ピアリングの制御で
なんとかなることも
Hub
Network
Project A
Network
Project B
Network
Project B’
Network
External A
Network
External B
Network
Spokeごと切り替え
仮想プライベート
ネットワークの
ピアリング

48. まとめ

49. お伝えしたかったこと
「インフラの」CI/CDの現状
ツールの前に、人を知る
ツールだけじゃなく、戦略とデザインで制す
エンジョイ！

50. © Copyright Microsoft Corporation. All rights reserved.