174
1
0

Carelyのインフラストラクチャについて

Published at October 28, 2019 5:10 p.m.
Edited at October 28, 2019 6:59 p.m.

AWS

CarelyのインフラストラクチャはほとんどAWS上に乗っています。
現状(2019/10/28時点)ではGCP/Azure等の他のIaaS/PaaSは利用していません。

AWS上では多岐にわたったリソースを利用しています。
EC2を中心に、

  • EKS
  • Lambda
  • Elastic BeansTalk
  • S3
  • EFS
  • RDS
  • ElastiCache
  • VPC
  • CloudFront
  • Route53
  • API Gateway
  • CodeCommit(基本githubですが、一部利用している)
  • CloudWatch
  • CloudFormation
  • Athena
  • Inspector
  • WAF & Shild
  • Simple Notification Service
    等等。

弊社では、AWSのリソース管理は
Terraform
で行っています。

Terraform

本番環境だけでなく、ステージング環境から検証環境までをTerraformで管理することで、
Infrastructure as Code
を実現しています。

VPCといったネットワーク設定から、EC2, RDS, ElastiCache, Route53, CloudFrontまでWebサービスに必要なリソースは、Terraformで管理されています。

Ansible

ミドルウェアの管理については、
Ansible
を使っています。

WebサーバーやRailsで必要になるミドルウェア等はAnsibleで設定しています。

なお、Webサーバーは
Nginx
で、そこから
Puma
を呼び出される構成になっています。

コンテナ化に向けての動き

現状は上記の通り、Terraform, Ansibleの管理のためコンテナ化されておりませんが、開発環境はDockerを利用しており、本番環境、ステージング環境も今後コンテナ管理することを視野に入れております。

Kubernetes

その前準備として、
Carelyのサービス紹介ページ
は、既に
Kubernetes
で管理されています。

監視、ログ管理

Datadog

弊社ではサーバーの監視、アプリケーションのパフォーマンス監視(APM)、ログ管理を
Datadog
で行っています。
Datadogにしきい値を設定し、インフラ及びアプリケーション・サーバーのレスポンスに以上が発生した場合、アラートを上げSlackに通知し、エンジニアが異常を即座に受け取ることができる環境を作っています。

twillio

クリティカルな状況が発生した場合は、
twillio
を経由してエンジニアに架電されるようにしており、休日、夜間にサービスが停止したりしたのにも関わらずエンジニアが気づかなかった、というようなことが起こらないようにしています。

Sentry

アプリケーションエラーに関しては
Sentry
を利用しています。

上記のように、サーバーの負荷状況、アプリケーションのパフォーマンス状況、アプリケーションエラーをしっかり監視し、トラブル発生時に迅速に対応できる態勢を整えています。