技術

AWSインフラ知見まとめ 2021.03

たまにはエンジニアの話題も。

フリーランスになってからは、案件の関わり方は、バックエンドを構築しつつ、ついでにインフラも少しやるという感じがほとんでした。でも、今とある案件に、インフラ専任というポジションで参画しています。そこで私のインフラに関する知見がupdateされたので、まとめたいと思います。

※AWS環境を前提としています。

Terraformまとめ

Terraformを採用する理由

インフラのコード管理(IaC)は、いくつか選択肢があります。AWSの公式にCloudFormationがありますが、個人的にはTerraformがいいのかなと思います。

一番の理由は、CloudFormationより簡単(コードが読みやすい)だからです。Terraformは、触る前まではHCLという独自言語なので、それはちょっとと思ってしまいがちなのですが、いざ触ってみると、CloudFormationのYAMLより全然シンプルで読みやすいです。

そして、Terraformの公式マニュアルが読みやすくサンプルも豊富にあるので、コピペしてちょっと編集するだけで済むことがほとんです。シェア的にも、Terraform一強の気がします。ググれば、やってみた系の記事がいろいろでてきます。

簡単な手作業も、可能な限りTerraformでやるべき

AWSコンソール上で数クリックで完了する簡単な作業も、可能な限りTerrafromでやるべきです。理由は以下。

  • 変更管理が楽(AWSコンソールの手作業でも、CloudTrailで追えるけど面倒くさい)
  • タグが他のリソースと統一しやすい(手作業だとタグを付け忘れることが多い)
  • Terraformだと再作成や複製が簡単なので、結局Terraformでやったほうが楽になることもある

サーバーレス環境は、serverless-frameworkに委任したほうがよい

ほぼ何でもできるTerraformですが、サーバレス関連に関しては、serverless-frameworkに任せるべきです。具体的には、Lambda, API Gateway, DynamoDBあたりは、Terraformでなくserverless-frameworkでやったほうがいいと思います。

この辺りは、開発者がいじるべき領域で、ほとんどの開発者はTerrafromは触ることはありません。serverless.ymlは開発のリポジトリに収納され、開発期間中は頻繁に更新されるので、インフラ担当から切り離すべきです。

Terraform開発環境

VSC(Visual Studio Code)か、Jetbrainsでやる方がほとんどだと思います。Terraformのコーディング程度なら大差ないので、どっちを使ってもいいと思います。私も、どっちも使っています。が、やっぱりJetbrainsのほうが参照やスペルチェックなどの面で秀逸だと思います。Terraformを長時間さわるときは、だいたいJetbrainsでやっています。

実行環境はローカルが楽

Terraformの実行は、厳密にやればCI/CDとかになるのでしょうが、設定面倒くさいですし、実行IAMやtfvarsどうするのとかいろいろ考えることもでてくるので、可能ならローカルからapplyコマンドを直接叩くのが楽です。tfstateをS3で管理するようにすれば、ローカル実行でもそんなに問題が生じることはないと思います。

ディレクトリ構成

ディレクトリ構成の最適解もアンチパターンもよくわからないのですが、以下のような構成にしています。

envs
|—dev
|—stg
modules
|—ec2
|—s3

envs/xxx/main.tf の moduleステートで、modules/xxx/main.tf の resource をコールしています。

modulesは各案件で共用にして、git submoduleで使い回しできるかもと思っていたのですが、結局modules配下も案件ごとにカスタマイズしたほうが使いやすく構築スピードもあがるので、各案件のリポジトリに、オリジナルで持っています。

公式のupdateを定期的にチェック

ほぼ何でもできる Terraform ではありますが、さすがにAWSの新しめのアップデートには対応していません。

Terraform公式にロードマップがありますので、いつぐらいに対応されるか予測できます。
https://github.com/hashicorp/terraform-provider-aws/blob/main/ROADMAP.md

ここを見て、当分対応されそうになかったら、諦めて手作業かCloudFormationなどの別方法とのハイブリッドを考えないといけません。

CodeCommitはさけるべき

コード管理に、GitHubでなく、CodeCommitを採用した案件がありました。コストや納品しやすさが主な理由です。最近、とある銀行のGitHubコード漏洩が問題になりましたが、それとは無関係です。(笑)

この案件で、はじめてCodeCommitを使ってみたのですが、地獄でした(笑)
GitHubって良くできたサービスだと改めて思いました。

GitHubは組織外の人をコラボレーターにするのは有料です。(価格体系がよく変わるので、わかりづらいですが・・・) 自社サービスなら外注は少なめと思うのでそれほどコストの問題はないのですが、SI案件だと複数社が関わりコラボレーターもどんどん増えていくので、GitHubはお高くなります。それでもコスト的に許されるなら、GitHubを採用するべきです。それほどまでに、CodeCommitは使いづらいです。

UIが使いずらい

CoddeCommitはUIがかなり残念です。IssueやReleaseがありませんし、Commit履歴を見るのにも、Commitページにいってからブランチ選択とクリック回数が多いです。

クロスアカウントだと地獄

クロスアカウントだと更に大変です。そして、本番は別アカウントにするというケースが大半だと思いますので、ほぼ全ての案件に当てはまることです。

いちいちスイッチロールしないといけない

AWSの環境を確認しながら、コードを見たいとなったとき、もしCodeCommitが別アカウントにあったらスイッチロールしないといけないです。つまり、AWSコンソールを見ながら、Gitのリモートリポジトリを見ることはできないんですね。これは地味につらいです。まあ、それより毎回、スイッチロールしないといけないストレスの方がやばいですが。。。

CI/CDの権限設定で地獄をみる

CodeCommitを使うと言うことは、CI/CDは、CodeBuild, CodePipelineを採用していることかと思います。クロスアカウント(CodeCommitがアカウントAにあって、CodePipelineがアカウントBにあるケース)だと、IAM設定で地獄を見ます。実行ロール、S3、KMSの権限設定が複雑に絡んできます。もう面倒くさいのでAWSサポートに丸投げしようと思っても、それはアカウントBに関することなので、アカウントBから問い合わせお願いしますとかの回答が来たりします。

slack通知はChatBotで!

昔はAWSからslackに通知するときは、Lambda関数を書いて、イベントをトリガーにするとかだったのですが、今は、AWS Chatbotでできるようになりました。細かい設定はできませんが、これで事足りることがほとんどです。

ChatbotはTerraformでは未対応なのですが、積極的に採用していきたいところです。

たいていのことはサーバレスでできる

一般的なREST APIはもちろん、たいていのことはサーバーレスでできるようになってきました。

参考 AWS公式 サーバーレスパターン
https://aws.amazon.com/jp/serverless/patterns/serverless-pattern/

RDB使いたいからとか、規模や処理時間的に厳しいとかで、すぐにFargate1つでどかっとやろうとする人が多いですが、構成次第でどうにかなるケースもかなりあります。

余談になりますが、今請け負っている案件のマネージャーは最初、シンプルなwebサービスの新規案件で、Fargateどころか、EC2にtomcatやnginxを構築しようとしていました。実装担当ではないといっても、酷いものでした。あなたは10年前からタイムスリップしてきたんですかとツッコミたくなります。説得に苦労しましたw。まあ、こういった問題に直面する一番の原因は、こういった案件を紹介される自分の技量の低さにあるんですが。。。

話が逸れましたが、可能な限り、サーバレスパターンは採用するべきです。

まとめ

以上、インフラ周りの知見updateでした。

今は、サーバレス+PythonでWebSocket APIを作る案件をメインでやっています。いつになるかわかりませんが、こちらも知見がまとまってきたらoutputしていきたいと思います。