プロダクト運用のCloudOps化に伴うジレンマ

CLOUD OPERATOR DAYS TOKYO 2020 にて発表

Transcript

1. プロダクト運⽤の Cloud Ops化に伴う ジレンマ - The Cloud Operatorʼs Dilemma -
2. AXLBIT Inc. 熊⾕ 育朗(AXLBIT 株式会社) • 業務内容︓ プロダクトマネージャ（⾃称） • 経歴 アプリケーション開発 ->パッケージ導⼊担当 -> -> ミドルウェア・運⽤設計担当 -> クラウドインフラ研究開発 を経て現職 ⾃⼰紹介 2
3. AXLBIT Inc. • 第１章 ショートストーリー 〜 クラウドオペレーション Small Start • 第２章 クラウドオペレーション移⾏のジレンマ • 第３章 クラウドオペレーションは必要か • 第４章 どうしたら良いのか 今⽇話したいこと 3
4. AXLBIT Inc. 第１章 ショートストーリー クラウドオペレーション Small Start 4
5. AXLBIT Inc. • この話は実体験を基にしたフィクションです。脚⾊があります。 Cloud Operationを⽬指す物語 5
6. AXLBIT Inc. • 主⼈公はDev } Cloud Operation推進派（個⼈の思いが強い） } ビジネス課題や計画策定に疎い、技術知識先⾏ } B to Bのサービスには数社の既存ユーザー 既存ユーザーからの機能追加要望、新規案件の獲得のための追加必須機能要求が⼭積み 開発速度の向上が主たる業務 } 開発部員の⼤半はミドルウェア構成に疎い • 現⾏のサービス運⽤はOpsが管理 } VMを主体とした運⽤で、可⽤性はもっぱらVMwareのHAに依存 } Ansibleを使⽤した⾃前ツールでの構築、リリース管理 } 開発の容易さを優先したモノリシックなサーバ構成（ただしミドルウェア構成は複雑） } 開発環境をOpsが払い出して使う。リソースは有限 設定 6
7. AXLBIT Inc. 当初状況 7 開発チーム インフラ管理チーム 開発環境サーバ 管理 共 有 共 有 複雑なミドルウェアスタックの All in one ノード Mail DB AMQP Batch Web APP Event Log 複雑なミドルウェアスタックの All in one ノード ス Mail DB AMQP Batch Web APP Event Log 複雑なミドルウェアスタックの All in one ノード Mail DB AMQP Batch Web APP Event Log 案件担当 設定確認や バグ確認に環境ください ソース修正 だけしたい 環境は有限です。⼤事に使って。 構築は３営業⽇くらい掛かります Cloud Ops やりたい︕
8. AXLBIT Inc. Case1 課題︓開発環境の衝突 8 開発チーム インフラ管理チーム 開発環境サーバ 管理 共 有 共 有 案件担当 バグの確認します 設定変更の 確認します 案件毎にサーバつくってるので そこで開発してね 新しい機能の 開発おねがいします。 機能Aの 動作確認します 機能Bの テストします 新機能開発 はまだ無理です
9. AXLBIT Inc. Case1 対応: 開発環境⽤のDockerイメージ化 9 https://speakerdeck.com/kumagai19o/ansible-kara-docker-hefalseshi-jian-ji • 既存のAnsibleを実⾏した作成したコンテナイメージの作成
10. AXLBIT Inc. Case1 成果: (⼀部の)ローカル環境での開発が可能に 10 複雑なミドルウェアスタックの All in one ノード Mail DB AMQP Batch Web APP Event Log • 構築したイメージでのローカル開発 新機能 先⾏して開発します 開発環境サーバ 共 有 共 有 案件担当 バグの確認します 設定変更の 確認します 新しい機能の 開発おねがいします。 機能Aの 動作確認します 機能Bの テストします 1GBのイメージとかｗ （闇の声） Mr.Dilemma
11. AXLBIT Inc. Case1 まとめ 開発作業の管理環境からの分離 11 課題︓開発者毎に実⾏環境がない • 状況 } 開発したい機能の数に対して開発環境が⾜りない } 新しいサーバを⽴てるためにはOpsとの調整が必要。ただし数⽇かかる。 } 機能の開発内容は数⽇単位で⼊れ替わる • やったこと } 既存のAnsibleを実⾏して作成したコンテナイメージの作成 • 成果 } ⼀部メンバーは開発環境の制約なく開発作業が可能に
12. AXLBIT Inc. 新しく参加します Dockerってなんですか PCが重い 12 Case2 課題︓イメージの横展開とチームの習熟 複雑なミドルウェアスタックの All in one ノード Mail DB AMQP Batch Web APP Event Log これを使って開発 しましょう Dockerが インストールできません 管理のコマンドが⾜りな いんだけど SSHできない やめよう。。 開発、 前より遅くないですか
13. AXLBIT Inc. Compute Engine Case2 対応︓Cloud 環境VMでのコンテナイメージ展開 13 複雑なミドルウェアスタックの シングルテナントサービス Mail DB AMQP Batch Web APP Event Log テンプレート化 各⾃⾃分で 起動 コンテナ に直接SSH コマンドで 初期化 起動やデータの セットアップは⼿動で 個人開発環境 Compute Engine AllinOne 個人開発環境 Compute Engine AllinOne 個人開発環境 Compute Engine AllinOne 個人開発環境 Compute Engine AllinOne 個人開発環境 Compute Engine AllinOne Mr.Dilemma コンテナにssh??ダサ
14. AXLBIT Inc. 各開発メンバーにコンテナイメージ上での開発を展開する 課題 } 開発メンバーのPCにDockerが⼊らない -> PC管理ツールと社内ポリシー } Docker環境の操作⽅法がわからない } 環境構築に関する知識の不⾜ 解決策 } クラウド環境上でのコンテナ環境起動のテンプレート化 } ssh接続でのコンテナ利⽤ Case2 まとめ 開発現場の拡⼤ 14
15. AXLBIT Inc. Case3 課題︓社内の⾮開発者向けの環境整備 15 個人開発環境 Compute Engine AllinOne 個人開発環境 Compute Engine AllinOne 個人開発環境 Compute Engine AllinOne 個人開発環境 Compute Engine AllinOne GCEで提供 インフラ管理チーム 開発環境サーバ 管理 その他メンバー 案件担当 環境は⾜りてます 欲しい時に作ります メンバーも案件も増えた 起動したままで 必要な時に使いたい 起動とかの設定はして欲しい 共 有 共有 そんなにたくさんは 管理できません
16. AXLBIT Inc. Kubernetes Engine Case3 対応︓社内の⾮開発者向けの環境整備 16 その他メンバー 案件担当 案件1共有環境 Container Engine Container 案件2共有環境 Container Engine Container バージョン1共有環境 Container Engine Container バージョン2共有環境 Container Engine Container 個人開発環境 Container Engine ContainerVM 複雑なミドルウェアスタックの シングルテナントサービス Mail DB AMQP Batch Web APP Event Log GKEで提供 Kubenetes のManifestを 作成し、依頼毎に ⼀括作成シェルを⼿動起動 Mr.Dilemma ⼿運⽤してて草
17. AXLBIT Inc. ⾮開発者の社内メンバーへの環境提供 課題 } 増える社内の⾮開発者への環境提供 } ⼀度構築した環境が維持されている必要がある 解決策 } Kubernetes 上でのコンテナ提供 残課題 } 増えていく環境の管理 Case3 まとめ︓社内の⾮開発者への環境提供 17
18. AXLBIT Inc. Case4 課題︓増えていく環境への対応 18 個人開発環境 Compute Engine AllinOne 個人開発環境 Compute Engine AllinOne 個人開発環境 Compute Engine AllinOne 個人開発環境 Compute Engine AllinOne Compute Engine 案件1共有環境 Container Engine Container 案件1共有環境 Container Engine Container 案件1共有環境 Container Engine Container Kubernetes Engine 管理、⼤変だな
19. AXLBIT Inc. Case4 対応︓管理作業の⾃動化 19 Google App Scriptを使った 情報取得と⾃動削除等の管理 個人開発環境 Compute Engine AllinOne 個人開発環境 Compute Engine AllinOne 個人開発環境 Compute Engine AllinOne 個人開発環境 Compute Engine AllinOne Compute Engine 案件1共有環境 Container Engine Container 案件1共有環境 Container Engine Container 案件1共有環境 Container Engine Container 案件1共有環境 Container Engine Container 案件1共有環境 Container Engine Container Kubernetes Engine 情報取得 Mr.Dilemma ダッシュボート 使わないの︖
20. AXLBIT Inc. • 課題︓開発関連の各種⼿順の⾃動化 } 増加する環境の管理 • 対応 } 管理表が⽬に⾒える形で⾃動更新されるように対応 } 無駄なインスタンスの削除なども⾃動で⾏われるように制御 Case4 課題︓環境管理の⾃動化 20
21. AXLBIT Inc. Case5 課題︓様々な業務の効率化 21 イメージ作成 ドキュメント ⽣成 ⾃動テスト
22. AXLBIT Inc. Case5 対応︓各種作業の⾃動化 22 バージョン毎イメージ作成 Cloud Build Build image 自動テスト Cloud Build Auto test アドホックに ⾃動化プロセスを作成 作成時期ごとに異なる⼿法 マニュアル自動生成 Circle CI Build manual Gear-Image Container Registry Test Result Cloud Storage
23. AXLBIT Inc. Case5 残課題 23 メンテが不⼗分 ⾃動化のフローや内容が 不⾜すると⼗分な効果がない 改善したいが、メンテが⼤変。。 バージョン毎イメージ作成 Cloud Build Build image 自動テスト Cloud Build Auto test マニュアル自動生成 Circle CI Build manual Gear-Image Container Registry Test Result Cloud Storage トリガの発⽣が アドホック 内容が充実しない 属⼈化してるぞ Mr.Dilemma
24. AXLBIT Inc. Case5 残課題対応︓CI/CD フロー策定と共有 24 フローの全体での理解を進める フィードバックを強化する
25. AXLBIT Inc. • 課題︓開発関連の各種⼿順の⾃動化 } マニュアルHTML化等の⼿動運⽤の排除 ▪ Sphinx形式で作成されたマニュアル⽣成の⾃動化 } イメージ作成⾃動化 ▪ バージョンアップ毎のイメージ作成の⾃動化 } テスト⾃動化 • 対応と残課題 } テストや開発環境の⾃動化を動かすことは少⼈数でも可能 } ただしそれぞれの作業の品質は内容しだい。 ⾃動化だけでなく内容が重要。フィードバックを厚くする必要がある Case5 まとめ︓開発に関わる運⽤作業の⾃動化 25
26. AXLBIT Inc. Case6 課題︓モノリシック to マイクロサービス 26 複雑なミドルウェアスタックの シングルテナントサービス Mail DB AMQP Batch Web APP Event Log Kubernetes Engine Back (Statefull) DB AMQP Log Mail Batch Event Web APP Front (Deployment) Web APP Front (Deployment) Web APP Front (Deployment) マイクロサービス化 するぞ
27. AXLBIT Inc. Case6 ・・・︓マイクロサービス化。。 27 Kubernetes Engine Back (Statefull) DB AMQP Log Mail Batch Event Web APP Front (Deployment) Web APP Front (Deployment) Web APP Front (Deployment) ・・・ ・・・ ・・・ まだ早い・・・ スケール しないじゃん Mr.Dilemma
28. AXLBIT Inc. 現⾏同様踏襲のうえで 改善されるポイントを教えてください。 移⾏はどうする︖ 管理が⼤変 Case7 課題︓ Container化した本番運⽤の⽴てつけ 28 ログはどうする︖ 監視はどうする︖ セキュリティは︖ 本番運⽤も コンテナ化 してはどうでしょう メリットは︖ Ansibleでできてますよ。 サービス要件は︖ どこのクラウドでやったらいいかな GCPは開発チームしか使ってない
29. AXLBIT Inc. Case7 対応︓現⾏踏襲した本番運⽤ 29 複雑なミドルウェアスタックの シングルテナントサービス Mail DB AMQP Batch Web APP Event Log VPC 運⽤は現⾏踏襲で コンテナ化しましょう Cloud Ops って なんなんだ。。 Mr.Dilemma
30. AXLBIT Inc. Case7 本当は、、: サービス要件の定義とSLA化 30 どうやってやるか 調べないと、、 仮想化基盤の HAで担保します VMのスケールアップ でできる範囲で 可⽤性は 性能は ネットワークを 分離している 可⽤性10倍 リリース時間 1/5 サービス要件は︖ イメージ管理は︖ セキュリティは︖ 可⽤性もリリース時間も 問題になっていない 機能追加が遅いのを改善して 現⾏同様踏襲のうえで 改善されるポイントを 教えてください。
31. AXLBIT Inc. 新たな課題︓本番運⽤とのギャップが増⼤すると 31 • ⼤きすぎるギャップによる渋滞 ＝ 開発できてもリリースできない
32. AXLBIT Inc. 俺たちの戦いはこれからだ︕ 先⽣の次回作にご期待ください 32
33. AXLBIT Inc. 第２章 CLOUD OPS 移⾏のジレンマ 33
34. AXLBIT Inc. ジレンマ ある問題に対して2つの選択肢が存在し、そのどちらを選んでも何らかの 不利益があり、態度を決めかねる状態。葛藤。 34 (di-lemma)
35. AXLBIT Inc. Cloud Operation の導⼊にまつわる2つの選択肢 } やるべきか。やらざるべきか。(Pros Cons) } 現⾏運⽤ ( 既存踏襲か ⼀新か ) } 先導役 ( Dev⼿動 か Ops⼿動か ) 2つの選択肢︖ 35
36. AXLBIT Inc. Pros Cons のジレンマ Pros • 可⽤性 • スケーラビリティ • 分散構成が容易 • リリースの⾃動化 Cons • 学習コスト • 構成の複雑化による管理コストの増 ⼤ • 移⾏コスト • 場合によっては組織構成の⾒直し 36
37. AXLBIT Inc. Pros Cons のジレンマ(Prosの議論) Pros • 可⽤性 • スケーラビリティ • 分散構成が容易 • リリースの⾃動化 Cons • 学習コスト • 構成の複雑化による管理コストの増 ⼤ • 移⾏コスト • 場合によっては組織構成の⾒直し 37 ⾃動化できるリリースフローになっているか Ansibleで⼗分じゃないのか 分散を想定したアーキテクチャになっているか 開発者が対応できるか 満たすべき可⽤性⽬標 HAで⼗分じゃないか スケールさせるべき理由はあるのか サービスの利⽤状況と必要性 ビジネス側の要求が⾼いほど導⼊のメリットが⼤きい 担当者がProsConsを書き出しても判断がつかない。
38. AXLBIT Inc. Pros Cons のジレンマ(Consの議論) Pros • 可⽤性 • スケーラビリティ • 分散構成が容易 • リリースの⾃動化 Cons • 学習コスト • 構成と管理⼿法の複雑化 • 移⾏コスト・リスク • 開発組織構成の⾒直し 38 既存メンバーのタスク、スキル構成 いつまでにやるか。⽬標が⽴てられるか リスクを判断できるか コンテナ技術の習熟を徹底できるか 全体にどうやって習熟させるか ⾃動化や最新のツール群の習熟が必要 ⾃動化した場合は品質（テスト）も重要 メンバーの意欲とスキルが⾼いほど導⼊のコストが低いが 組織全体への浸透が求められる
39. AXLBIT Inc. Pros Cons のジレンマ Pros • 可⽤性 • スケーラビリティ • 分散構成が容易 • リリースの⾃動化 Cons • 学習コスト • 構成の複雑化による管理コストの増 ⼤ • 移⾏コスト • 場合によっては組織構成の⾒直し 39 • ビジネス側の要求が⾼い(売れている)ほどメリットが⼤きい • 売れているサービスの管理者ほど余裕時間は少ない
40. AXLBIT Inc. ジレンマを抱える層 40 導⼊メリット ⾼い 低い メンバスキル 意欲 ⾼い 低い 不要 導⼊必⾄ ジレンマ 代替⽅法 検討 クラウド ネイティブ
41. AXLBIT Inc. Pros Consのジレンマ 41 導⼊必⾄ • ビジネス側の要求が⾼くスキルが⾼い クラウドネイティブ • サービスの価値向上を進める ジレンマを抱える層 • サービスの成⻑スピードと 組織の成⻑スピードのバランスに悩む 代替⽅法あり • VMwareなどのHAを備えた基盤での運⽤も検討 不要 • リスクやコストを取る必要はない。
42. AXLBIT Inc. 既存運⽤ (踏襲か⼀新か） 既存運⽤の現場 • ⼿動オペレーション前提の運⽤ } ⼿順書ベースの作業と⽬視確認 • 問題を起こさないことを第⼀とした 可⽤性設計 • 管理省⼒化のためのPet運⽤ Cloud Operationでの運⽤ • ⾃動化前提の運⽤ } コード化された作業とテスト • 問題発⽣を前提とした可⽤性設計 • 管理や監視を⾃動化したCattle運⽤ 42
43. AXLBIT Inc. 既存運⽤ (踏襲か⼀新か 43 • リスクを抑えたいと考えたら現⾏運⽤を踏襲したい • 現⾏運⽤を踏襲したら効果は半減 • 変更に伴うリスクにどこまで対応すべきかを決めたい • しかし、守るべきサービスレベルがわからない。
44. AXLBIT Inc. 先導役のジレンマ Ops先導のCloud Ops化 • 現状優先 • 今守っているものを実現させたい • 穏やかに着地させたい Dev先導のCloud Ops化 • 技術先⾏ • ⾃動化のために例外的な運⽤を排除 したい • 劇的な改善を図りたい 44 ※個⼈の感想です
45. AXLBIT Inc. 先導役のジレンマ 45 • Cloud Opsの技術の習得やコード化は開発者の⽅が得意 • 劇的な改善を志向するとリスクは⼤きくなる
46. AXLBIT Inc. 第３章 イノベーションのジレンマ 46
47. AXLBIT Inc. ジレンマ ある問題に対して2つの選択肢が存在し、そのどちらを選んでも何らかの 不利益があり、態度を決めかねる状態。葛藤。 47 (再掲)
48. AXLBIT Inc. ジレンマといえば 48 Clayton M. Christensen. イノベーションのジレンマ 増補改訂版 (Harvard business school press) (Japanese Edition) 翔泳社.
49. AXLBIT Inc. イノベーションのジレンマ } 持続的イノベーション (Sustainable Technologyによる イノベーション) } 破壊的イノベーション (Disruptive Technologyによるイ ノベーション) 49 業界で主要な地位を占める企業が、既存の顧客の意見に耳を傾け、 さらに既存の製品サービスを改善して高品質の製品サービスを 提供することに注力していくことで（これ自体は正しくみえるのに）、 既存の業界構造を破壊するイノベーションに立ち後れ、失敗を招く
50. AXLBIT Inc. 技術のSカーブ •持続的イノベーション •破壊的イノベーション 50 Clayton M. Christensen. イノベーションのジレンマ 増補改訂版 翔泳社.
51. AXLBIT Inc. 成果実現スケジュールイメージ 51 0 5 10 15 20 25 30 35 40 45 50 1年目 2年目 3年目 4年目 5年目 6年目 7年目 8年目 9年目 10年目 既存運用 CloudOps • この期間をどう計画して乗り越えるか • このような成果をどう可視化するか(成果なしの期間をどう過ごすか
52. AXLBIT Inc. 第４章 どうしたらよいのか ⼀現場の⼈間としての考察 52
53. AXLBIT Inc. • 破壊的な改善を⽬指すためにコストをかけてやる } Continues Deliveryを実現したい } ⾼可⽤性を保証したい( 99.9 -> 99.999へ ) } スケーラビリティを確保したい • 逆に⾔えば不要なもしくはできないケース状況は多い } そのサービスでまだ必要性がない } 移⾏のリスクは⼤きい。リスクを犯したくない } 勉強したくない } 今の仕事をこなすだけで精⼀杯の現状では計画さえ危うい Cloud Operationを⽬指すに⾜る理由 53
54. AXLBIT Inc. • メンバーのリテラシー・学習コスト • 時間をかけるか⼈を採⽤するか • 現場での必要性の議論 • 現場の課題解決議論は漸進的なもの(Sustainable) • （時間がない）同じ担当者に両⽅を求めるのは酷 • 達成したい⽬標に対して最適な実現⽅法を検討する • X⼈で何を実現したいのかを議論 • クラウドペレーションが必要な場合 • 現⾏の運⽤で⼗分な場合 • 安全な移⾏とクリティカルパスの認識 } ⼤きすぎるギャップは事故の元 乗り越えるためのポイント 54
55. AXLBIT Inc. • 誰がやる︖ } インフラ担当者がプログラミングを覚える or ソフトウェアエンジニアがインフラを覚える or ⼀緒にやる -> DevOps • 共通の⽬標にむかって意識を合わせる⼟壌の醸成が⼤事 } サービスとして達成すべき⽬標 とは } サービス運⽤要件でありそれがSLAと結びつくのがやっぱり理想に思えます 鍵はやっぱりDevOps 55
56. AXLBIT Inc. DevのやりたいCloud Opsイメージ 56 ここはGplangで ここはServerlessで ここはKVSで ここはPaasで テストも⾃動化できる そう、クラウド環境ならね • 実現したいこと } 開発環境の変化のスピードの最⼤化 • ⼿法 } CI/CDパイプライン } ⾃動テスト
57. AXLBIT Inc. Cloud Operatorなら（希望） 57 ここはGplangで ここはServerlessで ここはKVSで ここはPaasで テストの⾃動化と リリースの⾃動化も連携できる そう、クラウド環境ならね これはコンテナで これはFunctionsで これはPaasで そのまま使おう Dev Ops
58. AXLBIT Inc. SRE 58
59. AXLBIT Inc. ジレンマ ある問題に対して2つの選択肢が存在し、そのどちらを選んでも何らかの 不利益があり、態度を決めかねる状態。葛藤。 59 (再掲)
60. AXLBIT Inc. • 担当者なら } 個⼈としてやりたくなったら、、逸脱が必要 ▪ ⾃分で始める or 余裕時間で始める ▪ 成果を上げる計画が⽴てられればチャレンジ ▪ 会社の⽬指す⽅向性とあっているか、あっていなければ会社からの逸脱が必要かもしれない } 上司の指⽰でやることになったなら、、 ▪ Zoomを作るとしたらで⾒積もって、的な無茶振りじゃないか考えてみよう どうすべきか - 役割別アドバイス 60
61. AXLBIT Inc. • 提案するなら } 権限の及ぶ範囲でのCloud Operation技術を活⽤しながら成果を上げる。 これぞ腕の⾒せ所 } ただ、ビジネス的な要求がないなら、売れるサービスを作る⽅が先 • 上からの指⽰なら } 意図を理解して、最適な成果を最適な時期に挙げる。 • いずれにせよ } うまくいっているうちに切り替えなければ、後から抜かれる。 （抜かれないサービスなら必要ない） 危機感を持って取り組まなければ。 } とはいえ現場は⽬の前に理解できる成果がないと切り替わらない 技術理解と計画作成、そして周囲を納得させる成果 管理者なら 61
62. AXLBIT Inc. すべての創造は「たった⼀⼈の熱狂」からはじまる 最後に 62 Cloud Operationを始めたいけど 始められないすべての 担当者に贈る言葉 引用：たった一人の熱狂 仕事と人生に効く51の言葉 見城徹著