満漢全席を食らえ！JAWS DAYS 2019レポート 第12回

コード化するメリットはあるのか、手作業ではダメなのか？

Infrastructure as Codeが目的化してない？ABEJAの村主さんが問う

　クラウドの魅力のひとつが、インフラをアプリケーションのように扱える点にあると思う。これにより、それまで物理インフラを構築する技術を持っていなかったアプリケーションエンジニアでも、自分でサーバを立てたりネットワークを構築できるようになった。さらにコード化することで自動化などの恩恵も受けられる。その魅力、いや魔力は強いが、何でもかんでもコード化するのは正解ではないのではないか。ABEJAの村主 壮悟さんはそう問いかける。

ABEJA,Inc. Product Owner & Lead Infrastructure Engineer 村主 壮悟さん

コード化する努力は本当に報われているのか？

　これは筆者の偏見なのだが、エンジニア、特にコーディングを生業とするプログラマーは、自動化が大好きだ。コマンドを手打ちすればできることを、その数倍の手間をかけてバッチやプログラム化し、「これで次回以降は楽になる」とほくそ笑む。個人的に「プログラマーは10の手間を惜しむために100の手間をかけて自動化する」と素人には説明している。その作業が何十回も必要なら、それは間違いではない。しかし実際には数回しか必要ではなく、プログラム化する方が手間が大きかった、なんてこともよくある話。これは、筆者自身の経験談でもある。筆者はバッチファイルが大好きで、大学生時代に使っていたX68000XVIのAutoexec.batは数キロバイトに及んでいた。

　そんな偏見にド直球で刺さったのが、ABEJA,Inc.の村主さんが行なった「Infrastructure as Codeに疲れたので、僕たちが本来やりたかったことを整理する」というセッション。村主さんはインフラ構築を自動化するTerrraformに大ハマり。かつてはQiitaに「Terraform Best Practice in 2017」というエントリを公開している。ディレクトリ設計に気をつけること、Workspaceを活用して環境を分けることなどを中心に、こまかいテクニックまで記載した熱意のこもったエントリだ。

「考えられるシチュエーションに、できる限りコード化で対応するためのベストプラクティスだと当時は考えたのですが、あとから読み返すとちょっと複雑すぎたなと。すみません、イキってました」（村主さん）

　とある日、同僚に「DynamoDBを立ち上げるためのTerraformのコードを作って」と頼まれた村主さん。2017年のBest Practiceを提唱しただけあり、その後のTerraformの進化について調査し、現時点での最適解を考察し始めた。が、その途中でふと気づいたのだった。

「いや、俺こんなことしてる場合じゃない」（村主さん）

　村主さんが勤めるABEJAはAI開発のスタートアップであり、従業員数は多くなく、一人が担う業務の幅も広い。村主さん自身はプロダクトオーナーであり、インフラの責任者でもあり、インフラに関わる操作を直接行なう担当者でもある。その中で、インフラ構築のために直接手を動かす担当者としての役割はもっとも比重が低い。

ひとりが多くの業務を担うスタートアップにおいて役割の比重を考えることは大切だ

「プロダクトオーナーとしての責務を果たすことに重点を置くべきで、こんなことに多くの時間を使っているのはもったいない。そもそも最適なコードを追求してTerraforｍでの自動化を実現できたとして、DynamoDBの構築や仕様変更はそう頻繁にあることではありません。だったら、DynamoDBのために差分を気にしたり、リファクタを考慮したりしながらコード化するメリットがあるのでしょうか」（村主さん）

　こうして自問自答するうちに、「そもそもInfrastructure as Codeで僕たちが本来やりたかったことは何だったのか」という根本的な疑問に行き当たった。

コード化で実現したかったこと、コード化によるメリット・デメリットを整理

　インフラをコード化するとはどういうことなのか。何を求めてコード化するのか。村主さんは基本に立ち返り、そのメリットとデメリットを含めて見直すことにした。

　そもそもInfrastructure as Codeとは、自動化やバージョン管理、テスト、継続的インテグレーション、継続的デプロイなど、ソフトウェア開発のプラクティスをインフラ管理に応用するための方法論だ。メリットとしては、工数削減や作業履歴の記録、テストの自動化、オペレーションミスの削減などが挙げられる。教科書的ではあるが、目的やメリットは明快だ。

「しかし、コード化することに伴う辛いことがたくさんあります」（村主さん）

　マウスクリックだけで数分で終わる作業もコード化しようとすると時間がかかる。コード化すると、リファクタしたい病が発病する。差分の整合性を取るのに時間と気を遣う。そして、コード自体が問題をはらむ場合もある。コードの拡張性を上げると可読性が下がり、シンプルにして可読性を上げると拡張性が下がるのだ。これに加え、コード化の有用性は自分が置かれている環境にも左右されるという。

