クラウド構築自動化の理想と現実解　～＜前編＞ クラウド構築の自動化についての検討事項

Text＝北野 龍二、豊田 穣　（日本アイ・ビー・エム システムズ・エンジニアリング）

クラウド構築自動化とは何か　

クラウドインフラストラクチャ構築に限らず、「インフラストラクチャ構築自動化」という文言が世の中に広まってから、かなりの時間がたっている。

しかしその言葉の定義／範囲については人によって理解が異なり、時として大きな誤解を残したままプロジェクトが進み、最終的な段階で「こんなはずではなかった」という状態になることもある。

ここでは、「クラウド構築自動化」を「クラウド上でのインフラストラクチャ（基盤）の設定や管理を自動化すること」と定義する。

またここでの自動化とは、クラウド上のインフラストラクチャ設定については、図表1の左側のように基本的に１つのリソースに対してユーザーが作業していくことが基本とする。ただし同図右側のように、「リソース作成用」のサービスに対してユーザーが作業を実施し、そのサービスが複数のリソースに対する設定を実施することを前提とする。

クラウド構築自動化の理想　

クラウド構築自動化と聞いて思いつくことは人それぞれであるが、代表的な例としては図表2がある。

ここに挙げられているのは、「自動化」と聞いて、「便利になる」「簡単になる」という思いから出た「理想」「願望」であり、実際にこのようなことが実現できるのであれば、インフラストラクチャ構築自動化はどのような場合でも積極的に進めていくべきだと思われる。

ただし残念ながらこのような考えは基本的に間違いであり、この考えのままプロジェクト等で自動化を採用し、進んでいくと後々大きな問題となることが多い。構築自動化を採用する場合、実際にはその前に知っておかなければならないこと、考えなければならないことが多々ある。

自動化の際に考えるべきポイントには、以下が挙げられる。

・自動化するシステムの範囲
・自動化する際に必要な作業
・コストとメリットについて

これ以外にもいくつか考慮点があるが、ここでは主に上記3つについて考えてみる。

自動化についての検討事項

自動化するシステムの範囲

システムのどの範囲を自動化するかは、最初に検討する必要がある。たとえば以下のような場合に自動化するかどうかは、きちんと評価し判断すべきである。

❶　システムが非常に簡単な方法（例：GUIのボタンを１つ押下するだけ）でデプロイ可能な場合
❷　複数のサービスが連携して動いており、複雑な依存関係が存在する場合
❸　セキュリティ的に独立性の高いシステムが存在する場合
❹　レガシーシステムが残っており、構築するシステムとの統合が必要な場合

いずれの場合でも、自動化により、これまで以上に複雑な作業が必要になったり、単純に自動化することが不可能であったりするため、たとえば以下のように段階的な自動化を検討するなどの対応が必要となる。

①　システム構築の一部のみをコード化（自動化）し、定常運用で利用する
②　コード化した作業に関連する部分から順次コード化していく
③　コード化した部分にCI/CDプロセスを組み込み完全自動化する

自動化する際に必要な作業　

自動化する際には、これまでのインフラストラクチャ構築と同様にいくつかの作業が必要となる。そのため単純な工数削減につながらない可能性もあり、要検討である。以下に自動化に関する作業の例を記述する。

❶　インフラストラクチャ設計

（1） テンプレート作成：構築用のテンプレート（後述）を作成
（2）パラメータ設定：要件に応じたパラメータ（例：メモリサイズ）を設定

❷　インフラストラクチャ構築

（1）テスト実行：作成したテンプレート・パラメータ設定を元に環境構築が正しく行えるかテスト／修正を実施
（2）構築：実際に環境を構築する作業（これまでと同じ作業だがこの部分は自動化により工数削減が期待できる）

❸　インフラストラクチャ運用自動化

（1）監視設計／ツール：作成した環境の監視設計はこれまで同様に必要

コストとメリットについての検討

自動化を採用した場合でもこれまでと内容は異なるが、必ずコストが発生する。場合によっては既存の構築方法を採用した場合以上にコストがかかることも考えられるため、以下のような検討が必須となる。

❶　自動化に関するスキル習得が必要

