クラウドオペレーションの厄介なジレンマを克服する複合的なアプローチ：Gartner Insights Pickup（186）

誰がクラウドオペレーションについての責任を持つのか――。1つの解はない。オペレーションアプローチには多くの選択肢があり、企業の個別状況によって最適な選択肢は異なる。

[Lydia Leong, Gartner]

ガートナーの米国本社発のオフィシャルサイト「Smarter with Gartner」と、ガートナー アナリストらのブログサイト「Gartner Blog Network」から、＠IT編集部が独自の視点で“読むべき記事”をピックアップして翻訳。グローバルのITトレンドを先取りし「今、何が起きているのか、起きようとしているのか」を展望する。

　クラウドオペレーションの責任は、社内で政治的な駆け引きの対象になりがちだ。

　時には、誰もこの責任を負おうとしない場合もある。これは開発の負担を押し付け合っている場合と同様に見える。逆に、誰もがこの責任を負いたがる場合もある。一部の経営幹部は、クラウドオペレーションを管理下に置くことが、次の昇進や多額のボーナス、転職時のアピールポイントにつながると考える。

　また、開発者とインフラ＆オペレーション（I＆O）チームは、しばしばクラウドオペレーションを巡って衝突する。CIO（最高情報責任者）が、クラウドセンターオブエクセレンス（CCOE）チームにクラウドオペレーションを任せようと決めるケースもある。もともと、CCOEはクラウドのアーキテクチャとガバナンスを手掛ける組織として生まれたが、クラウドに関する何でも屋と化している。

　どこがクラウドオペレーションについての責任を持つかについて、そしてこのオペレーションを行うさまざまな方法について、多くの議論が交わされている。基本的にリフト＆シフトでクラウドに移行され、めったに変更が発生しない“退屈な”ものと、変化が速いアジャイルなものでは、クラウドオペレーションに関する議論がぶつかるのは避けられない。IaaS、PaaS、SaaSのさまざまなアプローチについても、多様な議論がある。これらをはじめ、クラウドオペレーションに関する議論はネタに事欠かない。

　実際、さまざまな個々の問いに対する複数の答えがあるのだろう。1つの万能なアプローチは存在しない。オペレーションアプローチは、ビジネスニーズに合わせる必要がある。マルチクラウド環境で共通のアプローチを取っても、主要なハイパースケールプロバイダーごとに専門チームを設置すべきかもしれない（Azureと非Azure――つまり、「Microsoft Azure」と「Amazon Web Services（AWS）」というチーム分けが一般的だ。多くの場合、この区分はWindowsベースアプリケーション環境とLinuxベースアプリケーション環境という区分と密接に相関している）。

　クラウドオペレーションにおいて、高度な自動化やアジリティ、クラウドネイティブ、開発者と運用担当者の協力（つまり、DevOps）を実現できれば理想的だ。ただし、それを常に目指す必要はないだろう（全てのアプリケーションが活発に開発されているわけではないため）。

　さらに、基本的なオペレーションアプローチを1つまたは複数選んだら、クラウド構成やリリースエンジニアリング、セキュリティの責任をどう扱うかを考えなければならない（適切に扱うために必要なスキルアップについても）。

　そこで人々は行き詰まってしまうことが多い。「現実的に、開発チームにどれだけの責任を任せられるか」「開発チームはどれだけの責任を負いたいか」「時間とともに、新しいオペレーションアプローチを徐々にどのように導入するか」「このアプローチを既存のCI／CD（継続的インテグレーション／継続的デリバリー）、アジャイル、DevOpsの取り組みにどのように組み込むか」といった問題に直面するからだ。

　1つの正解はない。だが、ほぼ常に間違っている1つの答えがある。それは、クラウドオペレーションをI＆Oの機能別チームで分担するというものだ。これではクラウドオペレーションがサイロ化されてしまう。サーバチームが「Amazon EC2」の仮想マシンを扱い、「NetApp」ストレージ管理者が「Azure Blob Storage」を扱い、F5 Networks製品の専門家がGoogleの「Cloud Load Balancing」を構成し、ファイアウォールチームとネットワークチームが、仮想プライベートクラウド（VPC）の構成を誰が管理するかで対立する（あいにく、仮想ファイアウォールアプライアンスを購入することで決着することが多い）といった具合だ。

　このアプローチが取られると、管理者は必ずと言っていいほど、クラウドポータルをハードウェアの最新のポイント＆クリックインタフェースのように扱ってしまう。これでは、運用能力低下や調整不足、著しい非効率に陥るのはほぼ確実だ。クラウドの利用規模にかかわらず、通常、悲惨な結果につながる。残念ながら、このアプローチは、ほとんどの人が最初に試すものだ（そしてすぐ後に、クラウドの導入初期に付き物の、全てをクラウドに関連付けたいという要望に伴い、一部のクラウドアーキテクトに過大な負担が掛かる）。

　ほとんどの企業に有効なアプローチは、クラウド管理を“プロダクト”のように扱う、クラウドプラットフォームのオペレーション形態だ。それはほとんど社内クラウドMSP（マネージドサービスプロバイダー）のアプローチだ。

　このアプローチでは、クラウドプラットフォームオペレーションチームが、CMP（クラウド管理プラットフォーム）スイートや、クラウドベースのCI／CDパイプライン統合、テンプレート、自動化、その他のクラウドエンジニアリングを提供する。必要に応じて、コーダーやアプリケーション開発チームにコンサルティングも提供する。

　一般的に、このチームはオンコールでインシデントにも対応するが、通常、NOC（ネットワークオペレーションセンター）などやインシデント管理チームがインシデントレスポンスの最前線を担う。

　ただし、クラウドオペレーションのアプローチは多くの選択肢があり、企業の個別状況によって最適な選択肢は異なる。選択の観点としては、手法としてのメリットとデメリットを論理的に分析する、クラウドエンジニアリング、運用、管理のタスク、役割分担、コーダーの責任、セキュリティ統合などが挙げられる。

出典：The messy dilemma of cloud operations（Gartner Blog Network）

筆者　 Lydia Leong

VP Distinguished Analyst