ソフトバンクにおける Java による クラウドネイティブの実現
0 likes872 views
CloudNative Days Tokyo 2020 発表資料
ソフトバンクにおける Java による クラウドネイティブの実現
- 1. ソフトバンクにおける Java による クラウドネイティブの実現 Shigeru Tatsuta 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. CloudNative への挑戦 事業環境の変化に伴い、事業部門との密なコミュニケーション、および スピード感が必要等のシステムの特性に応じて、最先端のアジャイル 手法や CloudNative なシステム開発も積極的に取り組んでいます。
- 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 面を用意。
- 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 の liveness Probe で再起動させるよ うに構成することでダウンタイムを最小化。 restart maintance
- 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. ご清聴ありがとうございました