（1）　これまでの基盤構築スキルに加えて自動化ツールに関するスキル習得が必要となる
（2）　自動化の際にCI/CDまで検討する場合、そのスキルも必要となる

❷　複雑すぎるシステムをそのまま自動化するメリットはあるのか

（1）　自動化に際して調査事項／調整事項が多々ある場合、それらを調査／調整する時間／コストをかけられるのか
（2）　自動化するだけでなく、システムの再設計／簡略化を検討したほうがよい可能性もある

❸　システムの利用期間

（1）　たとえば2週間程度しか利用しないシステムに関して、コストをかけて自動化するメリットがあるのか
（2）　１回もしくは数回しか構築しないシステムであれば、これまでどおりの構築方法を利用すべきでないか

このような事項を検討し、自動化にかかるコストに相応のメリットが享受できるのかを議論したうえで、自動化の採用可否を決めるべきである。

その他検討が必要な事項

上記に挙げた3つの内容に加えて、以下のような事項も検討しておく事が重要である。

❶　自動化するシステムを手動で変更する可能性

（1）　ちょっとした変更（リソースのメモリ上限の変更など）についてGUIから簡単にやってしまいたいこともある
（2）　管理者が複数いる場合、知らない間に変更される可能性もある

❷　すべてのリソースが対応していない可能性

（1）　利用するツールによるが、利用したいすべてのサービスが自動化に対応しているわけではない（例：IBM CloudのWatson系サービスは未対応）
（2）　サービスに設定可能なすべてのパラメータが指定可能でない可能性がある

❸　セキュリティリスクの可能性

（1）　パラメータファイルにセキュリティ上注意が必要な情報を書いてしまう可能性がある

クラウド構築自動化の実現方法　

構築自動化は、Infrastructure as Codeと呼ばれる手法で実現する。Infrastructure as Code とは、仮想マシンやオブジェクトストレージといったクラウドリソースをコード化して管理する手法を指す。

従来、クラウド基盤にITインフラストラクチャを構築する場合、あらかじめコンポーネントのスペックを記述したパラメータシートを用意し、インフラストラクチャを担当するエンジニアが、ブラウザやCLIを用いてリソースを払い出す。

Infrastructure as Codeでは、パラメータシートの代わりとなる設定ファイルを記述し、専用ツールがリソースをデプロイする。コード化することで、リソースをデプロイする際の属人化を無くし冪等性を担保した構築が可能となる。

Infrastructure as Codeツールの種類

Infrastructure as Codeツールは主にオーケストレーションツール、構成管理ツールの2種類に分類される。それぞれ別々の目的を持ったツールである。

Infrastructure as Codeにおけるオーケストレーションツールとは、クラウド上に用意する仮想マシンやネットワークのエンドポイント、ストレージ、データベース、 OS、アプリケーションを起動する基盤の構成管理を目的としたツールである。

構成管理ツールとは、 ミドルウェアの導入やソフトウェアのバージョン管理、サービスの起動、 ファイアウォールなど、初期セットアップや管理を目的としたツールである。

Infrastructure as Codeの実行環境

各種クラウドプロバイダーや企業がサービスを展開している。図表3に、実行環境を提供しているサービスを列挙する。

なかでも「Terraform」と呼ばれるツールは、HashiCorp社によって開発されたオープンソースソフトウェアであり、AWSやIBM Cloud、Azure等のクラウド基盤に対応している。

Terraform実行基盤上に設定ファイルを配置することで クラウドリソースを作成／変更／削除する。実行基盤はローカルマシンまたはリモートサーバーに接続して、サーバー上で実行することも可能である。

IBM Cloud Schematics

Terraformは実行基盤であるローカルマシンやリモートサーバー上にインストールして、Terraform CLIを操作してリソースを管理する。IBM Cloudでは、「IBM Cloud Schematics」と呼ばれるTerraform実行基盤をサービスとして提供している。

ユーザーがホストする実行基盤は不要であり、Schematicsワークスペースと呼ばれるTerraformが利用可能なコンテナが提供される。設定ファイルを準備してSchematicsコマンドやワークスペース上でのGUI操作により、リソースをプロビジョニングする。

＜後編へつづく＞