「コンテナ」「Kubernetes」はコスト削減のためではない――ガートナーが語る“誤解と真実”：最も重要なのは「組織変革」（2/2 ページ）
2021年6月21〜22日にガートナーが開催した「アプリケーション・イノベーション＆ビジネス・ソリューション サミット」で、ガートナー ジャパンの桂島 航氏が「コンテナとKubernetesをITリーダーはどのように活用すべきか」と題して講演した。その内容をレポートする。
コンテナの長所が生きる所から利用を開始、成熟度に合わせてユースケースを拡大
2つ目の論点である「ITリーダーはコンテナをどのように活用すべきか」は「ユースケース」「ソリューション選択」「役割分担」という3つのポイントに整理して解説した。
まず「ユースケース」については、どのようなアプリにコンテナを利用しているかをユーザーに聞いたガートナーの調査結果がある。それによると「新しいアプリ」が72％、「マイクロサービスのアプリ」が55％、「クラウドネイティブの基盤」が51％となった。
「デジタルやAI（人工知能）、IoTといった領域でのユースケースが最も多く、マイクロサービスやクラウドネイティブなどのモード2領域での利用が続いています。一方で、レガシーアプリに適用しているユーザーはまだ少数です。このように、コンテナにあったユースケースを選んで適用していくことがポイントです」（桂島氏）
ガートナーが推奨しているのは「新規アプリ」「軽量な既存アプリのコンテナ化」「複雑な既存アプリのモダナイゼーション」の3つになる。
「メリットを享受しやすい新規アプリケーションからコンテナの利用を開始し、自社の成熟度に合わせてコンテナのユースケースを拡大していくことを推奨しています。軽量な既存アプリのコンテナ化では、開発ライフサイクルの高速化やコンテナの可搬性を生かしハイブリッドクラウド化を図ります。複雑な既存アプリのモダナイゼーションでは、レガシーアプリをサービス指向アーキテクチャに分解したり、ステートフルなアプリに対応したりしていきます」（桂島氏）
次の「ソリューション選択」は、ガートナーが提唱するコンテナ管理プラットフォームのレファレンスアーキテクチャをもとに進めていく。レファレンスアーキテクチャは、コンテナランタイム（Dockerコンテナエンジン）、コンテナオーケストレーションのKubernetes、サービスのディスカバリと登録機能、ロードバランシング機能、モニタリング機能、セキュリティ機能、ポリシー／ガバナンス機能、API機能、管理インタフェースなどで構成する。
「コンテナエンジンとKubernetesは、企業が必要とするコンテナプラットフォームの一部にすぎません。各種管理を備えたプラットフォームとしてコンテナを考えることが非常に重要です。自分たちでこれらを連携させるのは大変難しいので、これら機能をパッケージングしたクラウドサービスやソフトウェアを検討することを推奨しています」（桂島氏）
実際にコンテナプラットフォームのソリューションを選択する場合、「パブリッククラウドコンテナサービス」「コンテナ管理ソフトウェア」「PaaSソフトウェア」「自分で構築（アップストリーム）」の4つから選択することになる。それぞれ特性があるため、自社の要件に合わせて選択していく。
具体的には「運用のシンプルさ」「スピード」「包括的な管理」「ハイブリッド／マルチクラウド」「マイクロサービス、DevOpsツール統合」「柔軟性、カスタマイズ性」「コスト構造」の点から評価、検討していくことになる。
「Kubernetesはバージョンアップのライフサイクルが速いこともあり、自分たちで構築することは容易ではありません。ガートナーでは、ある程度パッケージングされたコンテナ管理ソフトウェアやPaaSソフトウェアの利用をお勧めしています。オンプレミスやマルチクラウドで同じ環境を作ることができるのもメリットです」（桂島氏）
組織の変革も重要――プラットフォームチームとSREチームで開発チームを支援する
最後の「役割分担」は、人や組織にかかるものであり、「個人的には最もここが重要だと考えている」という。
「コンテナでインフラのスピードを向上させても、アプリケーションやそれらを開発、運用する人たちがスピーディーに動くことができなければ宝の持ち腐れになります。そのため、ガートナーでは、チーム構成のベストプラクティスを提案しています」（桂島氏）
このベストプラクティスでは、複数の開発チームがそれぞれDevOpsやアジャイルな取り組みを進められるようにする一方、開発チームから独立したSREチームと、各開発チームをサポートするプラットフォームチームを設ける。各チームは、それぞれの取り組みに適した「自動化スキル」「プラットフォームスキル」「クラウドスキル」を保有する。
「プラットフォームチームとSREチームで開発チームをサポートしていきます。サポートチームは、これまでのようなサイロ化されたインフラ管理をするチームではなく、KubernetesをベースとしたPaaSを提供したり、プラットフォームを利用する際のトラブルシューティングをしてシステムの信頼性を高めたりする役割を担います」（桂島氏）
このように単にテクノロジーを採用するだけでなく、適切なユースケースを定め、それに合ったソリューションを選択した上で、ビジネススピードを高めるための適切なチームを編成していくことが重要なポイントになるわけだ。
もっとも、コンテナやKubernetesは新しいテクノロジーであり、さまざまな課題も残っている。例えば、商用アプリケーションの対応がある。コンテナ／KubernetesをサポートしているERPパッケージはほとんどない状況だ。またデータベースのようなデータを保持する必要があるステートフルアプリケーションをKubernetesで実行している事例も少数だ。
その一方で、マルチクラウドやエッジコンピューティングなどの新しい領域でKubernetesを利用しようという取り組みもスタートしているが、さまざまなベンダーが新しい機能を提供しており、発展途上にある。
「課題に対するソリューションの成熟度を見極めながら、適切なタイミングで導入していくことが重要になります。テクノロジーの進化は速いので、必要以上に課題を恐れすぎないようすることもポイントです。動向を見ながら『いま何か使えるようなものがないか』をその都度、探し、検討するといったスタンスで臨むことをお勧めします」（桂島氏）
既存アプリの9割をクラウドネイティブ化する国内先進事例も
3つ目の論点である「国内の先進事例」は、国内製造業のIoTプラットフォームにKubernetesを採用した事例を紹介した。
「IoTのような新しい領域では、コンテナ／Kubernetesのメリットが非常に生きます。クラウドサービスを採用し、変化に素早く対応できるようにし、最新のテクノロジーを使うことで、エンジニアの支持が得られやすく人材の確保もしやすいといったメリットがあったといいます。課題としては、ライフサイクルが短いことやデータベースのようなアプリの取り扱いを上げています」（桂島氏）
また、NTTドコモ サービスデザイン部の取り組み事例も紹介した。サービスデザイン部では、2019年に全システムのAWS（Amazon Web Services）移行を決定し、移行するアプリをリフト＆シフトではなく、リファクタリングする方針を打ち出している。
「AWS EC2を利用せずに、クラウドのマネージドサービスやサーバレス、コンテナを活用しています。全体の9割をそうしたクラウドネイティブに作り替えることができているといいます。成熟したチームを持つことができれば、既存のアプリをコンテナ化して、クラウドネイティブ化することができるようになってきています」（桂島氏）
桂島氏は最後に「コンテナのメリットが生きるところで利用を開始し、成熟度に合わせてユースケースを拡大していってください。その際には、インフラチーム、DevOpsチーム、アプリ開発チームが協力して、コンテナプラットフォーム戦略を策定し、自社の要件に合ったソリューションを選択します。課題を認識しつつ、テクノロジーの進化を考慮して、必要以上に恐れすぎないようにすることも重要です」と述べ、講演を締めくくった。
特集：クラウドネイティブに「一歩踏み出す」現実的な処方箋-今のスキルで乗りだす秘訣-
素早く価値を生み出すためにビジネスとITサービス開発、運用を直結させる取り組みが不可欠となる中、注目されているアプローチがスピーディーにアプリケーション＝ビジネスをデプロイし、その後も高度な変化適応力を持ちながら、安定的に運用する「クラウドネイティブ」だ。だがクラウドネイティブの実践に当たっては、コンテナ、オーケストレーション、マイクロサービスアーキテクチャなどの開発、運用技術の知識が不可欠で、人材も予算も不足する企業で全てを実践するのは難しい。本特集では、クラウドネイティブの実践に向けてどのような取り組みを進めていくべきか指南する。
Copyright © ITmedia, Inc. All Rights Reserved.