CULTURE
SaaSプロダクトのインフラアーキテクチャ
- プロダクト
SaaSプロダクトのインフラアーキテクチャ
こんにちは！
これまでなかった食後の睡魔に老いを感じているCTOの東川です。
2回に渡ってプロダクト開発の組織紹介をさせていただきました。
今回は弊社プロダクトのインフラアーキテクチャに関して簡単に紹介させていただきます。
細かい各論の部分は今後弊社メンバーが色々と記事を上げてくれると思います。
なお弊社ではAWS上に構築していますので、AWS利用を前提としています。
またソフトウェア的な話はスコープ外です。
ちなみに、先に言ってしまうと、サーバーレスアーキテクチャを採用しています。
アーキテクチャ検討
まず、弊社プロダクトは特性上、セキュアでかつ安定稼働することが最低条件と考えています。
また立ち上がったばかりのスタートアップということでメンバーの数も少ない上、インフラの専門家は不在（強いて挙げれば東川のみ）のためインフラの監視やスケールアップといった運用に関する工数は最小化する必要があると考えました。
そしてエンジニアリングの力で経営を支えるというのが私のポリシーですので、SaaSプロダクトのランニングコストは可能な限り小さくすることを目標としています。
以上のことから、プロダクトの根幹となるアーキテクチャを決めるにあたっては、下記の5点を達成することを目標に設計しました。
- 高セキュリティ
- 高スケーラビリティ
- 高可用性
- メンテナンスフリー
- 低インフラコスト
では、各目標をAWS上で達成するための施策をブレイクダウンしていきます。
高セキュリティ
サーバー管理をなくし、ミドルレイヤーの脆弱性による対応を限りなくゼロにしたい
- フロントを静的コンテンツで開発し、S3に配置してサーバーを持たないようにする
- バックエンドはAPI Gatway+Lambdaの構成にしてサーバーを持たないようにする
AWSセキュリティサービスを積極的に取り入れたセキュリティレベルを担保したい
- WAFやCloudFrontなどの保護サービスを利用してDDoSなどの攻撃から防御する
- CognitoやAuthorizerなどの認証機能を利用して侵入を防止する
データをしっかり保護した形で運用したい
- データベースを外部攻撃から保護するためプライベートサブネットに配置する
- データはすべて暗号化して保護する
高スケーラビリティ
AWSが持つ膨大なリソースを利用し、高い拡張性を持たせたい
- フロントを静的コンテンツで開発し、S3に配置してS3のスケーラビリティを利用する
- バックエンドはAPI Gatway+Lambdaの構成にして高いスケーラビリティを実現する
AWSマネージドサービスによるスケーラビリティ機能を活用したい
- データベースにはマネージドなものを採用してAWSが持つスケーラビリティの高さを利用する
高可用性
AWSの高い可用性の持つサービスを利用したい
- フロントを静的コンテンツで開発し、S3に配置して99.99%という高い可用性を活用する
単一AZで動作させず可用性を高めたい
- バックエンドはMulti AZで動作するLambdaを利用する
- データベースは単一AZで動作するものは利用せず可用性の高いものを活用する
メンテナンスフリー
インフラメンテナンスから解放されたい
- フロントを静的コンテンツで開発し、S3に配置してサーバーを持たないようにする
- バックエンドはAPI Gatway+Lambdaの構成にしてサーバーを持たないようにする
ミドルウェアの更新から解放されたい
- データベースにAWSマネージドなDBを採用する
- EC2は使わずにLambdaを利用する
低インフラコスト
低コストサービスを積極的に活用したい
- フロントを静的コンテンツで開発し、安価なS3に配置する
リリース初期時の低利用を考慮して従量課金サービスを活用して構築したい
- バックエンドはミリ秒単位の従量課金のLambdaを利用する
アーキテクチャ設計
検討結果を下記にまとめるとベースのアーキテクチャリソースはこんな感じになりました。
- フロントはS3を利用する
- バックエンドのコンピューティングソースはLambdaを利用する
- 結果API Gateway+ Lambda + DBの構成とする
- マネージドなDBを利用する
- マネージドDBとしてDynamoDBやAuroraが候補に挙がる
- メインDBにはデータの特性上RDBが利用したいのでAuroraを採用する
- 外部からの攻撃から保護する
- CloudFrontを利用する
- WAFを利用する
- 認証機構を利用する
- Cognitoをユーザープールとして利用する
- Lambda Authorizerでユーザー認証を強化する
- マルチAZにリソースを配置する
アーキテクチャ実践
設計に基づいて実践した結果を記載していきます。
アーキテクチャ概要図
フロントエンドとバックエンドに分けてアーキテクチャの概要図を記載します。
必要最低限のリソースのみ記載しているので様々な制約を回避するためにアレコレしている部分は省略しています。
フロントエンド
- S3に静的サイトを配置して、バックエンドAPIから必要な情報を取得して表示する
- いわゆるSSG(Static Site Generator)での実装
- CloudFrontやRoute53、ACMで一般的なWebサイトのインタフェースを実装する
フロントエンドアーキテクチャ概要
バックエンド
- ベースとしてAPI Gateway+ Lambda + Auroraの構成を取る
- CloudFrontやRoute53、ACMで一般的なWebサイトのインタフェースを実装する
- WAFを導入してSQLインジェクションなどの攻撃からデータベースを守る
- Lambda Authorizerでユーザー認証を強化する
バックエンドアーキテクチャ概要
やってみて
では、実際にこのアーキテクチャでサービス開発を進めて当初の目標が達成されたのかを各項目に沿って振り返っていきます。
高セキュリティ
セキュリティ事故は当然発生しておらず、大手企業様によるクラウドセキュリティチェックもすべて通過しています。
高スケーラビリティ
現時点でリソース増強は必要になっていません。
リソースの利用状況をCloudWatchで監視していますがまだまだ余力があるので評価は今後に！
高可用性
運用開始以降システムエラーによるサービス停止は発生していません。
メンテナンスフリー
運用開始以降ミドルウェアの更新でメンテナンスが入ったのはAuroraのエンジンバージョンアップのみとなります。
※Lambdaのサポート終了に伴い言語バージョンアップが必要になりますが、インフラではないのでスコープ外ということで…
低インフラコスト
具体的な金額は書けないのですが、だいぶ安く運用できていると思っています。
課題
当然やってみた中で感じた課題もありましたので書いていこうと思います。
世の中すべて良いことなんてないんです。
エンジニアには一定以上のレベルが求められる
これは一番に感じる課題でした。
立ち上がることのないまま去っていく業務委託エンジニアが何人もいました。
当然採用の際もアーキテクチャについてこられるかが重要でした。
（結果として強いエンジニア軍団が出来上がったのですが…）
制約が多い
サーバーレスアーキテクチャは色々と制約が多いです。
今は大分緩和されてますがVPCに紐づけた際のコールドスタート問題やデプロイの複雑さなどいくつも課題を解決しないといけなかったです。
ちなみにUniforceではAWS SAMとCDKで実現してます（Terraform使ってないところダサい？）
ローカル環境の構築もちょっと面倒です。
フレームワークが使いにくい
ソフトウェア的なところはスコープ外と言っておきながら最後にどうしても触れなきゃダメなことがありました。
どうしてもフレームワークが当て込みにくいです。RubyでいうRailsやPuythonでいうDjango、JavaのSpringといったものを友好的に使うのがとても難しいと思います。
5年ほど前に、JAWS FESTA 2019 SAPPOROで登壇させていただいたときはLambda Layerを使ってRuby on Railsで実装するという荒業を発表したことがありますが、果たして良アーキなのかどうか…ｗ
まとめ
サーバーレスアーキテクチャは制約が多かったりして考えることが多く、正直言って難しいと思います。サーバーにフレームワーク使ってチャチャっと実装しちゃった方が楽なのは間違いないです。
でもAWSリソースをパズルのように組み上げて構築しきった際の達成感はすごくありましたし、その結果として立てた大きな目標を達成することもでき、やってよかったと胸を張って言えます。
次回は東川以外のメンバーの記事を披露させていただこうと思います。
- Writer
Uniforce株式会社 取締役CTO
東川 寿充
