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

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

あらゆる作用には同等かつ逆方向の反作用が働く。この法則は「Infrastructure as Code」（IaC）にも適用される。メリットを享受するために、対処すべき課題とは何か。

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

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

著者

Tom Nolle

[TechTarget]

印刷する

IaCのメリットを引き出すために対処すべきこととは

　インフラの構成や設定変更をプログラムで実行する「Infrastructure as Code」（IaC）は、ハイブリッドクラウドとマルチクラウドにおける管理の合理化を促す強力なツールになる。サーバやコンテナ、仮想マシン（VM）の導入と構成が自動化できるからだ。だがプロセスの非効率化や導入ミス、全体的な混乱を招く恐れもある。こうした課題にどう対処するかが、IaCの実装結果に関わる。

併せて読みたいお薦め記事

Infrastructure as Codeで変わる運用管理の現場

「DevOps」再考

開発者と運用者の関係性が課題に

　IaC実装の課題として大半の企業が最初に直面するのは、開発チームと運用チームの間で円滑な関係を築くことだ。以前はアプリケーションを稼働するシステム基盤をセットアップする際、開発者が関わることはほとんどなかった。実はこうした状況が問題を生み出してきた。

　アプリケーションをテストから運用へ移行する段階では、特にそうだった。開発と運用の融合を図る「DevOps」の支援ツールを使えば、開発チームと運用チームとの連携を促すことができる。DevOps支援ツールは大企業を中心に使用が進みつつある。だがDevOpsの文化がない企業にとっては、ハイブリッドクラウドやマルチクラウドの実装が、こうした連携を必要とする初めての機会になる可能性がある。

　IaCの実装が容易になるケースもある。例えば開発開始時、企業がアプリケーションを特定の基盤製品に関連付けており、その基盤製品の要件に基づいたインフラポリシーが、アプリケーションライフサイクル管理（ALM）から運用まで一貫して適用されている場合だ。また仮想化基盤の規模が小さく管理が容易な場合も、IaCは実装しやすくなる。

役割の境界線を曖昧にするべからず

　2つ目の課題は、ハイブリッドクラウドとマルチクラウド管理戦略において、IaCとDevOpsが、それぞれ適切な役割を果たせるようにすることだ。DevOpsはアプリケーションの導入、IaCはリソースの構成管理に関わる。Amazon Web Services（AWS）は、同社のクラウドサービスの導入管理ツールとして、Chef SoftwareのDevOpsツール「Chef」をベースとした「AWS OpsWorks」をそろえる。この事実は、DevOpsとIaCの境界線が曖昧になる可能性を示唆する。実際、IaCツールがDevOpsの一部として利用されていることは珍しくない。このことが、開発チームと運用チームの間に混乱を来す可能性がある。

　アプリケーションの導入を自動化してALMを合理化するには、DevOpsも必要になる。複数レイヤーや複数コンポーネントのアプリケーションを導入したり、クラウドやデータセンターの障害への対処方法を検討したりすることは、企業が一貫して正確に実行するには複雑過ぎる。ただし適切なツールがあれば話は別だ。ChefやPuppetの同名ツール、Red Hatの「Ansible」、SaltStackの「SaltStack Enterprise」などのDevOpsツールを1つ選び、それを生かすとよいだろう。全てのDevOps機能をすぐに必要としていない場合でも同様だ。

次ページへハイブリッド／マルチクラウド管理にまつわる課題