DevOps と コンテナー、そしてオンプレミスとクラウド

DevOps and Containers, On-Prem or in the Cloud | Rancher Labs
http://rancher.com/devops-containers-prem-cloud/
からの翻訳です。

on Mar 14, 2017

クラウドかオンプレミスかという論争は既に古いものとなりました。このような議論はクラウドがまだ目新しいものであった時代、業務をオンプレミスのデータセンターに残すかクラウドに移行するかどうしようか人々が議論していた時期の話です。

しかし、Docker革命がこの議論に新しい局面をもたらしました。数多くの企業がコンテナー(仮想化)を次々と採用し、そのコンテナーをオンプレミスとクラウドかのどちらに置くのがベストであるかを議論しています。

回答は1つではないことは、ご想像に難くないでしょう。このブログでは、コンテナーの展開におけるクラウドとオンプレミスのプラス面とマイナス面、そしてどの要素があなたの組織にマッチする正しい選択の決め手になるのかを考えてみます。

DevOps、コンテナー、クラウド

まず、DevOps、コンテナ、クラウドの基本的な関係をさっと見てみましょう。多くの場合、DevOpsとコンテナの組み合わせは(本来の使い道ではないかもしれませんが)クラウド内でITを行う方法の1つとみられています。

結局のところ、コンテナーがもたらすDevOpsのムーブメントの最終目標である拡張性と柔軟性は、言うまでもありませんが多くの人がクラウドに移行する一番の理由になっています。仮想化や継続的デリバリなどはクラウド(またはクラウドのような環境)に完璧にマッチしているので、もしアジャイル開発によるDevOpsを実施している場合、無理にクラウドに合わせたIT利用プロセスに当てはめようとしなくても極めて自然に開発できるでしょう。

DevOpsとオンプレミス

ということは、一方、オンプレミスでのデプロイはコンテナ化やDevOps,継続的デリバリにどうやっても適さない、または異質なものでしょうか? いやそうではありません。オンプレミスでのデプロイそのものも変化してきています。今や、抽象化することによる仮想化やハードウェアから相対的な独立性のようなクラウドの多くの特徴を持ち始めています。

今日のオンプレミスシステムは一般的な「プライベートクラウド」の定義に幅広くマッチしていて、DevOpsの心である自動化された開発やオペレーションサイクルに適しています。

実際、AWSやDockerをふくむ、DevOps/コンテナーの世界の主要事業者は、オンプレミスへの展開の強力なサポートや、パブリッククラウドとプライベートクラウドの境界線を超えシームレスに動作するよう設計されたRancherのような高度なコンテナ管理ツールを提供している。コンテナーは今やクラウドと同程度にオンプレミスの世界で普通に存在しているといっても過言ではありません。

なぜオンプレミス?

どうしてオンプレミスにコンテナを展開したいのでしょう?

ローカルリソース

たぶん最も明白な理由はハードウェア、つまりストレージやプロセッサ固有の操作などの特徴的なハードウェアを使ったり、直接アクセスする必要がある場合です。例えば、もし行列計算にGPU配列演算チップを使用しなければならないなら、ローカルハードウェアを使わざるを得ないでしょう。

仮想化マシンみたいなコンテナーでは、ある程度の抽象化が必要ですが、オンプレミスでコンテナーを動かすことにより、アプリケーションとその下にある物理的なハードウェアとの間にあるいくつもの抽象レイヤーを減らすことができます。コンテナーだとその下層にあるOSを通してハードウェアまで大なり小なり直接アクセスすることができますが、ベアメタル上のVMやパブリッククラウドのクラウドではあまり実用的ではありません。

ローカルの監視

同じような状況に、ローカルデバイスを監視、制御、および管理するためにコンテナが必要な場合もあります。例えば、工業施設や研究施設においては重要な検討事項です。もちろん、従来のタイプのソフトウェアで監視機能と制御機能を実行することも可能である。しかし、コンテナ化と継続的なデリバリを組み合わせることで、製造プロセスや研究手順の変更に対応して、ソフトウェアを迅速に更新して適応させることができる。

セキュリティのローカル制御

オンプレミスにコンテナを配置する理由に、セキュリティも重要な検討事項です。というのも、コンテナはOSのリソースに直接アクセスするため、潜在的なセキュリティ脆弱性があります。コンテナの安全性を確保するためには、コンテナシステムにセキュリティ機能を追加する積極的な取り組みが必要です。

