編集部からのお知らせ
新着PDF集:データセンターの省電力化
「これからの企業IT」の記事はこちら
海外コメンタリー

DevOpsの3つの形態、最適なアプローチは?--開発主導、運用主導、プラットフォーム2.5

Keith Townsend (Special to TechRepublic) 翻訳校正: 村上雅章 野崎裕子

2015-08-04 06:30

 DevOpsの採用によって、アジリティという大きな利点が得られる。その利点を実際に手にできるかどうかは、DevOpsの実現に向けてどのようなアプローチを選択するかにかかっているのではないだろうか。


DevOpsに向けた戦略は「HP Discover」カンファレンスでも大きなテーマとなっていた。
提供:Keith Townsend

 業界にかかわらず、既存の因習にとらわれている企業は、DevOpsのことをアジリティ向上のための手段として捉えがちだ。しかし、DevOpsの方法論はプライベートクラウド対パブリッククラウドという議論と同じように、技術力に関する話にはなり得ない。DevOpsの有効活用は組織で取り組む難題なのだ。本記事では、開発部門主導と運用部門主導、プラットフォーム2.5型の環境という3つの形態に分けてDevOpsを考察している。

開発部門主導のDevOps

 DevOpsの実現例で最も人目を引くのが開発部門主導によるものだろう。この形態を指して、「コードとしてのインフラ」(Infrastructure-as-Code)と呼ぶ人もいる。

 Netflixは、テクノロジに注力しているという観点で、DevOpsという文化を最もうまく体現している企業だ。同社では、アプリケーション開発部門がインフラを統制している。より正確に言えば、アプリケーションの管理プレーンがインフラを主導している。例として、可用性の高さ(HA)を見てみよう。

 アプリケーションは、土台となるインフラに障害が発生した場合でも運用を継続するように設計されている。つまり、アプリケーションのフロントエンドをホストしている仮想マシン(VM)が停止した場合、アプリケーションの管理プレーンが新たなインスタンスを起動する。また、アプリケーションの設定をホストするオブジェクトストアが停止した場合、アプリケーションの管理プレーンが冗長化されたデータソースへの切り替えを行う。

インフラに依存した開発

 従来のインフラでは、開発部門はインフラ担当チームのお客さんという位置付けとなっている。このためインフラ担当チームは、可用性の高いインフラを開発部門に提供し、開発部門が土台となるインフラを意識せずにアプリケーションを開発できるようにする必要がある。つまり、開発部門はアプリケーション内にインフラの管理プレーンを作り込むのではなく、個々のOSに委譲することになる。そしてインフラ担当チームは、障害回復力の高いOSをインフラとして提供するというわけだ。結果的にアプリケーションの可用性は、インフラ担当チームが管理する冗長性の高いインフラに依存することになる。

 アプリケーションの設計アプローチに見られる違いに目を向ければ、開発部門主導のDevOpsという形態に移行する際の問題が明らかになる。今日におけるエンタープライズアプリケーションの大半は、従来のインフラを前提に置いて設計されている。そして従来型の企業には、開発部門主導のDevOpsを考慮したアプリケーション要求がほとんど存在していない。そのうえ、更地のようなインフラを統制するアプリケーションを配備できるだけの十分な知識を有した開発者も多いとは言えず、十分な数のインターフェースを取りそろえた成熟したデータセンターもずっと少ない。

ZDNet Japan 記事を毎朝メールでまとめ読み(登録無料)

特集

CIO

モバイル

セキュリティ

スペシャル

NEWSLETTERS

エンタープライズ・コンピューティングの最前線を配信

ZDNet Japanは、CIOとITマネージャーを対象に、ビジネス課題の解決とITを活用した新たな価値創造を支援します。
ITビジネス全般については、CNET Japanをご覧ください。

このサイトでは、利用状況の把握や広告配信などのために、Cookieなどを使用してアクセスデータを取得・利用しています。 これ以降ページを遷移した場合、Cookieなどの設定や使用に同意したことになります。
Cookieなどの設定や使用の詳細、オプトアウトについては詳細をご覧ください。
[ 閉じる ]