IT動向 IT技術

「Infrastructure As Code」と「Configuration As Code」の歴史を調査してみる

2020年3月11日

の話を読んで、私も確かによく理解してなかった。と思ったので自分の頭の整理のために書いてみました。

ここでは、上記の記事で語られている

  • Configuration As Code :  構成を管理するツール。仮想マシンが既にあり、その上にアプリケーションのスタックを自動インストールする作業をコーディングにより自動化する事
  • Infrastructure As Code :  仮想マシンや、仮想ストレージ、仮想ネットワークなどを API を使って、コーディングにより自動化する事

と言う言葉の定義ではじめて行きます。

初期の Configuration As Code 

起源は、シェルや、インストーラーになるのではなるのでは無いでしょうか。初期の Configuration as Code と言ってよいでしょう。

インストーラーと言うと GUI のイメージが強いですが、通常インストーラー作成ソフトは CLI にも対応しており、CLI でパラメーターや構成ファイルを読み込んで、「1ターン(キーのヒット)」で全て構成してくれます。

こうしたインストーラーは、そのアプリケーション毎に特化しもので、各アプリケーションに足してビルドするもので、アプリケーションと密結合しているのが現在でも普通だと思います。

多くの場合は、インストーラーとインストールされる対象のアプリケーションはパッケージ化されます。これは今でも Windows 用のアプリが msi 形式だったり、setup.exe として、ある程度固まったファイルになっている事を考えるとイメージしやすいと思います。

Windows では、Windows 95 の時代からインストール自動化ソフトが現れてて、その中でもInstallShield は 85から90パーセントを占めていたようです。

当時、筆者も自分で作ったプログラムを作るのに InstallShiled を使用していましたが、この記事執筆時点で 2019年に最新版がリリースされています。

そしてユースケースは、PCだったりサーバー上で、個々にアプリをインストールするためのローカルで単独で使用するものでした。

システム規模の拡大で構成管理スクリプトを一元管理する需要が生まれる

ITの進化とともに、特に業務用のシステムでは管理端末上から、複数の管理対象に対して、同様な構成を一度に行う需要がでてきました。

アプリケーション・モジュールの配布や構成スクリプトの配布、各管理対象の現在の構成情報の取得等を、管理者が各マシンにログインしてコマンドをたたいて実行しなくても、選択した管理対象に対して実行したい。という需要が生まれました。(多分 2000年前後?)

この時に、いろいろ大手ベンダーが出す構成管理ツールを出していたと思います。私が覚えている製品だと、IBM の Tivoli Configuration Manager という製品があります。2005年前後に金融機関で触る機会がありました。

単純なシェルやインストーラーとの違いは、アプリケーションモジュールの保管や、構成を行うためのスクリプト等を管理サーバ側で一元管理する事ができた事です。

同時に、こういったベンダーが作った製品に不満を持った人、もしくはお金が無く、ベンダー製品を買う余裕がなかった人によって、OSS の同様の製品が生まれてきたのだと思います。

OSS としては、Puppet (2005年)、 Chef (2009年) 、Ansible (2012年) が出て来ました。Ansible は後発組の特徴として Agentless です。

こう言った OSS製品は、エンタープライズで使われていませんでした。それは、恐らくエンタープライズで要求されるクオリティが高いため、もしクリティカルなバグが発覚した時に速やかに修正されるサポートの提供が必用だったためです。

一部の会社は OSS に対してクリティカルなバグの場合は修正を自分の会社で直します。というサービスを提供していましたが、そう言った OSS を修正できるようなエンジニアを抱えた会社は一般的ではありませんでした (これは現在でも同じだと思いますが)

個人的には Chef は実際に手を動かして触った事は、(おそらく)ないはずないのですが、「クックブック」、「レシピ」や「ナイフ」という言葉は覚えてます。覚えやすいネーミングはとても重要だな。と思います。

こう言った OSS 製品のシェルに対するメリットの一つとして、冪当性 (idempotency) を簡単に守れるような仕組みがツールに無い方されている。という点が良く言われます。

またこう言った仕組みを、シェルだけで似たようなのシステムをくみ上げるエンジニアもいました。今でも普通にいると思います。

2005年~2010年の時代背景を正確に思い出せませんが、100台のサーバーで構成されるシステムがあれば、世の中的にはまだ Windows サーバーがシステムの半分以上を締めていた時代だったと思います。Linux はそこまで企業ユースでは一般的ではありませんでした。その代わりに UNIX は重要なシステムで使われていました。

