ネイティブか、サードパーティーか
ハイブリッド、マルチクラウド環境での「Infrastructure as Code」(IaC)ツール 何を導入すればよい?
「Infrastructure as Code」(IaC)ツールには2種類ある。1つはサードパーティー製ツール、もう1つは特定のクラウドベンダーのネイティブツールだ。本記事では、適切なツールを選ぶ際に留意すべき項目を取り上げる。
「Infrastructure as Code」(IaC)の目的は、モジュール形式のインフラ作成、つまりサーバリソースの抽象化にある。IaCツールを利用することにより、整合性を保ちつつ複数のアプリケーションプラットフォームを導入できる。
IaCツールがあれば、開発チームと運用チームはテンプレートを使用することで整合性を取りながら要件に応じた仮想リソースを導入できる。デプロイと構成スクリプトのバージョンを管理することも可能だ。
IaCツールは主に次の2つのグループに分かれる。
- サードパーティー製ツール。ほぼ全ての用途に適合する。
- ベンダーのネイティブツール。アプリケーションの導入を最適化できる。
ベンダーのネイティブIaCツールは、マルチクラウド導入には最適といえない。サードパーティー製ツールの大半は、任意のクラウドプラットフォームやデータセンターで動作するが、全てのクラウドプラットフォームで正しく動くとは限らない。こうしたトレードオフがあるため、IaCツールを選ぶ際は、現在と将来の両方における要件を視野に入れ、慎重に判断することが重要だ。
サードパーティー製IaCツール
HashiCorpの「Terraform」はオープンソースのIaCツールだ。Terraformは、さまざまなベンダーのクラウドに適合するサードパーティー製ツールとして知られている。他のIaCツールと同様、Terraformもモデル(テンプレート)を作成する。テンプレートにはドメイン固有言語(DSL)で構成が記述されているため、開発者はテンプレートを簡単に作成し使い回しができる。このDSLの構文はおおむねJSONと互換性があり、開発者にも取っつきやすいものとなっている。
開発者は実際のコードと同じようにTerraformテンプレートを作成し管理する。テンプレートはバージョン管理が可能なので、インフラのプロビジョニングや構築、新しいテンプレートの開発に流用できる。このテンプレート再利用機能は複数のプロバイダーのインフラ構成を標準化するので、ハイブリッド環境やマルチクラウド環境にメリットがある。
Terraformのテンプレートには計画フェーズと実行フェーズがある。そのため、定義した手順の分析や、手順を適用する前のダブルチェックが可能だ。環境間で構成を移行させることも容易なので、ハイブリッド環境やマルチクラウド環境のユーザーに向いている。
クラウドベンダーネイティブのIaCツール
最も普及しているクラウドベンダーのネイティブIaCツールは、Amazon Web Services(AWS)の「AWS CloudFormation」とMicrosoftの「Azure Resource Manager」(ARM)だ。どちらのツールも基本レベルではTerraformの機能と大差ない。だがIaCテンプレートコードのモジュール性については、Terraformが圧倒的に優れている。このため、AWS CloudFormationやARMでは、ツールの導入やテンプレートの再利用に難がある。
AWS CloudFormationとARMのIaCに対するアプローチは若干異なる。ユーザーにとっては、この違いが極めて重要になる。
Microsoftの「Azure Terraform Resource Provider」では、Azureユーザーが「Terraform Provider」を、Azureのネイティブリソースプロバイダーのように導入できる。Terraform Providerとは、クラウドやデータセンターのリソースと、Terraformテンプレートとの間にリンクを確立するサービスだ。このサービスにより、TerraformとARMが連携され、Terraformエレメントがタスクを実行できるようになる。こうした連携により、Terraformを実質全てのAzureサービスと併用できる。
AWS社はAWS内でTerraformを利用する方法についての情報を提供している。HashiCorpはAWSの大手DevOpsパートナー企業だ。しかし、両社ともTerraformとのインテグレーション用の機能をまだ開発していない。従ってTerraformの動作範囲外にあるAWSの機能はまだ幾つかあるものの、こうした機能はAWS CloudFormationで簡単に処理できる。2018年9月時点では、AWSでのIaC運用にはAWS CloudFormationが必要だと考えるべきだ。しかしTerraformと統合し、機能を拡張するという選択肢もある。
何が最適か
AWS社もMicrosoftも、ネイティブIaCツールの拡張機能としてのTerraformが持つ価値を認識している。ハイブリッドモデルやマルチクラウドモデルが普及する中、両社ともTerraformとの連携に必要な機能をネイティブIaCツールに組み込む準備をしていない。こうしたクラウドベンダーのネイティブツールは、主にシングルクラウドやシンプルなハイブリッドクラウド環境の運用に重きを置いている。
AWSを重視して、複雑なアプリケーションをハイブリッドクラウド環境やマルチクラウド環境に導入する予定であれば、AWS CloudFormationとTerraformの両方の利用を考えるとよい。AzureのIaCなら、Azure Terraform Resource Providerを利用できる。
ハイブリッドクラウドやマルチクラウドのユーザーにとって、今後はTerraformが「IaCのKubernetes」といえる存在になりそうだ。
Copyright © ITmedia, Inc. All Rights Reserved.
この記事の著者
関連記事
新着ホワイトペーパー PR
-
製品資料
AI時代の自律的なパートナー 「データエージェント」構築&活用ガイド -
製品資料
使用中のデータを保護して安全な共同開発へ、クラウド時代のデータセキュリティ -
製品資料
“AIによる高速な脆弱性検出”対策を行う、RHELの統合セキュリティ機能とは? -
製品資料
企業ITを支える定番Linuxの運用管理、手動の限界を乗り越える手法とは? -
製品資料
AIとクラウドネイティブの課題を解決する、シンプルで費用対効果に優れた方法
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
「Microsoft 365」が乗っ取られる 跡形もなくMFAを破る手口
-
2
なぜ人はいるのにDXが進まない? ライオンも直面した“老害”レガシーシステム
-
3
IT人材の42%が転職予備軍 辞めさせない組織の4つの共通
-
4
イーロン・マスク氏が生成AI「Grok」をオープン化する“語られない狙い”
-
5
LLMの「過学習」、正しく説明している文章はどれ?
-
6
GitHubが指摘 AIが書いた「おそらく動くコード」が招くシステム崩壊
-
7
なぜOpenAIやAnthropicのAIは「脱走」したのか 情シスが迫られるエージェント統制
-
8
Azure Red Hat OpenShiftは脱VMware問題の救世主になるか? 技術資料で解説
-
9
「結局使わなくなる」Microsoft 365 Copilotを半年で定着 キリンの3施策
-
10
ライオンが脱レガシーシステムのパートナーに「Google Cloud」を採用した理由
ホワイトペーパーランキング PR
-
1
属人化や仕様バグはなぜ起きる? AI時代に必須のドキュメント文化の作り方
-
2
「NAS」「SAN」「DAS」は何が違う? いまさら聞けないストレージの基礎
-
3
AIエージェントで多様な日常業務を効率化するための入門ガイド
-
4
5分で分かる「AI駆動開発エージェント」 要件定義から設計・実装・テストまで
-
5
中小企業必見、Microsoft 365でゼロトラストセキュリティを実現する方法
-
6
マンガで解説:「ゼロトラスト」「SASE」の必要性とメリット
-
7
コスト分析で見る「デバイス復旧」の代償 損失額から導きだされた投資戦略とは
-
8
セキュリティソフトをすり抜ける標的型攻撃メール、不審メールの見破り方とは?
-
9
“あのファイル転送”で暗躍するノーウェアランサム
-
10
オープンウェイトLLMの推論最適化事例:ローカル環境で応答速度を約15分の1へ
TechTargetジャパン SNS
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー