Kubernetesの利用が広がると、運用が大きな課題として浮上してくる。あるプロジェクトで経験を積み、知見を手に入れた人たちが出てきたとしても、社内の他のプロジェクトまで任せるのか。連載の第2回は、この問題を解決する方法を探る。
この記事は会員限定です。会員登録(無料)すると全てご覧いただけます。
第1回では、ハイブリッド/マルチクラウドの管理が注目される中で、IT管理者が抱える課題と、Kubernetes利用における解決の方向性を考察しました。要点は次の3つです。
今回は、「Azure Arc」でこうした取り組みをいかに支えられるか、そのコンセプトや特徴を、エピソードを交えて解説します。
以下のエピソードは、事実をもとにしたフィクションです。
ある企業が、新システムの基盤としてKubernetesを採用し、パブリッククラウド上に導入しました。背景には、変化の激しいビジネス環境への対応と、オープンソースエコシステムへの期待があります。その企業ではKubernetesの採用実績がなかったのですが、プロジェクトチームは試行錯誤しながらもこの技術を手の内に入れ、安定運用に至りました。
しかし、安定運用までの道のりは平坦(たん)ではなく、さまざまな課題が生じました。以下はインフラチーム視点での代表的な課題です。
このような課題に直面しながらも、プロジェクトメンバーは根気強く解決策や落としどころを見出し、成果を出しました。これが、社内で広く関心を集めることとなります。すると次に待っていたのは、他プロジェクトへの横展開です。インフラチームは得た知見を期待され、他プロジェクトも兼任で支援することになりました。
しかし、成功したプロジェクトも、それ自体がクラウドやKubernetesの急速な進化に追従しなければなりません。他プロジェクトに割ける時間は限られます。加えて、チームに経験のない他のクラウドやオンプレミスで動かしたい、という要望もありました。その結果、レビューは形骸化します。事前に気づき、解決できたであろう問題が、目立つようになります。
成功したプロジェクトをベースに全社的な共通基盤を作り、そこに相乗りすべきでは、という意見もありました。しかし、全社的に投資する合意を得るには時間がかかるでしょう。また、何か起こったときの影響の大きさを考えると、共通基盤を運用する自信は、まだありません。
エピソードは以上です。成功体験を持つ「人」は、簡単には増えません。人ではなく、その知見をスケールさせる「仕組み」はないものでしょうか。
以下では、Azureの持つリソース管理の仕組みとAzure Arcが、その解になり得るかを考えます。
Azure Arcの解説の前に、まずMicrosoft Azureがどのようにリソースの管理を行っているかを説明します。なぜなら、この仕組みがAzure Arcの基礎となるからです。
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やメモリの量を制限したり、リスクの高い設定が行われた場合に、作成を拒否したりできます。つまり、ガードレールを作れるわけです。
AKSクラスタへのGatekeeper(Azure Policyアドオン)の導入も、Azure Policyのポリシーで強制できます。そして、Azure Policyで設定したポリシーは、AKSクラスタと定期的に同期するため、クラスタ側で個別にポリシー設定、同期作業を行う必要はありません。
ポリシーは特定のリソースだけでなく、広いスコープへ割り当てることも可能です。Azureの基本管理単位であるサブスクリプションはもちろん、複数のサブスクリプションを束ねた管理グループに対しても割り当てられます。つまり、全社共通のポリシーを定義し、割り当てることができます。
人が得た知見は重要です。ですが、それを企業のポリシーとして広げるには、Azure Policyのような、人に頼らずスケールする仕組みが必要ではないでしょうか。なお、Azure Policyの組み込みポリシーには、Azureユーザーからの要望が継続的に取り入れられています。社内だけでなく、社外の知見も活用できると言えるでしょう。
Azure Arcは、シンプルに言えば、Azure Resource Managerと付加管理サービスの持つ機能を、Azureの外でも使えるようにするサービスです。
ただし、Azureのリソースに対してできることが、全て可能なわけではありません。オンプレミス、他クラウドにはそれぞれ固有の制約や差別化要素があり、Microsoftがコントロールできないことも多いからです。「何でも同じようにできます、頑張ります」などと無責任なことは言えません。よって、Azure Arcは現時点で、次のような割り切りをしています。
オンプレミス、複数のクラウドを使い分ける背景には、制約への準拠、それぞれの特徴やエコシステムへの期待などがあるでしょう。よって、全てをAzureから中央集権的に行い、インタフェースやツールを標準化することは、その背景の否定になりかねません。例えば、仮に私がAmazon Web Services(AWS)の利用者であったら、リソースのプロビジョニングにはAWSが提供するCloudFormationや、Terraformなどのオープンソースのツールを使いたいです。
Azure Arcでは、管理対象側の利用者、管理者の自発性を尊重します。Azure Arcの管理下にあるからといって、常にAzureを通じて操作しなければならない、ということはありません。Azure Arcはガードレール作りなど裏方の仕事を中心とし、必要に応じて付加機能を提供します。これは重要なコンセプトです。
今回は、管理者の課題を踏まえ、Azure Arcのコンセプトや特徴を、エピソードやアーキテクチャを交えて解説しました。ポイントは以下の通りです。
では次回から、Azure Arcの提供機能や内部構造を、より詳しく解説していきます。
Copyright © ITmedia, Inc. All Rights Reserved.
Cloud Native Central 記事ランキング