なので 日本企業の Enterprise な環境では、Linux への対応しかしていない OSS ツールを使うのは一般的でなかったと思いますし、エンタープライズの現場で見た事がありませんでした。

私はエンタープライズ屋だったためだと思いますが、OpenStack のインストールで Chef が使われているのを見かけた程度しかありません。

created by Rinker
¥3,740 (2024/03/29 02:09:49時点 Amazon調べ-詳細)

ベアメタルに対するOSインストールの自動化

OSは手動でインストールして、その後、構成管理用の Agent を各端末にインストールして・・・そこから構成を自動化する。という事が普通に行われていました(今でも OSからのインストールが必要な場合、大半のケースはそうだと思います)

HWに対する OS の導入や OS の初期構成は、大変な作業でしかも時間もかかりました。それすらも自動化しようというベンダー製品も存在しています。

サーバーにネットワークケーブルと電源をつなぐだけで後はリモートで OS がセットアップされて・・・という環境を継続的に維持するのは容易ではありませんでした。対象の HWが新しくなるたびに、上手く動かなくなります。

OS の自動インストールという観点で、私がよく見かけたのは、研修センターや大学の教室で、生徒の座席に備え付けられた研修用の Windows PC 端末等を、研修後に一気にOS毎初期化するためにこういうツールが使われていました。(まだパブリッククラウドが一般的になる前なので、2010年より前だと思います)

最近では、パブリック・クラウドサービスでユーザーに好みの OSを選択してインストールする事のできるベアメタル用のインストールサービスが存在しています。

IBM Cloud の前身である、Softalyer 等はベアメタルサーバーに、好みの OS をインストールできる事を売りにしていました。

これらのパブリック・クラウドのサービスでは、OSのインストールと構成を自動化していますが、検証されたハードウェアとOSの間の組み合わせで実行されており、その辺りの x86のサーバーを適当に持ってきて同じ手法でインストールできるか。と言うとそういう訳には行かないのが実態です。

これは抽象度がゼロのハードウェアを相手にする限りは解決しない問題だと思いますし、次々に新しいハードウェアの技術は出てくるので、抽象化されたソフトウェア上での自動化より技術的な複雑度が増す作業になるため致し方ないと思います。

ハードウェアレイヤーにまつわる自動化というのは、ハードウェアのベンダーの仕様に依存するので、今後も難易度の高いエリアであり続けると思います。

仮想化により仮想インフラのコンポーネントが API で作成できるようになる

AWS EC2 (2006~) や S3  (2006~)の API がいつから公開されていたか、歴史を調べきれなかったのですが、S3のバケット作成のサンプル内のコードの日付などを見ると 2006 年3月になっていたり、こちらの 2006年9月の EC2 のQA に既にコマンドが存在しているので、恐らくリリース当初から API を公開していたのだと思います。少なくてもアメリカでは、現在の感覚に近い Infrastructure As Code の概念は、2006年には生まれていた事になります

一方で、ベンダーのツールでは、VMWare が 2006年に 「Programming API Programming Guide Version 1.0」 というドキュメントを出していました。ただ、中を見ると、既存の vmx ファイル(仮想マシンファイル)を認識させるような事はできたようですが、基本的にサーバーの起動・停止など運用面の API だったようです。

私もこの文章を書き始める前は、クラウド用の API の登場 = Infrastructure As Code の登場くらいに考えていたのですが、VMware の API の状況を考えるに、 2006年当時は、これらの API は、仮想マシンを作成するというよりは、起動・停止などの運用目的で使われていたのではないかなと思います。

似たようなWebサイトを業務で何度も作らないといけないような Webサイト作成を請け負うエンジニアからの、仮想マシンの調達レベルからの全自動化への需要はあったと思われますが、インフラ自体をコマンドで生成すると言う作業を一番使っていたのはAWS 自身で、一般人が繰り返しコマンドで同じ作業をする必用性はこの頃には高くなかったのではと推測します。

単発で EC2のインスタンスを作成したり S3のバケットを作成するのであれば、自動化の必用もなく、GUI からやった方から楽なのでそちらの需要が殆どだったのでは無いでしょうか(もちろんユーザーが GUI から行った作業は裏で API が呼ばれているのですが)

