「人はスケールしない、仕組みが必要だ」 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が、その解になり得るかを考えます。

Copyright © ITmedia, Inc. All Rights Reserved.

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

注目のテーマ

AI for エンジニアリング
「サプライチェーン攻撃」対策
1P情シスのための脆弱性管理/対策の現実解
OSSのサプライチェーン管理、取るべきアクションとは
Microsoft & Windows最前線2024
システム開発ノウハウ 【発注ナビ】PR
あなたにおすすめの記事PR

RSSについて

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

メールマガジン登録

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