DevOpsで必要とされるエンジニアスキルの変化 / engineer skill for devops

GMO Technology Boot Camp 2020、コンテナ技術講義資料
「DevOpsと継続的デリバリーの関係性」や「技術進化によるエンジニアの担当領域の変化」など

https://techblog.gmo-ap.jp/2020/06/15/gtb_devops/

Transcript

1. DevOpsで必要とされるエンジニアスキルの変化 2020年5⽉19⽇ GMO TECHNOLOGY BOOT CAMP 平⽥ 瑞樹 GMO AD Marketing, Inc.
2. • DevOpsを実現するチームとシステム • サービスを細分化する技術 • サーバーやコンテナの制御を⾃動化する技術 • まとめ もくじ
3. ⾃⼰紹介 Mizuki Hirata @mizkich 趣味は⽝×⾞×登⼭。 Full Stack Engineer @GMO AD Marketing, Inc. Data Management Platformシステムの開発運⽤担当 (Java × Ruby× Kubernetes × BigQueryなどで構成されたシステム) 3
4. DevOpsを実現するチームとシステム
5. DevOpsの基本は⾃律的なチーム駆動開発 l DevOpsは、開発者と運⽤者の共同作業と調整を促進する⽅法論です。 l DevOpsには様々なアプローチが存在しますが、その⽬的は共通しています。 l DevOpsは、責任共有を通じて運⽤効率を向上させ、可能な限り短時間で製品やサービスを 配信することを⽬的としています。 5 要件定義 設計 開発 テスト リリース 運⽤ 改善 開発者 & 運⽤者
6. ⾃律的なチーム開発に適した⼈数 l チームが⾃律的に活動するには、1回のミーティングで全てのメンバーが⾃発的に発⾔出来る事 が好ましいとされています。 l ⾃発的な発⾔が⾃発的な⾏動に繋がり、チームのパフォーマンスの最⼤化に繋がります。 l ⾃律的なチーム開発に適した⼈数は、ピザ2枚を囲める程度(8⼈程度)と⾔われています。 6 ※ 参考: https://www.businessinsider.jp/post-34471
7. チームが責任を持てるサービスの規模 l 1サービスの開発運⽤を、複数チームではなく1チームで⾏うことが責任意識をより⾼めます。 l サービスに専属のチームを付けることで「誰かが直すだろう」の油断を減らすことができます。 l そのためには、サービスの規模が1チームで開発運⽤できる規模よりも⼩さい必要があります。 7
8. やり直しに強いサービスを作る l ⽇経コンピューターの調査では、2018年度のシステム開発の成功率は52.8％でした。 l 失敗の可能性を常に念頭に置き、失敗をやり直せることがより重要です。 l その為には⼩さな機能を段階的にリリースする、失敗と成功の積み重ねが良いとされています。 l リリースの単位を⼩さくする事は、失敗を恐れずに新しいことに挑戦しやすいメリットにもなりま す。 8 要件 定義 設計 開発 テスト ユーザ テスト 要件 定義 設計 開発 テスト ユーザ テスト 8ヶ⽉掛かるウォーターフォール型の開発では、 問題が起こったときに最⼤8ヶ⽉の⼿戻りが発⽣する。 1ヶ⽉単位のイテレート型の開発では、 問題が起こったときの⼿戻りは1ヶ⽉となる。 ※ 参考: https://business.nikkei.com/atcl/opinion/15/100753/030700005/
9. サービス間の繋がりを薄くする l 密結合なシステムでは、システム全体で開発やリリースの⾜並みを揃える必要がありました。 l この問題は、機能間の結合をネットワーク越しのI/Fに変えることで、解消することが出来ます。 l 疎結合なサービスでシステムを構成する⽅式をサービス指向アーキテクチャ(SOA)と呼びます。 9 在庫管理機能 販売管理機能 決済機能 配送管理機能 ECサイト(従来) ECサイト(SOA) 在庫管理機能 販売管理機能 決済機能 配送管理機能 在庫管理サービス 販売管理サービス 決済サービス 配送管理サービス ※ URLなどを⽤いた、ネットワーク越しの連携 ※ 同⼀プログラムからの関数呼び出しでの連携 ※ 参考: https://anond.hatelabo.jp/20111018190933
10. サービスを細分化する技術
11. リリースの⾃動化と⾼速化 l 2010年以降、ビルドからデプロイまでを⾃動化する、継続的デリバリー(CD)が普及しました。 l コンテナ普及前の当時はCDの対象はプログラムコードのみでしたが、⼿間と時間の掛かるテスト とリリースを無⼈化出来たことで、リリースサイクルの⼤幅な短縮が可能となりました。 l CDサーバーの構築には、開発者の持つプログラム構成に関する知識が必要となります。 11
12. l 2013年以降、Dockerと共にコンテナの仮想化が普及しました。 l コンテナにはOSやミドルウェアやランタイムなど、プログラム以外も載せることが出来ます。 l 継続的デリバリーによるリリース対象がコンテナへと進化したことで、開発者にはOSやミドルウェア の知識も必要とされ始めました。 コンテナの普及による継続的デリバリー範囲の拡⼤ 12 Host OS Docker Engine Guest OS Libraries Middleware Runtime Application Guest OS Middleware Runtime Application
13. モノシリックシステムからマイクロサービスへ l 2014年以降、SOAを拡張した思想、マイクロサービスが普及しました。 l マイクロサービスが唱えるサービスの単位は、「ただ⼀つのことをして、それをうまくやる」です。 l 新しい仕組みを⼀つ作るとき、開発者はプログラムに加えコンテナも作るように変化しました。 13 モノシリックなコンテナの使い⽅(古い考え) マイクロサービスなコンテナの使い⽅(新しい考え) Linux OS Docker Engine Alpha OS Linux OS Docker Engine Alpha OS JRE JRE AP Server Web Service A Web Service B AP Server Web Service A Alpha OS JRE AP Server Web Service B Alpha OS JRE Job Scheduler Alpha OS JRE Batch Program Alpha OS JRE Job Scheduler Batch Program
14. 既存機能 l ただ⼀つだけの事をするマイクロサービスは、DevOpsとの⾮常に⾼い親和性を持ちます。 l マイクロサービスの導⼊により、変化や失敗に強い、効率的な開発に適したシステムを⻑期に 渡って維持することが出来ます。 マイクロサービス化の効果 14 サービスの肥⼤化や複雑化を防ぐことができる。 ⼩さな単位(マイクロサービス)で、⾼速に開発サイクルを回せる。 ・ 局所的な開発がしやすく、開発⽣産性が⾼まる。 ・ 安定したサービスを作りやすく、サービスの再利⽤がしやすい。 モノシリック マイクロサービス ・ プロダクト成⻑に⽐例して、チームへの負担が⼤きくなることを防げる。 ・ 役割毎にサービスが分かれているため、チームで管理しやすい。 モノシリック マイクロサービス 機能追加 Aチーム担当 既存サービス 追加サービス Bチーム担当 Aチーム担当
15. サーバーやコンテナの制御を⾃動化する技術
16. マイクロサービス化に伴う弊害 l サービスが増えると、その数だけネットワークアドレスが増え、ネットワーク設定は複雑化しました。 l コンテナの数を増やすためには、複雑なネットワーク設定を更新し、その都度デプロイする必要が ありました。 LB REST AP AP REST REST LB DB Cache Cache LB LB AP DB AP モノシリックは、ネットワークの線と変化が少ない マイクロサービスは、ネットワークの線が多く、変更も多い。 16
17. コンテナ制御の⾃動化 l 2015年以降、Kubernetes(K8s)によるコンテナオーケストレーションが普及します。 l K8sは、ポッド(≒コンテナ)の状態監視とPodの増減変更を⾃動化します。 l コンテナのネットワークアドレスを任意の名称で解決できるようになり、複雑なネットワーク設定の 変更やデプロイが不要になりました。 17 ポッドオートヒーリング ・ 負荷の⾼いポッドの数を⾃動で増やし、それを認識してくれる。 ・ 負荷の低いポッドの数を⾃動で減らし、それを認識してくれる。 ・ エラーの出たポッドを、システムから⾃動で切り離してくれる。 ・ エラーの出たポッドを、⾃動で再起動してくれる。 ポッドオートスケーラー Kubernetesの機能は、他にも多々あります。 SVC α POD β POD α POD α POD β POD β SVC β 再起動 接続断 SVC α POD β POD β SVC β POD α POD α POD α POD β POD α 追加 追加 削除
18. サーバー構築の⾃動化 l 2017年以降、GCPやAWSなどのクラウド環境でもK8sを利⽤可能になりました。 l クラウド環境のK8sは、ノード(≒サーバー)の状態監視と増減も⾃動化することが出来ます。 l オンプレ環境でのポッドオートスケールは、増やせるポッドの数に上限がありました。 l クラウド環境では、ポッドに連動してノードの数も増減するため、ポッドの数に上限がありません。 18 クラスタオートスケーラー ノードプロビジョニング Pod 追加 Pod 追加 ・ Pod追加時、既存のNodeのCPUやMemoryに空きが無い場合、 Nodeを新規に構築してくれる。 ・ Node追加時、予め選択していたリソースや割引契約を考慮し、 要求に合うサーバーを⾃動で調達してくれる。 リージョン: vCPU: RAM: 割引契約: 東京 2 core 14 G 継続割(30%OFF) リージョン: vCPU: RAM: 割引契約: ⼤阪 2 core 30 G プリエンプティブ割(75%OFF) 新規Node ⾃動調達 新規サーバ ⾃動調達 空き 空き
19. l K8sの構成情報は、ファイルにコードとして保存することが出来ます。(=IaC) l コードとして保存することで、ゼロから無⼈でシステムを構築することも可能となります。 l クラウド環境など、コードでの保存に対応していないサービスでも、Terraformなどのプロビジョニ ングツールを導⼊することで、コードでの管理とCDが可能となります。 設計をコードで管理する 19 Cloud SQL BigQuery Kubernetes Engine Kubernetes Engine Google Cloud Platform Terraform定義 K8s 定義 Dockerfile GitHub Jenkins Terraform Versioning Coding Provisioning CI/CD
20. まとめ
21. DevOpsの⽬標はスタートアップの⽣産性 l DevOpsは、肥⼤化したシステムを抱える企業が、スタートアップのような少数先鋭での変化に 強いチーム開発を⼿に⼊れるための⽅法論です。 l システムが⼤規模になるほど、DevOpsの実現には多くの技術導⼊と改⾰が必要とされます。 l システムが⼩規模なら、まずはマイクロサービスを実現し、システムの成⻑に備えるべきです。 21
22. 運⽤コストと学習コストを秤に掛ける l K8sや継続的デリバリーの実務利⽤には、準備として⾼い学習コストが必要となります。 l 学習に掛けるコストが軽減できる運⽤コストを上回ってしまわぬ様に、システムやエンジニアの⾝ の丈に合った無駄のない技術選定が必要とされます。 l DevOpsの実現には、システムの成⻑に合わせて適切な技術を選定する、新しい技術を習得 する習慣も必要とされます。 22
23. 完