フォーム読み込み中
前回の記事「CNAPで実現するプラットフォームエンジニアリング:Kubernetesの真価を引き出す鍵(vol.2)」では、開発者の認知負荷を軽減し、優れた開発体験を実現するための中核技術であるKubernetesと運用課題を解説し、その運用課題をソフトバンク開発の「Cloud Native Application Platform(CNAP)」が肩代わりすることで、プラットフォームエンジニアリングを加速させることを紹介しました。
今回の第3弾では、CNAPが提供する具体的な機能とその導入によって得られる効果に焦点を当てます。そして、実際の導入事例を通じて、ソフトバンクが実現するプラットフォームエンジニアリングについて詳しく解説します。
CNAPは、誰もが再現性の高いインフラ運用を実現できるプラットフォームです。ここでは、CNAPが提供する主要な機能とその特徴を紹介します。詳細な技術情報は、CNAP Technical Document(ユーザードキュメント)を参照してください。
※1 お客様のクラウド環境にリモートからデプロイします。
※2 Kubernetes APIとマニフェストのAPIバージョンの整合性は構成テンプレートによってCNAP側で担保します。
開発者視点からCNAPを一言で表すなら「インフラ知識を持たないアプリケーション開発者でも、ローコードでインフラ環境を容易に管理できるKubernetesベースのプラットフォームサービス」です。CNAPを活用したアプリケーションとインフラ全体の管理イメージを以下に示します。
図の左上のアプリケーション開発者は普段使い慣れたエディタやGitの操作だけで、アプリケーションコードとインフラ構成の双方を一貫して管理できます。開発者はすでにこれらの操作に習熟しているため、その強みを活かし、アプリケーションだけでなくインフラもセルフサービスで管理できる仕組みが提供されます。これにより、学習コストを最小限に抑えつつ、俊敏な開発を実現します。
ここで言う「インフラ」は Kubernetes クラスタそのものに留まらず、PaaS、ネットワーク、ストレージといった周辺のクラウドリソースを含む広範な概念を指します。CNAPの基盤には Kubernetes 上で動作するコントローラー群が組み込まれており、これらが周辺リソースを含めたインフラのライフサイクルを自動で管理します。開発者は 宣言的な YAML で記述するだけで、アプリケーションとインフラの望ましい状態を定義することが可能になります。
CNAPのコストメリットを説明するために、ここでは一般的なインフラ管理パターンと比較しながら、CNAPの管理パターンがどのような優位性を持つのかを解説します。
一般的に採用されている以下の3つのパターンを基に比較を進めます。
パターン1:最も簡易な方式
管理対象とUI(操作方法)
パターン2:TerraformやCDツールを活用
管理対象とUI(操作方法)
パターン3:開発者ポータルを活用
管理対象とUI(操作方法)
コンテナアプリをKubernetes上で動作させる場合、インフラ知識が少ない開発者はまず「パターン1」から試すのが一般的です。しかし、GUIやCLIベースでの管理に限界を感じ始めると、IaC(Infrastructure as Code) に取り組む「パターン2」へと移行します。
さらに、近年のプラットフォームエンジニアリングの潮流に沿って、プラットフォームチームが開発者ポータルを全社的に提供し、「パターン3」が採用されるケースが増えています。
これらの各パターンの特徴とメリット・デメリットを以下の表にまとめました。比較検討のため、CNAPの管理パターンを「パターン4:構成テンプレートを活用」としています。
| パターン | 概要 | SSoT | メリット | デメリット |
|---|---|---|---|---|
| 1 | 最も容易な方式 CLIやGUIを直接操作する方式。習熟度の高い開発者にはフレキシブル | ✖️ |
|
|
| 2 | TerraformやCDツールを活用 Terraformによる初期構築と、GUIによる日常運用の併用 | △ |
|
|
| 3 | 開発者ポータルを活用 開発者ポータルを介した標準化されたテンプレートを通じてデプロイ | ⚪︎ |
|
|
| 4 | 構成テンプレートを活用 ローコードのGitOpsにより、標準化されたテンプレートを通じてデプロイ | ◎
|
|
|
ここで、長期的な運用負荷を軽減する上で重要なポイントが、Single Source of Truth (SSoT)を如何に維持できるのかという点です。
ITライフサイクル全体において、運用フェーズが最もコストを消費します。CNAPでは、これまでのクラウド構築・運用の豊富なノウハウに基づき、開発者による運用のあるべき姿を追求し、以下の5つの方針を掲げました。これにより、「パターン4:構成テンプレートを活用」という最もメリットの大きい効率的な運用を実現しています。
| No | 方針 | 説明 |
|---|---|---|
| 1 | Single Source of Truth(SSoT)の担保は「仕組み」で維持する |
|
| 2 | UIの分断を発生させない | K8sはコードエディタ、PaaSはクラウドコンソールといったようにインフラ管理のUIが複数存在すると、ツール毎のプロセスフロー整備やその学習コストといった負荷が発生する。単一のUIに集約することで、認知負荷を削減する。 |
| 3 | ドキュメントと実態との乖離を発生させない | GUIでの緊急操作を行った場合、パラメーターシートなど設定記録の更新漏れが発生し、後工程でレビューや監査が困難となる。GUIは読み取り専用用途(モニタリング・トラブル対応)に限定し、本番設定は全てGit管理(構成テンプレート、マージレビュー)に一本化すべき。 |
| 4 | 環境のスケーラビリティと再現性を重視する | 開発環境/本番環境の差異はバグ・障害の要因となり得るため、テンプレートにより複数環境を同一パターンで生成できるようにする。 |
| 5 | 緊急時運用に備えた「例外対応」の設計 | 現実的な考慮として、GitOpsなどによる宣言的制御では、緊急時の即時操作が困難になるケースがある。「一時的な手動操作 → Gitに差分反映」という例外フローを許容する。 |
これらの比較を踏まえ、実際にどれだけのコストメリットがあるのかを以下の図に示します。この図は「パターン2:TerraformやCDツールを活用」と「パターン4:構成テンプレートを活用」における、アプリケーションとインフラ管理の全ライフサイクルにわたる作業内容と、それにかかる費用を算出したものです。
※コスト算出は、当社のデリバリー実績を基に試算。中規模程度のアプリケーションと複数のPaaSを含むKubernetes環境のインフラを想定し、黒字「パターン2」と、CNAP管理パターンの青字「パターン4」でのコストを比較。
まず、CI/CD基盤の初期開発フェーズについてです。CIパイプラインの設定は、アプリケーション開発者側で行う必要がありますが、CNAPをお申し込みをいただいた後の初期開通時にインフラのGitOps環境が準備されるため、このフェーズのコストを約1/3に削減できます。
アプリケーションの初期開発フェーズにおいては、アプリケーションコードの記述自体には、共通基盤としてのCNAPは関与しないため、この部分での直接的な削減効果はありません。(CNAPのスコープ外の領域です)。
インフラの初期開発フェーズに関してです。基本設計はインフラチームが担当する必要がありますが、パッケージ化された構成テンプレートはプラットフォームチームから提供されます。これにより、インフラチームが独自に構成テンプレートを準備する必要がなくなるため、このフェーズのコストを約半分に削減できます。
運用コストには特に大きな削減効果が期待できます。まず、アプリケーション運用においては、開発者自身がセルフサービスでインフラを調達できるようになることで、インフラ調達にかかる待ち時間を大幅に短縮します。これにより、アプリケーションのリリース速度が向上し、結果としてアプリケーション運用コストを約30%削減できます。
そして、最も効果が大きいのがインフラ運用です。Kubernetesの煩雑な運用を全て共通基盤側、すなわちプラットフォームチーム側で引き取ることが可能となるため、この部分のコストを約1/5に削減することが可能となります。
図中の赤枠で囲まれた部分をご覧いただくと、運用コストの削減効果が際立って高いことがお分かりいただけるでしょう。これこそがCNAPの真価であり、前述した長期的な運用負荷を軽減する上で極めて重要な要素である、SSoTを担保する仕組みが、この大幅な削減効果を実現しているのです。
逆に、IaCのSSoTが維持できなくなると、プラットフォームの信頼性や再現性が損なわれ、運用が不安定化し、結果として長期的なコストが肥大化してしまうリスクがあります。
ここまでCNAPの特徴や仕組みを紹介してきました。では実際に導入すると、どんな変化が起きるのでしょうか?
最後に、CNAPが現場で生み出している成果を示す3つの導入事例をピックアップしてご紹介します。
QRコードソリューション「Qプラットフォーム」や食堂自動精算システム「DECSSY」では、運用の複雑さとリリース頻度の低さが課題でした。CNAPの導入により、GitOpsによる構成管理と自動デプロイを実現。結果、リリース頻度は年3~4回から10回以上に増加し、クラウド版DECSSYのデプロイも従来の約0.5人月から「1~2時間」へ大幅短縮されました。
→ Qプラットフォーム | DECSSYの事例はこちら
画像認識AIサービス「レコメンドアイ」の基盤を構築する際、信頼性と柔軟性の高いインフラが求められました。CNAPとGoogle Kubernetes Engineを組み合わせることで、マルチクラウド戦略を実現。MSPパートナー支援のもと、効率的な運用と迅速なサービス展開を可能にしました。
→ 画像認識AIプラットフォームの事例はこちら
従来の問い合わせ管理システムでは、インフラ構築や運用に多くの時間と手間がかかり、リリースが遅延する課題がありました。CNAPを導入し、Azure Kubernetes ServiceやFlux CDを活用することで、構築・デプロイを自動化。結果、開発者自身がセルフサービスでリリース可能となり、開発スピードと運用効率が飛躍的に向上しました。
→ LINEを活用した開発の事例はこちら
CNAPがもたらす革新的なアプローチを全3回にわたってご紹介してきました。第1弾ではインフラ管理の課題とプラットフォームエンジニアリングの概念を、第2弾ではKubernetesの真価を引き出す鍵としてのCNAPの役割を解説し、そして最終回となる本稿では、CNAPの具体的な機能、顕著なコストメリット、そして導入企業の成功事例を通じて、その実用性と効果を深く掘り下げました。
CNAPは、単なるツールではなく、複雑なインフラ管理をシンプルにし、開発者が本来の価値創造に集中できる環境を提供するソリューションです。SSoTを担保する仕組みと、ローコードでのインフラ管理は、貴社の運用コストを劇的に削減し、開発スピードとビジネスの俊敏性を飛躍的に向上させるでしょう。
ご紹介した株式会社デンソーウェーブ様、JTP株式会社様、株式会社ソフトバンクの自社事例が示すように、CNAPは多様な業界でその効果を発揮しています。貴社が抱えるインフラ管理の課題も、CNAPが解決へと導きます。
この機会に、貴社のビジネスにCNAPがどのような変革をもたらすか、具体的なご相談を通じて検討してみませんか。
CNAPにご興味をお持ちいただけた方は、ぜひお気軽にお問い合わせください。
CNAPの導入が、貴社の成長を加速させる次のステップとなることを願っています。
CNAPは標準化されたアプリケーション実行環境を手軽に利用できるサービスです。リリースプロセスを自動化し、開発者自身がセルフサービスで実行環境を準備できるようになります。
Microsoft Azureは、Microsoftが提供するパブリッククラウドプラットフォームです。コンピューティングからデータ保存、アプリケーションなどのリソースを、必要な時に必要な量だけ従量課金で利用することができます。
MSP(Managed Service Provider)サービスは、お客さまのパブリッククラウドの導入から運用までをトータルでご提供するマネージドサービスです。
条件に該当するページがございません