新しい IBM Developer JP サイトへようこそ!サイトのデザインが一新され、旧 developerWorks のコンテンツも統合されました。 詳細はこちら

IBM Developer Blog

IBM Developer サイトで最新の出来事をフォローし、情報を入手しましょう。

このブログ記事では、コンテナーとは何か、なぜ重要視するべきなのか、コンテナーはどのようにマイクロサービスやクラウドとやり取りするのかを説明します。


「諸君、こんな単純なことがどうしてわからないのかな。君たちには復習の必要があるだろう。… 最近では行き着くところはすべてボール・ベアリングなんだ」(出典: 映画「フレッチ/殺人方程式」、1985年、アーウィン・”フレッチ”・フレッチャーの台詞)

悲しいことに、最近では行き着くところはすべてボール・ベアリングではなく、コンテナーです。コンテナーについて耳にしたことはあっても、それが何であるかわからない場合、まさにその答えを見つけられるのが、このページです。このブログ記事では、以下の質問に答えます。

  • なぜコンテナーを重要視しなければならないのか?
  • コンテナーとは何か?
  • コンテナーはマイクロサービスと同じなのか?
  • マイクロサービス・アプリケーションにはどのような例があるか?
  • Docker とは何か?
  • コンテナー・オーケストレーションと Kubernetes とは何か?
  • コンテナーと VM イメージの違いは何か?
  • コンテナーを使い始める方法は?
  • IBM Cloud Paks が役立つ理由は?
  • コンテナーを実行できる場所は?
  • Red Hat OpenShift on IBM Cloud とは何か?

輸送用コンテナーの写真 出典: Shutterstock

なぜコンテナーを重要視しなければならないのか?

程度の差はあれ、さまざまな組織でコンテナーの導入が進んでいます。多くの人々はコンテナーについて学び始めたばかりですが、一部の企業はコンテナー化をかなり進めています。仮にもコンテナー化の導入を検討しているとしたら、今こそこの画期的なテクノロジーに参加すべき時です。コンテナー化によって、以下のビジネス成果を上げることができます。

  • 市場投入までの時間の短縮: 競争力を維持するには、新しいアプリケーションとサービスを次々とリリースする必要があります。組織がアジャイルに開発および運用を進めることができれば、新しいサービスをリリースする速度が 3 倍 (300 パーセント) 向上します。
  • 開発速度: 開発からデプロイまでの時間を 60 パーセント短縮できます。コンテナー化は DevOps チームがデプロイの所要時間を短縮し、頻度を上げる際の障壁を取り除くからです。
  • IT インフラストラクチャーの縮小: コンテナー化はアプリケーション・ワークロードの密度を高め、サーバー処理能力の使用を効率化し、ソフトウェア・ライセンスのコストを削減するため、40 パーセントのコスト削減を実現できます。
  • IT 運用の効率化: コンテナー化によって、さまざまなアプリケーションとインフラストラクチャーの管理を簡素化して 1 つの運用モデルに統一し、自動化することで、運用の効率性を 40 パーセント高めることができます。
  • 選択の自由: アプリケーションをパッケージ化して出荷し、どのパブリック・クラウド上またはプライベート・クラウド上でも実行できます。

(出典: Why Docker? | Docker.com)

コンテナーとは何か?

コンテナーを理解するのに最もわかりやすい例えは、輸送用コンテナーです。このことから、コンテナーに関する記事とブログの大半では輸送用コンテナーの写真を載せているわけですが、この記事もその例外ではありません。皆さんはこのような大型のスチール製輸送用コンテナーを一度は目にしたことがあるはずです (私はコンテナーを使用して家を建てたり、スイミング・プールを作ったりしている「アウトドア派」の人々を見たこともあります)。輸送業界ではコンテナーのサイズを標準化しています。そのため、同じコンテナーを船から電車、電車からトラックまで、荷物を載せたまま移動できます。コンテナーを移動する際に、その中身が何であるかは問題になりません。

