現時点でWebエンジニアとしてできることを書き出してみた【AWS編】（2020年5月）

こんにちは。株式会社NoSchoolでCTOをしている名人です。

普段ベンチャー企業でほぼ自分1人で開発しているので、自分の技術を客観視する機会がありません。ということで、自分ができること、これからの課題をまとめる機会を作ってみました！

まずは自分が最も苦手としているAWSからまとめていきます。

概要

今の自分のAWSの知識の7割くらいは、NoSchoolに転職してから得たものです。

CloudFrontでリクエストを受け取り、S3またはALBにトラフィックを分割します。ALBのバックエンドにはNuxt.jsを扱うEC2とLaravelで構築したAPIサーバーとしてのEC2が構えており、APIリクエストはLaravel、ページのリクエストはNuxtにトラフィックを流しています。

デプロイはCodeDeployで自動化しています。

ミドルウェアとしてはRDSとElastiCacheを使っています。

ちょっとしたタスクやバッチ的な処理を実現するために、適宜SNSやLambdaを利用した実績もあります。

もちろん、すべての環境は開発環境と本番環境の2つ用意しています。本当はステージングも欲しいですが、節約もしたいのでこの2つです。

それでは詳細にまとめていきます。

---

CloudFront/WAF/S3

できること
・​ドメインを紐付けることができる
・トラフィックを適宜ALBやS3に流すことができる
・S3に画像を上げて、画像はS3から配信、それ以外はアプリケーションサーバーから配信というようにできる
・WAFを紐付けて、開発環境にIP制限や、本番環境の特定のパスにAPI KEYでのアクセス制限を簡単に掛けることができる

できないこと
・画像以外にもCSSやJSなどをCDNから高速で配信すること（今はNuxtやLaravelのアプリケーションサーバーから返している）
・Lambda@EdgeでCloudFrontをカスタマイズ（する要件にいまだ出会っていないと自覚している）
・S3の運用に不安がある。バケットを用途に応じて適当に作っていっているので、長期的に見て運用が心配。ドキュメントにまとめるしか無いのか？

ALB/CodeDeploy

できること
・ターゲットグループを作成して、EC2サーバーを所属させて、パスベースでルーティングができる。特定のトラフィックはLaravelに、それ以外はNuxtにといった分割ができる
・ALBでトラフィックを調整しながらCodeDeployでデプロイを自動で実行できる。GitHubと連携してmaster merge時にデプロイスクリプトをEC2に対して実行してリリースできる

できないこと
・たまにNuxtへのnpm run buildが重くてデプロイが失敗する。再デプロイしているが、他に方法は無いのか
・CodeDeployのデプロイスクリプトが秘伝のタレになりつつある

EC2

できること
・NuxtまたはLaravelで構成したアプリケーションを配置して動作させることができる
・サーバー内にはNginxを入れて、XX番ポートにALBからアクセスが来たら3000番にプロキシする、といった設定ができる
・Nginxやphp-fpmの設定を変えて、最大アップロードファイルサイズ上限を上げることができる
・セキュリティグループの設定により、限られた環境からSSHできるように構築できる
・RDSやElastiCache等のSGを調整してインスタンスからのみアクセス可能にできる
・CloudWatchエージェントをサーバー内で動作させ、Webサーバーのログを流すことができる
・サーバーの設定を変更したらAMIで管理する
・ある程度以上のアクセスがあったらオートスケールで台数が増える

できないこと
・Dockerベースで、ECS/EKS/Fargateなどで運用すること。AMI運用のデメリットを考えたら、Dockerベースで扱って設定ファイル系をすべてGit管理しつつローカルでも再現できると嬉しい

RDS/ElastiCache

できること
・インスタンスを立ち上げて、Laravelアプリケーションサーバーから普通に利用できる
・RDSはリードレプリカを配置し、エンジニアがなにか事情があって本番データを見たいときは原則そちらを見る

できないこと
・ElastiCacheのスペックを最低にしていたら、不定期にメモリが一杯になって落ちることがあり、スペックを上げたのだが、原因が何だったのかわかっていない
・RDSよりもAuroraのほうが、少し値段は高いけどオートスケールなどあるようで良さそう。使ったこと無いので試してみたい
・CloudWatchで見ている感じ、現状のスペックで問題なく動いているのだが、どれくらいのトラフィックで詰むのかの見立ては無い（CPU利用率だけでサーバーが動くとも言い切れないはず。書き込み読み込みIOPSのほうが重要？）

Lambda/SNS/ChatBot

できること
・Lambdaでは、AWS SDKをNode.jsまたはRubyから利用して、タスクを実行できる
・具体的には、EC2サーバーへのコマンド実行、CloudFrontへのIP許可、一部EC2のSG変更ができる。おそらく他のAWSサービスへの実行もLambda経由で同様に実装できるので、タスクの幅が広がったと思う
・アプリケーションサーバーからエラーがありCloudWatchに記録されると、LambdaからSlackにエラー内容が通知される（個人情報はLambdaの責務でマスキングする）
・CodeDeployでデプロイが成功すると、SNSを経由してLambdaで受け取って、Slackにデプロイ成功/失敗通知を流すことができる。このあたりは、度のサービスを使えば何ができそう、という見立ては立つようになってきた
・最近ではChatBotを使って、Slackから特定のコマンドを実行するとLambdaが実行できるようになった

できないこと
・簡単なタスクの範疇を超えたLambdaの利用はまだしていない。OGP画像生成とか、Nuxtを動かすとか
・Lambdaのソースはコンソールで直接いじっているため、GitHub管理かつ、GitHub Actionsでの自動デプロイをやってみたい
・アプリケーションの実装の都合上、キューを駆使できると便利なように思うから、SQSを使いこなしてみたい
・iOSアプリへの通知は、現状アプリケーションサーバーから同期的に実行しているが、S3→Lambda（Step Functions）→SNSとかでサーバレスに構築できる余地もあるはず

その他

できること
・IAMをユーザーまたはAWSサービスのある程度制限した権限で作成、割当ができる
・Route53でドメインを作成できる
・HTTPS証明書を作成、管理できる
・SESでメール配信できる
・iOSアプリ関係で、/.well-known/hogehogeといったパスにDinamic Links用のファイルを置きなさい、といった要望が来たときにALBやCloudFront、S3を駆使してローコストでネットワーキングできる

できないこと
・CloudFormationを使ってインフラをコードで管理する
・ElasticSearch等で検索に特化したユースケースを実現する

---

総括

改めて振り返ってみると、Lambdaでできることが増えたなと思いました。エラー通知やデプロイ通知をSlackとLambdaの連携によって実現するなどです。

慣れるとAWS SDKも使いこなせるようになってきたので、Lambdaでちょっとしたタスクを実現して生産性やエラー時の対応力を上げることはこれからもできそうです。

一方で、会社で使うインフラが固定されてくると、知っているサービスと知っていないサービスの差が広がってきていると感じました。全体的にAWSの今後の学習方針は、知らなかったサービスをまずは使ってみるのが良さそうです。