コード化すべきかどうかはシステムの内容だけではなく、自分が置かれている環境にも左右される

「組織、体制、事業フェーズなど、自分を取り巻く環境によってコード化するかどうかを判断すべきだと考えます。なんでもかんでもコード化するのではなく、ROIを考えて、手作業も視野にいれましょう」（村主さん）

　そう語り、村主さんは次に手作業によるデメリットを挙げていった。これは、コード化のメリットの裏返しと言ってもいい。オペレーションミスが起こりやすい、記録が残らない、再現性がない、使い回せない、作業のレビューができない。これらのデメリットをひとつずつ検討してみれば、コード化や手作業以外の代案が見つかるかもしれないと、村主さんはさらに考察を深める。

　たとえばオペレーションミスが起こりやすいという点については、そもそもオペレーションミスが許される作業と許されない作業を分けて考えてみる。記録が残らないという点については、作業内容や履歴をGitHubで管理することができるのではないか。そういった具合にデメリットをなくすための手段を考えた結果、ひとつの代案として浮上したのが、CLIのコマンドを記録に残した上で実行するというものだ。コマンドをコピーして実行すればオペレーションミスは減らせるし、どのようなコマンドを実行したのか記録も残る。再現性もあるし、使い回しも可能だ。記録されたコマンド履歴からレビューもできる。コード化ほどの手間をかけなくても、手作業のデメリットをある程度相殺できる代案はあるのだ。

「つまり、まだあわてるような時間じゃない、ということです」（村主さん）

　ついついコード化したくなる自分に言い聞かせるように、「自分に対して冷静になりましょう」と村主さんは言う。本当にコード化するメリットはあるのか、手作業ではダメな理由は何か、もう一度洗い出してみることを村主さんは勧める。

コード化する前に、自分に対して冷静になり、代案について検討してみよう

「状況を鑑みて、要件を満たしつつ、コスト、スピード、リスクを評価し、代案の方がコード化よりもROIが高ければそちらを選ぶべきでしょう。たとえばDBやCDNって頻繁に作りませんよね？ そのような場合は代案の方がROIが高くなると思います。逆にコスト、スピード、リスクの観点でコード化した方がROIが高ければ、コード化しましょう」（村主さん）

ROIで考える、コード化すべきシチュエーションとすべきでないシチュエーション

　ROIで考えるべき、という方針はわかった。が、具体的にはどのようなシチュエーションでコード化し、あるいはどのようなシチュエーションではコード化しない方がいいのか。それについて村主さんは次のような例を挙げた説明してくれた。

コード化しない方がいい場合

• DBやCDNのように何回も作らないもの（コスト効率が悪い）
• 意図しない動作を許容できないステートを持つ系統のシステム（リスクを許容できない）
• インフラ担当者が少ない（学習コストが大きい、スピードが落ちる）

コード化した方がいい場合

• ALB＋EC2+RDBをセットで構築（頻繁に使うのでコスト効率がいい）
• DR用にすぐに立ち上げる必要があるシステム（スピードが求められる）
• 多リージョンにサービス展開する野望がある（スピードが求められる）
• リソース間をつなぐシステム（頻繁に使うのでコスト効率がいい）
• オペレーションミスを可能な限り排除したい（自動化によるリスクヘッジが可能）

「コード化する際にも、いくつかの注意点があります。すべてを盛り込もうと過度にキレイなコードを書こうとしないことです。コードが複雑になり、コード化のハードルは上がり可読性は下がります。どうしても複雑になる場合は、割り切って手作業で対応するのもひとつの手です」（村主さん）

　コード化する際に気をつけるべきことを訴えるのではなく、コード化が本当に必要かどうか見極めようと訴えた村主さんだが、最後にコード化する場合に使うと便利なツールの紹介も行なった。

Terraformをより便利に使えるツールを最後に紹介……結局懲りてはいないようだ

　紹介されたのは、Terraform Module Registry。誰かが作ったmoduleを再利用できるという、コード化によるリファクタを最大限に活かすツールだ。どこの誰が作ったのかわからないものを利用することの是非はあるとしつつも、「コード自体はGithubに公開されており何をしているのかはわかるので、信用に足ると考えています」と言う。こうしたツールを使ったり、Terraform 0.12でサポートされたfor文を使ったりすることで可読性の高いコードが書けると、最後にはやはりTerraform推し。

「すいません。ちっとも懲りていません」(村主さん）

　プログラマに対する筆者の偏見も、あながち間違いではないなと再確認したセッションであった。

■関連サイト

• 講演資料「Infrastructure as Codeに疲れたので、僕たちが本来やりたかったことを整理する」（SpeakerDeck）
• JAWS DAYS 2019