輸送用コンテナーと同じく、ソフトウェア・コンテナーは標準化されたソフトウェアのパッケージです。ソフトウェア・コンテナーには、所定のソフトウェアを実行するために必要なものがすべて収容されます。ソフトウェア・コード、ランタイム、システム・ツール、システム・ライブラリー、設定のすべてが 1 つのコンテナー内に収容されることになります。

コンテナーはマイクロサービスと同じなのか?

コンテナーについて調べる過程では、マイクロサービスについて読まないわけにはいきません (勘違いしないでください。マイクロサービスは暗闇の中で誤って踏み付けてしまう、あの小さな車ではありません。それはマイクロ・マシンです。こう言うと、時代遅れに聞こえるのでしょうね)。マイクロサービスはアーキテクチャー・スタイルの 1 つです。マイクロサービス・アーキテクチャーでは、それぞれが特定のビジネス機能を果たす、一連の疎結合されたサービスを使用してアプリケーションを構成します。このアーキテクチャーを可能にするのが、コンテナーです。

マイクロサービスを使用するアプリの例は?

約 10 年前にコンテナーを大々的に利用し始めた企業の 1 つとして、Netflix が挙げられます。Netflix は動画サービス全体を実行するアプリケーションを、マクロサービス・アーキテクチャーを使用して作り直しました。Netflix による推定では、現在、約 700 個のコンテナーを使用して Netflixを構成する多数の機能のそれぞれを制御しています。(700 個すべてではなく) そのうちのいくつかを紹介しましょう。

  1. 動画選択: コンテナーに収容されたこのマイクロサービスは、スマートフォン、タブレット、コンピューター、または TV に、インターネット速度に基づく動画品質で再生する動画ファイルを配信します。
  2. 視聴履歴: ユーザーが視聴したコンテンツを記録するマイクロサービスです。
  3. プログラム・レコメンデーション: このマイクロサービスは視聴履歴を調べ、アナリティクスを使用してお勧めの映画を提示します。
  4. メイン・メニュー: メイン・メニューに表示する映画の名前と画像を提供するマイクロサービスです。
  5. 課金: ユーザーのクレジット・カードから月額料金を引き落とすマイクロサービスです。

Netflix は世界 190 か国の約 1 億 1,800 万人の加入者に 1 日あたり約 2 億 5,000 万時間分の動画を配信しています。これだけの規模にわたり、わずか数秒でエンターテイメントを提供するのは、アプリケーションにとって大きな試練です。こうした試練に打ち勝つために、中小企業でも大企業でもコンテナーを利用しています。 (出典: How Netflix works: the (hugely simplified) complicated stuff that happens every time you hit Play | Mayukh Nair 著)

Docker とは何か?

コンテナーが何であるかを説明したところで、次は Docker を紹介します (Casual Friday の Dockers パンツのことではありません)。Docker は、コンテナーを作成して使用することを可能にする、オープンソースのコンテナー化テクノロジーの名前です。意外なことではないと思いますが、Docker オープンソース・コミュニティー内では IBM が大いに活躍しています。

Docker は新しいものではありません。実際のところ、2008 年あたりから使用されてきています。コンテナーを使用する方法は他にもありますが、一般的には Docker がコンテナー競争に「勝った」と認められています (覚えている方もいると思いますが、数年前の BlueRay 規格と HD-DVD 規格の戦いでは、BlueRay が勝利を収めました。この例えで言うと、Docker は BlueRay のようなものです)。Docker を使用すると、アプリケーションをパッケージ化して出荷し、どのパブリック・クラウド上またはプライベート・クラウド上でも実行できます。場所を問わずにアプリケーションを実行できるため、ベンダー・ロックインを回避して、いつでも新しい環境に移行できます。

コンテナー・オーケストレーションと Kubernetes とは何か?