暫くするとAWSのようなパブリッククラウドをオープンなアーキテクチャーで作ろうという動きのもと、AWS のアーキテクチャーを参考にした、OpenStack (2010~) が出てきます。

AWS のアーキテクチャー自体が疎結合で、サービス間を API で結ぶように作られていたため、それを模した OpenStack が人々の手元に渡るようによって、AWSの中身が疑似体験できる事で、さらに仮想マシンや仮想ストレージは API コールでデプロイするもの。という意識が生まれてきた気がします。

同時にエンタープライズ向けのストレージ等でも、OpenStack と接続するためのドライバ ( OpenStack の API リクエストをベンダー独自仕様のコマンドに変換するためのモジュール)を提供するようになってきます。

Infrastructure As Code の概念がエンタープライズにも広がってきたのは、2010年頃かもしれません。ただ実際には強い動きは起きなかったと言って良いと思います。

クラウドにより、インフラは常にある程度準備されている。という前提からはじまるようになる

AWS の東京リージョンは、2011年の3月に開設されています。その後、しばらくは「Webサイト作るのに便利だよね」くらいの個人ユースのイメージが強く(私個人が)、日本で AWS が 大規模に企業向けに使えるんだ。という印象になったのは(これも私個人が)、東急ハンズの事例 (2013) だったと思います。

東急ハンズのユースケースは恐らく何度もデプロイして古い環境は破壊して・・・という開発が必用なサービスでは無いと思うので、あくまで AWS の知名度がこのくらいに出て来ていた。という例になると思いますが、このくらいの時期には日本でも一部のユーザーは、API を使って自分のシステムを構築しようとしていた人がいてもおかしくないのかなと思います。

少なくても(どのようなユースケースがあったのか定かでは無いですが)、 日本で Infrastructure As Code の概念の認知度が出てきたのは AWS 東京リージョン が開設された辺りになるのかな。と推察します。

この頃から HWを購入して OSをインストールして、そこからアプリを導入して・・・という概念の前半の作業は、既に終わっていて、その後から考えれば良いケースが出てきた事になります。

実際にはプライベート・クラウドのユーザーは、同様な事を AWSの登場以前も行ってきたわけですが、インフラのベースを準備してマネージする人と、それを使用する人は通常同じ会社に所属していました。

それが AWS の登場によってインフラをマネージする人と使用する人が明確に分かれた事になります。

created by Rinker
SBクリエイティブ
¥344 (2024/03/29 02:09:50時点 Amazon調べ-詳細)

EndPoint Management 製品も構成管理ツールの一つ

少し脱線しますが、企業で働く社員の PC 端末の構成管理を行う Endpoint Management 製品は、これらの構成管理の一つの進化の一つだと思います。

Endpoint Management 製品は、 PC 端末の Security Policy 設定や、パッチのインストールを管理サーバーから一括して行う製品です。

管理対象PC が100台や1000台の規模でなく数万台~の構成管理に対応する必要がある場合もあります。全ては PC を使う従業員の数次第です。

その規模になると、管理対象に対して管理サーバーからの命令が上手く届かなかったり、実際には命令は届いても、管理サーバー側からは命令が上手く実行されたかわからかったりという事が頻発します。

PC端末は、ネットの接続から切り離されてアクセスできない常態になっていたり、端末によって状態はさまざまです。

構成管理対象が常にオンラインでアクセスができる常態になっていて、コマンドのリクエストに対しては、必ずリプライを返してくれるサーバーの構成管理製品の世界とは違った難しさがあります。

そのような環境で、構成管理を行うために、管理サーバーと構成管理対象のPCに導入された管理 Agent が直接通信するのではなく、管理 Agent が他の Agent に対して命令をフォワードする事で複雑なネットワーク環境でも効果的に命令を伝達させる独特なアーキテクチャーを取っている Tanium のような製品もあります。

Chef や Ansible 等のツールを使う事によってパラメーターシートを使わなくなるか

SIer の世界では、Excel に設計書として、各種設定値を記載しておくのが重要な仕事の一つだと思っています。

これは障害時などに「何が設計時の設定だったんだっけ?」というのを確認したり、システムにアクセスしなくても設計書を見ればシステムの構成を知るために使われています。

環境が壊れた時に再構築のために使う。という目的には幸い遭遇しなかったのですが、システムに変更を加えないといけない要件が起きた時に、システムにアクセスしないでドキュメントだけで構成を理解するために使われるのが主だと思います。

