独自構築か商用製品か、どの商用製品か
後悔しないKubernetesプラットフォームの選び方
コンテナ運用にKubernetesは不可欠だが、Kubernetes環境の構築は難易度が高い。そしてKubernetesだけでは足りない。他のツールも必要だ。困難な独自構築を試みるか、商用製品を購入するか。検討のポイントとは？
コンテナの最大のメリットは、モジュール性が高く、スケーラブルで回復力のあるアプリケーションが保証されることだ。だがコンテナの運用にはオーケストレーション、監視、メンテナンスが必要だ。結果として複雑さが著しく増大する。
コンテナのメリットを十分活用してコンテナ化に伴う複雑さに対処するには、インフラを自社のニーズに合わせることが不可欠だ。では、コンテナプラットフォームを構築するに当たって何を検討すべきなのか。
適切なOSの選択
コンテナを運用するに当たって驚くほどよく間違えるのは、コンテナを運用するOSの選択だ。どのOSを選んでもコンテナは運用できる。だがコンテナプラットフォームとして「Linux」以外が推奨されるケースはほとんどない。
これにはそれなりの理由がある。
コンテナがその内部のアプリケーションを実行するために、SELinux、名前空間、コントロールグループなど、Linuxの主要な概念や機能を利用している。「Kubernetes」などのコンテナオーケストレーションツールはLinuxの概念を用いて構築されており、コンテナの管理にLinuxのツールとAPIが使われている。
システムリソースと開発者の時間の無駄を最小限に抑えるためにも、コンテナプラットフォームはLinuxを選択すべきだ。
Kubernetesの先を思い描く
コンテナについて話をする際、Kubernetesの正確な役割を話題にしないことは多い。そうした会話では、Kubernetesの役割を「コンテナを実行するアプリケーションだ」という程度にとどめている。だがそれは間違いだ。
Kubernetesは、正確にはAPI、ユーティリティー、ツールの集合体で、コンピューティングリソース管理とコンテナオーケストレーションを担当する。だが、Kubernetesはコンテナプラットフォームに必要な全ての要素を提供するわけではない。コンテナプラットフォームを完全なものにするには、Kubernetesが提供するツールに加えてネットワーク、ストレージ、レジストリ、ログ記録、監視が必要だ。これら全てをオーケストレーションツールとともにOSに配置しなければならない。
リソースやニーズに応じて、「商用製品の購入」と「独自構築」を選べる。商用製品ならば包括的なコンテナプラットフォームの開発、管理、インストール、構成に要する時間を節約できる。そのため独自構築よりも商用製品の方が魅力的な選択肢になることが多い。
さらに、商用製品は大企業向けの便利な「すぐ使える」機能の開発と構成（と試行錯誤のテスト）が既に完了している可能性がある。最も重要なのはクラウドに依存しないことだ。その結果、コンテナプラットフォームを異なるクラウドプロバイダー間でシームレスに運用できる。
忘れてならない4つのC
コンテナプラットフォームを選ぶに当たっては、そのプラットフォームが自社のニーズに結び付いていることを必ず確認する必要がある。商用製品を選択する場合は、その製品がどの程度ニーズを満たすかを評価するための経験則による優れた評価基準がある。それが4つのCだ。
- コード（Code）
ベンダーはどのようなコードの種類とレベルを提供しているのか。
- 顧客（Customers）
そのプラットフォームを既に使っているユーザーはあるか。そのユーザーの運用ニーズは自社とどの程度類似しているか。
- クラウド（Cloud）
コンテナプラットフォームをどこで運用するのか。どのクラウドプロバイダーで使えるのか。
- 包括性（Comprehensive）
製品のポートフォリオはどの程度網羅されているか。それでチーム全体のニーズが満たされるのか。自社が求めるスケーラビリティを実現できるのか。
最後に考えるのは、コンテナプラットフォームが単独では適切に機能するとしても、他の運用や戦略から切り離して実装するものではないことだ。コンテナプラットフォームが他の目標を実現する妨げになるのであれば、コンテナプラットフォーム選びを振り出しに戻すことをためらってはならない。
コンテナプラットフォーム選びは1回で終わるものではない。むしろ、定期的に繰り返し変更が必要になるインフラの一つだ。それは、そのプラットフォームに配置されるコンテナで繰り返し変更が求められるのと変わらない。
エリカ・ランギ氏はRed HatのEMEA（ヨーロッパ、中東、アフリカ）担当シニアソリューションアーキテクト。
Copyright © ITmedia, Inc. All Rights Reserved.
Computer Weekly日本語版
この記事の著者
関連記事
新着ホワイトペーパー PR
-
製品資料
[株式会社キーエンス] なぜRPA導入は頓挫する？ シナリオ作成の壁を乗り越える解決策とは -
製品資料
[株式会社セールスフォース・ジャパン] 「CRMは設計と無関係」は本当か？ PLMとの融合で実現する高速開発 -
事例
[日本ヒューレット・パッカード合同会社] AIエージェントの時代にどう備える？ 「新たな働き手」を支える3要素とは -
製品資料
[日本ヒューレット・パッカード合同会社] “横並びの自動化”から脱却、AI活用で生産性と競争力を高める秘訣 -
製品資料
[サイボウズ株式会社] AIが「わざわざ使うツール」になっていない？ 業務で自然に使う導線にする秘訣
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
なぜ「全社配布Copilot」は使われないのか？ 失敗に学ぶAI定着
-
2
法務と開発者で「言葉が通じない」問題 トヨタやソニーが語るOSS管理の真実
-
3
ChatGPTは“検索しまくり”でGeminiは“淡泊”？ データが明かすAIの裏側
-
4
なぜ「Gemini 4 Argon」は出遅れたのか？ Googleが狙う“逆転のシナリオ”
-
5
「中堅・中小企業のネットワーク・セキュリティ運用実態」に関するアンケート
-
6
損保ジャパンはなぜ「COBOL」を捨てなかったのか？ 脱メインフレームの真相
-
7
「Wi-Fi 7」経由でWindowsが乗っ取られる？ 最高権限奪取の恐怖
-
8
情報漏えいはなぜ繰り返されるのか 今すぐ見直すべき「境界」
-
9
情シスの約8割が転職や退職を意識 調査で分かった“辞めたくなる最大の理由”
-
10
【漫画付き】ひとり情シス協会が明かす、RAG導入でしくじる企業「2つの共通点」
ホワイトペーパーランキング PR
-
1
不審メールの経路や見せ方に変化？ 2026年夏の3事例から見えた動向と対処方法
-
2
家庭用Wi-Fiルーターの業務利用は危険？ 避けるべき理由と具体的な対策
-
3
Microsoft 365を安全に運用 うっかりミスやサイバー攻撃に備えるデータ保護術
-
4
財務部門がAIを最大限に活用する方法 無駄のない戦略的リーダーシップへの道
-
5
LLMが兵器化？ 元FBI高官が鳴らす警鐘とセキュリティツール統合のポイント
-
6
「オンプレミス回帰」せざるを得ない“合理的な理由”
-
7
なぜRPA導入は頓挫する？ シナリオ作成の壁を乗り越える解決策とは
-
8
生成AIを開発に導入しても効果が見えない？ 実証実験で分かった成果と課題
-
9
経産省DX指針から読み解く、受発注業務デジタル化ロードマップ
-
10
HDDを使わない「SSDオンリー」が無謀なのはなぜ？
TechTargetジャパン SNS
@techtarget_itmをフォロー
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー