echo("備忘録");

IT技術やプログラミング関連など、技術系の事を備忘録的にまとめています。

【AWS】【Serverless Framework】CloudFormationでのリソースまとめ方(Part2)

はじめに

2か月以上前になりますが、「CloudFormationテンプレート(Serverless Frameworkのserverless.yml含む)でのリソースのまとめ方」について、ここに「同一プロジェクトで管理する場合」のメリット・デメリットを書きました。

あれから2か月、だいぶ間が開いてしまいましたが(プライベートでいろいろとありまして...)、今度は「別プロジェクトで管理する場合」について記載します。

別プロジェクトで管理する場合

「別プロジェクトで管理する」場合は、単に「どの単位でプロジェクトを分けるか」だと思います。

個人的に、主には以下の2つかなと思います。(もちろん他にもあるかもしれませんが)

  • ライフサイクル単位で分ける
  • サービス単位で分ける

なお、いずれの場合もフォルダ&ファイル構成はこうなります f:id:Makky12:20210530190110p:plain

下記ファイル&フォルダの説明は以下の通り

フォルダ名 説明 package.jsonおよびserverless.ymlの説明
rootPj ルートプロジェクト(全ての子プロジェクトを管理するためのフォルダ) ・複数プロジェクトで必要になるリソースの定義
・全プロジェクトのデプロイコマンドの定義
childPj(1~n) 子プロジェクト(特定の単位で分けたプロジェクト) ・自分のプロジェクトでのみ必要になるリソースの定義
・自分のプロジェクトのみのデプロイコマンドの定義

ライフサイクル単位で分ける

例えばストレージ系(S3など)は、一度デプロイしてしまえば、そうそう設定を変更することはないので、あまり追加でデプロイが必要になるケースは少ないと思います。

逆に、Lambdaなどは一度デプロイしても、機能追加・機能改修・不具合修正など、頻繁にデプロイする機会が多いと思います。(一番デプロイする機会が多いのがLambdaかも?)

また、同じLambdaのでも重要度が高い・アクセス頻度が高いなどで頻繁にデプロイするものもあれば、重要度が低い・実施頻度が低いなどで、デプロイ頻度が異なるものがあると思います。

こういった時に、ライフサイクルでプロジェクトを分けておけば、デプロイ頻度が高いリソースのデプロイ特に、毎回デプロイ更新が低いリソースも一緒にデプロイしなければならない...ということが減ります。

ただし、プロジェクト間でリソースの依存関係があった場合に、ちょっと厄介だったりします。(クロススタック参照など)

  • API Gatewayの情報を別プロジェクトのLambdaに渡す。
  • S3の情報を別プロジェクトのLambdaに渡す。(S3トリガなどの場合)

サービス単位で分ける

これはマイクロサービスアーキテクチャなどで複数のマイクロサービスを作成する際、マイクロサービスごとにプロジェクトを作成する方法です。(Azureの「リソースグループ」に似ています)

そのようにプロジェクトを分けることで、プロジェクト単位でデプロイできるため、マイクロサービスの管理がしやすくなります。

また、マイクロサービス単位で完結するようにすれば、ライフサイクル単位に比べて、依存関係の問題は発生しにくくなります。

ただし、同一マイクロサービス内で更新頻度の高いリソースと低いリソースが混在する場合に、やはりしなくていいリソースのデプロイが発生してしまいます。

また、プロジェクト間でリソースの依存関係の問題も、完全に解決する...というわけではありません。

メリット・デメリットまとめ(一覧表)

管理方法 メリット デメリット
1ファイルにすべて記載 リソースが少なければ管理が容易 ・リソースが多いと管理が大変
・リソース数の上限問題
スタックのネスト(親子関係をつける) リソース数の上限を気にしなくていい ・ネストのやり方に慣れるまでが大変
デプロイに時間がかかる
リソース種別で管理 ・不要なリソースのデプロイが減らせる
デプロイ時間が減らせる
・依存性の管理
サービス単位で管理 ・管理がしやすい
・依存性の問題が発生しにくい
・不要なデプロイが発生するケースもある
・依存性の問題がなくなるわけではない

まとめ

と、時間が空いてしまいましたが、CloudFormationでのリソースまとめ方について、2回に分けて説明しました。

実は1回目の記事を公開後、ちょっと間が開いてしまったのですが、5/18(火)にクラスメソッドさんの「AKIBA.AWS ONLINE #03 -IaC を語りたい 編- 」というイベントがありました。
dev.classmethod.jp

で、その中で

CloudFormationを使用していますが、Lambdaを1つ更新したいだけなのに全リソースを一括デプロイしなければならず面倒です。何か良い管理方法はないでしょうか?

という質問があり、「めちゃくちゃわかる!!!×100」と思った際、1回目の記事のことを思い出したので、今回その続きを書いた次第です。

ちなみに

私事なのですが、5/28(金)を持ちまして、2年間就業した今までの契約先での業務が終了になりました。

思えばここと契約しなければ、クラウドAWS、そしてServerless Frameworkに出会うこともなければ、各種イベントで登壇するなんてこともなかったわけで、そういう意味では私のエンジニア人生の転機となった場所であることは間違いないと思います。

ここ半年間、いろいろ思うところやそううつ病の関係、そして自分の将来を考えたときに「ずっとコンフォートゾーンにとどまっていていいんだろうか...」などと色々葛藤する部分があり、いろいろ悩みんだり、迷惑をかけてしまった部分もありましたが、本当に素晴らしい環境&メンバーと過ごすことができた、本当に幸せな2年間でした。

で、今はニートなわけですが、まずはしっかり休んでリフレッシュしながら、次の案件(or正社員での就職先)を探そうと思います。

また、今までなかなかできなかったAWSの勉強(AWS資格試験とか)を始め、各種スキルアップ、そして健康・体調面をしっかり治そうと思います。

それでは、今回はこの辺で。