わたしたちに、 IaCはまだ早かったのかもしれない AWS STARTUP MEETUP #13 LT Presented By 株式会社ユニラボ 末澤

株式会社 ユニラボ リードエンジニア　末澤 普段はスクラムによる爆速開発を推進しています 主にバックエンドの開発を中心に、ソリューション アーキテクト的なことをするのが好きです テックブログで開発生産性やスクラム、社内勉強会 の取り組みを書いています see https://note.com/deliku0306 twitter deliku0306 自己紹介

テックブログ 開発生産性の向上やスクラム、社内勉強会の開催など、 エンジニア組織の様子や取り組みがわかるように心がけています

お仕事の発注先をお探しの方、 ぜひ使ってみてください！ 会社紹介 国内最大級のBtoB受発注プラットフォーム「アイミツ」を提供 受発注者を最適な形でマッチングさせることで、世の中の無駄な「相見積もり」を省き、 あらゆる発注をスムーズにすることを目指しています

2022.12 第4回 日本サービス大賞「優秀賞」 2022.10 Findy Team+ Award 2022 会社紹介 サービスの高度化と産業の発展を先導する、き らりと光る新しい価値を提供しているサービス や、これまでになかった新しいやり方を実現し ているサービスに贈られる ファインディ株式会社が運営する Findy Team+ 企業を対象にした、生産性が高いエンジ ニア組織を表彰する「Findy Team+ Award 2022 」 にて「規模別部門（Small Div ）」受賞

わたしたちに、 IaCはまだ早かったのかもしれない AWS STARTUP MEETUP #13 LT Presented By 株式会社ユニラボ 末澤 本編

メリット Infrastructure as Code 手動のプロセスではなく、インフラストラクチャの管理や プロビジョニングをコード管理すること ex Terraform 、CloudFormation IaCとは？ 環境の再構築の容易性、自動構築

IaC化 一度はIaC化したものの、やっぱり脱IaC... 既存プロダクト IaC化 2020秋 新規プロダクト リリース 2021/01 新規プロダクト リリース 2021/04 既存プロダクト システムリプレイス 2022春 not IaC not IaC 脱IaC 2020年までプロダクトは1つのみ。2021年に新規プロダクトを2つリリース。 2022年春にシステムリプレイスを実施。このタイミングで脱IaC化しました なぜわたしたちはIaCをやめたのか、今日はそのお話をします

当時抱えていた課題とIaC化することでの期待 課題 ・AWSマネジメントコンソールでしか状態がわからず、依存関係の理解が難しい ・インフラ構成の全体像把握が困難 ・コード化することで依存関係の把握や、構成把握をしやすくなるのでは？ ・変更したい箇所や影響範囲は、コードを検索することで調査しやすいのでは？ 期待

IaC化してみた分かったこと　その1 ・コード化することで依存関係の把握や、構成をしやすくなるのでは？ 　 　本番環境のみで、ymlファイル30以上、ファイルによっては数百行以上　　 　 　全てをコード化したことにより、コードを読み解いて理解するコストがかかる ・変更したい箇所や影響範囲は、コードを検索することで調査しやすいのでは？ 　これは期待通りでした 　Security Group に VPNIP追加 など 現実

IaC化してみた分かったこと　その2 ・コードを管理/運用できる人が社内の一部の人しかできず属人化してしまった ・AWSのサービス知識に加え、IaCの学習コストがかかる ・そもそもインフラの構成を変更する頻度が少なかった ・コード化したものの思い出すのに時間がかかる ・マネジメントコンソールを操作して数分で完結できる作業がコード化が必要 現実 当時弊社エンジニアは10人程度でしたが、AWSを扱える人は2人、 IaC化したことでさらにとっつきにくさが増えてしまいました

（勝手に）思ってたのとなんか違う ・そもそもコード化しないとなにに困る？ 　オペミス？ 　　　そもそも変更機会が少ない 　　　STG環境 → PRD環境で作業を行い、 　　　かつダブルチェック体制で行うことでオペミスをそもそも防ぐ 　　　 　再現性必要？ 　　　再現させることはほぼなかった 　　　構築手順およびシステム構成図を全てNotionで管理するようにした 　　　上記ドキュメントをもとに簡単に新規プロダクトインフラ構築が行えた 整理

インフラ構成図をdraw.ioで書いてみた 全体像を図示することでアーキテクチャ構成の把握を容易に 構成自体シンプル（CloudFront -> WAF -> ALB -> FarGate -> Aurora / Redis） デプロイは、CodePipelineを使用

インフラ構築手順はNotionに図解付きで 構築手順 / 設定方法をスクショ付きでドキュメント化 理解を補助するための位置付けとして活用

改めて考えてみた 考察 自分たちに必要だったのは、コード化ではなく、 ブラックボックス化していたインフラアーキテクチャの可視化であり、 「わからない → わかる」状態にすることでした。 そのためのHowとしてコード化は大きく作業しすぎた。

https://speakerdeck.com/shogomuranushi/infrastructure-as-code-is-very-tired https://ascii.jp/elem/000/001/860/1860716/ 大変勉強になった資料 「状況を鑑みて、要件を満たしつつ、コスト、ス ピード、リスクを評価し、代案の方がコード化よ りもROI が高ければそちらを選ぶべきでしょう。 たとえばDB やCDN って頻繁に作りませんよね？ そのような場合は代案の方がROI が高くなると思 います。 逆にコスト、スピード、リスクの観点でコード化 した方がROI が高ければ、コード化しましょう」

PR ご清聴ありがとうございました！ 「受発注を変革する インフラを創る」を VISION に掲げるユニラボでは、 一緒に働くエンジニアを募集しています！