HCL Accelerate on Kubernetes: あるいは、私はいかにして心配するのをやめて、自動化されたコンテナ・オーケストレーションを愛するようになったか
2022/5月/20 - 読み終える時間: 2 分
HCL Accelerate on Kubernetes: あるいは、私はいかにして心配するのをやめて、自動化されたコンテナ・オーケストレーションを愛するようになったか
2022年5月19日
著者: William Federkiel / HCL Accelerate Software Engineer
最近、コンテナ化は至る所で見られるようになり、技術者は組織でそれを採用しようと躍起になっています。しかし、コンテナ化とはいったい何なのでしょうか？実際に有益なのか、それとも単なる流行なのか？それを活用する最良の方法は何でしょうか？そして最も重要なことは、それが HCL Accelerate とどのように関係しているのかということです。
コンテナ。それはあなたの両親のタッパーウェアとは違うもの
ある意味、コンテナは仮想マシンに似ていると考えることができます。その環境では、外部のものに影響を与えることなく、また影響を受けることなく、ソフトウェアを実行することができる分離された環境です。しかし、従来の仮想マシンには多くの欠点があります。その主な原因は、各仮想マシンで完全なオペレーティングシステムを実行することによるオーバーヘッドにあります。これに対してコンテナは、ホストマシン、つまりコンテナ化プラットフォームを実行するマシンのカーネル（ほとんどの場合、Linux）を共有します。そのため、前述のような重複を最小限に抑えることができ、リソースの利用効率がかなり高くなります。
しかし、より具体的には、コンテナ化にはどのようなメリットがあるのでしょうか。答えはいろいろありますが、最も基本的な利点は、アプリケーションをデプロイする環境が予測可能で、絶対的な一貫性を持つようになることです。アプリケーション開発者は、依存関係からシステム構成まで、ソフトウェアを実行するために必要なすべてを指定し、そのすべてがコンテナ・イメージに組み込まれます。ユーザーがアプリケーションをデプロイするときには、イメージをデプロイするだけで、必要なことはすべて自動的に処理されます。アプリケーションサーバーを設定したり、クラスパスを設定したり、ポートマッピングを気にしたりする必要はもうないのです。もうひとつの利点は、コンテナによって、異なるアプリケーションが互いに干渉し合うのを防ぐことができる点です。それぞれが独自のコンテナで隔離され、独自の依存関係で実行されるため、異なる要件から生じるコンフリクトを排除することができます。
コンテナ・オーケストレーション。カオスに秩序をもたらす
ここまでで、コンテナによるアプリケーション展開がもたらす利点について理解できたと思います。しかし、より複雑なアプリケーションで複数のコンテナが必要な場合、あるいは複数のコンテナ化されたアプリケーションを一度にデプロイしたい場合、それらをどのように管理すればよいのでしょうか？その答えは、コンテナ・オーケストレーション・プラットフォームにあります。簡単に言えば、このようなプラットフォームは、複数のコンテナのデプロイ、監視、および相互作用を管理し、これらのタスクの複雑さを抽象化して、管理者が個々のコンテナではなく、アプリケーションという観点から考えることができるようにするものです。
Docker Compose：開発者の遊び場
コンテナ化されたアプリケーションの経験がある人の中には、「これはDocker Composeではないか」と思う人もいるかもしれません。答えは、残念ながら「ノー」です。Docker Composeは、開発者がアプリケーションの基本的なスケルトンを指定することができ、基本的な能力で実行するのに十分ですが、限られた開発、プロトタイプ、自動開発シナリオでの使用のみを意図しています。コンテナオーケストレーションプラットフォームの特徴である、堅牢なデプロイメント、監視、セキュリティ、設定、高度なネットワーキングのツールは一切提供されない。Composeには認証や認可の概念がなく、効率的なリソース管理はできません。
Kubernetes：みんなで一緒に漕ぐ
Kubernetesは、ギリシャ語のκυβερν?τη? の英訳で、文字通り舵取りを意味します。ちょうど舵取りが船を操縦し、木の板、キャンバスの帆、船員からなる巨大な集合体を目的地までナビゲートするように、Kubernetes もそのリソースを集結して、その上に展開されたアプリケーションを実行および管理するのです。強力な認証フレームワークがプラットフォームへのアクセスを管理し、あらゆる構成の変更を規制します。高度なリソース割り当てツールにより、開発者と管理者は同様に、計算負荷の最適な配分を確保することができます。デプロイメント、ポッド、レプリカセットなどの抽象化機能により、動作のきめ細かな指定と再現可能なデプロイメントが可能になります。また、堅牢な健全性と活性化の概念により、プラットフォームは異常な状態を検出し、多くの場合、異常な状態から回復することができます。
Kubernetesでバリューストリームを加速させる
この議論の核となる製品、HCL Accelerate は、膨大な数の異なるソースからのデータを結びつけます。Jiraのような課題追跡ツールから、GitHubのようなソースリポジトリ、さらにはJenkinsやHCL LaunchのようなCIインフラまで、Accelerateは配信パイプライン全体から情報を取り込み、消化して、開発ライフサイクルの洞察を提供することができます。しかし、このような作業をすべて行うには、かなりのリソースが必要です。そこで、Kubernetesはデプロイメントプラットフォームとして特に注目すべき優位性を持っています。
Kubernetes は単一の計算ノードにリソースを割り当てるだけでなく、複数のノードにわたってアプリケーションのデプロイをオーケストレーションし、アプリケーション内のすべてのコンテナが最適な効率で動作するために必要なリソースを取得できるようにすることができます。当社のドキュメントでは、HCL Accelerate の本番インストールには 4 つのノードを割り当てる必要があることを示唆しています。 最初のノードは、RabbitMQのようなサービス間通信メディア用で、すべてのデータに対応するための専用スペースがあります。2つ目は、サイクルタイム、リードタイム、スループット、デプロイ頻度など、複雑なバリューストリーム計算用です。3つ目は、新しいデータを取得し、HCL Accelerateを同期させるためのプラグイン用です。そして最後に、4つ目はMongoDBのデプロイメント（ユーザーが提供、管理）です。これはすべてのサービスで共有されており、重いワークロードを実行するのに最適なように、独自のノードに割り当てられる必要があります。4つのノードに分散させることで、リソースを大量に消費するアクションがUIやAPIに影響を与えず、体験が悪くならないようにします。これは、少なくとも1つのノードに「ワークロードクラス」ラベル（バックグラウンド、トランザクション、外部）を追加することで実現されます。起動時に、Kubernetesは、リソースの競合を最小限に抑え、パフォーマンスを最大化する方法で、利用可能なノード間で各サービスを自動的にスケジューリングします。結果はさまざまですが、内部テストでは、適切なノード割り当てにより、バリューストリーム、パイプライン、リリースの各機能領域でパフォーマンスと安定性が30%向上することが確認されています。
生産現場での正しい選択
堅牢性、セキュリティ、パフォーマンス、これらはIT管理者がエンタープライズツールに求める美点です。Kubernetesはこれらを提供し、Docker Composeは提供しません。したがって、Kubernetesが自動化されたコンテナオーケストレーションのデファクトスタンダードであることは驚くべきことではなく、この分野におけるKubernetesの優位性は今後さらに増していくでしょう。HCL Accelerateで最高の体験をしたいのであれば、それは正しい選択というだけでなく、本当に唯一の選択なのです。