Publickey新野淳一IT羅針盤

「ITインフラエンジニア」の新しい姿はプログラマーと見分けがつかなくなる!?

クラウドの登場とインフラのコード化は、ITインフラエンジニアの仕事を現場の力仕事から、テキストエディタを使ったコーディングへと変えていくことになる。

クラウドが変えたITインフラエンジニアの仕事

クラウドが日本で普及し始めた10年ほど前、ある女性ITエンジニアから聞いた、とても印象深い言葉があります。それは「クラウドのおかげで、女性でもITインフラ業務がやりやすくなった」という言葉です。

どういうことかと聞くと、彼女は2つの理由を説明してくれました。

1つ目の理由は、データセンターの中で強力な冷房に寒い思いをしながらサーバーやストレージを運ぶような力仕事がなくなったことです。

ITインフラ担当の仕事は、ソフトウェアを実行するための環境を整えることです。そのためにはソフトウェアの開発を担当するITエンジニアとも相談のうえ、適切なサーバーの選択やネットワークの構成を検討します。そして必要な機材が納品されたらチェックし、データセンターやサーバールームに搬入してサーバーをラックに設置、電源やネットワークを接続し、冷房にふるえながらOSをインストールする、といった仕事が待っています。

かつての(現在でも一部の)ITインフラエンジニアにとって、こうした物理的な力仕事は業務のなかで重要な位置を占めていたのです。

これがクラウドの登場で一変しました。そもそもクラウドでは、まずデータセンターに入ることができません。ITインフラエンジニアの仕事はコンソール画面から、クラウド上で適切なインスタンスやストレージの構成、ネットワークの設定、OSの導入や仮想マシンの起動などを適切に設定することになりました。

2つ目の理由は、データセンターに入る必要がなくなったことで、どんな場所からでも仕事ができるようになったことです。

おかげで子供が熱を出して会社に行けなくなったとしても、自宅からITインフラエンジニアの仕事ができるようになったと、彼女は説明してくれました。

クラウドの登場によって、ITインフラは物理的なものから論理的なものになりました。そのおかげで、力仕事や寒さが苦手だったり、家庭の事情を抱えたりする人であっても、以前より仕事がやりやすくなったのです。

Infrastructure as Codeの登場

クラウドの登場によって始まったインフラの変化は、ここでとどまることなく、さらに進んでいます。次に起きた大きな変化は「Infrastructure as Code」(IaC)と呼ばれる仕組みの登場です。

前述の通り、クラウドの登場によってインフラの設定が画面から行えるようになりました。IaCはそれがさらに進み、サーバーやストレージ、ネットワーク機器などすべてのITインフラの構成を、プログラムのようにコードで表記できるようになるというものです。

例えばIaCを実現するための代表的な製品のひとつであるHashiCorp社「Terraform」では、設定ファイルによってオンプレミスからAWSやMicrosoft Azureといったさまざまなクラウドまで、構成を定義できます。

また最近登場したIaCツールの「Pulumi」では、PythonやJavaScriptといった既存のプログラミング言語でインフラを定義できる機能を備えており、コードによるインフラ定義とプログラミングの境目はどんどん曖昧なものになっています。

図1:「Terraform」のWebサイト(https://www.terraform.io/)

インフラのコピペやバージョン管理も可能に

インフラをコードとして表記できるIaCには、さまざまな利点があります。

その1つは同一のコードをもとに何度でもクラウド上でインフラを構築できるため、まったく同じ構成を確実かつ簡単に、何度でもすぐに再現できる点です。本番環境と同じ構成をテスト環境用に再現することも、構成ファイルを少し書き換えれば可能であり、さらに小さめの構成に変更することなども容易です。

コードであるため構成の変更を履歴として残すバージョン管理も、GitHubなどのソースコード管理ツールを利用して簡単に実現できます。またアプリケーションとそのためのインフラを構成するコードが同じようにソースコード管理ツール上で管理できるので、いつだれがどんな変更をしたのかが分かるようになり、より安全にインフラ管理を行えます。

Kubernetesのレイヤもカバーへ

最近ではインフラエンジニアのカバーするレイヤが上昇する傾向も見られます。

例えばクラウドであれば、必然的に物理的なサーバーではなく仮想マシンや仮想ネットワークのレイヤで構成を行うようになっています。これがコンテナ型仮想化の普及につれてコンテナの構成、つまりKubernetesのようなコンテナクラスタの構成についても、インフラエンジニアの守備範囲と見なす組織も出てきています。

またDevOpsの普及などによって、アプリケーションの変更とそれに関連したインフラに対するフィードバックと改善も、早いサイクルで行われるようになってきています。

インフラエンジニアとプログラマーの見分けはつかなくなっていく

こうなるとインフラエンジニアが主に使うツールは、Terraformの構成ファイルやDockerファイル、KubernetesのYAMLファイル、Pulumiのためのプログラミング言語などを操作するテキストエディタとなり、それを管理するためにバージョン管理ツールのGitHubを利用したりすることになるでしょう。

また仕事のサイクルも、アプリケーションを開発しているプログラマーに追随するようになるのではないでしょうか。

もちろん、こうした仕事の仕方をしているインフラエンジニアはまだ少数派です。しかしインフラのコード化とコンテナの普及によるレイヤの上昇、開発サイクルの高速化といった変化は、インフラエンジニアとプログラマーの仕事をどんどん見分けがつかないものにしようとしています。

インフラエンジニアがこの先もその能力を発揮するには、こうした変化に追随していく必要があるのではないでしょうか。

※本記事は東京エレクトロンデバイスが提供する不定期連載のタイアップコラムです。
※会社名および商標名は、それぞれの会社の商標あるいは登録商標です。

※このコラムは不定期連載です。
※会社名および商標名は、それぞれの会社の商標あるいは登録商標です。

新野淳一

新野淳一Junichi Niino

ブログメディア「Publickey」( http://www.publickey1.jp/ )運営者。IT系の雑誌編集者、オンラインメディア発行人を経て独立。新しいオンラインメディアの可能性を追求。