時代に逆行したハイブリッド／マルチクラウド管理への期待が本末転倒な理由：AzureArcで学ぶクラウドとKubernetesのガードレールづくり（1）

「ハイブリッド／マルチクラウド管理」という言葉がよく聞かれるようになってきました。しかし、その意味は曖昧です。そして、実際の「ハイブリッド／マルチクラウド管理」ソリューションは、ユーザー組織の管理者が抱く期待とずれているようにも思えます。なぜなのでしょうか。連載第1回では、これを見ていきます。

» 2021年11月17日 05時00分公開

[真壁徹，日本マイクロソフト]

この記事は会員限定です。会員登録（無料）すると全てご覧いただけます。

　「ハイブリッド／マルチクラウド管理」という言葉がよく聞かれるようになってきました。しかし、「ハイブリッド」「マルチ」「管理」は、どれも文脈や期待によって指すものがさまざまで、曖昧な言葉です。このため、「ハイブリッド／マルチクラウド管理」というコンセプトは、誤解を招きやすくもあります。

　この連載では、Microsoft Azure（Azure）のハイブリッド／マルチクラウド管理サービスである「Azure Arc」を例に、Kubernetesの利用を中心とした管理を管理者とユーザー双方の視点から解説します。第1回は、システム管理者が抱える課題と、解決の方向性を考察します。

複数を統合管理するという総論はいいが……

　ビジネスにおいて、複数の選択肢を持つことには価値があります。例えば技術や素材の供給元が複数あれば、競争による技術革新やコストダウンが期待できます。また、依存リスクも緩和できるでしょう。このため、複数の何かを組み合わせる「ハイブリッド」「マルチ」というコンセプトは、大枠では受け入れやすいものです。

　現在、エンタープライズITの世界は、クラウドの本格活用に向けた過渡期にあります。従って、オンプレミスとクラウド、また複数のクラウドを組み合わせて使いたい、というニーズが生まれるのは自然です。それに伴い、「ハイブリッド」「マルチ」クラウド「管理」をうたうソリューションが目立つようになりました。

　しかし筆者は、こうしたソリューションに管理者がピンときていないように感じています。

管理者が実際のソリューションにピンとこない理由

　ITにおける「管理」が指す行為や活動は、使い手や受け手、文脈によって異なります。例えば、リソースの作成や削除、死活や性能の監視、資産やコストの可視化など多様です。そもそも、「管理者の期待とソリューションが提供するカテゴリーが異なる」、これがピンとこない原因の1つ目です。「ハイブリッド／マルチクラウド管理」という言葉自体には、行為や活動、つまり管理タスクについての情報がありません。何ができるのか明確でなく、分かりにくいのも当然です。ベンダーは伝え方を工夫すべきです。

　そして、もう１つの原因は、期待するアプローチとのギャップです。筆者の経験では、多くの管理者が「標準化」を望んでいるようです。

「オンプレミスで標準化している管理タスクをそのままクラウドでも実行したい」
「クラウドAとクラウドBの標準ポータルを作って、できることを統一したい」

　これらのアプローチに合うソリューションが見つからないという声を、しばしば耳にします。

　この標準化志向が、ピンとこない元凶ではないかと考えています。

行き過ぎた標準化志向が習熟を阻む

　ITはいまや、生産性向上のための道具だけでなく、自社の製品やサービスを差別化するための武器となりました。「クラウドからリソースを」「オープンソースソフトウェアからコードを」「コミュニティーから知を」得やすくなったいま、それらを生かした差別化やイノベーションは組織にとって重要なテーマです。そのためには、ユーザー企業自らが経験を重ね、手の内に入れなければなりません。しかし「行き過ぎた標準化志向」が、その機会を奪っているようです。

　クラウドで、オンプレミスではできないことに挑戦するなら、オンプレミスと同じルールで標準化するのはナンセンスです。また、競争により各クラウドベンダーが技術革新を起こしている中、特徴ある機能やサービスを過度に避けるのは、作るシステム、ひいてはビジネスの競争優位を築きたいのであれば本末転倒でしょう。

　オンプレミスとクラウド、また、複数のクラウドでの標準化が特に難しいカテゴリーは、リソースの作成や構成管理です。オンプレミスのリソースをクラウドのように操作するにはAPIがなく、複数のクラウドのAPIに対応するには膨大な投資が必要、などの理由から、万能なツールを求めるのも現実的ではありません。

　管理者がクラウド利用の標準化を試みたり、期待するツールの登場を待ったりしている間に、利用する側のフラストレーションは増大します。例えば、クラウドでのリソース作成作業は全て管理者が行い、利用者は管理者が用意した表計算シートに記載されているパラメーターしか選択できない、といった状況です。結果として、陰に隠れてクラウドを利用するアプリケーション開発者が増えます。いわゆる“野良クラウド”です。

「標準化」を進める前に、「ガードレール」という考え方を

