IACの基本とツールの紹介
こんにちは、シニアソフトウェアエンジニアのriddleです。このポッドキャストは、IT業界のいろんな話やリアルをお届けするポッドキャストです。
今回はですね、Infrastructure As Code、略してIACと呼ばれるものの何なのかというところと、実際に使ってみて、こんな感じだよというところをご紹介できればと思います。
IACなんですけれども、10年ぐらい前に登場したので、もう多くの企業だったり、プロダクトでは使われているかなと思うんですけれども、改めて紹介すると、
クラウドだったり、OSみたいなもの、もしくはネットワークの機器とかですね、いわゆるインフラって呼ばれるものを構築するときに使うものになっています。
どういうことかというと、インフラって基本的に今までずっと手作業でやってたんですけれども、例えばOSの設定をこうするとか、
AWSのマネージドのコンソールからEC2を起動するっていう、一つ一つの手作業をコードに落とし込んで、そのコードを実行すれば常に指定された台数のEC2が起動しますよとか、
RDSが起動しますよみたいなことが書けるという感じになっています。で、これ何が嬉しいのかというと、GUIで操作しても一応同じものが作れるんですけど、
環境を新しく作りたい、そっちでもEC2を同じだけ起動したいよとか、作ったEC2の中にいろいろ設定ファイルとか入れたんだけど、横にも同じものを作りたいとか、
そういうことがあった際にですね、手作業だと何やって、何やってないんだっけみたいなことがわかんないですし、全部のファイルを持っていくって言っても全部ってどれみたいな話もなったりするので、
自分たちで管理しているものについては全部コードにして、Git系のものにうまくバージョニングで管理していくと、ちゃんと管理できるよねみたいな思想で作られてますね。
代表的なツールで言うと、テラフォームだったり、AWSだとクラウドフォーメーションとかCDKってものがありますし、
プルミとか、あとOS側だとアンシブルとかシェフ、板前みたいなものもあったかなと思いますね。いろんなツールがあります。
その中でも最近だとテラフォームとクラウドフォーメーション、CDKが多いイメージですかね。特にクラウドの構築の際には。
なんかOSとかだとアンシブルとかですかね、あとネットワーク機器とかが多いかなと思います。
IACの運用の課題
でですね、私もこの辺りのツールはよく使うんですけども、まあ便利ではあるんですけど、ないと困るんですけど、あったらあったでね、大変なんですよ。
なので今回は実際に運用したりとか使っている観点から、ちょっとあったらあったで何が大変なのかというリアルをお届けしようと思います。
まずですね、独自の機構というか独自の機法が求められることが結構多くて、これが大変ですね。
今ではAWSの場合だとCDKと呼ばれるもので任意のプログラミング言語で書ける、みたいなものも登場してきたんですけれども、
それを除くとほとんどの場合は独自の機法だったり、YAMLとかそういうものをいい感じに書くとやっと動くみたいなものが多くてですね、
その独自の機法でプログラミング言語みたいなリッチなことがあんまりできないので、最低限のif文とか最低限のループみたいなことを書けるんだが、
実際にインフラを作るときは結構なんか条件分岐とかループして何個も作るみたいなケースが多いので、毎回その文法なんだっけって調べ直したり、
微妙になんかやりたいことと違う挙動をしたりするので結構トラップが潜んでいます。
続けて、実際これGUIでやった方が絶対早くね、みたいなことをわざわざコードで書きがちってのもありますね。
それこそクラウドでサーバーを立ち上げるときってほとんど多分数クリックでいけると思うんですよね。
立ち上げます、こういう設定で、再立ち上げて、で30秒ぐらいしたら立ち上がってくるみたいな感じなんですけども、
同じことをISCのツールでやろうと思うと、まずはISCが動く環境を用意しないといけないし、
その上でISCがちゃんとEC2を作るとかVMを作るみたいなコードを一通り書かないといけないですし、
ではそれを流すってなったら、叩くところから叩き先に対してのなんか権限付与みたいなことをうまくやらないといけないしで、
割と最初に導入するためのステップも長いし、実際にそれで運用管理していった時に、
これやりたいだけなのになんでこんなコード書かないといけないのかなみたいな、
このなんかコード書いてる時間でもう作り終わってるんだけどなぁみたいなことを感じることがめっちゃ多いです。
これはもうね、あのISCツール作ってる人全員の共通の見解だと思いますね。
はい続いて、いろんなところにバグが多くてまともに作れないことがある。これもねありますね。
何を言ってるかというと、テラフォームを例にとって説明しますが、
テラフォームって呼ばれるハシコープ社ってところが出している製品、もしくはそのOSSがあるんですけれども、
こちらがですね、いろんなクラウドのベンダーの出しているIaaSとかSaaSをうまくコントロールできるみたいな仕組みを持っています。
基本的にはテラフォームが出して、テラフォームのコアの機能と各クラウドベンダーごとのプロバイダーってものを組み合わせて、
例えばAWSならAWS、GCPだったらGCP、AzureだったらAzureのインフラリソースを操作するんですけれども、
そのプロバイダーが何をやっているかというと、AWSで用意しているAPIを代わりに呼んでくれたりするんですね。
そうするとですね、我々がそのテラフォームを使うってなると、テラフォームとAWSのプロバイダーとAWSっていう3つの登場人物が出てくるんですけれども、
この全てがちゃんと意図した通りに動かないとおかしなことになるんですよ。
で、その3つってプロバイダーにもよりますけど、微妙に主体が違ったりするんですが、AWSのことはAWSのことなんで、テラフォームの人は知らないじゃないですか。
そうなると、テラフォームとしてはこういう挙動をするように作ったけど、AWSがいつの間にか仕様変更しましたとか、ちょっと挙動が変わるようになりましたってなったらすぐバグるんですよね。
で、それなると解決までもやっぱりそのテラフォームが悪いのかプロバイダーが悪いのか、もしくはAWS側の問題なのかみたいなまず切り分けないといけないし、
で、切り分けととってそれぞれが大きなOSSとか大きな企業ですから、そこに対して気軽にプルリク投げて直せますみたいなそういうものでもないんですよね。
実際私が今ダイナモDB周りでちょっとコードを書いてるんですけど、私が直面した問題は7年ぐらい前から一周が経ってて、
今現在も直ってないみたいなリアルタイム信号中の問題だったりして、その解釈を探すのにめちゃくちゃ時間かかってるんですよね今。
そういう感じですね。別にテレポチポチやればすぐできるのに、影響範囲というか関連しているリソースが多すぎるせいでなかなかコードにできないという問題がよくあります。
IACの重要性と今後の展望
続いて、何かわからないけど失敗するっていうことがあります。これもねよくありますね。
なんかエラー入ってて構築に失敗してるんだけど、何で失敗したのかよくわからん。エラーメッセージも雑だしみたいな感じのことがあります。
これもね、IACツール側というよりかはクラウド側の事情で、これとこれはこういう順番で作らないとダメですよとか、
これとこれは同時に作れませんよとかなんかいろんな制限があって、それを知らずに使うと普通にこけて、エラーメッセージもそういうことをうまく出してくれないことも多いので、一生ハマるってやつですね。
これもねなかなか辛いんですよね。でこれも起きると手で作ればいいじゃんって思っちゃうんですよね。
はい。続いて、プルリクは変更内容よりも最終的にどのように差分が出るかが大事。
これ何を言ってるかというと、普通アプリケーションのコードとかをレビューするときにGitHubだったらGitHubとかのレビューのページで差分を見ると思うんですけれども、同じくIACもその差分を見るんですね。
ただ一方で実際にそのIACコードを作ったときにサーバーにドライランみたいなことができるんですけれども、変更ともらわないけどこういう変化の差分が出るよみたいなやつがあるんですけれども、
大体の場合はそのドライランした結果をGitHubとかのプルリクにペタッと貼るんですよ。自動でCIツールが。
そうするとその差分だけ見れば今回のプルリクの修正ではこういうことが起きるんだってことがわかるので、どっちかっていうとそっちを見て判断するんですよね。
なので100行ぐらいコードが増えてても結果インフラリソースに対するなんかディフが1行しかないんだったら、まあその1行が間違ってなければいろいろ100行書いてあるけど
おおむね間違ってないことをやってるんだなってことはまず判断つくじゃないですか。もちろんその100行書いている処理が明らかに何か間違っている処理とか
なんかなんでこれいじってんのみたいなことだったらまあレビューとしてコメントはしないといけないですけど、おおむね最終的に出てる結果が正しければ
逆説的に今回のプルリクの内容もそんなに窓外れじゃないっていうことが言えることが多いかなと思います。これはIACツールが結構シンプルな構造を持っているがゆえ
っていうこともあると思いますね。はい、ということで今回はですね、私がIACツールを実際に使って運用している現場で
便利な反面いろいろ大変だよということをちょっとご紹介しました。 とはいえですね、やっぱりこの大変さを享受しつつもちょっと
インフラの高度化っていうのは一定やっておかないと後でいろんなところで苦しくなる経験があるので、まあ開発の初期は時間をかけてでもやった方がいいかなと思いますね。
まあ残念ながら長く維持されるプロダクトばかりではないんですけれども まぁちょっとねぜひインフラリソースに余裕があればまだ入れていない現場はぜひ入れてみてください
何度も変更する場合はねすごい力になってくれます。 このポッドキャストはハッシュタグユーザーITで皆様からの感想やコメント募集しております。
またチャンネルの概要欄にGoogleフォームのリンクもありますのでそちらからのご投稿も大歓迎です。 ありがとうございました。
