対象読者

IaCの利用者
システムアーキテクト

IaCとは？

Infrastructure as Code (IaC) とは、手動のプロセスや設定の代わりに、コードを使用してインフラストラクチャの管理とプロビジョニングを行うことを言います
https://www.redhat.com/ja/topics/automation/what-is-infrastructure-as-code-iac

IaCの概念自体は、2000年代初頭から存在はしていたようですが、2010年頃から2015年にかけて、Puppet, Chef, AnsibleそしてTerraformが発表されたことで広がりを見せたようです。

IaCを利用する際のメリットとしては、次のような点が挙げられると思います。

コスト削減
スピードと柔軟性
リスク管理

コスト削減

ソフトウェア開発におけるInfrastructureを構築する際に、2006年以前、AWSがAWS S3とElastic Compute Cloudを発表する前はハードウェアの選定からVM基盤などを決定し、VMのサイズの決定などあらゆる面を一つ一つ手作業で行なっていました。クラウドサービスが普及した現代では、大手クラウドベンダーがサーバーを事前に準備しており、従量課金制でのVMを提供しています。これらのサービスを利用することで、ハードウェア、VM環境構築など従来行っていた作業をする必要がなくなりました。IaCはこれらのベンダーサービスと連携することで少人数で開発環境を整えることが可能になりました。

スピードと柔軟性

IaCの利用で、各サービスのコンソールでそれぞれ作業をする必要がなくなりました。既に構成が記載されているファイルを利用することや変更をそのファイルに加えることで、高速かつ柔軟に変更を加えることができるようになりました。

リスク管理

サービスの設定をWeb UI上で手動で設定を行なっていた際は、どこかの設定を間違えてしまってそれが致命的な問題になってしまったりすることがありました。これらのリスクをIaCを利用することで減少させることができます。また、コードとして記載するため、GitのようなVersion管理システムと併用することで、変更点を第三者に確認してもらうことでリスクを減らすことができます。

現代の開発環境

現代では、インフラの開発だけでなく、現代の開発環境はクラウドサービスの提供するSaaSやその他のService Providerを組み合わせて構築することが多いと思います。IaCツールもInfrastructure向けと言いつつ、Serviceとの連携も念頭に置かれて利用されることが増えてきているように思います。

例えば、Terraformのprovidersでは現在およそ4500ほどのproviderが作成され提供されています。これは大手Service Providerが提供しているものもあれば、個人が作成しているSaaSに対してのものも含まれています。また現状、Provider一つが一つのサービスを提供しているのではなく、Serviceに対して、一つのProviderがあるため、Providerの中にさらに区分けされたSaaSが多く存在していることがあります。

このような現状は現代のエンジニアに次のような問題を引き起こしていると思います。

1. エンジニアの認知負荷

2020年台の問題点として、エンジニア個々人が扱わなければならない領域が、幅広くなってしまったということだと思っています。2020年以前は、多くの企業に属するエンジニアがある程度自分たちの領域を、ジョブタイトルによって制限することで、扱う製品、サービス、環境もある程度狭い範囲で行うことができました。しかしながら、PaaS, IaaS, SaaSなどの製品のサービス化が増加したことにより、素早く環境構築などをすることができるようになりましたが、環境構築をする対象のサービスに対する理解度を求められるようになリマした。

例えば、インフラが良い例だと思います。以前は社内にインフラエンジニアが在籍することによって、アプリケーションエンジニア、バックエンドエンジニアなどはインフラに関する知識を自ら行わずに、委託することで仕事の領域が明確でした。クラウドへの移行が進んだ会社では、インフラエンジニアを雇うのではなく、アプリケーションエンジニア、バックエンドエンジニアがインフラエンジニアの領域を兼務することも求められているように思います。当然クラウドエンジニアなどのポジションを持っている会社もあると思いますが、人件費の削減という点理由づけという意味ではIaCが良い隠れ蓑となっているのではないかと感じます。

2. コードレビューの難易度の増加

IaCのメリットとして、リスク管理があったと思います。GitなどのVersion Controlを利用することで、コードレビューなどが容易に行えるようになりましたが、認知負荷と合わせてコードレビューの難易度が上がっていると思っています。なぜなら、レビューする側もされる側もIaCの内容を理解していないとコードの品質の保証ができないからです。

コードレビューの方法や品質に関しては組織によって粒度があると思いますが、IaCで記載されるそれぞれの要素の情報や、利用方法を正しく理解していなければ、仮に設定が正しかったとしても、挙動が想定していないものになったり、リスクを減らすはずが、リスクを上昇させている可能性もあると思います。

改善点

これらの問題点から、私はいくつかの改善策を提案したい

1. 抽象化レイヤーの導入

クラウドベンダーのサービスや多くのSaaSは、似たようなサービスを提供していることが多いように思う。当然内部の性能やサービス内容は個々のサービスによって異なるのだろうが、ユーザーが触れるインターフェースはほとんどが似たようなものになると思う。

ユーザーの認知負荷を減らすために、IaCのインターフェースを共通化できるところは、共通化をし、より抽象化されたリファレンスアーキテクチャを構築しても良いのではないだろうか？

2. Code から Visualへ

またレビューを行うことは非常に難しいことを先に述べた。これをVisualで解決できるのであればVisualで解決することでコードで把握するのではなく、Visualで状態を把握することでより高速に柔軟にエンジニア同士の認識を合わせることができるのではないかと思う。

最後に

IaCはここ10年でクラウドやSaaSなどのビジネスの変化によって、より利用されるようになってきた技術ではあると思う。しかしながらエンジニアに対する認知負荷がサービスの増加に伴って課題として上がっているのが現状だと思う。2023年のGartnerのレポートではPlatform Enginereringがキーワードに上がり、エンジニアの認知負荷を低減するサービスなども続々と作られている。

日本では2018年の時点でエンジニア不足と言われており、今後より一層エンジニアの需要と供給のバランスが崩れ、エンジニアに対する負荷が増加するものと思われる。これを打開するにはどのように効率よく、また取捨選択をしながら業務を行っていくのかが重要になっていくのではないかと思う。