ほとんどのコンテナー配置のシステムには、セキュリティ機能が組み込まれています。しかし、オンプレミスに展開することは、セキュリティレベルを追加するために有用な手法です。オンプレミスのコンテナ展開は、物理的な施設へのアクセスの制御という追加のセキュリティに加え、基盤ハードウェアに組み込まれたセキュリティ機能を利用できます。

レガシーなインフラ基盤とクラウドへ移行

もしあなたが、既存のオンプレミスのインフラ設備を捨てられる立場になかったらどうでしょう?もし企業が多額の資金をハードウェアに投入していたら?または企業が単に望んでいなかったり、相互に接続された大規模で複雑な一連の旧来のアプリケーションから一度に移行してしまうことができなかったら、当面はオンプレミスで使い続けることが最も実用的な(または最も政治的に慎重な)短期から中期の選択でしょう。コンテナー(とDevOps実践)をオンプレミスに導入することにより、クラウドへの段階的な移行を比較的無理なく行うことができるでしょう。

ローカルでのテストし、クラウドへデプロイ

あなたはコンテナ化アプリケーションをローカルで開発/テストし、その後にクラウドにデプロイしようとするかもしれない。オンプレミスで開発することにより、ソフトウェアと配置プラットフォーム間の相互接続の入念な観察や、制御されたコンディション配下で挙動を確認することができます。

こうすることにより、クラウドのアプリケーションの動作とクラウドではないローカルで管理されている動作環境と比較することで、デプロイ後の予期しない問題を簡単に特定することができます。またそれ以外にも、新しい機能や性能に関する情報が競合他社に漏れないのが明確な環境で、コンテナーベースのソフトウェアを導入してテストすることもできます。

パブリック/プライベートのハイブリッド

クラウドとオンプレミスでコンテナ展開を比較しているなら、別の観点から考えてみましょう:パブリッククラウドとプライベートクラウドの展開は基本的に互換性がないわけではなく、いろいろな意味でそれらの間には明確な境界線はありません。

これは、従来のモノリシックアプリケーション(例えば、プライベートサーバーに設置されたブラウザーベースのUIで外部から接続できるようなもの)にもあてはまりますが、コンテナーだとパブリックとプライベートの境界線がもっと流動的で曖昧になってきます。もちろん、それを使うのに適している時にのみですが。

例えば、パブリッククラウドにアプリケーションの大部分をコンテナーで配置し、オンプレミスのコンテナーでいくつかの機能のみ動かすこともできます。これにより、セキュリティやローカルデバイスへの接続などを段階的にコントロールすることができ、一方で同時にパブリッククラウドへの展開により柔軟性や接続性の確保、費用の優位性をうまく利用することもできます。

御社にとっての適切な組み合わせ

どのタイプの配置が御社に向いているか?
一般に、ハードウェアを使うことに密接に関係していないスタートアップ企業や中小企業は、クラウドへの移行(開始)は簡単でしょう。より大きな(事業が大きい)会社や、ローカルのハードウェアリソースを管理および制御する必要がある企業は、オンプレミスのインフラ設備を優先する傾向があります。こういった企業の場合、オンプレミスでコンテナーを展開することは、完全なパブリッククラウドまたはプライベート/パブリックのハイブリッド構成への架け橋を提供するでしょう。

最後に、パブリッククラウドかオンプレミスかという問いについての答えはつまり、会社毎の特定のビジネスニーズに全く依存しています。2つとして同じ企業はなく、2つとして同じソフトウェア構成はありません。しかし、ソフトウェアやITのゴールが何であれ、目標を達する計画がどうあれ、オンプレミスとパブリッククラウドの間には、そのプラン実行のために十分過ぎる柔軟性があるのです。

Michael Churchman started as a scriptwriter, editor, and producer during the anything-goes early years of the game industry. He spent much of the ‘90s in the high-pressure bundled software industry, where the move from waterfall to faster release was well under way, and near-continuous release cycles and automated deployment were already de facto standards. During that time he developed a semi-automated system for managing localization in over fifteen languages. For the past ten years, he has been involved in the analysis of software development processes and related engineering management issues.

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です