紹介しなければならない重要なコンセプトがもう 1 つあります。それは、オーケストレーションです。コンテナーが 1 つだけなら管理するのは簡単ですが、コンテナーをいくつも作成するとなると、コンテナーの管理が極めて重要になります。管理しなければ、たちまち大混乱に陥ってしまうでしょう(大混乱はいただけません)。こうした大混乱から救ってくれるのが、Kubernetes です (豆知識: Kubernetes は、かじ取りまたは水先案内人を意味するギリシャ語です)。オープンソース・システムである Kubernetes は、コンテナー化されたアプリケーションの水先案内、つまりオーケストレーションを行います。言うなれば、Kubernetes はコンテナーを移動させて制御するクレーンに例えられるでしょう。Docker の場合と同じく、IBM は Kubernetes オープンソース・コミュニティー内でも活発に活動しています。

前述のとおり、Kubernetes はコンテナーのオーケストレーションを行います。オーケストレーションを行うとは実際に何を意味するのかと言うと、アプリケーションをスケールアップまたはスケールダウンすることです。さらに、アプリケーションへの変更やアップグレードのロールアウトも行います。何か問題が発生した場合、Kubernetes は変更をロールバックし、障害が発生したコンテナーを再起動します。また、ノードが機能停止するとコンテナーを置き換え、コンテナーがヘルス・チェックに応答しなければ、そのコンテナーを強制終了します。こうした管理によって、可用性を犠牲にすることなくリソースを節約できるとともに、負荷分散も自動化されます。

コンテナーと VM イメージの違いは何か?

仮想マシンは、その名が示唆するようにコンピューター・システムをエミュレートするソフトウェアです。VM を使用すると、チームは 1 台のコンピューター上に複数のマシンがあるように見えるものを実行できます。ソフトウェアを別の種類のハードウェアまたはオペレーティング・システムで実行しなければならない場合、VM を使用すれば、ハードウェアを追加しなくてもそれが可能になります。

コンテナーと VM の間の主な違いとして、VM を使用する場合、チームはそれぞれに異なる種類のソフトウェアを実行できる (オペレーティング・システムを含む) 複数の仮想環境を作成します。一方、コンテナーはソフトウェアを環境およびオペレーティング・システムから切り分けるため、コンテナーの場合はほぼあらゆる場所で実行できます。 (出典: Containers vs. VMs: What’s the difference?)

コンテナーを使い始める方法は?

「千里の道も一歩から」という諺を引用することもできますが、あえてそうしません。コンテナーを使い始める最良の方法は、最初は 1 つのコンテナーを使用することです。アプリケーションをコンテナー化すると、さまざまなメリットがもたらされます。けれども、どこから、どのようにしてコンテナー化を始めればよいのでしょうか?

コンテナー化を開始するには、3 つの方法があります。

  1. 移行して最適化: 「リフト・アンド・シフト」とは、オンプレミス・アプリケーションをコンテナー化して、通常はパブリック・クラウドまたはプライベート・クラウドに (大抵の場合はデータ・センターから) 移行した後、移行先でアプリケーションを最適化するプロセスを意味します。指摘する点として、「リフト・アンド・シフト」はアプリケーションをリファクタリングすることでも分解することでもありません。アプリケーション全体またはその一部を 1 つのコンテナーに収容することです。
  2. アプリケーションのモダナイゼーション: リフト・アンド・シフトよりも積極的な手法は、モノリシックなアプリケーションをリファクタリングしてマイクロサービスに変換することです。この手法では、ある開発手法から別の開発手法に移行することになります。
  3. 新規開発: 組織によっては、最初からコンテナーを使用して新しい開発を始めることを選択する場合もあります。

IBM Cloud Paks が役立つ理由は?

コンテナーと Kubernetes そのものだけでなく、企業では本番環境トポロジーのオーケストレーション、アプリケーションの管理、セキュリティー、ガバナンスにも対処する必要があります。そこで役立つのが IBM Cloud Paks です。

