string(4) "blog"

CONTENTS

2019.10.30

DevOps(Infrastructure)

written by 山本 竜二
devops

こんにちは、エンジニアの山本です。

今回はFixelにおけるDevOpsの中からインフラについて話します。

インフラ

Fixelは全員がリモートワークという事もあり、オンプレ環境のサーバは用意していません。

現在は、ほぼAWS一択でインフラを構成しています。
今後、Azureとかも触ってみたいなと思いつつ、なかなか時間を取れないのが現状です(言い訳)

AWS上でWebアプリのインフラを構築する際のパターンをいくつか見ていきたいと思います。

  • EC2 + RDS
  • ECS(Fargate) + RDS
  • API Gateway + Lambda + DynamoDB

EC2 + RDS

従来のオンプレ環境に似た構成です。

コストを掛けずにオンプレから移行する時に便利な反面、せっかくAWSに移すなら、クラウドネイティブな作りにしたいとジレンマと戦う事が多いです。

オートスケーリングと組み合わせれば、負荷に合わせた柔軟なスケーリングが可能です。
ただし、前提として、アプリの構成がステートレスである事が求められます。

具体的にいうと、ローカルストレージ(EBS)にデータを保持していたり、セッション情報をEC2内で持っている場合は、オートスケーリングが使えません。

インフラとしては設定さえすれば負荷に応じてオートスケーリング(スケールアウト)はしてくれますが、EC2間でデータを共有できない(※1)ので、データの整合性が取れなくなってしまいます。

※1 EFS(ElasticFileSystem)を使用すればEC2間のデータ共有が可能です。ただし、後述するFargateでは使用できません。

ECS(Fargate) + RDS

EC2の部分をコンテナに置き換えた構成です。
スケーリングを勝手にやってくれるので、一度乗せてしまえば運用が非常に楽です。

コンテナを使った経験が無い場合、まずはそこからの技術習得が必要になるので、最初は大変かもしれません。

コンテナのホストとなるEC2が必要な従来のECSと、ホストを必要としないFargateがあります。

料金や起動の速さなど違いがありますが、これから試してみるならFargateで良いと思います。

API Gateway + Lambda + DynamoDB

API Gateway + Lambda で従来のEC2やFargateの役割をします。

Lambdaは実行するサーバが不要で、JavaやNode.jsのコードをアップするだけで実行できる凄いやつです。数年前、始めて存在を知った時は震えました。

完全なサーバレス環境になるので、スケーリングを含めてインフラの管理はAWSが勝手にやってくれます。

サーバレスいいね!と飛びつきたくなりますが、いくつか注意点もあります。

LambdaとRDS (RDB) は相性が悪い

Lambdaは比較的短時間の処理をステートレスで処理する用途に向いています。

DBのコネクションを維持する事ができないので、例えば1000アクセスが同時にくると、Lambdaも1000個動き、DBコネクションも1000個張られる事になります。

アクセス数が増えるとDBコネクションが枯渇する可能性があるので、Lambdaから基幹系のRDSに無闇に繋ぐのは非常に危険です。

対応として、DynamoDBのようなDBコネクションが必要の無いDBに移行する事が考えられますが、NoSQLになる為、アプリの設計・実装から見直す必要があります。

すべてをRDBからDynamoDBに移すのは難しい場合が多いので、一部の機能だけDynamoDBに移行する、もしくは段階的に移行しても良いですね。

Lambdaの制限

1回の実行時間が最大15分まで、呼び出しペイロード(リクエスト、レスポンス)が6MB(同期)、256KB(非同期)といった、Lambda自体の制限があります。

15分を超える長時間の処理が必要な場合、Lambda → SQS → Fargate のように、Lambdaは受付だけをして、メインの処理はFargateやAWS Batchで行う必要があります。

Webアプリで15分を超える処理って滅多に無いかもしれませんが、考慮はしておいた方が良いですね。

ペイロードの制限は、WebAPIでそこそこ大きいファイル(動画など)をアップする時に引っかかります。Lambda→S3とアップしたいのであれば、LambdaはS3の保存先パス(署名付きURL)を返し、クライアントからS3に直接保存させる等の対応が必要になります。

まとめ

比較的メジャーな構成を紹介しましたが、他のサービスを使ったり、上記を組み合わせるだけでも色々とでてきそうですね。

フロントエンドとバックエンドが分かれているのであれば、CloudFront+3でフロントエンドを構築し、バックエンドを先に述べた方法で構築するのも有りだと思います。

AWSは顧客の要望から新しいサービスを次々に生み出してくれるので、新しいサービスの組み合わせを考えるだけでも楽しいです。

しかも、大抵の事は管理コンソールでポチポチやるだけで試せますからね。

一覧に戻る
お問合わせ