Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Kubernetes 導入から始める DevOps について

DevOpsDays Tokyo 2021 発表資料

  • Be the first to comment

  • Be the first to like this

Kubernetes 導入から始める DevOps について

  1. 1. Kubernetes 導入から始める
 DevOps について
 Shigeru Tatsuta
 2021/04/15 DevOpsDays Tokyo 2021

  2. 2. 自己紹介
 竜田 茂 (たつた しげる)
 
 ソフトバンク株式会社
 テクノロジーユニット コンシューマ IT 本部
 
 前職の日本オラクルでは Java アプリケーションサーバ製品の技術サポートを 担当。
 
 2013 年よりソフトバンクに参画し、Java ミドルウェア製品の全社導入支援、お よびリアルタイム処理基盤 Chronos Core プロジェクト、IBM との提携にともな い IBM Watson のローカライズにも参画。 
 
 現在はプロフェッショナルなテクノロジー集団の実現を目指して、Agile や CloudNative などのモダンなシステム開発を推進中。 

  3. 3. ソフトバンクの IT 部門について
 ソフトバンクの IT 部門はいわゆる情報システム部門で、主に通信事業 に必要な IT サービスを提供するためシステムを開発・運用していま す。
 ソフトバンクの IT 部門のシステムの多くは Java で開発されています。

  4. 4. 通信事業を支えるシステム
 通信事業のシステムはユーザーの皆さまの生活を支える重要なインフ ラであるため、これまでは自社のデータセンターのオンプレミスな環境 でウォーターフォール等の重厚な堅牢・堅実なシステム開発がメインで した。

  5. 5. モダンなシステム開発への挑戦
 事業環境の変化に伴い、事業部門との密なコミュニケーションが必要 なシステム等のシステムの特性に応じて、最先端の Agile 手法や CloudNative 等のモダンなシステム開発に積極的に取り組んでいます。

  6. 6. Kubernetes を導入前

  7. 7. 開発と運用組織
 ソフトバンクの IT 部門では、IT 統制の観点から開発と運用が組織レベ ルで分かれています。
 開発組織
 運用組織
 ユーザのためにいち 早く機能をデリバリー したい。
 障害ゼロを達成するた めに、余分なリリース はしたくない
 DevOps の実現には様々な障壁が・・・

  8. 8. 運用組織の課題
 運用組織では、運用担当者あたりのシステム数が多く、リアクティブな 定形業務に追われがちで、プロアクティブな作業にさける時間が少な く、社員のスキルアップ、キャリア形成に課題を抱えていました。
 ログの抽出
 アプリのデプロイ
 LB からの切り離し
 サーバー再起動
 AP サーバ再起動
 アプリの切り戻し

  9. 9. Azure 
 Kubernetes
 Service
 Azure/Kubernetes の導入
 全国のソフトバンクショップにて、スマホ教室を開催しているスマホアド バイザー業務を支援するシステム開発において、若手エンジニアの技 術力向上を狙い、Azure/Kubernetes を導入。
 2019/12 に MVP をリリース、1 年半ほど追加開発・運用

  10. 10. Azure/Kubernetes の導入の狙い
 Azure/Kubernetes の各種自動化機能による徹底的にトイルを削減し たシステムを開発し、運用負荷の低いシステムを提供することで、運用 担当者の負担を軽減し、プロアクティブな作業に費やせる時間を捻出 する。
 リアクティブな作業
 プロアクティブ な作業
 リアクティブな作業
 プロアクティブな作業

  11. 11. Kubernetes を導入してみて

  12. 12. システムの構成
 システムの構成としては、コンテナはステートレスに実装し、状態は Redis に保持するベーシックな構成。Kubernetes のバージョンアップ、 万が一の待機面として、Blue/Green 面の 2 面を用意。

  13. 13. リリース作業の省力化
 v1.0.0
 v1.1.0
 v1.2.0
 apiVersion: apps/v1 
 kind: Deployment 
 metadata:
 name: frontend 
 namespace: defalt 
 spec:
 replicas: 20 
 strategy:
 type: RollingUpdate 
 rollingUpdate: 
 maxUnavailable: 25% 
 maxSurge: 0 
 template:
 spec:
 containers: 
 - name: frontend 
 image: myregistory.azurecr.io/sample/frontend:1.1.0 
 これまでのリリース作業ではアプリケーションサーバごとに war/ear を デプロイしていたが、Kubernetes ではマニフェストを用意して kubectl を apply するだけでよくなった。
 Azure Container 
 Registory
 Azure Kubernetes 
 Service
 Node
 Node
 Node
 apply

  14. 14. 切り戻しの省力化
 リリース作業で問題が発生した場合、最悪は以前のバージョンに切り 戻し作業を実施していたが、Kubernetes では以前のバージョンのコン テナに戻すだけ。
 v1.0.0
 v1.1.0
 v1.2.0
 apiVersion: apps/v1 
 kind: Deployment 
 metadata:
 name: frontend 
 namespace: defalt 
 spec:
 replicas: 20 
 strategy:
 type: RollingUpdate 
 rollingUpdate: 
 maxUnavailable: 25% 
 maxSurge: 0 
 template:
 spec:
 containers: 
 - name: frontend 
 image: myregistory.azurecr.io/sample/frontend:1.0.0 
 Azure Container 
 Registory
 Azure Kubernetes 
 Service
 Node
 Node
 Node
 apply

  15. 15. 縮退リリースの省力化
 オンライン時間帯にリリースが必要な場合は、LoadBalancer から切り 離してデプロイ、動作確認してから、LoadBalancer 下に戻すという作業 を実施していたが、Kubernetes の Rolling Update でコマンド一発でよく なった。
 AP Srv
 AP Srv
 AP Srv
 AP Srv
 AP Srv
 AP Srv
 deploy
 AP Srv
 AP Srv
 AP Srv
 LB から切り離し
 デプロイ&動作確認 
 LB 下に戻す

  16. 16. FeatureFlag の実現
 Kubernetes のマニフェストの環境変数で FeatureFlag の切り替えが手 軽に実現。Feature レベルでリリースが制御できるため、リリースの失 敗も大きく低減された。
 ############################################## 
 # Feature Flag 
 ############################################## 
 feature.searchCustomer=${SEARCH_CUSTOMER_FEATURE_FLAG:true} 
 feature.recentUsingSearch=${RECENT_USING_FEATURE_FLAG:true} 
 application.properties 
 containers:
 - name: frontend 
 image: myregistory.azurecr.io/spad/frontend:1.0.0 
 env:
 - name: JAVA_TOOL_OPTIONS 
 value: -XX:+UseContainerSupport -XX:InitialRAMPercentage=50 ... 
 - name: SPRING_PROFILES_ACTIVE 
 value: pr 
 - name: SEARCH_CUSTOMER_FEATURE_FLAG 
 value: "true" 
 - name: RECENT_USING_FEATURE_FLAG 
 value: "false" 
 kubernetes の yaml 

  17. 17. Full GC による障害
 ヒープを激しく消費する処理を実行すると、ヒープが枯渇して Full GC 頻発状態となり、システムは応答不可となり、これまでは大障害となっ ていたが、Kubernetes では Liveness Probe によってコンテナが再起動 されて自動で復旧される。
 restart
 Full GC 
 頻発

  18. 18. ログの調査
 これまではサーバごとにログファイルを取得して調査していたが、コン テナのログはすべて Azure Monitor に収集され、サーバーに入らなくと もログが参照可能となり、また横断的にクエリも可能となった。
 Azure Kubernetes 
 Service
 Node
 Node
 Node
 Metrics
 Logs
 Azure Monitor 

  19. 19. Azure/Kubernetes 導入によって得られた知見
 Azure/Kubernetes の導入によって、これまで開発が運用に依頼してい た定形作業が、開発作業の片手間で実施できるほどまでに、運用負荷 が大きく軽減。
 #
 主な運用作業
 導入前
 導入後
 1
 アプリケーションのリリース作業 
 30 分
 10 分
 2
 リリース時のアプリケーションの切り戻し 
 30 分
 10 分
 3
 オンライン時間中の縮退リリース 
 30 分
 10 分
 4
 障害発生時のアプリケーションサーバの再起動 
 手動再起動
 自動回復
 5
 障害発生時のサーバの再起動 
 手動再起動
 自動回復
 6
 障害発生時のログの抽出 
 1 時間
 オンデマンド

  20. 20. Kubernetes 導入によって
 もたらされた DevOps

  21. 21. 開発主導による運用の模索
 運用の定形作業が自動化によって、大きく軽減したことにより、運用を 介さなくとも様々な作業が可能となり、開発主導の運用が模索され始め る。
 開発組織
 運用組織
 この調子でガンガ ン自動化してトイ ルを削減だ!!
 あれっ!?

  22. 22. 運用の開発への留学
 運用の定形作業が自動化によって、大きく削減された状況を踏まえ、 運用から開発に社員が留学し、共にシステム開発を行い、業務知識、 開発スキルを身につける取り組みが行われる。
 開発組織
 運用組織
 開発教えて下さ い。

  23. 23. 付加価値の高い運用作業の実現
 運用担当者がシステムの業務知識、開発スキルを身に付け、ソース コードを参照して運用を行えることによって、より付加価値の高いス ピーディーな運用が可能となった。
 開発組織
 運用組織
 見える、私にもロ グが見えるぞ!

  24. 24. 運用担当者がスプリントプランニング、スプリントレビューなどのイベン トに同席することで、これまでになく開発と運用が密に連携できるように なり、我々なりの DevOps が見えてきた。
 運用担当者のスクラムイベントへの参画
 PO
 フィードバック
 フィードバック
 アドバイザー
 お客さま
 開発
 運用

  25. 25. ソフトウェアデリバリのパフォーマンス
 これらの取り組みによって、現状ミディアムパフォーマー相当であると考 えられるが、さらに運用との協業を推進し、ハイパフォーマーに近づけ て行きたい。
 
 ハイ
 パフォーマー
 ミディアム
 パフォーマー
 ロー
 パフォーマー
 デプロイの頻度
 オンデマンド
 (1 日複数回)
 週 1 日から月 1 日
 週 1 日から月 1 日
 変更のリードタイム
 1 時間未満
 1 週間から 1 ヶ月
 週 1 日から月 1 日
 MTTR
 (平均修復時間)
 1 時間未満
 1 日未満
 1 日から 1 週間
 変更失敗率
 0 - 15%
 0 - 15%
 31 - 45%

  26. 26. まとめ
 Kubernetes の導入当初は DevOps を目標にしていた訳ではなかった。
 1) Kubernetes 導入によって、それまでの運用の定形作業が大きく削 減され、より高度な運用が必要とされる状況となった。
 
 2) 運用担当者が開発スキル、業務知識を身につけることで、よりプロ アクティブな運用業務が実施可能となった。
 
 3) 運用がスクラムイベントに参画するなど、開発と運用との連携が密 となり、DevOps が副次的に促進された。
 Kubernetes の導入によって、運用作業が質的に変化し、
 結果として DevOps が促進される

  27. 27. ご清聴ありがとうございました


×