なけなしの130万を使って、Cloud Praticaに人生をオールインした話
初めまして
お疲れ様です！
新卒じゃなくなってしまって絶望している、またいたです...🫠。
本記事では、Cloud Praticaに4ヶ月間フルコミットし続けて、自分の中で変わったことや実業務での成果をまとめていきます。
Cloud Praticaとは
まず、Cloud Praticaとは、現役エンジニア向けのインフラ特化テックリード養成スクールです。
カリキュラムは以下の全12コースで構成されており、一般的なモダンインフラ構成をほぼ網羅できる内容となっています。
- AWS基礎コース
- AWS実践コース
- Terraform importコース
- Terraform applyコース
- CI/CDパイプライン構築コース
- Kubernetes 入門コース
- Kubernetes 応用コース
- AWS 応用コース
- AWS 道場コース
- Datadog コース
- Google Cloud 基礎コース
- Google Cloud 実践コース
📌 値段に関する詳細について
料金等の詳細につきましては、Cloud Praticaの説明会にてご確認ください。
1. Cloud Praticaを始めたきっかけ
まず、年明けの時点での受講前の自分はECSという単語の意味すらわからない状態でした。
そんなレベルのエンジニアであり、そのくせ「このままエンジニアとして何を勉強すればいいのだろう」と漠然とした不安や悩みを抱えていたどうしようもない人間だった頃、会社の先輩からお勧めしていただき、受講する決意を固めました！
そうはいっても払っているお金を思い出すと、漠然とした不安がありましたが、最初のaws基礎コースの進捗４パーセントくらいで、濃密な一方で本当にわかりやすい解説で、不安は吹き飛び、これに全ベットすれば、絶対に強くなれるという確信が湧き、この４か月コミットを続けてきました。
その結果、実務では頼りない新卒だった自分がものの数か月で、チームの中で何かあったらあの人に聞けというポジションになっており、エンジニアとしての地力も明らか上がったのが実感でき、本当に自分でもびっくりしております！
正直、そこらのスクールと違って、泥臭く地味な作業も繰り返しあり、全コース終わらせるのは辛く苦しいときもありましたが、やり切った今本当に成長を感じています！
2. Cloud Praticaがおすすめな人
一応、全コースが終わった自分の感想からすると、
- 新卒やエンジニア成り立てで、何を学べばいいかわからないけど、やる気だけは誰にも負けない人
本当にお勧めです！！
わかりやすい解説に、ちょうどいい難易度、手厚いサポートに、周りを見るとハイレベルすぎる受講生、すべてが学ぶ環境に適しています！！！
本当に自分は成長を実感できたので、以上の悩みを持つ方にぜひお勧めしたいです！
一方で、
- 寝ているだけで（楽して）エンジニアとして成長したい方
は、お勧めできないかと思います。
本当にボリュームが多く、章によってはつらい戦いが待っているので！（だからこそ、レベルアップができたと実感しているのですが）
もしそんな方法がありましたら、DMで教えていただけると助かります 笑！！！
3. Cloud Praticaで学んだこと
本当にどれも濃密なカリキュラムでしたが、特に印象に残っているコースを軽くご紹介します。（学んだことが濃密すぎて、軽くまとめてもこの量でした...！）
AWS実践コース
このコースでは、基礎コースで学んだ基本的なECSの構成をより発展させ、
Route 53 → ALB → ECS Service → ECSタスク → RDSの構成から、以下を行いました！
-
EC２を用いた踏み台環境の構築
SSM（AWS Systems Manager）を用いたポートフォワーディングにより、ローカル環境からセキュアにRDSへアクセスする構成。セキュリティグループの22番ポート（SSH）を開ける必要がなくなり、鍵の管理からも解放されました。 -
コスト最適化
AWS Fargate Spotの活用や、Amazon EventBridge Schedulerを用いた夜間のタスク停止など、無駄なコストを徹底的に抑える設計。 -
障害影響を最小化するサービス分離
バッチ処理用とAPI用のサーバーを分離し、デプロイ時や障害発生時の相互影響を最小限に抑えるアーキテクチャ。 -
Amazon SQSを用いた非同期処理とグレースフルシャットダウン
レスポンスに時間がかかる処理を非同期化。デプロイ等でコンテナが終了する際のSIGTERMシグナルをキャッチし、安全に処理を終了させるグレースフルシャットダウンや、DLQの設計を実装。 -
CloudFront + S3による静的コンテンツ配信
OACを有効化し、CDN経由のアクセスのみを許可するセキュアな配信構成。 - AWS Amplifyの活用によるフロントエンドのコスト削減
Kubernetes 応用コース
こちらのコースでは、以下を学びました！
- HelmとKustomizeを使用した柔軟なリソース管理
-
External Secrets Operator（ESO）による秘密情報の動的管理
Git管理したくない情報を AWS Secrets Manager で定義し、ESOが Pod Identity で認証・取得して Secret を動的に作成するセキュアな運用。 - Horizontal Pod Autoscaler（HPA）を用いたオートスケーリング
-
AWS Load Balancer ControllerによるL7ルーティング
Ingressの定義を基にALBリソースを自動プロビジョニング。 -
Argo CDを用いたGitOpsの実現
Kubernetesの実際の状態を、Gitの状態へ自動的に同期。 - Prometheus & Grafanaによる監視基盤の構築
-
Istioによるサービスメッシュの構築
PodにEnvoyプロキシをサイドカーとして注入し、Istiod（コントロールプレーン)によるサービス間のIP管理とマイクロサービス間通信の制御を実装。
Google Cloud 実践コース
こちらのコースでは、以下を学びました！
-
AWSとGoogle Cloudの設計思想の違い
VPC、ロードバランサー、ファイアウォールルールの仕組みや違いの理解。 -
Cloud Run Jobとリトライ設計
Cloud SchedulerからCloud Run Jobを起動し、Direct VPC Egress経由でCloud SQLに書き込む構成。システムに負荷をかけないよう、指数バックオフやジッターを考慮したリトライ処理の設定。 -
Cloud Tasksを用いた非同期処理の実装
ゼロスケールや柔軟なリトライ処理を鑑み、Pub/SubではなくCloud Tasksを採用。のCloud Runの強みを活かして別サービスとして切り出す設計。 - Cloud Runのネットワーク周り（Ingressや認証）の学習
-
IAPを利用したセキュアなアクセス
ローカルからポートフォワーディング＋IAPでGCEの踏み台サーバーにアクセスし、Cloud SQL Auth Proxyを経由してCloud SQLへ接続。 - Cloud CDN + Cloud Storageによる静的コンテンツ配信
- Cloud BuildによるGitプッシュ時の自動デプロイ構築
正直、これ以上書いてもキリがないのでここらへんで終わりにします！！
4. この4ヶ月で実際に業務へ活かしたこと
Cloud Praticaで学んだことを生かし、以下を行いました！
① GitHub移行に伴うCI/CDワークフロー改善 & Dockerビルド高速化
GitHub移行(14リポジトリほどやらされました...)に伴い、開発のボトルネックになっていたDockerビルドの時間をレイヤーキャッシュや並列実行、ビルドボリュームの削減などを行い、
11分台 -> 5分後半 まで短縮しました。
また、GitHub Actions移行時のCI/CDのリファクタ（Reusable WorkflowsやComposite Actionを用いたファイル管理や、最小権限の法則を遵守したpermission設定、concurrencyなどによる開発体験向上)などを行いました。
② GitHub Actions & Terraformによるブランチごとのstg環境の自動構築
従来のstg環境は、すでに立ち上がっている固定のECSに対してECRイメージを付け替えてデプロイする運用でした。そのため、「環境が足りない」「Slackでデプロイ宣言をしないといけない」という不満がある状況でした。
特にバッチ処理専用のECSは1環境しかなかったため、検証の順番待ちで業務が滞ることが多々ありました。
そこで、CI実行時にブランチごとの独立したECS環境が立ち上がり、不要になったら自動でdestroyされる仕組みを構築しました。
実装方法としては、GitHub ActionsからTerraformリポジトリを参照し、ブランチごとの環境変数を注入して環境を動的に作成するようにしています。これにより、GitHub上でデプロイが完結し、上限を気にせず検証できるようになりました。
※バッチ処理の重複実行を防ぐため、この動的環境では特定の環境変数をタスク定義に渡し、ミドルウェア側でそれを検知した場合は手動実行のみを許可するガードレールを設けています。
また、コスト削減のために以下の工夫も行いました。
- AWS Fargate Spotの採用
- ARM化
-
EventBridge Scheduler + AWS Lambda を用いた夜間のタスク自動停止や、作成から3日以上経過した環境や、マージ/クローズされたPRの環境を自動destroyする仕組み（消し忘れ防止）
stateファイルをブランチごとに作成することで、リソース削除時に楽になるような工夫も
③ 本番ECRのイミュータブル化
以前は本番環境が latest タグで運用されており、「タグの付け替えが裏で失敗していても、タグ自体は存在するためデプロイツールが正常終了と誤認し、障害に繋がる」という問題がありました。また、デプロイ履歴がすべて同じイメージタグになるため、いつ何がリリースされたのか追えない状態でした。
そこで、デプロイ時にCI側で新しいタスク定義を動的に生成する構成へ変更し、ECRをImage Immutabilityに設定しました。これにより、現在どのイメージが本番にデプロイされているかが一目で可視化され、履歴も完全に追えるようになりました。
④ EC2からAWS Fargateへのリプレイス
社内の技術標準化、およびOSの定期メンテナンス（パッチ当て等）の運用負荷から脱却するため、EC2構成をFargateへ移行しました。
多数存在していた環境変数は、タスク定義に直書きするのではなくS3から取得する設計に変更。これにより、環境変数変更時の不要な再デプロイを減らしたりなど行いました。同時に、不要なポートが開いていたセキュリティグループも一新し、セキュアな状態へ改善しました。
⑤ Datadog導入による監視基盤の強化 & ボトルネック改善
過去に、論理削除されたレコードを含むテーブルを一括取得する際にDBのメモリが枯渇し、スワップが発生して障害に繋がったことがありました。（当時は障害が発生するまで誰も認知できていませんでした...!)
これを機に「監視基盤を強化したい」と上に提案し、Datadogを導入しました。
具体的には、Datadog AgentをサイドカーとしてAppコンテナに配置し、AWS FireLens経由で一定以上のログレベルをDatadogに集約する構成にしました。
さらに、APMを導入してログとトレースを紐付けたことで、エラーログから即座に該当のAPMを確認できるようになり、障害発生時の原因究明スピードが向上しました。
また、横断的なサービスのメトリクスを1枚にまとめたダッシュボードを新規作成し、運用の認知負荷を軽減。これまでオオカミ少年化していたCloudWatchアラームもDatadog Monitorへ移行し、通知の優先度（Priority）を設定して「本当に対応が必要なアラート」だけが適切に飛ぶように設計し、エンジニアの疲弊を軽減しました。
この過程で、一部のユーザーに影響が出ていたAPIの N+1問題やDeadlock も特定・修正し、パフォーマンス向上も行いました。
⑥ その他のインフラ改善成果
- AWSリソースのIaC化：変更の多いリソースをTerraformでコード管理し、変更履歴の可視化と本番環境apply時の再現性を担保。
- Amazon RDSのブルー/グリーンアップデート：これまで何十分もメンテナンス画面を出して行っていたデータベースのアップデートを、約5分程度のダウンタイムに抑え、システムの可用性を向上。
- AWS WAFの導入：ALBにWAFをアタッチし、SQLインジェクション等の攻撃をブロック。
また、詳細は別の機会にまとめようかと思いますが、インフラ周りの知識が全くなかった自分としては、かなりボリューミーで成長できた４カ月だったと思います。
5. まとめ
この4ヶ月間は、私のエンジニア人生にとって本当に大きな転換点となりました。
以前はバックエンドの世界に閉じた改善しかできなかった自分が、今ではインフラの設計・構築から運用改善まで、一人で主体的に推進できるようになりました。ここまで成長ができたのは、Cloud Praticaをやり切ったからだと感じています。
特に、
- ブランチごとのstg環境自動構築
- EC2からFargate replace
- Datadog導入
は、小手先の知識では絶対にやり切れなかった案件でした。ここで学んでいなければ、途中で挫折していたかと思います。
ちなみに、本記事を書くにあたって、１円も自分に入っておりません笑！！
思いをそのまま書かせていただきました😌
最後になりますが、このような最高の学びの場を提供してくださり、時にはアドバイスをくださった
りょうまさん には本当に頭が上がりません。
ありがとうございました！！🙏
まだまだせっかく学んだことを生かし切れていない部分も多いので、今回の経験を糧に、さらにエンジニアとして強くなっていきます！！！😾
Discussion