成功への道を切り開くには、開発者に柔軟な環境を与え、ネットワーキング戦略を進化させる必要がありますが、非現実的な期待を抱かないことも重要です。

今日ではコンテナそのものに加え、Kubernetesの登場に最大の関心が集まっていて、それらは最も影響力のあるITテクノロジーとなっています。コンテナによって企業は、迅速なアプリケーション構築、プラットフォーム間でのワークロードの移植、環境の最適化などを実現する、素晴らしい能力を手に入れられます。

コンテナを適切に利用すれば、組織は新たな俊敏性を得られ、チームはこれまでにない速さでソリューションを構築できます。しかし、新しいテクノロジーを導入したことがある人なら誰もがわかるように、その道のりは必ずしも平坦ではありません。このブログでは、コンテナ化の取り組みに着手するときに避けるべき落とし穴を順に見ていきます。

1. 開発者の俊敏性を抑制しない。開発者は素晴らしいソフトウェアを生み出したいと考えており、快適な環境で作業できることを求めています。開発者の適応が必要となる構造を生み出すのではなく、Kubernetesクラスターをパブリッククラウド、コアデータセンター、エッジに構築できるツールを提供しましょう。

2. コンテナとVMを同じように扱わない。コンテナは、仮想マシンと同様の重要な機能を果たすこともあります。しかしVMとは技術的背景が異なるため、必要なスキルセットも異なります。VMは廃れません。メインフレームが今でも管理されているように、私たちは引き続きVMを管理する必要があります。VMは何年も利用され続けるでしょう。コンテナはVMとは異なるものであり、新しい方法でのソフトウェア開発を可能にします。ステートフルアプリとステートレスアプリ、データの持続性、従来型とクラウドネイティブ型の開発プロセスなどについて重要な違いを知り、そうした違いを組織で活用しましょう。

コンテナ導入の現状: 課題と機会

3. 可能な場合、常にベンダーロックインを避ける。これはわかりきったことかもしれません。コンテナ戦略を特定のクラウドサービスで開発したり、戦略の一環として、あるクラウドサービスを利用したりしている場合、そうした公開形態を最小限にとどめます。クラウドプラットフォームを1つだけ採用したときに誰もが犯した失敗を教訓にしましょう。オープンソースのコミュニティを受け入れて、アプリケーションを移植できるツールを活用します。俊敏性を将来も維持するために重要なのは、アプリケーションを別のプラットフォームに移植できることです。

4. コンテナプラットフォームで生成されるデータの量を過小評価しない。コンテナのノード数は、今管理しているVMの数よりも少なくなります。しかし、新しいコンテナプラットフォームのコンプライアンスを管理し維持するには、膨大な量のテレメトリデータが必要であり、そうしたデータには、異なるツールセットと異なるデータ管理機能が必要となります。

5. 新しいコンテナ戦略には既存の運用モデルで対応できると期待しない。きわめて多数の仮想化ユニット (コンテナ) を管理している場合、チケットに基づいた実証済みのエスカレーションプロセスであっても、稼働に関わる膨大な量の変更には対応できません。そのためには自動化が必要です。新しい運用モデルに対応可能な自動化の仕組みを開発できるように、サイトリライアビリティエンジニア (SRE) チームを発足させる準備を整えましょう。

6. 旧来のファイアウォールネットワーキングセグメンテーション戦略が新しいコンテナモデルにも通用すると考えない。非常に多くのノード同士が、さまざまなプラットフォームで通信し合っており、旧来のVM管理の新しいファイアウォールガバナンスルールでは対応が困難です。より多くのネットワークデバイスが相互通信できるように、新たなネットワーキング戦略を策定する必要があります。

7. 開発チームがKubernetesのバージョン導入で一貫性を維持できることを期待しない。Kubernetesはオープンソースのプラットフォームであり、サポートされるのは常に3つの公開バージョンです。オープンソースコミュニティによって新しいバージョンがリリースされると、以前のバージョンは期限切れになります。そのため、各クラスターに対して、そのほかの開発用クラスターとは別に、アップグレードパスの管理と制御を計画する必要があります。これを行うには、各種プラットフォームで実行されるKubernetesディストリビューションのさまざまなバージョンを管理できるコントロールプレーンが必要になります。

