コンテナの最大のメリットは、モジュール性が高く、スケーラブルで回復力のあるアプリケーションが保証されることだ。だがコンテナの運用にはオーケストレーション、監視、メンテナンスが必要だ。結果として複雑さが著しく増大する。
コンテナのメリットを十分活用してコンテナ化に伴う複雑さに対処するには、インフラを自社のニーズに合わせることが不可欠だ。では、コンテナプラットフォームを構築するに当たって何を検討すべきなのか。
コンテナを運用するに当たって驚くほどよく間違えるのは、コンテナを運用するOSの選択だ。どのOSを選んでもコンテナは運用できる。だがコンテナプラットフォームとして「Linux」以外が推奨されるケースはほとんどない。
コンテナがその内部のアプリケーションを実行するために、SELinux、名前空間、コントロールグループなど、Linuxの主要な概念や機能を利用している。「Kubernetes」などのコンテナオーケストレーションツールはLinuxの概念を用いて構築されており、コンテナの管理にLinuxのツールとAPIが使われている。
システムリソースと開発者の時間の無駄を最小限に抑えるためにも、コンテナプラットフォームはLinuxを選択すべきだ。
Kubernetesの先を思い描く
コンテナについて話をする際、Kubernetesの正確な役割を話題にしないことは多い。そうした会話では、Kubernetesの役割を「コンテナを実行するアプリケーションだ」という程度にとどめている。だがそれは間違いだ。
Kubernetesは、正確にはAPI、ユーティリティー、ツールの集合体で、コンピューティングリソース管理とコンテナオーケストレーションを担当する。だが、Kubernetesはコンテナプラットフォームに必要な全ての要素を提供するわけではない。コンテナプラットフォームを完全なものにするには、Kubernetesが提供するツールに加えてネットワーク、ストレージ、レジストリ、ログ記録、監視が必要だ。これら全てをオーケストレーションツールとともにOSに配置しなければならない。
リソースやニーズに応じて、「商用製品の購入」と「独自構築」を選べる。商用製品ならば包括的なコンテナプラットフォームの開発、管理、インストール、構成に要する時間を節約できる。そのため独自構築よりも商用製品の方が魅力的な選択肢になることが多い。
さらに、商用製品は大企業向けの便利な「すぐ使える」機能の開発と構成（と試行錯誤のテスト）が既に完了している可能性がある。最も重要なのはクラウドに依存しないことだ。その結果、コンテナプラットフォームを異なるクラウドプロバイダー間でシームレスに運用できる。
忘れてならない4つのC
コンテナプラットフォームを選ぶに当たっては、そのプラットフォームが自社のニーズに結び付いていることを必ず確認する必要がある。商用製品を選択する場合は、その製品がどの程度ニーズを満たすかを評価するための経験則による優れた評価基準がある。それが4つのCだ。
ベンダーはどのようなコードの種類とレベルを提供しているのか。
そのプラットフォームを既に使っているユーザーはあるか。そのユーザーの運用ニーズは自社とどの程度類似しているか。
コンテナプラットフォームをどこで運用するのか。どのクラウドプロバイダーで使えるのか。
製品のポートフォリオはどの程度網羅されているか。それでチーム全体のニーズが満たされるのか。自社が求めるスケーラビリティを実現できるのか。
最後に考えるのは、コンテナプラットフォームが単独では適切に機能するとしても、他の運用や戦略から切り離して実装するものではないことだ。コンテナプラットフォームが他の目標を実現する妨げになるのであれば、コンテナプラットフォーム選びを振り出しに戻すことをためらってはならない。
コンテナプラットフォーム選びは1回で終わるものではない。むしろ、定期的に繰り返し変更が必要になるインフラの一つだ。それは、そのプラットフォームに配置されるコンテナで繰り返し変更が求められるのと変わらない。
エリカ・ランギ氏はRed HatのEMEA（ヨーロッパ、中東、アフリカ）担当シニアソリューションアーキテクト。