IBM Cloud Paks は、エンタープライズ対応のコンテナー化ソフトウェア・ソリューションです。このソリューションを利用すると、オープンでより迅速かつセキュアな方法で、コアとなるビジネス・アプリケーションをあらゆるクラウドに移行できます。IBM Cloud Pak は Red Hat® OpenShift® on IBM Cloud™ および Red Hat Enterprise Linux 上で稼働します。共通のインテグレーション層を基礎に、各 IBM Cloud Pak にはコンテナー化された IBM ミドルウェアと開発および管理用の共通ソフトウェア・サービスが組み込まれます。この動画で、アーキテクチャーについて説明しています。

利用可能な Cloud Paks for Applications、Data、Integration、Automation、および Multicloud Management について詳しくは、このリンク先の IBM Cloud Paks のページをご覧ください。

コンテナーを実行できる場所は?

何度も言うようですが、Docker (および IBM Cloud Paks) を使用すると、アプリケーションをパッケージ化して出荷し、どのパブリック・クラウド上またはプライベート・クラウド上でも実行できます。最近ではほとんどの場合、組織は複数のクラウド・ベンダーを利用しています。これがベスト・プラクティスです。企業の 71 パーセントは、3 つ以上のクラウドを使用しており、10 社中 8 社がマルチクラウド戦略を採用しています。

選択肢となるクラウド環境は 3 種類あります。

  1. パブリック・クラウド: パブリック・クラウドはマルチテナント型環境ですが、完全に管理され、しかも従量課金制で利用できます。IBM Cloud、AWS、Azure はいずれもパブリック・クラウドです。これらのどのクラウド内でも IBM Cloud Paks を実行できます。
  2. 専用クラウド: 専用クラウドには、パブリック・クラウドのメリットに加え、専用インフラストラクチャーを使用できるというメリットがあります。専用クラウドは、多くの業界での法規制に関する要件を満たします。また、計算能力を他のテナントと共有することもありません。
  3. プライベート・クラウド: プライベート・クラウドはクラウド・コンピューティングのメリットを、しかもファイアウォールの背後で提供します。IBM が提供している Red Hat OpenShift on IBM Cloud という包括的なサービスでは、極めてスケーラブルで信頼性の高い IBM Cloud プラットフォーム上でフルマネージドの OpenShift クラスターを使用できるようになっています。鍵は取得するものの、実行されるのはセキュアな IBM データ・センター内です。

Red Hat OpenShift on IBM Cloud とは何か?

コンテナー、Docker、Cloud Paks、Kubernetes のすべてをまとめて提供してくれるのが、Red Hat OpenShift on IBM Cloud です。Red Hat OpenShift on IBM Cloud は IBM Cloud を利用するため、開発者はアプリケーションの開発と管理に注力できます。IBM が管理するインフラストラクチャーで、ボタンをクリックするだけで可用性に優れたフルマネージドの OpenShift クラスターが提供されます。詳細については、Red Hat OpenShift on IBM Cloud のガイド付きツアーの動画をご覧ください。

Red Hat OpenShift on IBM Cloud は、The Weather Company で毎日 2,500 億件のオンデマンド予測を支える同一の Kubernetes サービスに直接統合されています。これはかなりの数です。

ネイティブの OpenShift と同じように操作できるダッシュボード、マルチゾーン・クラスターによる継続的な可用性、ワークロードとデータを移行する際のセキュリティーの強化など、さまざまな機能の詳細について、このリンク先の Red Hat OpenShift on IBM Cloud のページで確認してください。

まとめ

コンテナーは将来を築くビルディング・ブロックです。目新しい「外見が注目を引く」存在ではなく、定着している存在です。より迅速なアプリケーション・デリバリーから、開発からデプロイまでのプロセスの迅速化、インフラストラクチャーとソフトウェアのコスト削減まで、コンテナーは中小企業と大企業の両方に真のビジネス成果をもたらします。以下のリンクから、他のリソースにもアクセスしてください。動画、ハンズオンのトライアル、チュートリアルなど、今すぐコンテナー化を開始する上で役立つ情報を入手できます。

参考リンク