Recommended
More Related Content
What's hot
What's hot (20)
Similar to Kubernetes 導入から始める DevOps について
Similar to Kubernetes 導入から始める DevOps について (20)
Recently uploaded
Kubernetes 導入から始める DevOps について
- 1. Kubernetes 導入から始める DevOps について Shigeru Tatsuta 2021/04/15 DevOpsDays Tokyo 2021
- 2. 自己紹介 竜田 茂 (たつた しげる) ソフトバンク株式会社 テクノロジーユニット コンシューマ IT 本部 前職の日本オラクルでは Java アプリケーションサーバ製品の技術サポートを 担当。 2013 年よりソフトバンクに参画し、Java ミドルウェア製品の全社導入支援、お よびリアルタイム処理基盤 Chronos Core プロジェクト、IBM との提携にともな い IBM Watson のローカライズにも参画。 現在はプロフェッショナルなテクノロジー集団の実現を目指して、Agile や CloudNative などのモダンなシステム開発を推進中。
- 3. ソフトバンクの IT 部門について ソフトバンクの IT 部門はいわゆる情報システム部門で、主に通信事業 に必要な IT サービスを提供するためシステムを開発・運用していま す。 ソフトバンクの IT 部門のシステムの多くは Java で開発されています。
- 5. モダンなシステム開発への挑戦 事業環境の変化に伴い、事業部門との密なコミュニケーションが必要 なシステム等のシステムの特性に応じて、最先端の Agile 手法や CloudNative 等のモダンなシステム開発に積極的に取り組んでいます。
- 7. 開発と運用組織 ソフトバンクの IT 部門では、IT 統制の観点から開発と運用が組織レベ ルで分かれています。 開発組織 運用組織 ユーザのためにいち 早く機能をデリバリー したい。 障害ゼロを達成するた めに、余分なリリース はしたくない DevOps の実現には様々な障壁が・・・
- 8. 運用組織の課題 運用組織では、運用担当者あたりのシステム数が多く、リアクティブな 定形業務に追われがちで、プロアクティブな作業にさける時間が少な く、社員のスキルアップ、キャリア形成に課題を抱えていました。 ログの抽出 アプリのデプロイ LB からの切り離し サーバー再起動 AP サーバ再起動 アプリの切り戻し
- 9. Azure Kubernetes Service Azure/Kubernetes の導入 全国のソフトバンクショップにて、スマホ教室を開催しているスマホアド バイザー業務を支援するシステム開発において、若手エンジニアの技 術力向上を狙い、Azure/Kubernetes を導入。 2019/12 に MVP をリリース、1 年半ほど追加開発・運用
- 12. システムの構成 システムの構成としては、コンテナはステートレスに実装し、状態は Redis に保持するベーシックな構成。Kubernetes のバージョンアップ、 万が一の待機面として、Blue/Green 面の 2 面を用意。
- 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. 切り戻しの省力化 リリース作業で問題が発生した場合、最悪は以前のバージョンに切り 戻し作業を実施していたが、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. 縮退リリースの省力化 オンライン時間帯にリリースが必要な場合は、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. 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. Full GC による障害 ヒープを激しく消費する処理を実行すると、ヒープが枯渇して Full GC 頻発状態となり、システムは応答不可となり、これまでは大障害となっ ていたが、Kubernetes では Liveness Probe によってコンテナが再起動 されて自動で復旧される。 restart Full GC 頻発
- 18. ログの調査 これまではサーバごとにログファイルを取得して調査していたが、コン テナのログはすべて Azure Monitor に収集され、サーバーに入らなくと もログが参照可能となり、また横断的にクエリも可能となった。 Azure Kubernetes Service Node Node Node Metrics Logs Azure Monitor
- 19. Azure/Kubernetes 導入によって得られた知見 Azure/Kubernetes の導入によって、これまで開発が運用に依頼してい た定形作業が、開発作業の片手間で実施できるほどまでに、運用負荷 が大きく軽減。 # 主な運用作業 導入前 導入後 1 アプリケーションのリリース作業 30 分 10 分 2 リリース時のアプリケーションの切り戻し 30 分 10 分 3 オンライン時間中の縮退リリース 30 分 10 分 4 障害発生時のアプリケーションサーバの再起動 手動再起動 自動回復 5 障害発生時のサーバの再起動 手動再起動 自動回復 6 障害発生時のログの抽出 1 時間 オンデマンド
- 25. ソフトウェアデリバリのパフォーマンス これらの取り組みによって、現状ミディアムパフォーマー相当であると考 えられるが、さらに運用との協業を推進し、ハイパフォーマーに近づけ て行きたい。 ハイ パフォーマー ミディアム パフォーマー ロー パフォーマー デプロイの頻度 オンデマンド (1 日複数回) 週 1 日から月 1 日 週 1 日から月 1 日 変更のリードタイム 1 時間未満 1 週間から 1 ヶ月 週 1 日から月 1 日 MTTR (平均修復時間) 1 時間未満 1 日未満 1 日から 1 週間 変更失敗率 0 - 15% 0 - 15% 31 - 45%
- 26. まとめ Kubernetes の導入当初は DevOps を目標にしていた訳ではなかった。 1) Kubernetes 導入によって、それまでの運用の定形作業が大きく削 減され、より高度な運用が必要とされる状況となった。 2) 運用担当者が開発スキル、業務知識を身につけることで、よりプロ アクティブな運用業務が実施可能となった。 3) 運用がスクラムイベントに参画するなど、開発と運用との連携が密 となり、DevOps が副次的に促進された。 Kubernetes の導入によって、運用作業が質的に変化し、 結果として DevOps が促進される
- 27. ご清聴ありがとうございました