日立が懸念するインフラ担当者と開発者の「責任範囲の変化」　コンテナで拡大する“グレーゾーン”解決へ

従来のITインフラとコンテナではそもそも文化が違う

　コンテナの登場でITを取り巻く状況が急激に変化しており、「ITシステム自体に対する考え方が変わってきています。それに合わせて、ITインフラに対する考え方も変えなければなりません」と言うのは、株式会社日立製作所 マネージドサービス事業部 クラウドマネージドサービス本部 クラウドプロフェッショナルサービス部 技師の加藤雄三氏だ。

　オンプレミスの物理環境、仮想化やIaaSの運用において、ITインフラ担当者には信頼性や堅牢性の確保が求められていた。一方でコンテナを活用したDXでは、アプリケーション開発の柔軟性やスピードが重視される。そのため、ITインフラにも柔軟性やスピードなどが求められ、リソースを柔軟に変化させられるコンテナプラットフォーム「Kubernetes」を採用することになる。

　このコンテナやアジャイル開発などの新しい技術への取り組みについては、ITインフラ担当者よりもアプリケーション開発者が積極的だ。そのため、コンテナやKubernetesについては、アプリケーション開発者のほうが良く知っている。一方、不慣れなITインフラ担当者は、コンテナやKubernetes環境をどのように提供し、どこまで責任をもって対処すれば良いのかに頭を悩ませているのだ。

　コンテナ以前の時代、ITインフラ担当者は安定性のある環境を提供し、アプリケーション開発者はその上で開発を行うといったように、双方の責任の境界は比較的ハッキリとしていた。しかしながら、そこにコンテナという新たな管理層が生まれたことで状況は一変する。コンテナの設計図となるマニフェスト（Manifest）などは、アプリケーション開発側で用意することが多い。そうなると、実際にコンテナをオーケストレーションして管理するところまでは、アプリケーション開発者が行うことになるだろう。さらにKubernetesの運用や管理まで、先にノウハウを身に付けたアプリケーション開発者が担うことも珍しくない。

　アプリケーション開発者は、俊敏性や柔軟性を得てアプリケーション開発を楽にしたくてコンテナを使い始めたはずだ。ところが、いつのまにかコンテナやKubernetesの管理まで担っているのが現状である。加えて、もし採用したものがOSS（オープンソースソフトウェア）のKubernetesであれば、運用管理や更新には大きな手間が余計にかかる。

　もちろん「VMware Tanzu」や「Red Hat OpenShift」などを選んだとしても、それらが混在していたり、稼働環境にオンプレミスやクラウドが混在していたりすれば、ITインフラがばらばらで統制を効かせることはかなり難しくなる。そのような状況では、アプリケーション開発者は開発に注力できない。

　コンテナで俊敏性を得たければ、アプリケーション開発者が自由にリソースを用意可能な状態にし、すぐに使えるようにすることが理想といえるだろう。それを実現できる点こそが、コンテナのメリットでもある。

　一方、ITインフラ側から見れば、アプリケーション開発者に勝手にリソースを使われるとガバナンスが効かなくなり、組織全体として信頼性や安定性を担保することが難しくなる。

　たとえば、セキュリティ面においても、コンテナイメージの脆弱性はITインフラとアプリケーション開発のどちらが担保すべきかの判断は迷いどころだ。「通常はイメージに作り上げるところまではアプリケーション開発側で、デプロイした後のコンテナの改ざんを防ぐなどの対策はITインフラ側でしょう」と加藤氏。本番運用のコンテナ環境については、不慣れであってもITインフラ側で責任を負うべきだと考えるケースは多いだろう。

　コンテナ環境でセキュリティを担保するには、コンテナイメージのデプロイ後のルールを決め、あらかじめアプリケーション開発とITインフラでしっかりと調整する必要がある。アプリケーション開発者はルールを守ったコンテナイメージを作らなければならず、それを本番環境にデプロイする際にはセキュリティルールに合致しているかを、ITインフラ側でも確認する必要があるのだ。