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

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

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

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

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

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

人はスケールしない

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

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

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

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

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

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

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

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

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