「人はスケールしない、仕組みが必要だ」 Kubernetes運用の現実Azure Arcで学ぶクラウドとKubernetesのガードレールづくり(2)

Kubernetesの利用が広がると、運用が大きな課題として浮上してくる。あるプロジェクトで経験を積み、知見を手に入れた人たちが出てきたとしても、社内の他のプロジェクトまで任せるのか。連載の第2回は、この問題を解決する方法を探る。

» 2022年01月11日 05時00分 公開
[真壁 徹日本マイクロソフト]

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

 第1回では、ハイブリッド/マルチクラウドの管理が注目される中で、IT管理者が抱える課題と、Kubernetes利用における解決の方向性を考察しました。要点は次の3つです。

  • 標準化の前に、ガードレールを
  • 管理者も、使い手とともに学ぶ
  • 意思のある使い手の、自発性を尊重する

 今回は、「Azure Arc」でこうした取り組みをいかに支えられるか、そのコンセプトや特徴を、エピソードを交えて解説します。

人はスケールしない

 以下のエピソードは、事実をもとにしたフィクションです。

 ある企業が、新システムの基盤としてKubernetesを採用し、パブリッククラウド上に導入しました。背景には、変化の激しいビジネス環境への対応と、オープンソースエコシステムへの期待があります。その企業ではKubernetesの採用実績がなかったのですが、プロジェクトチームは試行錯誤しながらもこの技術を手の内に入れ、安定運用に至りました。

 しかし、安定運用までの道のりは平坦(たん)ではなく、さまざまな課題が生じました。以下はインフラチーム視点での代表的な課題です。

  • アプリケーションがメモリを制限なく消費したことで、システムコンポーネントの停止(OOM Kill)につながり、エラーが多発した
  • Kubernetes固有の脅威を学びながら、その都度マニフェストへの反映をアプリケーションチームに依頼したため、工数だけでなく心理的負担が重かった
  • 生じた課題をアプリケーションチームとインフラチームのどちらが主体的に解決すべきか、責任分界点を模索し続けた(まだきれいな線は引けていない)

 このような課題に直面しながらも、プロジェクトメンバーは根気強く解決策や落としどころを見出し、成果を出しました。これが、社内で広く関心を集めることとなります。すると次に待っていたのは、他プロジェクトへの横展開です。インフラチームは得た知見を期待され、他プロジェクトも兼任で支援することになりました。

 しかし、成功したプロジェクトも、それ自体がクラウドやKubernetesの急速な進化に追従しなければなりません。他プロジェクトに割ける時間は限られます。加えて、チームに経験のない他のクラウドやオンプレミスで動かしたい、という要望もありました。その結果、レビューは形骸化します。事前に気づき、解決できたであろう問題が、目立つようになります。

 成功したプロジェクトをベースに全社的な共通基盤を作り、そこに相乗りすべきでは、という意見もありました。しかし、全社的に投資する合意を得るには時間がかかるでしょう。また、何か起こったときの影響の大きさを考えると、共通基盤を運用する自信は、まだありません。

 エピソードは以上です。成功体験を持つ「人」は、簡単には増えません。人ではなく、その知見をスケールさせる「仕組み」はないものでしょうか。

 以下では、Azureの持つリソース管理の仕組みとAzure Arcが、その解になり得るかを考えます。

Azureのリソース管理「Azure Resource Manager」の仕組み

 Azure Arcの解説の前に、まずMicrosoft Azureがどのようにリソースの管理を行っているかを説明します。なぜなら、この仕組みがAzure Arcの基礎となるからです。

図1 Azureのリソース管理の中核となるAzure Resource Manager

 Azureの利用者や管理者は、ポータルやCLI、SDKを使ったツールを介し、APIを呼び出すことでAzureのリソースを操作します。そして、APIの先にあるのが、Azureのリソース管理の中核である「Azure Resource Manager」です。認証・認可や監査など、Azureのリソースの管理に共通する機能を提供します。そして、管理対象リソースの種類ごとに固有の管理を行う、リソースプロバイダーを管理下に置きます。また、監視、構成管理、セキュリティなどの付加管理サービスが、Azure Resource Managerを補強します。

 前の節で、プロジェクトで得た知見を他で活用できなかったエピソードを紹介しました。Azure Resource Managerには、それを解決し得る仕組みがあります。その代表例が、ポリシーの定義、評価機能です。サービス名が付いており、「Azure Policy」と言います。

 Azure Policyは、リソースの操作時に操作内容が定義したポリシーに準拠しているかを評価します。また、定期的にリソースの状態の評価も行います。評価した結果、準拠していない場合には、操作の拒否、監査ログへの記録、必要なリソースの追加や変更などの作業を代行します。Azureの各種リソース向けに多様な組み込みポリシー定義が提供されており、加えてカスタムポリシーを作ることもできます

 例えばAzure Policyには、「Azure Kubernetes Service(AKS)」向けの組み込みポリシーがあります。このポリシーは、Azure PolicyとAKSクラスタ上のGatekeeperが連動して機能します。具体的には、アプリケーション開発者がコンテナを作成する際に利用できるCPUやメモリの量を制限したり、リスクの高い設定が行われた場合に、作成を拒否したりできます。つまり、ガードレールを作れるわけです。

