失敗しないコンテナ化戦略【前編】
コンテナ移行を阻む課題と解決のヒント
レガシーアプリケーションのコンテナ化にはどのような課題が発生するのか。それを最小限のコストで解決するためのヒントを紹介する。
パブリッククラウドにモノリシックアプリケーションをそのままデプロイするという、何もかもが力ずくの動きは依然存在する。
アプリケーションは、機能ブロックに分解して各ブロックをコンテナで実行する方が効率が高い。Computer Weeklyは、企業がコンテナに移行する際に直面する最新の動向、力学、課題を専門家に聞いた。
仮想マシン(VM)とは異なり、コンテナはOS(カーネル)を共有する。そのため1つのOSで複数のコンテナをサポートできる。簡単に言えば、コンテナはOSレベルではなくプロセス(アプリケーション)レベルの仮想化と見なすことができる。
コンテナに移行すれば、よりモジュール性の高い構成が可能になる。だがリソースの相互接続が複雑になり、管理、メンテナンス、オーケストレーションが必要になるというトレードオフを伴う。「Kubernetes」のエコシステムが広がりを見せてはいるが、デプロイされている全てのコンテナの健全性、機能、広範な状態を同時に把握するのは簡単なことではない。
コンテナへの移行
Alibabaのレイ・チャン氏(技術リード兼エンジニアリングマネジャー)は次のように話す。「アプリケーションをVMからコンテナに移行するベストな方法についてよく尋ねられる。Kubernetesの構築を試みる顧客は全て、それを複雑だと感じているようだ」
VMのコンテナ化を検討している企業が最初にすべきことは、明確な移行計画を作成することだとチャン氏は言う。そのためには、移行を複数のステップに分ける必要がある。最も安定しているアプリケーション(例えばWebサイト)から始め、複雑なアプリケーションはコンテナスタックが成熟してから移行する。
Appviaのルイス・マーシャル氏(技術エバンジェリスト)は、リスクを軽減するだけでも大きなメリットがあり、レガシーシステムをコンテナ化するという決定が容易になると語る。「レガシーシステムは適宜アップグレードしなければならないため、イミュータブル(訳注)ではない。イミュータブルなコンテナを利用することは、レガシーシステムに存在する不適切な習慣、プロセス、運用プラクティスを取り除く機会になる」と同氏は話す。
訳注:immutable(不変)。この場合は、本番環境にパッチ適用などの変更は行わず煩雑な更新作業から解放されること。
手作業の処理が多く、あらゆる種類のアップデート作業に驚くほど手間が掛かり、リスクを伴うレガシーシステムもある。マーシャル氏の経験では、コンテナには運用コストとメンテナンスコストを下げながらセキュリティを向上させる能力があるという。
レガシーシステムの運用コストがゼロに向かって下がるように努めることをマーシャル氏は推奨する。「コストが高く、提供するビジネス価値が限られているシステムがあるのなら、それをアップデートまたはアップグレードすることを優先する必要がある。システムが『稼働し続ける』ために数人の担当者が定期的に多くの残業を強いられているのなら、それは重大な危険信号だ」
「システムが古くなると、通常はメンテナンスコストが上がり、セキュリティのリスクが高くなり、安定性が低下することを忘れてはいけない」(マーシャル氏)
コンテナ化の課題
コンテナベースのサービスは、新たなアップデートが利用可能になったらサービスを削除してデプロイし直すことができる。だがCCS Insightのボラ・ロティビ氏(リサーチ部門ディレクター)は、適切な制御を施して常にアクセス可能にしておかなければならない重要なデータも存在すると指摘する。
「開発者は、コンテナを含むストレージ資産のプロビジョニングに関与する必要がある。データ駆動型の企業は、最新データストレージと物理ストレージ層に精通することが不可欠になる」(ロティビ氏)
Hammerspaceのダグラス・フォールズトロム氏(製品および運用部門バイスプレジデント)は、アプリケーションはインフラとデータの場所を認識する必要があると指摘する。これによりコンテナ化の全体的な複雑さが増し、何かが変わったらアプリケーションを再構築する必要性が生じると同氏は警告する。
「オーケストレーションをシンプルにするために、コンピューティングはサーバレスになった。同様に、アプリケーションがインフラについて何も知らなくてもデータにアクセスできるように、データもストレージレスにする必要がある。ストレージレスデータが実際に意味するのは、どのサイトでもどのクラウドでもデータ管理がセルフサービスで行われ、自動化によってデータのサービス提供や保護がIT部門に負担を掛けることなく最適化される必要があるということだ」(フォールズトロム氏)
データ管理の点で言えば、データベースは一般的にはクラウドネイティブアーキテクチャで運用するようには構築されていない。Cockroach Labsのジム・ウォーカー氏(製品マーケティング部門バイスプレジデント)は、Kubernetesなどのインフラでレガシーデータベースを管理するのは非常に難しいと言う。Kubernetesが提供するスケールアウト環境と並行してデータベースを運用している企業が多いと同氏は語る。
「これによって、多くの場合はアプリケーションのボトルネックが発生し、さらに悪いことに単一障害点ができる。KubernetesでNoSQLデータベースを運用するのが適切だが、それでもトランザクションの一貫性の問題が発生する」(ウォーカー氏)
データベースのこの問題に対処せずにクラウドネイティブアプリケーションを構築しているソフトウェア開発者は、コンテナとオーケストレーションの価値のほんの一部しか得られないと同氏は考えている。「Kubernetesは本来ステートレスなワークロード向けだ。結果として導入が抑えられている。導入が実際に進むのは、データを集中的に扱うワークロードをKubernetesで構築するときだろう」と同氏は語る。
後編では、コンテナ化したアプリケーションの運用時に発生する可能性のある問題と、迅速なコンテナ化を成功させる3つのステップを紹介する。
Copyright © ITmedia, Inc. All Rights Reserved.
Computer Weekly日本語版
この記事の著者
関連記事
新着ホワイトペーパー PR
-
製品資料
[株式会社シーイーシー] 脱VMwareに成功した企業は何をどう実践した? 事例に学ぶ戦略立案&実装のコツ -
製品資料
[株式会社オービックビジネスコンサルタント] ランサムウェア攻撃を“二重の防御構造”で防ぐ、クラウド型基幹システムの実力 -
製品資料
[株式会社オービックビジネスコンサルタント] 動画で知るランサムウェア被害企業のリアル、会計データが無事だった理由とは -
市場調査・トレンド
[セコムトラストシステムズ株式会社] EDR導入を成功に導くロードマップ:選定/稟議/運用のつまずきを防ぐコツ -
事例
[日本オラクル株式会社] ピンチをチャンスに変えたEPR製品は? 先行企業の導入事例3選
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
損保ジャパンはなぜ「COBOL」を捨てなかったのか? 脱メインフレームの真相
-
2
なぜ「全社配布Copilot」は使われないのか? 失敗に学ぶAI定着
-
3
「企業におけるAI導入検討度とIT投資優先度」に関するアンケート
-
4
「ノートPC派」は損をしている? Dellと考える“自作PC”のメリット
-
5
生データを隠してデータ連携 KDDIが4000万人の顧客情報を安全に分析できた理由
-
6
慶應義塾が「Notion」を選んだ理由 AI導入の盲点になる“情報のサイロ化”
-
7
「0.3秒のスピード顔認証」の入退室管理が社員に好評 事例に学ぶオフィス改革
-
8
年収700万超エンジニアに共通するスキルと「もっと勉強すべきだった分野」
-
9
「また同じ説明か」 消費者の半数が離脱するAIチャットbotの“記憶喪失”
-
10
IT製品の導入に関するアンケート「サーバ&ストレージ」編
ホワイトペーパーランキング PR
-
1
不審メールの経路や見せ方に変化? 2026年夏の3事例から見えた動向と対処方法
-
2
DX/AI投資の壁を突破、現代の最高財務責任者が直面する課題と克服のヒント
-
3
「オンプレミス回帰」せざるを得ない“合理的な理由”
-
4
LLMが兵器化? 元FBI高官が鳴らす警鐘とセキュリティツール統合のポイント
-
5
システムの保守がモダン化を阻む? 「変えない判断」から脱却する方法とは
-
6
生成AIを開発に導入しても効果が見えない? 実証実験で分かった成果と課題
-
7
経産省DX指針から読み解く、受発注業務デジタル化ロードマップ
-
8
“あのファイル転送”で暗躍するノーウェアランサム
-
9
Microsoft 365を安全に運用 うっかりミスやサイバー攻撃に備えるデータ保護術
-
10
HDDを使わない「SSDオンリー」が無謀なのはなぜ?
TechTargetジャパン SNS
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー