アプリケーションのリリースは、従来手間がかかっていました。
開発環境（マシンやOS、アプリケーションで使用するライブラリなどをまとめて「環境」と呼びます）では動くのですが、実際の運用環境だと動かない、ということが頻発し、環境の整備に時間を取られていました。
しかし、です。もし開発環境と運用環境を同一の環境にしてしまえるとしたらどうでしょうか？
アプリケーションの動作は保証されます。なぜなら環境が同一ですから。
そのために用いられるのがコンテナ技術です。
この記事では、そのコンテナ技術の概要をお伝えします。
2014年 大学在学中にソフトウェア開発企業を設立
2016年 新卒でリクルートに入社 SUUMOの開発担当
2017年 開発会社Jiteraを設立
開発AIエージェント「JITERA」を開発
2024年 「Forbes 30 Under 30 Asia 2024」に選出
その開発、見積もり段階で諦めていませんか？
アプリ・システム開発は生成AIを活用することで、従来の開発ではあり得なかった、低コスト・高品質開発・スピード開発が同時に実現できます。
▼従来の開発とAIを使った開発の違い
Forbes30 under 30 Asia に選出
システムソリューションを得意とし、新規事業からDX推進まで幅広いジャンルの開発実績があります。
コンテナ技術とは何か？
まずは、そのコンテナ技術について、そもそもなにかということを解説します。
ITエンジニアでさえも難しいというイメージを持っている人が多いコンテナ技術ですが、原理としてはそれほど難解な原理ではないということがお分かりいただけると思います。
コンテナ技術の定義
コンテナとは、港などで見るあのコンテナです。
様々な荷物を鉄でできた金属の箱に詰めて、運搬しやすくしたもの。
荷物は雑多にならず、ひとまとまりになっています。
ソフトウェアのコンテナも、同じ意味です。
ソフトウェアに必要な、アプリケーション、ライブラリ、OSをまとめてひとまとまりにしたものです。
これにより、ソフトウェアは「持ち運び」ができるようになります。
ざっくりと言えば、アプリケーションと、アプリケーションを動かす「環境」の全てをまとめたものです。
コンテナ技術の基本
コンテナとは？
と言っても、そもそもそのコンテナを動かせないと、実際のマシン上でソフトウェアは動作しません。
実際のマシン上で、コンテナを管理するソフトウェアをまず動かします。一番多く用いられているコンテナ管理ソフトウェアはDockerです。
その上でコンテナを動かします。
コンテナの中のアプリケーションはコンテナの中のOSに依存しているので、実際に動かされているマシンのOSが何かということは気にしません。
実際に動かしているマシンのOSの違いを吸収するのはDockerになります。
イメージとは？
この、ひとまとまりのコンテナのことを、「イメージ」と呼びます。
抽象的なOSがあり、抽象的なライブラリがあるのでそう呼ばれます。
イメージは、Dockerの場合は、Dockerfileという「構成ファイル」を書いて構成します。
Dockerfileが実際に動かしているマシンの違いを吸収するので、マシンにより中身が異なる場合があります。例えば、最新のMacに搭載されているM2と呼ばれるCPUのマシンだと、特別な命令を書かなくてはいけないことがあります。
コンテナを走らせるには、イメージを「ビルド」します。
ビルドはマシンパワーを使うので、やや時間がかかります。
コンテナオーケストレーション
さて、実際の運用環境では、同時にいくつものアプリケーションが連携しながら並行して走るということがあります。単一のアプリケーションであっても、複数のコンテナにまたがって実行されているかもしれません。
そんな時、いちいち手作業でコンテナを立ち上げていたら大変ですね。
あるいは数百個のコンテナが立ち上がっているかもしれませんし。
そこで、コンテナオーケストレーションツールという、「コンテナをまとめて管理するツール」があります。
代表的なのはKubernetesです。k8sとも呼ばれます。
コンテナの「指揮者」ですね。
コンテナ技術の重要性とは？
このようなコンテナが、なぜ重要なのでしょうか？
アプリケーションを運用する視点から書き起こします。
もちろん、運用は開発者も考えますので、開発者にとっても重要なポイントです。
コンテナ技術の役割
先述した通り、コンテナ技術の役割とは「アプリケーションとアプリケーションの環境をひとまとまりにすること」です。
例えばライブラリのバージョンが違うだけで、アプリケーションは容易に動作しなくなります。
この「動作しない」が曲者で、ソフトウェアの場合、一ヵ所でも動作しないと全体が動作しなくなることが大変多いのです。機械は人間のような柔軟性はありませんから。
したがって、環境を「全く」同一にするということは、アプリケーションの動作保証上大変重要になります。
ところが、「全く」同一にするのは大変困難な場合が多いのが現実です。
OSに対し改変を加えることは、コンピュータを使っていればあります。
そこで無理やり全く同一にするために、コンテナ技術を使用するのです。
コンテナ技術の目的
全く同一の環境を用意することで、
「開発環境からコンテナごと運用環境に持っていけば動作する」
ことになりますね。
これは画期的でした。
それまでマシンの違いなどに苦しんでいたインフラ担当者の労働を軽減しました。
ユーザーとしても、速やかなリリースができて満足度が上がります。
更に、開発者としても、運用時の細かなことを考えることが大幅に減り、本来のアプリケーションの機能開発に専念できるようになりました。
例えば運用時にバグが出て開発者にフィードバックされたとしても、環境の違いでバグが起きているのではないかという視点はなくなります。なぜなら環境は全く同一だからです。
速やかなバグフィックスはユーザーにも嬉しいですよね。
大きく言うと、これがコンテナ技術の目的です。
コンテナ技術の種類
ここでコンテナ技術を構成する各要素について詳しく見ていきましょう。
ちらっと出しましたが、コンテナを構築するための技術であるDockerと、コンテナ群を管理する技術（コンテナオーケストレーションツール）であるKubernetesについて見ていきます。
Dockerとは？
先述した通り、Dockerとは、イメージを作り、そのイメージをビルドしてコンテナを構築するツールです。
イメージはDockerfileで書きますが、Dockerfileの中身は、ほとんどがコンテナ内のOSに対しての命令になります。
コンテナ内のOSがWindowsならWindowsのバッチファイルのようになりますし、Linuxならシェルスクリプトのようになります。
どのOSをコンテナ内のOSにするかも、Dockerfileで記述します。
Dockerfileに定められた記述があるので、コンテナの再現性は保証されます。
このことが、コンテナの「持ち運び」を可能にします。
Dockerそのものをマシンにインストールすることだけは多少難解ですが、Dockerfileを記述するのはそれほど難解でもありません。
Kubernetesとは？
Kubernetesは、コンテナをまとめて管理するツールなので、独特の概念が多数あります。
一般的なサーバーの管理とはかなり趣が異なります。
ただ、Kubernetesを導入することで、コンテナの自動増設が可能になったり（既存のものと同じコンテナを自動で立ち上げて、負荷分散のために同じアプリケーションを動かすイメージ）、コンテナの動作監視がシステマティックにできるようになったり（コンテナの動作記録をコンピュータで分析しやすいように記録してくれる仕組みがKubernetesにはあります）、現代の大規模なシステムにはKubernetesは欠かせない技術となっています。
Kubernetesは難解です。学習には相当の時間を要します。
ですので、多くの場合専任のインフラエンジニアがKubernetesの運用を担当します。
しかし、エンドユーザーにとってみれば、それだけのコストをかける価値はあります。
Kubernetesによって改善される事項が多いので、コストに見合った価値があるのです。
コンテナ技術のメリット
さて、コンテナ技術の概要が分かったところで、コンテナ技術のメリットを少し深掘りしてみましょう。
軽量性と高速性
コンテナは、コンテナの中にOSを持っていると書きました。
このOS、通常は、フルスペックのOSは用いません。目的のアプリケーションを実行するための最小限のスペックのOSを用います。単体ではマシンに載るOSにはならないようなスペックのOSです。
したがって、コンテナのサイズは小さくなります。
ITの世界ではこのことを「軽い」と呼びます。
軽いと何がいいのでしょうか。
実は、軽いと動作が高速になるのです。
余計なものがないほうが高速に動作する作りを、ソフトウェアというものはしています。
軽量性と高速性、これがコンテナの第一のメリットです。
環境の再現性
繰り返しになりますが、使用するライブラリの種類とバージョン、アプリケーションを構成するプログラミング言語などはDockerfileに記述されています。
Dockerfileでの環境の再現性を同じにしておけば、環境は「全く同一」になります。
例えば開発環境と運用環境で、OSの環境変数が異なるのはよくある話です。
同じWindowsにしていたとしても起こります。
環境変数に起因する動作の違いも頻繁に起こります。
コンテナであれば、動作するOSは同一、環境変数も同一です。
エンドユーザーであれば、バグをフィードバックする時に、どんな環境で動かしているか詳細に質問されて辟易したことはあるのではないかと思います。
そのコミュニケーションストレスがなくなるだけでも、コンテナのメリットはあります。
環境の再現性がコンテナの第二のメリットです。
スケーラビリティと柔軟性
コンテナは、イメージさえあればビルドできるので、多数の複製が簡単にできます。
Kubernetesのところで触れましたね。
従来であればサーバーを増設していたものが、コンテナをビルドだけで済むので、スケーラビリティに優れています。
このような特徴を持つコンテナは柔軟だと言えるでしょう。
また、Dockerfileの記述を変えるだけで環境を改変できるのも大変柔軟です。
スケーラビリティと柔軟性、これがコンテナの第三のメリットです。
コンテナ技術と仮想化の比較
さて、ここまでコンテナ技術について解説してきましたが、環境を同一にする目的であれば、もう一つ、仮想化と呼ばれている技術があります。
ここでは、まず仮想化とは何かを説明し、コンテナ技術と仮想化を比較します。
比較のために、コンテナ技術の技術的な側面にも立ち入ります。
仮想化技術とは？
仮想化技術とは何でしょうか？
仮想化技術とは、OSの上に仮想化のためのソフトウェアを立ち上げ、その上に「ゲストOS」を立ち上げる技術です。
コンテナでのコンテナのOSは、OSというよりも「ミドルウェア」になっています。
あくまでコンテナ管理ツールの上で動くものです。フルスペックではありませんし、そのまま実際のマシンの上に持って行っても動かない場合がほとんどです。
それに対して、仮想化技術でのゲストOSは、フルスペックで、そのまま実際のマシンの上にもっていっても動きます。
仮想化のためのソフトウェアは、「ハードウェアの違いを吸収するもの」です。
そのゲストOSの上でアプリケーションを動作させる技術が仮想化技術です。
コンテナ技術と仮想化の主な違い
さて、コンテナ技術と仮想化技術は何が違うのでしょうか？
まず一覧表にしてみます。
| 項目 | コンテナ技術 | 仮想化技術 |
|---|---|---|
| リソース | ホストOSのCPUやメモリを各コンテナで共有する | ホストOSがCPUやメモリを分割して割り当てる |
| 構築の手間 | イメージでコンテナがまとまっているので構築に手間がかからない | ゲストOSの上に構築するものなので、物理的なマシンの上に構築するのと同じ手間がかかる |
| サイズ | 小さい | 大きい（フルスペックのOSを含むため） |
| 起動時間 | 短い | 長い |
それぞれの項目について詳しく解説します。
リソースの割り当て
仮想化技術のホストOSの上で動いているゲストOSはあくまでもOSなので、固有のCPUやメモリ空間を消費します。
ですので、ホストOSはゲストOSにCPUやメモリのゲストOS固有のリソースを割り当てなければなりません。
それに対して、コンテナ技術の場合はOSとは言えど厳密にはOSではないので、ホストOSの固有のリソースを消費しません。
ホストOSのリソースはコンテナ管理ツールの上で「間借り」するだけで、コンテナには固有のリソースは割り当てられません。
仮想化技術と比較すると、コンテナ技術は、低スペックのマシンでも動作する仕組みとなっています。
イメージとパフォーマンス
コンテナはイメージからビルドされますが、仮想化技術にイメージに相当するものはありません。
ゲストOS上での環境構築は、実際のマシンの上での環境構築と同様の手間がかかります。
可搬性に優れているのはコンテナ技術です。
リリースするときの手間は、コンテナ技術の方がかかりません。
このことから、仮想化技術よりコンテナ技術の方がパフォーマンスが高いと言えます。
サイズと起動時間
仮想化技術にはフルスペックのゲストOSが搭載されているので、ゲストOSを含むアプリケーションの環境全体のサイズがどうしても大きくなります。
ソフトウェアは軽量だと高速に動作すると書きました。
逆に言うと、サイズが大きいと動作は低速になるのです。
つまり、軽量なコンテナ技術に対して、仮想化技術は起動に時間がかかるのです。
仮想化技術は、ゲストOSを立ち上げ、次にゲストOS上の諸々の環境を立ち上げ、最後にアプリケーションを立ち上げます。
このことから考えるだけでも、起動に時間がかかるのはお分かりいただけると思います。
コンテナ技術の学習と実践
コンテナ技術の学習リソース
コンテナ技術について書いてきましたが、ではコンテナ技術をどうやって学べばいいのでしょうか？
一つにはインフラの技術が頭に入っていることが重要です。
コンテナの構築もまた、インフラの領域に入るからです。
Linuxの技術などは、Linuxを解説した書籍にあたることを強くお薦めします。OSは様々な技術要素の集合体ですので、Web記事の断片的な情報だけではなかなか体系的な知識が身に付きません。
インフラ技術を習得したら、次はDockerについての学習に入りましょう。
この時も、Dockerについて書かれた書籍にあたることをお薦めします。Dockerは難解ではないとは言え、独自の概念が複数あるからです。
と言っても、すべてを書籍で学ぶ必要はありません。Dockerfileを書いていて疑問にぶつかったら、Web記事で解決できることがほとんどです。
その場合でも、インフラ技術の知識が基礎にはなりますが。
Kubernetesは難解なので、書籍にあたってください。
コンテナ技術のユースケース
では最後に、コンテナ技術の実際のユースケースを見てみましょう。
コンテナ化されたアプリケーションのデプロイメント
デプロイメントとはリリースのことです。
コンテナ化されたアプリケーションをリリースするのは簡単です。
コンテナごと運用環境のマシンに入れるだけです。
ただし、マシンにコンテナ管理ツールをインストールするのは大変です。
運用環境のマシンにコンテナ管理ツールがインストールされてなかったら、まずそれをインストールするところから始めなければなりません。
例えばDockerの場合でも、WindowsへのインストールとLinuxへのインストールはずいぶん違います。
調整しなければならない項目も多数あります。
この辺は、ホストOSのバージョンが変わるとがらりと変わったりもする項目でもあるので、最新情報を仕入れて取り組んでください。
Kubernetesを用いたコンテナクラスターの管理
Kubernetesでは、コンテナ群のことをコンテナクラスターと呼びます。
コンテナクラスターを管理することがKubernetesでの業務になります。
Kubernetes自体も構成ファイルを書いて構築するのですが、Kubernetesは、「そのとき見て調整する」よりも、「あらかじめ書いてあるものを再現する」というアプローチをとっています。
たとえばサーバーを運用しているとログの監視業務は発生しますが、ログで異常を発見して、同じ状態を再現したいと思っても、物理的なサーバーで同じ状態を再現するのは非常に困難であることが多くなっています。
Kubernetesでは、その状態を再現するスクリプトを書くことで、同じ状態を再現できます。
これにより、エラーへの対処がやりやすくなっており、しかも確実な対処ができるのです。
そんなことができるのも、管理対象が物理的なサーバーではなく仮想的なコンテナだからです。
Kubernetesのメリットの1つですね。
コンテナ技術のまとめ
コンテナ技術は、
- 環境の再現ができて
- 迅速なリリースが可能で
- 動作も軽い
ということを書いてきました。
実際、現代のアプリケーションはほとんどがコンテナの上で動作するようになっています。
環境構築に関しては、開発者の負担もエンドユーザーの負担も以前よりだいぶ軽減されました。
ところが、書いてきた通り、コンテナを構築することは多少難解な部分があります。
コンテナを管理するKubernetesの扱いになると、もう専門家でないと分からないレベルです。
「自社の人員でできるのだろうか…？」
そう思われたとしても不思議ではありません。
そんなときは、コンテナ技術を使用したアプリケーションの開発と運用を専門の開発会社に一任してはいかがでしょうか？
株式会社Jiteraは豊富な開発経験から開発と運用を承ります。
https://jitera.com/ja/insights/contact2
また、もしコンテナに関してお困りのことがあった場合、また、コンテナ技術のことで相談したいことがある場合も株式会社Jiteraにお気軽にご相談ください。
株式会社Jiteraは皆様からのお問い合わせをお待ちしております。
メールマガジン登録
