ネイティブか、サードパーティーか
ハイブリッド、マルチクラウド環境での「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
-
事例
[日本オラクル株式会社] ピンチをチャンスに変えたEPR製品は? 先行企業の導入事例3選 -
技術文書・技術解説
[日本オラクル株式会社] 無自覚なリスク 秘伝Excelファイルが監査の壁、不正・ミスの温床となる理由 -
製品資料
[日本オラクル株式会社] 戦略的経理の第一歩 失敗のない「脱Excel」を実現する秘訣とは? -
技術文書・技術解説
[日本オラクル株式会社] いまさら聞けないオンプレERPとクラウドERPの違い 最適な製品をどう見極める? -
事例
[株式会社ビザスク] 連結売上高が約2倍に成長、富士フイルムが実践した新規事業創出の戦略とは?
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
なぜ「全社配布Copilot」は使われないのか? 失敗に学ぶAI定着
-
2
損保ジャパンはなぜ「COBOL」を捨てなかったのか? 脱メインフレームの真相
-
3
「ノートPC派」は損をしている? Dellと考える“自作PC”のメリット
-
4
「業務改善とツール活用」に関するアンケート
-
5
LINEヤフーはなぜ「社内の管理者」すら信用しないインフラを作ったのか
-
6
慶應義塾が「Notion」を選んだ理由 AI導入の盲点になる“情報のサイロ化”
-
7
1200万円のSaaS導入を回避 スギ薬局「運用費10万円」のAIエージェント構築術
-
8
「GitHub Copilot」3000人に配布も基本機能しか使われない 保険大手が得た教訓
-
9
「Copilot」はなぜ放置される? “議事録要約止まり”を脱する処方箋
-
10
IBM iのブラックボックス化を打破 資産継承と進化を実現する「IBM Bob」の実力
ホワイトペーパーランキング PR
-
1
DX/AI投資の壁を突破、現代の最高財務責任者が直面する課題と克服のヒント
-
2
不審メールの経路や見せ方に変化? 2026年夏の3事例から見えた動向と対処方法
-
3
「オンプレミス回帰」せざるを得ない“合理的な理由”
-
4
バックアップは“取っているから大丈夫”なのか? ランサムウェア時代の備え方
-
5
システムの保守がモダン化を阻む? 「変えない判断」から脱却する方法とは
-
6
生成AIを開発に導入しても効果が見えない? 実証実験で分かった成果と課題
-
7
経産省DX指針から読み解く、受発注業務デジタル化ロードマップ
-
8
5分で分かる Microsoft 365のデータ損失に備えるためのバックアップの仕組み
-
9
ネットワーク遅延の原因、「パケットロス」の基礎知識と効果的な解決策
-
10
Microsoft 365を安全に運用 うっかりミスやサイバー攻撃に備えるデータ保護術
TechTargetジャパン SNS
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー