Download as PDF, PPTX
ソフトバンクにおける Java による クラウドネイティブの実現
- 1. ソフトバンクにおける Java による クラウドネイティブの実現 ShigeruTatsuta 2020/09/09 CloudNative Days Tokyo 2020
- 2. 自己紹介 竜田 茂 (たつたしげる) ソフトバンク株式会社 テクノロジーユニット IT＆ネットワーク統括 IT 本部 前職の日本オラクルでは Java アプリケーションサーバ製品の技術サポートを 担当。 2013 年よりソフトバンクに参画し、Java ミドルウェア製品の全社導入支援、お よびリアルタイム処理基盤 Chronos-Core プロジェクト、IBM との提携にともな い IBM Watson のローカライズにも参画。 現在はプロフェッショナルなテクノロジー集団の実現を目指して、Java での CloundNative な開発を推進中。
- 3. ソフトバンクの IT 本部について IT本部はいわゆる情報システム部門で、主に通信事業に必要な IT サービスを提供するためシステムを開発・運用しています。 IT 本部のシステムの多くは Java で開発されています。
- 4.
- 5.
- 6. Azure Kubernetes Service Azure/Kubernetes の採用 運用担当者の負荷の低減、若手エンジニアの技術力向上を狙い、 Azure、およびKubernetes を採用。 全国のソフトバンクショップのスマホアドバイザー業務を支援するシステ ムにおいて、すでに 1 年近く稼働。Kubernetes に起因する大きな障害 はなし。
- 7. Azure Kubernetes Serviceの主な特徴 Azure Kubernetes Service の特徴は以下のとおり。 ● コントロールプレーンは Azure で無償で提供され、Kubernetes ノードの VM に対してのみ課金 ● コントロールプレーンの SLA は 99.5% で Uptime SLA を購入する と、99.9 - 99.95% が保証 ● Kubernetes クラスタの構築は Azure CLI でコマンドで簡単に構築 可能 ● Azure Application Gateway と連携するための、Application Gateway Ingress Controller (AGIC) ● Azure Container Instances (ACI) を利用した Virtual Node への Pod のデプロイ
- 8. システムの構成 システムの構成としては、状態は Redis に保持してコンテナはステート レスに実装するベーシックな構成。Kubernetesのバージョンアップ、万 が一の待機面として、Blue/Green 面の 2 面を用意。
- 9.
- 10. リリース作業の省力化 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
- 11. 切り戻しの省力化 リリース作業で問題が発生した場合、最悪は以前のバージョンに切り 戻し作業を実施していたが、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
- 12. 縮退リリースの省力化 オンライン時間帯にリリースが必要な場合は、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 下に戻す
- 13. FeatureFlag と Kubernetes Gitのブランチ戦略としては、Trunk ベース開発を採用している。メイン ブランチ一本のため、FeatureFlag でプロダクションに出ていくコードを 制御しています。Kubernetes のマニフェストの環境変数で FeatureFlag の切り替えが手軽に実現。 ############################################## # 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
- 14. Full GC による障害 ヒープを激しく消費する処理を実行すると、ヒープが枯渇してFull GC 頻発状態となり、システムは応答不可となり、これまでは大障害となっ ていたが、Kubernetes では Liveness Probe によってコンテナが再起動 されて自動で復旧される。 restart Full GC 頻発
- 15. restart restart データベースのメンテナンス クラウドのデータベースを使用しているため、メンテナンス作業でノード がフェイルオーバーされ、フレームワークのデータソースが使用不可能 になる課題があった。Kubernetes の livenessProbe で再起動させるよ うに構成することでダウンタイムを最小化。 restart maintance
- 16.
- 17. Backend ヘルスチェックによる高負荷 Readiness Probe に、RDBMSにクエリを投げるようなエンドポイントで ヘルスチェックを実施していたが、Pod の数が多いと、RDBMS に DDoS 攻撃をしているような状態になり、却ってアンヘルシーに・・・。 Frontend 日本 東南アジア アメリカ西海岸 アメリカ東海岸 ヨーロッパ
- 18. 小さな Java プロセス大きなJava プロセス JVM チューニングの転換 これまでのアプリケーションサーバ上での可動を前提した大きな Java プロセスから、アプリケーションをコンテナにパッケージして、 Kubernetes デプロイするため、GC、ヒープサイズ等、JVM のチューニ ングの転換が必要。 App App App App App App App App App App many core/big heap few core/small heap
- 19. Direct buffer に起因するOOM Eden Survior From To Tenured Metaspace Compressed Class Space Code Cache Stack Direct Buffer C heap Java heap Native memory コンテナ化で Java プロセスのヒープが小さくなる一方で、最近のフレー ムワークでは Netty など Direct Buffer を積極的に使用するものが多 く、Direct buffer に起因する OOM が起きやすい。
- 20. まとめ 「本当にあなたのシステムで Kubernetes は必要なのか？」という意見 もあるが、以下の理由でお薦めであった。 1)開発が開発作業の片手間で運用できるほどに、運用負荷が大きく 軽減される 2) RollingUpdate など、オンライン時間帯の積極的なリリースが可能と なる。 3) アプリケーションサーバ時代と比べると、コンテナの中の JDK など の MW のバージョンアップが開発側でコントロールできる。 4) これまでの大障害に繋がっていた障害も Kubernetes によって自動 で復旧できる可能性がある 5) 最新の技術に触れることで、若手エンジニアのやる気の向上
- 21.