「人はスケールしない、仕組みが必要だ」　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はガードレール作りなど裏方の仕事を中心とし、必要に応じて付加機能を提供します。これは重要なコンセプトです。