8. 開発チームがコンテナ戦略として採用するクラウドプラットフォームは1つだけだと考えない。チームは同じ考えでまとまっていて、開発者たちは、さまざまなクラウドプラットフォームだけでなく、オンプレミス環境を操作するスキルも備えています。あなたが、どのような構造であれ、彼らが望む実行可能なKubernetesコンテナプラットフォームを用意したいと考えるなら、その仕事に対応できるコントロールプレーンが必要になります。

9. 経営陣がこの新しいパラダイムを理解できることをしばらくは期待しない。コンテナ化は、非常に高度なテクノロジーです。Kubernetesとコンテナが開発されてしばらく経ちますが、転換点を迎えたのはここ数年のことです。「理解している」と言っていても、戦略の策定について納得する前に、まず基本的な説明を求める経営陣が少なくありません。時間をかけて説明しましょう。そうすることで、あなたと経営陣とチームのそれぞれが恩恵を享受できます。

10. Kubernetesにすべてを求めない。世界平和の実現、パン焼き、子どもの世話、そしてレガシーITの問題解決。Kubernetesではこれらをどれ一つ解決できません。現実的な問題解決を期待しましょう。コンテナなら、非常に多くのレガシーアプリケーションを実行できます。しかし、すべてのアプリケーションが実行可能とは限らず、実行できないものもあります。それらをコンテナに移行する費用は妥当な額を超えてしまいます。投資に適さないこうしたレガシーアプリケーションのために、VMベースのインフラストラクチャを長期間保持できるようにしておきましょう。

11. 導入したKubernetesを簡単に拡張できると考えない。Kubernetesは、拡張も管理も簡単ではありません。また、これまでにないほど大量のデータを生成します。さらにあなたは、Kubernetesクラスターを、ネットワークに接続しているかどうかがわからないエンドポイントデバイスにプッシュしたいと考えるでしょう。これらが新たな課題となります。Kubernetesエコシステムは、まだほんの初期段階にあるのです。

12. コンテナの無秩序な拡散が治ることを期待しない。パブリッククラウドがシャドーITと呼ばれていた頃を思い出してください。開発者は、自分のクレジットカードを使って新たな環境を用意していました。今ではオンプレミスでもこうした行動が見られます。コンテナを幅広く利用したいと考えている彼らの希望を叶えてあげる必要があります。展開先、タイミング、対象プラットフォームのいかんにかかわらず、彼らの望みに即してコンテナとともにKubernetesクラスターを展開しましょう。そのためには、そうした方針に対応可能なコントロールプレーンとデータファブリックが必要です。今後もコンテナの無秩序な拡散に備えましょう。

13. スキル不足の程度を過小評価しない。コンテナの将来性は誰もが認めます。しかし現在、経験豊かな人材が非常に不足しており、進化途上にあるこのテクノロジーを十分に活用するには至っていません。コンテナ、大規模なKubernetes、エッジでのコネクテッドデバイスは、ITインフラストラクチャにおいて達成すべき最後の領域とも言えます。コンテナベースのテクノロジーの知識を持つ人材を引き付けるためだけでなく、既存のスタッフのそうした重要なスキルを向上させるために、リソースに投資しない組織は、後々苦労することになります。

 

成功へのロードマップ

コンテナ化の時代が到来しました。コンテナ化は、世界中の業界で、組織にとっての価値を高めます。ベストプラクティスの採用で成果を上げ、その取り組みの間に落とし穴を避けられる組織は、後れを取った組織よりも圧倒的に優位に立つことができます。

_{この記事/コンテンツは、記載されている特定の著者によって書かれたものであり、必ずしもヒューレット・パッカード エンタープライズの見解を反映しているわけではありません。}