　もちろん、標準化には利点があります。しかし、経験がなければ価値のある標準は作れません。オンプレミスで標準を確立できていたとすれば、それまでの経験を生かしていたからではないでしょうか。クラウドでも同様です。もちろん、ベンダーやコミュニティーが公開、共有しているクラウドのベストプラクティスは標準化の参考になります。しかし、実感の裏付けがない、お仕着せのベストプラクティスを採用しても、変化や思い付きに影響され、長続きしないものです。手を動かさなければ、手の内には入ってきません。

　それよりも、チームやプロジェクトに裁量を与え、経験を積ませつつリスクから保護する、そして周囲も守るような「ガードレール」を作るという感覚が、クラウドの管理にフィットすると筆者は考えています。交通規則や設備、車の仕様を全て決めてからでないと走れない、ではなく、保護されたガードレールの内側で自由度高く走り、外側の歩行者や器物も守る、というアプローチです。道路に入る前に、走る機会を奪うべきではありません。

ガードレールが有効な典型例はKubernetes

　コンテナの価値に注目が集まる中、その代表的なオーケストレーターであるKubernetesに挑戦する組織が増えています。アプリケーションとインフラ、どちらの視点でも従来にない概念に富んでおり、手を動かさないと理解できない技術の典型例です。さて、もしあなたが管理者で、Kubernetesのノウハウがない状態で標準化、ルール作りを求められたらどうしますか。なおKubernetesは活発に開発が進み、日々進化しています。作ったルールを、どのように変化へ追従させればよいでしょうか。

　筆者は、管理者がその時点ではノウハウがないことを認め、アプリケーション開発者など利用者とともに学んでいけばいい、と考えます。まずガードレールを作り、リスクを緩和しつつ、ノウハウを蓄積するのです。

　クラウドでのKubernetesは、コマンド1つで環境（クラスタ）を作れます。AzureのAzure Kubernetes Service（AKS）であれば「az aks create」、Google CloudのGoogle Kubernetes Engine（GKE）であれば「gcloud container clusters create」コマンドを打つだけです。「標準化」の名の下に利用を禁止、制限していては、野良Kubernetes環境が増えるだけでしょう。そうではなく、利用者に環境の作成を認め、何らかのポリシーに従い、リスクの高い特定の操作を拒否、補完、監査する方が生産的です。

　なお、Kubernetesは、クラスタを「どのように作るか」よりも、「どのように使い、維持するか」のほうが重要です。前述の通り、クラスタを作ることは難しくありません。そして、作る時点でチェックできることは限られています。それよりも、クラスタの作成後、その上で動き、増えていくアプリケーションとその設定を継続的にケアすべきです。

　「ガードレール」という例えは、Kubernetesの世界では主にセキュリティの文脈で使われています。しかし、セキュリティに限らず、他のリスクからの保護も含みます。その1つは可用性です。例えばアプリケーションコンテナがメモリを過大に消費し、システム全体の動作に影響を及ぼす事例は多くあります[^1]。このようなケースでは、「メモリの利用可能量を制限する」「条件に合わないアプリケーションの作成を拒否する」などのポリシーを適用し続けることで、リスクを軽減できます。

　初めは、ベンダーやコミュニティーから得たアイデアを基にポリシーを作ってもいいでしょう[^2]。そして、ノウハウや経験を積みながら充実させ、適用範囲を広げればいいのです。ガードレールに加え、標識や信号などの交通システムを高度化し、街や都市全体に広げていく感覚です。

意思のある使い手には、手段を任せる

　筆者はこれまで、クラウドを利用する多くのプロジェクトを支援してきました。成功しやすいと考えるパターンが幾つかあります。その1つが、自発性のあるチームです。必要な情報を主体的に調査し、使いたいツールを自ら選定するようなチームです。全てのプロジェクト、チームがそうあるべきとまでは思いませんが、差別化し、それを維持していく領域では、チームの自発性は成功要因です。

　となると、ツールなどの手段は使い手に任せた方がうまくいきます。押し付けられたものよりも、自ら選んだものの方が、当然ながら利用と改善の動機づけになりやすいからです。例えば、Kubernetesや、これを含めたインフラのプロビジョニング（構成）ツールには多くの選択肢があります。クラウドベンダーが提供する標準ツールやサービスから、「Terraform」や「Ansible」など人気のあるオープンソースソフトウェアまでさまざまです。いずれも急速な機能追加、バージョンアップが続いています。習熟と追従には動機が必要です。

　もちろん、技術選定を使い手に委ねると、組織としてのノウハウがたまらないという懸念はあります。使い手が「決めてもらった方が楽で早い」と考える場合もあるでしょう。従って、全てを使い手に任せなければならない、というわけではありません。使い手が意思を持っている場合には尊重できる仕組みを、ということです。得てして、意思のあるチームの成功事例が、組織で横展開できるようになっていくものではないでしょうか。

　そして、手段やツールの選択を利用者に委ねるのであれば、同時にリスクから保護する仕組みも求められます。これが、ガードレールが必要なもう1つの理由です。