自分の5年のキャリアを振り返り、インフラ力がグッと上がったタスクに共通項があり、そこに再現性があると確信しました。
今回は、インフラ力が急激に上がったタスク一覧を紹介しつつ、そこから導き出された「再現性高くインフラ力が向上する完全ロードマップ」を余すことなくお伝えしたいと思います。
インフラ力が急激に上がったタスク一覧を時系列順に整理してみました。
既存の本番環境のEC2を参考に、ステージング環境を一から構築しました。ネットワーク周りで何度も躓きながらも、最終的に動く環境を作り上げることができ、AWS環境での本格的なデプロイメント経験を得ることができました。
Lambda、API Gateway、RDS Proxyを使用した既存環境をベースに、新規プロダクトを2つ立ち上げました。既存構成を理解し、それを新しい環境に適用する経験を通じて、サーバーレスアーキテクチャへの理解が深まりました。
既存の本番・ステージング環境に加え、新たにサンドボックス環境を構築するタスクを担当しました。KubernetesとTerraformを使用した環境構築において、以下の経験が特に重要でした↓
上記を通して、これまで雰囲気でしか理解していなかった、GCPのサービスやKubernetesリソースについて解像度が高くなり、一気に実力がつきました。
手動管理されていたAWSリソースを全てTerraform化し、別のAWSアカウントへの引っ越しを行いました。
この経験を通じて、
について深い知見を得ることができました。
SREとして、インフラに関する課題に向き合っていくと、どうしても自分が経験した範囲では解けない応用問題が出てきます。
その際に、他社の上手くいった事例と技術書からのインプットを通して、根拠に基づいた意思決定 を実践し、既存の答えがない状況でも正解を作りあげていく応用力を身につけることができました。
AWSでの豊富な経験を活かしつつ、GCPでの新規プロダクトローンチに携わりました。 構築する上で必要なサービスについて、AWS → GCPへの適切な脳内変換を行うことで、マルチクラウド間でのサービスの類似性や差分について知見を得ることができました。
武道の世界で、「守破離(しゅはり)」という言葉があります。
「守」の段階では、お手本を徹底的に守り、基本の型を真似して覚えます。
これは、クラウドの世界でも同じで、まずはベストプラクティスに従ってシステムを構築し、基本の型を身につけていきます。
次に、「破」の段階では、他の優れた事例を参考にしながら、自分なりの工夫を加えて発展させていきます。
クラウドの世界でも、他社のうまくいった事例や技術書などを参考にしながら、自社に合った形でカスタマイズしていきます。
最後に、「離」の段階では、一つのクラウドで得た経験を生かして、新しいクラウドに挑戦していきます。例えば、AWS で培ったノウハウを活かして GCP に移行したり、あるいは他のクラウドに横展開したりすることで、さらなるステップアップを図ることができます。
「守」のStepでは、AWSとTerraformの呼吸を身体で覚えていきます。 この時点では自分の考えやこだわりは一切捨てて、お手本の綺麗な構成をTTP(徹底的にパクる) すればOKです。
まず、既存のAWSの構成を熟読して理解します。このときに、具体的な通信経路までしっかり読み解くことが大事です。
例えば、Route53でドメインの名前を解決した後に、ALBに行き、リスナールールによって、ターゲットグループが決定される。ECSやEC2などのターゲットグループに到達後、コンテナ内のWebサーバ(nginx)やアプリケーションサーバ(unicorn) を通じてRailsのアプリケーションに到達する、といったレベルまで理解できると最高です。
難易度の高い構成であれば、ぱっと見でわからないことも出てきます。その際は、紙に状況を整理することで世界が開けることが多々あります。僕も、仕事用の物理的なノートを常にデスクに置いてまして、理解に苦しむ箇所があれば書き殴っていました笑
既存の構成を理解した上で、それを見ながら似たような構成を手動で構築していきます。
やってみるとわかるのですが、構築して初めて理解できていない箇所が浮き彫りになります。その際は焦らず、1つ1つ丁寧に周辺知識をキャッチアップしていけばOKです。
僕の例でいくと、Kubernetesの環境をもう1つ作る際、Istio関連の理解が怪しいことに気づきました。 そこで、
など気になったことをとことん調べていました。当時は生成AIがそこまで発達していなかったのでZennやQiitaの記事で肩慣らしをしつつ、公式ドキュメントを読み込んで詳細を把握するようにしていました。 今(2024年の末時点)であれば、Perplexity Proに質問攻めするのが楽かなと思いますw
また、先に手動で構築することがめちゃくちゃ重要でして。いきなり、Terraformで構築を初めてしまうと、「手触り感」がなくなってしまうんですよね。
例えば、
などなど、コンソールの画面でしかわからない、設定のノリ・雰囲気のようなものがあります。
ちょっと老害っぽいコメントになってしまいますが、Terraformが綺麗に揃った環境でインフラを触り始めてしまうと、手触り感のないままインフラに更新をかけてしまいます。結果、重大なインシデントを意図せず発生させてしまったり、既存にないものを 0 → 1で構築する際に手も足も出なくなったり、という事態になりがちです。
大学受験や資格の勉強でも、問題を解いて初めて理解が曖昧だった箇所が浮き彫りになった経験があるかと思います。それと同じで、構築して初めてわかる世界があるので、このステップが特に重要だと思っています。
既存の構成を真似て構築するだけでも十分な力がつくのですが、さらにTerraformでコード化し、それを使ってもう一つ同じものを複製していく。この経験を積めると一気にインフラ力が上がっていきます。
既存の構成をコード化するには、以下の流れで行います。
実際にやってみるとかなり泥臭い作業です。
Terraformと聞くと、そこら辺に落ちているコードやmoduleを複製してterraform applyして簡単に環境ができた、やったー！というイメージが強いですが、実際に現場でやることは、緊張感満載の地味な時間が多いです。
しかし、これこそが多くの現場で求められている本当のTerraform力です。
僕が2024年に実施した実例でいうと、1つのAWSアカウントに本番と検証環境が同居していたものを別アカウントに分離するプロジェクトにて、時間配分はざっくりこんな感じでした。
比率でいうと、20 : 1。
色んなエラーに詰まりながら地道にコードを調整し、最後に気持ちよくapplyして複製するのはほんの一瞬。これがTerraform運用の実態かなと思います笑
既存の膨大なAWSのリソースを全てTerraform化した経験を通して、Gitコマンドを触るがごとくインフラを自由に変更できるようになります。
ソースコード管理で何かイレギュラーなイベントが起こった際、
と色んなコマンドを駆使して、リモートのソースコードを自在に操りますよね？
このコマンドを実行したら、ローカルやリモートの状態がこんな感じで変化して・・と身体が覚えているはずです。
Terraformも同様で、既存環境のコード化力を極限まで高めることで、不測な事態が起こった際も
などのコマンドを駆使して、元の綺麗な状態まで「手触り感を持って」整えることができるようになります。 (既存のmoduleをコピーしてapplyする経験しかないと、リリース作業中にTerraformでイレギュラーな差分が入った時にあたふたして、実態のリソースを削除してしまうような事故を起こしかねません)
上図のサイクルを何十回も繰り返すことで、それぞれのAWSサービスが持つ特徴や癖というものを 知識ではなく身体で覚えることができます。さらに、Terraformという武器を使って、Gitを触るかのごとくインフラを自在に操れるようになり、一度構築した環境を使い回し可能な「資産」として管理できるようになります。
先ほどのインフラ力が急激に上がったタスクでいうと、まさに緑のグループが「守」のステップに該当するものになります。
「守」の段階で AWSの基本的な呼吸をしっかりマスターすれば、ある程度自由自在にシステムを構築できるようになっています。
そこからさらにステップアップするには、「破」の段階に進むことが大切です。
自社サービスが成長する中で遭遇する課題に対して、成功事例をカスタマイズしながら解決を図ります。 最初は既存の構成に答えが落ちているかもしれませんが、「守」の知見だけでは太刀打ちできないタイミングがやってきます。ここが、殻を「破」るチャンスです。
他社の上手くいった事例や技術書など参考にして、良いものをどんどんカスタマイズして取り入れていきます。 その過程で、初めましてのサービスに出会うことも多々あると思いますが、守のStepで多種多様なサービスの型を覚えているので、そこまで苦労することなくキャッチアップできるはずです。
上図では、青のグループが「破」のタスクに該当します。
僕の実例で言うと、2024年の初めにジョインしたスタートアップのインフラ刷新プロジェクトでやった施策はほとんどがこの「破」のものでした。
2024年の振り返り記事 より一部抜粋
上記は、サービスが成長するに伴って出てきた課題に対し、他社の技術ブログやAWSの書籍を読んでインストールしたベストプラクティスを導入したものになります。
「守」のステップでAWSのサービスを扱う呼吸を覚えているので、初めて触る技術でもそこまで苦労することなくTerraform化まで済ませた状態で取り入れることができました。
この「破」のStepを通して解決した課題の量と質が自分の骨肉となり、インフラ力をさらに深めてくれたように思います。
最後に、「離」では1つのクラウドで得た豊富な知見を活かしてマルチクラウドへ展開していきます。
上図では、赤のグループが「破」のタスクに該当します。
１つのクラウドをしっかりマスターすれば、どのクラウドでも似たようなものが揃っています。そのクラウド独自の考え方が癖というものは多少ありますが、キャッチアップはそこまで難しくないはずです。
ざっくりAWS → GCPの対応表を載せておきます。
| AWS | GCP |
|---|---|
| EC2 | GCE |
| ECS | Cloud Run |
| EKS | GKE |
| S3 | Cloud Storage |
| Lambda | Cloud Functions |
| CloudFront | Cloud CDN |
| Route53 | Cloud DNS |
| ALB, ELB | Cloud Load Balancing |
| SQS | Cloud Pub/Sub |
| RDS | Cloud SQL |
| DynamoDB | Cloud Bigtable |
| ElastiCache | Cloud Memorystore |
| Step Functions | Cloud Workflows |
※ 厳密にはそれぞれ細かい違いはありますが、ざっくりとした脳内変換としては十分に使えると思います。
マルチクラウドの経験を積むことで、クラウドベンダー間の差分がわかるようになり、納得感のある意思決定ができるようになります。
例えば、以下のような差分です。
意思決定以外でも、シンプルにインフラの守備範囲が広がるので、活躍できるプロジェクト・会社が増えていきます。(直近だと、マルチクラウド構成の会社がかなり増えており、どちらもできるとかなり重宝されますね)
とある昔。本業のシステム構成を理解し、実際に構築してみる、そしてそれをコード化する。この一連の流れを繰り返し学習することで、インフラ力を劇的に向上させ、メガベンチャーのSREとして転職に成功。副業で技術顧問の案件を多数受けて、とんでもなく稼がれている方をTwitter上で見つけました。
魔法使いエンジニアるるさんという方です。
そのやり方を知った時は衝撃でした。時間の都合上、僕は同じ方式を辿ることはできなかったのですが、これまでのキャリアを振り返るとまさに同じサイクルを回していたことに気づいた時には電撃が走りました。
「まさに、これこそが再現性高くインフラ力を高める間違いのない方法だ！」と。
だからこそ、この方法論には大きな可能性があると確信しています。
以上、僕の5年間のキャリアから導いた、インフラ力を向上させる勝利のサイクルをまとめてみました。
この方法は、かなり再現性が高いので、一人でも多くの方の参考になれば嬉しいです。
この学習サイクルを信じて実践していただければ、きっと皆さんも現在の職場で、インフラを任せてもらえるようなエンジニアへと成長していけるはずです。
鉄は熱いうちに打て！ 今からでもAWSのアカウントを開設して、勝利のサイクルを回していきましょう！
皆さんがAWSを自由自在に使いこなし、テックリード・CTOへ駆け上がれる未来を心から信じています。
最後までお読みいただきありがとうございました！