私が居たプロジェクトでは、当時ベンダー製の構成管理ツール (Server - Agent 型) を使用していましたが、それでデプロイされる構成ファイルもしっかりエクセルに記載されていました。

最近関係したある Webサイトの案件で、使われていたソフトウェアが他社に買収されて無くなってしまうので、その部分を別に製品に置き換える。という仕事がありました。

既存システムの仕組みやパラメーター的なものは全て Excel にまとめられていたので、システムの把握に役だちました。

これが実際のシステムを見て下さい。と言われていたら(知らないソフトウェアですし)どういう実装されているか、どういう動きをするのか洗い出すのに何ヶ月もかかったと思います。

なので、こうしたツールを使う事 = Excel がなくなる。というのは別問題だと思っています。

環境毎(システム毎)は作っては/ 捨てるという概念

Blue Green Deployment という概念が出たのは起源を辿ると2010年だったようですが、多くの人がこの言葉を知ったのは 2012 年の AWS の re:Invent だったのでは無いでしょうか。私はエンタープライズ屋だったので、当時はめちゃくちゃ驚いた記憶があります。

ただ、世の中には巨大な Webサービスというのはあまりなく、そう言った環境に縁がある人もごくわずかで、大半の人が「そんな大規模な環境必用ないよね?」という状況だったと思います。

バージョンアップのために、まる毎新しいシステムをもう一セット作る。というのはプライベートクラウドしか普及していない時代には「そんなお金ないし・・・」と言う反応が一般的だったと思います。

それが「クラウドネイティブ」になり簡単にリソースが調達できる時代になる事で、その制限が取り払われて「バージョンアップ用のシステムをまる毎作ってしまってもいんだよ」となって来ました。

但しこの時代の日本のIT環境では、会社がクレジットカード決済をするという概念も無いですし、リソースの使用量に合わせて流動的な予算を許すような会社もほとんどありませんでした。なのでそのための環境は整ってなかったと言えると思います。Webサイトからインスタンスに必用な CPU とメモリの量を選択してOKをクリックすると、営業から電話がかかってきてお見積もりの話になる。という今では考えられないシステムもありました。

プライベート・クラウド環境と違い、使用できるリソースの量の制限がなくなり、作業も全てAPI できる。前回作成したシステム構成と同じシステム構成を新しいリリース用に作りたい。そして、同じ作業をリリースの度にするのも大変なので作業も自動化したくなる。という Infrastructure As Code の需要がAWS社内では存在し、2012年の時点で実際に使われていた事になります。(まさか、AWS内部で、Blue Green Deployment 環境のために、GUI で作っていたわけは無いと思いますので)

一方で、プライベートクラウド環境でも、システムをまる毎パターンとして構成して、パターンを使って同じシステムを何度も作成しよう。という概念が出てきます。

2012 年4月に発表された IBM の PureApplication は、システムの構成をテンプレートを UI で作成し、そのテンプレート使い回して同じ構成をデプロイする事が可能でした。

ただ、現在はこの製品が IBM のラインナップから無くなっている事からもわかる通り、IBM が担当するようなエンタープライズの顧客の間では、そもそもシステム構成をテンプレートかして何度も使い回す。と言うような需要はありませんでした。

マルチサービスの構成の自動化とコンテナの構成の自動化

クラウドが一般的になると、複数のパブリック・クラウド事業者等が提供するサービスを組みあわせてマルチクラウドなサービスを構成する事が当たり前になってきます。

そうした中で、各事業者のリソースの API の使い方を一つ一つ勉強して一つのスクリプトにする事も可能ですが、それぞれの API の仕様を覚えるのは大変だし、メンテナンスも大変になってきます。

Terraform は、HashCorp社のインフラ構成管理ツールですが、いろいろなサービスのリソースをできるだけ簡単に取り扱えるように Provider と呼ばれる各種クラウドサービスの API のラッパー的なものを準備しています。

また、Kubernetes は、コンテナ環境限定になりますが、manifest と呼ばれる YAML ファイルに必用なコンテナなどのリソースを記述する事で、Kubernetes 上に可用性を持ったシステムを展開する事ができます。
Docker と Kubernetes により、システム全体のデプロイがより簡単になりました。

参考リンク:

SpotifyがミスによりKubernetesの本番クラスタを二度も削除。しかし顧客へのサービスにほとんど影響しなかったのはなぜか?

