開発チームと運用チームの連携が鍵に

「Infrastructure as Code」に失敗する人が見落としがちな“5つの課題”（2/2 ページ）

公開 2016年10月03日 15時00分

更新 2024年03月09日 17時09分

著者

Tom Nolle

[TechTarget]

印刷する

全てのクラウドベンダーを一緒くたに扱うことなかれ

　3つ目の課題に直面するのは、IaCを使用してハイブリッドクラウドやマルチクラウドの管理を単純化するときだ。ほとんどのユーザー企業は、最終的にハイブリッドまたはマルチクラウドモデルを採用することになるだろう。全てのパブリッククラウドベンダーは、それぞれ異なる管理手段を用意しており、問題が起こった場合は異なる対処方法が要求される。こうした課題に対処すると、DevOpsによるアプリケーション導入とIaCによる構成管理の境界線が曖昧になる。

　利用しているDevOpsツールベンダーのアドバイスに従って、（1）IaCレイヤーでの対処が必要な状況なのか、（2）DevOpsレイヤーでの「事象」として報告が必要な状況なのかをはっきりさせる必要がある。計画中の変更が、仮想化製品の導入方法やアプリケーション自体の導入方法に影響が及ぶかどうかを判断しなければならない。

　（1）の場合、VMやコンテナなどのリソースを再導入することを検討しよう。（2）の場合は、アプリケーションコンポーネントの再導入を検討するのがよいだろう。例えばコンポーネントの拡張が必要な場合は、DevOpsレイヤーで変更しなければならない。だが不具合のあるコンポーネントを交換する場合は、IaCレイヤーで対処できる可能性がある。

　4つ目は、クラウドベンダーがさまざまなWebサービスを提供していることによって生じる課題だ。Infrastructure as a Service（IaaS）と基本的なコンテナサービスでは、アプリケーションイメージの他に最小限のミドルウェアが提供される。中にはAWSやMicrosoftの「Microsoft Azure」など、実質的にミドルウェアをクラウドサービスとして提供しているクラウドベンダーもある。

　同じ機能を備えていない環境間ではアプリケーションを移行できない。利用している全てのクラウドサービスで必要なWebサービスが利用できる場合でも、異なる導入構成が必要な場合は、複数の稼働オプションをIaCスクリプトで定義するのがよいだろう。

まとまりが欠かせないIaCへの取り組み

　IaC実装の5つ目の課題は、運用の統制だ。例えばIaCツールやスクリプトを使用せずに一部のシステム構成を変更している場合、IaCを機能させるのは困難になる。また運用チームは、IaCスクリプトやモデルを変更することなく、構成に変更を加えてソフトウェアの新しいバージョンに対処することが往々にしてある。この場合、適切なバージョンの構成が導入できない可能性がある。

　この問題を解決するには、運用上の規律が必要になる。運用チームはシステムやクラウドの構成を変える際、公式の変更管理システムで変更内容を記録しておくべきだ。実際に変更を加える場合はIaCスクリプトを変更し、その変更内容を記録しておくことが望ましい。運用チームがIaCスクリプトを変更するときには、加えた変更内容を開発チームに必ずフィードバックしなければならない。変更内容が、アプリケーションの要求事項に沿っているかどうかを検証するためだ。

　IaCは構成管理とDevOpsの両方からの進化であり、新しいパラダイムでもある。重要なのはIaCの将来を考慮に入れて準備をすることだ。さもなければ、ハイブリッドクラウドとマルチクラウドの管理や導入で、IaCの潜在能力を十分に発揮できない可能性がある。