図2 Azure PolicyによるAKSクラスタへのポリシー適用

 AKSクラスタへのGatekeeper(Azure Policyアドオン)の導入も、Azure Policyのポリシーで強制できます。そして、Azure Policyで設定したポリシーは、AKSクラスタと定期的に同期するため、クラスタ側で個別にポリシー設定、同期作業を行う必要はありません。

 ポリシーは特定のリソースだけでなく、広いスコープへ割り当てることも可能です。Azureの基本管理単位であるサブスクリプションはもちろん、複数のサブスクリプションを束ねた管理グループに対しても割り当てられます。つまり、全社共通のポリシーを定義し、割り当てることができます。

 人が得た知見は重要です。ですが、それを企業のポリシーとして広げるには、Azure Policyのような、人に頼らずスケールする仕組みが必要ではないでしょうか。なお、Azure Policyの組み込みポリシーには、Azureユーザーからの要望が継続的に取り入れられています。社内だけでなく、社外の知見も活用できると言えるでしょう。

Azure Arcって結局何? そのアーキテクチャと割り切り

 Azure Arcは、シンプルに言えば、Azure Resource Managerと付加管理サービスの持つ機能を、Azureの外でも使えるようにするサービスです。

図3 Azure Arcのアーキテクチャ

 ただし、Azureのリソースに対してできることが、全て可能なわけではありません。オンプレミス、他クラウドにはそれぞれ固有の制約や差別化要素があり、Microsoftがコントロールできないことも多いからです。「何でも同じようにできます、頑張ります」などと無責任なことは言えません。よって、Azure Arcは現時点で、次のような割り切りをしています。

  • Azureからのプッシュではなく、管理対象側から必要な情報をAzureへ送信、取得する(管理対象側のファイアウォールに内向きの穴を空けない)
  • 管理対象の作成は、オンプレミスや他クラウドで、やりやすい方法で行う(いわゆるブートストラップは範囲外)
  • 管理対象へ、自律的に動作するエージェントを導入する
  • 管理対象を代表的、機能拡張性のあるプラットフォーム(Windows/LinuxサーバとKubernetes)にフォーカスする
  • Kubernetesの機能拡張性を活用し、さまざまな付加機能(データサービスなど)を提供する
  • 管理対象の利用者や管理者は、好きなツールを使って操作する(全ての操作がAzure経由になるわけではない)

 オンプレミス、複数のクラウドを使い分ける背景には、制約への準拠、それぞれの特徴やエコシステムへの期待などがあるでしょう。よって、全てをAzureから中央集権的に行い、インタフェースやツールを標準化することは、その背景の否定になりかねません。例えば、仮に私がAmazon Web Services(AWS)の利用者であったら、リソースのプロビジョニングにはAWSが提供するCloudFormationや、Terraformなどのオープンソースのツールを使いたいです。

 Azure Arcでは、管理対象側の利用者、管理者の自発性を尊重します。Azure Arcの管理下にあるからといって、常にAzureを通じて操作しなければならない、ということはありません。Azure Arcはガードレール作りなど裏方の仕事を中心とし、必要に応じて付加機能を提供します。これは重要なコンセプトです。

今回のまとめ

 今回は、管理者の課題を踏まえ、Azure Arcのコンセプトや特徴を、エピソードやアーキテクチャを交えて解説しました。ポイントは以下の通りです。

  • 人はスケールしないため、管理できる範囲を広げるにはAzure Resource Managerのような仕組みが必要
  • Azure Arcは、Azure Resource Managerと付加管理サービスの対象範囲をAzure外へと広げるもの
  • Azure Arc管理下にあっても、それぞれの管理対象に適した操作、ツールの利用が可能

 では次回から、Azure Arcの提供機能や内部構造を、より詳しく解説していきます。

筆者紹介

真壁徹

日本マイクロソフト株式会社

シニアクラウドソリューションアーキテクト

企業におけるクラウドの可能性を信じ、ユーザーと議論、実装、改善を行う日々。アプリもインフラも好物。

趣味はナイスビール。

Copyright © ITmedia, Inc. All Rights Reserved.

スポンサーからのお知らせPR

Cloud Native Central 記事ランキング

本日月間

注目のテーマ

4AI by @IT - AIを作り、動かし、守り、生かす
Microsoft & Windows最前線2025
AI for エンジニアリング
ローコード/ノーコード セントラル by @IT - ITエンジニアがビジネスの中心で活躍する組織へ
Cloud Native Central by @IT - スケーラブルな能力を組織に
システム開発ノウハウ 【発注ナビ】PR
あなたにおすすめの記事PR

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。