コンテナ技術導入の成否を分ける非技術的要因とは？体制／役割設計の重要性テクニカルレポート

R&D本部 DI部 シニアITアーキテクトの小林です。サーバー仮想化基盤（Hypervisor）製品最大手のVMware社がブロードコム社に買収され製品戦略が大きく変わったことから、各企業はサーバー仮想化基盤を再構築するか否かの判断を迫られています。
選択肢としては「VMware社製品を継続する」「競合他社の製品へ切り替える」「業務アプリケーションのつくりを、VMベース（ソフトウエア技術により構築された仮想的なコンピューター環境）からコンテナベース（アプリケーションの実行環境をパッケージ化し、軽量で移植可能にする技術）へ変更する」といったものがあります。

これをきっかけに、サーバー仮想化基盤のあり方ひいては ITシステムそのものの在り方を見直そうという機運が高まっています。それは従来型のITシステムの開発／運用は、さまざまな課題を抱えているからです。
例えば、下記のような状況が挙げられます。

変化への迅速な対応という高い生産性と、本番障害の削減という作業品質向上のニーズは高まるばかりです。
本稿では、コンテナ技術導入の成功を左右する非技術的要因（開発体制・責任分担の見直しなど）について解説します。

従来の企業ITシステムは、サーバーOSやミドルウエアを統一し（標準化）、その指定された稼働環境を所与のもの（変えられない前提）として業務アプリケーションを開発します。
これは、「基幹系のような重要なITシステムを安全に開発する」「運用部門がさまざまなITシステムを一括して運用する」「ソフトウエアライセンス費用を最適化する」うえで、合理的な手法でした。
しかし指定された稼働環境で提供されないミドルウエアなどは、採用を諦めるか、自ら作りこむかなど、イレギュラーな対応をする必要が生まれることと表裏の関係にあります。

VMベースによるこの問題の答えの1つとして、コンテナ技術が注目されています。
コンテナ技術はパッケージング技術なので、そこで動かすITシステムを稼働させるのに必要最小限のソフトウエアで構成でき、極論すれば標準化自体しなくても安全に稼働させることができます。

特にマイクロサービスアーキテクチャーを採用する場合、このことは大きなメリットです。マイクロサービスは独立性が高い機能として開発されます。コンテナ技術を採用すれば、開発時点での最新ライブラリーの採用など、ソフトウエア選定の縛りは少なくなり開発効率的が向上します。運用面でも、コンテナ間でライブラリーのバージョンコンフリクトなどが起きないことから高い運用効率が期待できます。

コンテナ技術は、開発効率向上／品質向上／環境差異の解消が可能となりますが、そのかわりに、業務アプリケーション開発SEとインフラ構築SEの責任範囲を再定義する必要が生じます。
前述のように従来のVMベースのITシステムは、OSやミドルウエアの製品やバージョン／エディションを統一しており、インフラ構築SEはそれらのソフトウエアスタックを業務アプリケーション開発SEへ提供することに責任を持っていました。
しかし、コンテナ技術により業務アプリケーション開発SEがソフトウエアスタックを自由に構成できるようになると、誰がミドルウエアの構築や設定に責任を持つのか、という問題が新たに発生します。

この問題は、業務アプリケーション開発部門とインフラ構築部門を別組織として抱えるような大規模なITベンダーになるほど深刻になる傾向にあります。

プロジェクト体制構築時に業務アプリケーション開発SEとインフラ構築SE間の責任境界を決定しておくことで、この問題の深刻化を回避します。
この決定が遅れると、「必要なスキルを持つ人材のアサインができなくなる」「両者の認識のズレから必要なタスクが漏れる」など、スケジュールインパクトを伴うような問題に発展する恐れが出てきます。
境界を設定する上での制約として、開発メンバーのスキルだけでなく企業ポリシーなど技術力以外のものもありますので、PM（プロジェクトマネージャー）には、このようにさまざまな要素への目配りが求められます。

コンテナ技術と聞いてまず思い浮かぶのは、開発環境からテスト環境、本番環境までコンテナイメージに手を加えずにさまざまな環境で稼働できることでしょう。この可搬性はコンテナ技術の最大の特長といってよく、開発効率（生産性）やリリース障害回避などさまざまな恩恵をもたらします。
また、テスト環境をクリアしたバイナリイメージをそのまま準本番（ステージング）／本番環境へ持っていけることで、設定不備／環境差異による障害におびえずに済みます。

ただし、テスト環境からそのまま本番環境へ持っていけるということは、テスト環境でコンテナを稼働させる時点で、本番環境と同じソフトウエアスタックや設定を含んでいる必要があるということになります。例えば、監視エージェントやセキュリティチェックエージェントなどが典型的です。

従来はVM単位で各種エージェントが導入されており、業務アプリケーションは運用周りのソフトウエアなどは考慮する必要がありませんでした。
しかし、コンテナはVM上の各種エージェントを共有することはできません。そのため、個々のコンテナにそれらを含めなければなりません。
そのように、本番運用において必要となるエージェントなどを誰が（テストフェーズ初期から）コンテナに組み込むのかという問題が発生します。これは前述の責任境界の話と同じ話でもあります。

プロジェクトの早期に決めておくべきこととして、この境界だけでなく、開発プロセス（手順）も含まれます。

インフラ構築SEが本番運用を見据えたコンテナイメージを作成し、レジストリへ登録します（①～⑤）。
業務アプリケーション開発SEは、そのコンテナイメージに業務アプリケーションならびにその稼働に必要なソフトウエアを含めて新たなコンテナイメージを作成／レジストリへ登録し、テスト環境などの稼働環境へデプロイします（⑥～⑬）。

こうすることで、各種テストをクリアし安全性を担保されたコンテナイメージ（バイナリ）に、手を入れることなくそのまま本番環境で動かせます。
リリース障害などにドキドキすることなく、業務アプリケーション開発SE、インフラ構築SE、運用SEは、穏やかにカットオーバーの日を迎えられるでしょう。

今回はコンテナ技術を例に、「新しい技術（IT）を採用するということは、単に「道具」を入れ替えるだけにとどまらない」ことを紹介しました。
本稿では、開発体制やその責任境界への影響、業務プロセス／担当タスクへの影響などを取り上げています。
これらは、今後活用が見込まれる生成AIであっても同様です。便利な技術を導入する際には、非技術的な影響にも配慮／考慮が必要ですので、判断に迷う際には、お気軽にご相談ください。