本記事は
IaCウィーク
5日目の記事です。
⚙️
4日目
▶▶ 本記事 ▶▶
6日目
💻
こんにちは！25卒入社の柴原です。
入社から約7カ月、配属されてからは約3カ月が経ちました。あっという間です。
配属後は、AWS CDKやTerraformなどのIaCツールを用いたインフラ案件に従事していますが、分からないことだらけで日々苦戦しています。
その中で、「IaCをどうやったら使いこなせるか」や「どのように勉強すれば良いのか」は常に課題として考えています。
そこで今回は、新人目線でIaCとどう向き合うべきかについて私個人の見解をまとめてみました。皆さんのIaCとの向き合い方を考えるキッカケになれば幸いです。なお、この記事ではIaCの技術的なことやIaCツールの違いなどについては詳しく言及しませんので、あらかじめご了承ください。
IaCとは？
まずは、IaCの概要についておさらいしておこうと思います。 IaC（Infrastructure as Code）とは、手動での設定ではなくコードによってインフラを定義・管理する手法です。
IaCをするにはツールが必要となります。具体的には、AWS CDKやTerraformなどがあります。
コードを用いることによって、下記のようなメリットが挙げられます。
- 再現性の向上
- 同じコードを用いれば、何度でも同じインフラ構成ができる
- 自動化
- CI/CDパイプラインに組み込むことで運用負荷を削減できる
- テストやレビューが容易
- Gitなどで誰がいつどのように変更したのかが明らかに分かる
- 静的解析やPRレビューにより品質を担保できる
一方で、下記のようなデメリットも挙げられます。
- 学習コストが高い
- ツールの選定と運用が難しい
- 最新リソースに非対応の場合がある
特にIaC初学者は、「学習コストの高さ」に直面することになりますが、なぜ難しいと感じてしまうのでしょうか？私は自分が感じた難しさを上長に相談してみました。
ある日の上長との会話
上長とお客様先へ向かう道中の会話の一部です。
自分「CDKとかTerraformの構文自体は少しずつ分かってきたんですけど、コードとAWS上の挙動がうまく結びつかなくて…。抽象化できるのがIaCのメリットの一つだとは分かってますけど、その分ブラックボックスにも感じてしまいます…。」
上長「ほーん。それはAWS上で何が起こってるか分からないってこと？それともインフラとして？」
自分「両方ですかね…。とにかく手を動かして構築経験を積めばイメージできてくるものですか？」
上長「うーん。もちろん手を動かすのは大切やけど、そもそもAWSが無かったらどうやって今担当してるインフラ構成を構築すると思う？」
自分「え？全然わかりません…。」
上長「まず、物理的にサーバーとかを用意したりしないといけないよね。これを実現するにはOSI参照モデルの物理層から理解しないといけないよね。そもそも、どうやってインターネットって繋がってると思う？インフラを完全に理解するには、海底ケーブルあたりから分からないといけないかもね！」
自分「海底ケーブル…？」
海底ケーブルは言い過ぎな気もしますが、上記の会話はがむしゃらにIaCの勉強を進めていた自分を見つめ直すきっかけとなりました。
わかったこと
上長との会話を振り返って、わかったこと・考えたことは大きく以下の3つあります。
本来の目的
会話の中で、私はIaCの難しさを「コードとAWSの挙動が結びついていない」「ブラックボックスに感じる」と言っています。その原因は、IaCの「知識」を身に着けることを目的化していたことが原因だと思います。この時の私は、「早くIaCを書けるようになりたい！」と思うままに、本やドキュメントを読んでそのコードを書くという学習をしていました。
しかし、IaCはあくまでツールです。極端に言うと、IaCの構文が分かっているだけでは何もできません。「英語の文法は知っているけど話せない」のと同じ感じかと思います。本来は、インフラを理解してイケてる構成をIaCで実現し、その恩恵を受けることを目的とするべきですね。
手を動かすということ
「とにかく手を動かす」は半分正解で半分間違っているのかなと思います。
例えば、気になるサービスについてIaCでどうやって構築するのだろうと検索してみると山のように情報が転がっています。良い世の中ですね。
しかし、何も考えずにそこに載っているコード通りに手を動かして構築するだけでは、私はあまり身にならなかったように感じます。技術を身に着けるためにも良い設計をするためにも「なにを作って、何を実現できて、何が嬉しいのか」という意識がないとただの作業になってしまいます。
感動がない新人
また、ある上司からはこんな話を聞きました。
ある案件で膨大な数のテスト作業をする必要があったそうですが、当時はそれを手動で行っていたそうです。その作業をどうにかラクにしたいという思いからコードを書いて自動化し、結果的に圧倒的にラクになったそうです。ここでコード化の恩恵を体感し、その後はAWS CDKをGAされた時から活用するなどして現在もIaCの第一線で活躍されています。
このようなインパクトのある経験が私にはありません。手動でのAWSの構築もままならないままIaCを使用する案件にアサインされた私は、初めてIaCを使用して構築した際も「ふーん。すご。」くらいでした。
この違いは、シンプルに経験値の違いだと思います。上長との会話においても、私の疑問に対してすぐに答えを出せるのは経験の違いでしょう。過去の苦痛をIaCで解決できたという経験がある人と最初からIaCで構築している人では感動も思い入れも段違いでしょう。
新人エンジニアはIaCとどう向き合うべきか
ここまで、上長の会話から私が感じたIaCの難しさの原因を洗い出しました。では、どのように向き合っていくべきでしょうか。わかったことに対して3つ考えました。
AWSが先かIaCが先か
本来の目的は、インフラを理解してイケてる構成をIaCで実現し、その恩恵を受けることだとしました。インフラを1から理解するのは重要ですが、オンプレからハンズオンを始めるには時間もコストも足りません。では、どうすれば効率よく学習できるのでしょうか。2つ方法を考えました。
IaCで構築する前に手動で構築してみて各AWSサービスの理解を深める
割と王道な方法かもしれませんが、2回構築するので時間や労力を要し、その過程で理解が深まったりIaCの恩恵を肌で感じられるかもしれません。リバースエンジニアリング的思考でIaCをキッカケに各サービスの理解を深める
コードと構築したサービスや各AWSリソースの状態を照らし合わせながら理解するという方法です。適宜コードを改変したりして挙動を細かく見ることでブラックボックスに感じる部分がだんだん解消できると思います。
IaCもAWSもよく分かっていないレベルだと前者、どちらか一方でも何となく分かるレベルなら後者が良いのかなと思います。
「構成図・コード・AWS」三位一体
「何を作って、何が実現できて、何が嬉しいのか」を考えるためには、コードだけではイメージしにくいと思います。具体的に考えるためには、構築するアーキテクチャを図で理解したり、詳細な設定やログを確認する必要があるでしょう。つまり、手を動かす＝コーディングではなく、以下を繰り返し継続的にすることが「手を動かす」ということだと思います。
- 構成図の作成
- コーディング
- 各リソースやログの確認
でも、構成図を書くのも難しいんですよね…。そんな時には、以下の記事を参考にしましょう。
感動を体感しに行く
AIの発達もあり、今後コーディングを含めたエンジニアの業務はどんどんラクになっていくことが想像できます。IaCにおいても同様で、すでに大体のIaCのコードはAIで書くことができます。そもそもIaC自体が手動で構築していた人には感動的な技術なのに、さらにそれがAIでほとんど書けるのが当たり前の中で新人エンジニアデビューするとなると感動がないのは当然かもしれません。
しかし、感動を自ら体感しに行くことはできると思います。例えば上長の「AWSがなかったらどうする？」という問いかけのように、AWSやIaCが無かったらどうするかを都度考えることによってだんだんとその利便性を体感できるでしょう。IaCがなかったらどうするかという点では、上記のIaCで構築する前に手動で構築してみる方法が当てはまります。
また、他人の経験を聞くことも一手だと思います。先輩でも良いと思いますが、IaC関連のコミュニティに参加することでより多様性に富んだ話が聞けると思います。あまり知識のない状態でコミュニティに飛び込むのは少し怖いかもしれませんが、いざ行ってみると様々な経歴の先輩エンジニアの方々と交流できて十人十色の経験談を聞くことができます。そこで昔の苦労話やIaCによって効率化できた話などを聞くことができれば、その人の感動とIaCの利便性の両方を感じられるかもしれません。
最後に
ここまで読んでいただきありがとうございました！ この記事が皆さんのIaCとの向き合い方や勉強の方法を考えるキッカケになれば幸いです。偉そうなことをつらつらと書いていますがまだまだ何もできない身なので、初心を忘れずマイペースに頑張っていきたいと思います。