「Infrastructure As Code」 と 「Configuration As Code」は別のもの ?

この用語の使い分けの発端は、ソフトウェア・レベルの構成設定は 「Configuration As Code」で、仮想マシンや、仮想ストレージ、仮想ネットワークなどの構成を API で行う部分は「Infrastructure As Code」と呼ぼうという考え方で、この文章もここまで、その使い分けでやってきました。

2006年に AWS の S3 と EC2 のサービスがリリースされた時に、API によるインフラストラクチャーの作成という概念が生まれたため、ソフトの構成の自動化「Configuration As Code」 が インフラの構成「Infrastructure As Code」 まで作業範囲が増えました。

これはこれまでよりもより広い範囲の作業を、自動化、効率化する事ができるようになったという観点でエポックメイキングだったと思います。

ただ、一方で、やっている作業内容の視点(ツールの側の視点)で言うと、スクリプトによるコマンドの実行で、技術面で敢えて区別する必用は無いと思います。

何故、この用語があるんだろう?と上手く説明できず、いろいろ考えていたのですが、以下の例を思いつきました。

もしここで、ハードウェアをセットアップするエンジニアが出てきたとします。

「インフラを作るってはのは、こうやって Ethernet のカードを挿したり、メモリを挿したり、管理モジュールのカードを追加したり、BIOSをインストールした後に、ドライバーを導入してハイパーバイザーを導入する事を言うんだよ。しかも HP製のこのマシンは、メーカー標準のインストールDVDに入ってるツールが自動でハイパーバイザーまで入れてくるんだ。これこそ「Infrastructure As Code」だぜ。ハイパーバイザーが入った後で、API で仮想マシンを作ったりするのは、「Infrastructure」というよりは、ハイパーバイザーソフトの構成「Configuration」 だよね?」

と言ったとします。

彼が「Infrastructure」と呼んでいるのは、ハードウェアのレイヤーに近い部分で、仮想マシンや仮想ストレージより下のレイヤーの話になります。「Infrastructure」と呼んでいるものの範囲を特定のエリアに絞ろうとすると、人によって「Infrastructure」と思っている範囲が変わってくる事がわかります。

この記事の発端となった「Configuration As Code」と「Infrastructure As Code」の区別は、「Infrastructure」の定義の範囲からアプリケーション・レイヤーを外し、クラウドの仮想化レイヤーだけに絞った時に成りたちます。しかし「Infrastructure」という抽象語は、特定の技術レイヤーを指すものでは無いはずです。(ついついAWS等のレイヤーを表すために使ってしまいますが、よく考えると「Infrastructure」という言葉は、文脈によってはアプリケーションを指したりハードウェアを指したりいろいろです。)

「Infrastructure」と 「Configuration」は、「対象」と「動作」

本来は「Configuration」を行う対象が「Infrastructure」で、この二つは「動作」とその動作の「対象」という異なる概念上の存在のはずです。

例えば「インフラ構成管理ツール」と言う言い方がありますが、これは「インフラ」を「構成管理するツール」という意味で、この二つの言葉が、同じカテゴリーの概念として、インフラレイヤーの階層にそれぞれ割り当てて使われるので、(私の) 頭が混乱してしまうのかなと思いました。

「Configuration」を行う対象は、「Infrastructure」としてひとくくりに呼ぶには対象の技術範囲が広すぎて、コミニケーションを取るのに不便だとは思います。

例えば仮想化のレイヤーの構成作業を指した言葉を使いたいのであれば、「Virtualization Layer As Code」のように言った方がわかり易くて良いのでは。と思います。その中には、SDS (Software Defined Storage) や、SDN(Software Defined Network) が含まれてくるでしょう。

そして、仮想マシン上のアプリケーション・レイヤーのインストール・構成作業は「Application Layer As Codeと呼べば良いかなと思います。

アプリケーションの構成は「Configuration As Code」。仮想マシンの構成は「Infrastructure As Code」と分け方をすると、何か腑に落ちなくなるので、構成作業という「動作」に重きを置いた話をしたい場合は「Configuration As Code」、構成の「対象」に重きを置いた話をしたい場合は「Infrastructure As Code」で良いのかなと思います。

世の中的に明確な定義は無いと思うので。とりあえずは、私個人としては、この使い分けで暫く運用してみようかな。と思っています。

-IT動向, IT技術

Copyright© エンジニアの何でもメモ帳 , 2024 All Rights Reserved.