インフラCICDの勘所

インフラCICDの勘所

1. 1. インフラCI/CDの勘所 Azureのアーキテクトが語る 真壁 徹 日本マイクロソフト株式会社 2018/08/02 Cloud Native Days Tokyo 2018 C-1-5
2. 2. 自己紹介 { “名前” : “真壁 徹(まかべ とおる)”, “所属” : “日本マイクロソフト株式会社”, “部署” : “クラウドアーキテクト技術本部”, “役割” : “クラウド ソリューションアーキテクト”, “経歴” : “大和総研 → HP Enterprise”, “特技” : “クラウド & オープンソース”, “Twitter” : “@tmak_tw” }
3. 3. お伝えしたいこと 今日は中の人というより、ユーザーと一緒にAzureを使う人として 「インフラの」CI/CDの現状 教科書的ではなく、身近な話 ズバリな答えはないけど、ヒントになりそうな話 バリバリ系というより、しみじみ系の話 (これからの人、立ち止まっている人寄り) Azureの他でも使える話
4. 4. Agenda インフラって何 人と組織 ツールとテクノロジー 戦略とデザイン
5. 5. インフラって何 Part 1
6. 6. インフラCI/CDの話をする前に みなさんのイメージする「インフラ」の範囲は？ データセンター (空調・発電設備含む) ハードウェア インフラソフトウェア・API OS・仮想マシン コンテナー ライブラリ・パッケージ アプリケーション
7. 7. インフラCI/CDの話をする前に みなさんのイメージする「インフラ」の範囲は？ データセンター (空調・発電設備含む) ハードウェア インフラソフトウェア・API OS・仮想マシン コンテナー ライブラリ・パッケージ アプリケーション アプリから見たら こうなりがち
8. 8. インフラCI/CDの話をする前に みなさんのイメージする「インフラ」の範囲は？ データセンター (空調・発電設備含む) ハードウェア インフラソフトウェア・API OS・仮想マシン コンテナー ライブラリ・パッケージ アプリケーション ネットワークや ストレージの 専門家タイプ
9. 9. インフラCI/CDの話をする前に みなさんのイメージする「インフラ」の範囲は？ データセンター (空調・発電設備含む) ハードウェア インフラソフトウェア・API OS・仮想マシン コンテナー ライブラリ・パッケージ アプリケーション ガチ
10. 10. インフラCI/CDの話をする前に みなさんのイメージする「インフラ」の範囲は？ データセンター (空調・発電設備含む) ハードウェア インフラソフトウェア・API OS・仮想マシン コンテナー ライブラリ・パッケージ アプリケーション インフラ フルスタッ(
11. 11. • 話がかみ合わない問題 • 人によって「インフラ」の範囲は違う
12. 12. インフラCI/CDの話をする前に みなさんのイメージする「インフラ」の範囲は？ データセンター (空調・発電設備含む) ハードウェア インフラソフトウェア・API OS・仮想マシン コンテナー ライブラリ・パッケージ アプリケーション 本日の範囲
13. 13. インフラCI/CDパイプライン 本日の定義 コミュニケー ション支援 タスク・イ シュー管理 コード管理 Continuous Integration 成果物 (コード) Continuous Delivery (*) インフラ (本番) インフラ (ス テージング) インフラ (開 発・検証)コード (*)”Continuous”にしないこともある インフラ オーナー インフラ 技術者 • 構文チェック • テスト • シミュレーション • デプロイ用 コード生成・配置 監視 デプロイ インフラ (サン ドボックス) バグ、不具合、考慮漏れ
14. 14. なぜインフラCI/CDに取り組むのか?
15. 15. インフラCI/CDの目的は何か コスト削減以外の目的がありますか インフラCI/CDの代表的な効果 -> インフラ構築・変更時の検証、デプ ロイの工数削減と時間短縮 工数削減 -> コスト削減 というロジックが典型的だが… そもそもインフラの検証やデプロイのコストを把握しているか？ それだけで投資効果を説明できるか？
16. 16. • 目的があいまい問題 • 進まない、続かない
17. 17. あくまでビジネスが先 困ってなければ価値はない 困っていることは、インフラの検証やデプロイにかかる時間、工数？ それがビジネスにインパクトを与えていれば、取り組む価値がある (アプリやサービスをタイムリーにリリースできていない、など) 作業ミスの削減は、目的としてはインパクトが弱め (単純な作業ミスは減るかもしれないが、新たなリスクが生まれる) コスト削減は目的ではなく、他の目的を達成した上での成功指標 (短納期でのデリバリーを実現し、「加えて」低コスト、など) インフラチームに閉じる効果は投資を得にくい
18. 18. でもリーダー次第です ビジネス的な妥当性だけでもない 意欲と行動力のあるリーダーのもとではじまり、育つ 試行錯誤をよしとするリーダー、評価者はいますか？ 「挑戦」であれば人に依存して当然 仮にそのリーダーが辞めても動く組織づくりは、さらに上の人の仕事 そんなリーダーを求めて動くか、自分がリーダーになるか
19. 19. 人と組織 Part 2
20. 20. 誰がCI/CDパイプラインを作り、維持するのか インフラのCI/CDであれば、Ops？ Dev Ops アプリ インフラ ？
21. 21. 誰がCI/CDパイプラインを作り、維持するのか アプリとインフラ、それぞれにDevとOpsがいる どっちもやる人も アプリ インフラ 作る(Dev) 維持する(Ops) アプリ 開発者 インフラ開発者、 SRE アプリ 運用者 インフラ 運用者
22. 22. 誰がCI/CDパイプラインを作り、維持するのか CI/CDパイプラインの視点では アプリの CI/CDパイプライン インフラの CI/CDパイプライン アプリ 開発者 インフラ開発者、 SRE アプリ 運用者 インフラ 運用者 作る(Dev) 維持する(Ops)
23. 23. 誰がCI/CDパイプラインを作り、維持するのか 従来の枠におさまらない役割、まだできる人が少ない インフラが分かって、コードを書ける人 アプリの話が分かる人 ツールの目利きができる人 パイプラインの開発だけではなく維持も SREを組織化し、そこで担当するケースも増えている 受託開発との相性は微妙 (エンドユーザーの内製中心 + 委任 はある)
24. 24. • 少数精鋭すぎる問題 • いつもカツカツ
25. 25. 誰かが辞めたら回らない できる人は辞めやすい ビジネス側が少数精鋭を期待するのは仕方ない が、できる人が少ないだけに市場価値があり、転職しやすい 誰かが辞めた瞬間に、まずレビューが破綻 (誰も +1 してくれない) 「レビューし合える」メンバーが、3人以上は必要か ビジネス側の期待は受け止めたうえで、現実は理解してもらう (か、理解がある場に行く)
26. 26. テクノロジーとツール Part 3
27. 27. ツール先行になりやすい 楽しいからしょうがないですよね Ansible? Terraform? Chef? CircleCI? Jenkins? Concourse CI? VSTS? GitHub? GitLab? Bitbucket? 流行り廃りが激しい 使ってみて「当面」信じられると感じたツールを使う どれを使っても苦労する時は苦労するし、急に下火になりうる 「使わせる人」じゃなく、使う人が選ぶ、使う人を選定に巻き込む 選んだ人を後から非難しない
28. 28. • Git難しい問題 • 完全に理解した -> さっぱりわからない の繰り返し
29. 29. コード管理と共同作業は最重要課題 Your infrastructure depend on your code & collaboration コードでインフラを表現するなら、コードの管理は最重要テーマ 現在Gitがデファクトスタンダード、が、正直難しい 多くのインフラ技術者がここでつまづく ぼっちGit -----(高い壁、そしてマサカリ)----- チームGit 手を動かし、小さな成功体験を積んで学ぶしかない チームは”ダイバーシティ & インクルージョン”を大切に
30. 30. これまでの経験や経歴、得意な分野、発想、仕事に対する考 え方、価値観、ライフステージなどは十人十色。誰一人とし て同じではないからこそ、その力を結集したときの可能性は 未知数であり無限大です。 マイクロソフトの ダイバーシティ & インクルージョン https://www.microsoft.com/ja-jp/mscorp/diversity/default.aspx
31. 31. コード管理: ブランチとフロー 唯一の解はない Git Flow? GitHub Flow? GitLab Flow? 良し悪し以前にコンセプトの理解、周知が難しい チームメンバーが理解できることが重要 (みんなが腹落ちするなら独自のやり方でもOK) コードと環境が一致することがポイント 例: リリースバージョンごとにブランチを作り、変数で環境を分ける
32. 32. デプロイ: 冪等性の幻滅期 理想ではあるが 冪等性はツール本体より管理対象とプラグインに依存することが多い プラグインの中身を理解しているか？ 管理対象もプラグインも人が作ったロジックの塊 管理対象の状態を内部に持つツールでは、その状態が壊れることも リカバリー手段は用意する 新機軸: リスク高い変更時は、新しいインフラを作って切り替え
33. 33. 戦略とデザイン Part 4
34. 34. ドキュメント不要論 半分賛成 コードでインフラを表現する -> ドキュメント要らないのでは？ 確かに、コマンドやスクショを並べた「手順書」は要らないかも だがコードに表現しにくいこともある、ドキュメントは必要 (設計や実装の背景や判断基準、前提条件、全体像や外部との関係は コードで表現しにくい) なぜこうしたか？を残すにはタスクトラッキングとコードの改変履歴 も重要 (コメントが “bug fix” だけじゃ つらい)
35. 35. 「アジリティ」に期待してしまうこと 気持ちはわかりますが 変化を受け入れ、継続的に改善するから さらにクラウドを使うから 「よくわからない」「決めにくい」ことは後回しでいい？ 規模感、ネットワーク要件、など
36. 36. • 決めなくていいんでしょ問題 • そんなことはありません
37. 37. 決めることは決めましょう はじめが肝心です 特にネットワークは設計次第ですぐに破綻 (サブネットの重複、アドレス不足、ルーティングなど) クラウドでもキャパシティは無限ではない (後から足しづらいリソースがあります) 規模感を合意できていないプロジェクトは、インフラだけオートス ケールしても性能が伸びない印象 (アプリを含めた”良い”アーキテクチャは、規模感によって変わる)
38. 38. アプリCI/CDとの大きな違い 単体テストとデプロイ時間 単体テストが難しい 変更部分に絞ったテストが難しい要素がある ネットワークが代表的 たとえばサブネットのパケットフィルタルールを変えたら、どうテストする？ (そのサブネットで動いているすべてのサービスに影響がないと言い切るには すべてのサービスでテストしなければならない) デプロイに時間がかかる 待ち時間が無駄なだけでない 長いデプロイ時間 -> 失敗時の戻しもそれだけ時間がかかる -> リスク
39. 39. Subnet 監視をテストの一部とする 変更点ではなくアプリ、サービス視点でチェックする アプリ、サービスとして正しく動いているかを監視 もし変更点が影響すれば検知できる ステージングや開発・検証環境で影響を洗い出す Service A Service B Service C Packet Filtering Rules User Defined Routes この変更点が、動いているサー ビスにどんな影響を与えるか、 簡単にはテストできない… Monitoring ポート監視 コンテンツ監視 フロー監視
40. 40. ネットワークの「継続的」デリバリは現実的か リスクは高い 仮想マシンやコンテナーは、デプロイに失敗しても戻しやすい、が 動いているネットワークを変更して失敗した場合、すぐに戻せるか？ 仮想マシンやコンテナーの失敗は局所的だが、ネットワークは広範囲 に影響 データストアも同様 リスクを取って得られる効果とのバランス (IaaS事業者であればとるべきリスクかもしれないが)
41. 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. 42. やるなら相応の投資が必要 MicrosoftはAzureの本番ネットワークを再現するシミュレータを開発 https://www.microsoft.com/en-us/research/blog/eliminating-network-downtime/ 動いているネットワークの設定変更、機能追加はリスクが高い シミュレータを使ってテストし、リスクを軽減する
43. 43. ├── dynamic │ ├── container.code │ └── vm.code └── static ├── network.code └── datastore.code 管理単位を分ける DynamicとStaticを分ける 頻度やライフサイクル、リスクを考慮してパイプラインを分割する 仮想マシンやコンテナーと、ネットワークやデータストアを分ける デプロイ時間が長ければ、さらにその中で分割する
44. 44. 基盤のアップグレード インプレースアップグレードの是非 基盤ソフトウェアのアップグレード、どうしてますか (OpenStack、Kubernetes、etc) インプレースアップグレードツール、信用してますか アップグレード作業に成功しても、新バージョンで致命的な( 影響範囲はクラスター全体になりうる 有事に誰かのせいにしても、失われたあれこれは戻ってきません
45. 45. コアインフラの破壊的変更や アップグレード問題を 解決する戦略
46. 46. 基盤の維持ではなく 新に作って切り替える 「データは王様」戦略 最も動かしにくいのはデータ データストアは独立させる アプリもインフラも CI/CDパイプラインがあれば 再現、テストできる リスクある継ぎ足しCDや インプレースアップグレードではなく 新規作成し、切り替える 王様 Current Network New Network Traffic Control (例: DNS応用) 切り替え アプリ & インフラ CI/CD パイプラインCluster VM/ Containers Cluster VM/ Containers
47. 47. 外部とのインターフェイスを絞る Hub & Spoke 戦略 IPアドレスを直に使わず名前解決 絶対 外部とつなぐネットワークを集約する ゲートウェイの類をハブに集約する ハブにプロジェクトをつなぐ 仮想ネットワークアドレス空間が 被らないのが理想だが、 ピアリングの制御で なんとかなることも Hub Network Project A Network Project B Network Project B’ Network External A Network External B Network Spokeごと切り替え 仮想プライベート ネットワークの ピアリング
48. 48. まとめ
49. 49. お伝えしたかったこと 「インフラの」CI/CDの現状 ツールの前に、人を知る ツールだけじゃなく、戦略とデザインで制す エンジョイ！
50. 50. © Copyright Microsoft Corporation. All rights reserved.