こんにちは、SREの菅原です。

あっという間に2020年も年末ですね。時が過ぎるのが早い...

今回は今年の振り返りも兼ねて、2020年でSREチームが行ったインフラのリニューアルについて記事にしたいと思います。

以前スタディプラスを支えるインフラ技術(2019年)を投稿したのですが、2020年版という形でインフラ技術を紹介します。

なぜインフラのリニューアルをしているかという理由については、「Kubernetesを本番導入しました」という記事で「スタディプラスのインフラの現状の課題」を説明しているので、気になる方は読んでみてください。

tech.studyplus.co.jp

はじめに
システム構成
- 利用中の主なAWSリソース
構成管理
CI/CD
監視・検知
現在の課題
最後に

はじめに

弊社には大きく分けて以下3つのサービスがあります。

学習管理SNS「Studyplus」
教育機関向け学習管理サービス「Studyplus for School」
参考書読み放題アプリ「ポルト」

今回も2019年度の記事に引き続き「Studyplus」のインフラを紹介します。

システム構成

Studyplusは一番大きなメインシステムと複数のサブシステムによって構成されています。

2020年のリニューアルでは、EKSを新規導入しました🎉

現時点では開発環境と本番環境、ステージング環境(本番DBに接続しており、主にリリース前にアプリケーションの最終チェックをするQA環境)の3種類のKubernetesクラスタがあり、マルチテナント構成でいくつかのサブシステムを移行した状態です。

多少簡略化した図になりますが以下のようなシステム構成となっております。

f:id:ksugahara08:20201218183226p:plain — サーバー構成の概要図

将来的にはメインシステムを含む複数のシステムをEKSに移行する予定です。

利用中の主なAWSリソース

弊社で利用しているAWSリソースは以下になります。2019年と比べるとEKS等コンテナ関連リソースを使うようになりました。 ※簡略名称で記載しております。

EKS
ECR
EC2(ALB、Auto Scaling等含む)
Lambda
VPC
RDS for MySQL
Aurora MySQL
ElastiCache(Redis)
S3
CloudSearch
SQS
SES
Glue
Athena
CloudFront
IAM
KMS
ACM
Route53

構成管理

2019年ではAnsibleを使ってAWSリソースの構成管理を行っていました。

しかし、以下のような点からAnsibleではなくTerraformを使って構成管理するように変更しました。

AnsibleのAWSモジュールはあまりメンテナンスされていない
AnsibleはTerraformと違い、現在の構成との差分が取れないため実行時に何が変更されるかわかりづらい(チェックモードが有効でないモジュールが多く存在する)
AWSモジュールを使っている人が少ないため情報が少ない

現在はTerraformの導入を進め、EKSに移行したシステムからTerraformで構成管理するようにしています。TerraformであればAWSの新機能にもすぐに対応が入り、情報も多いためTerraformに移行して良かったと考えています。

Kubernetesのバージョンアップ時にもTerraformで簡単に切り替えられるようにしています。 EKSクラスタ自体を新規作成して、新旧バージョンのクラスタ2つを平行運用後切り替えるのですが、多少のパラメータ変更で済むので本当に助かっています。

www.terraform.io

CI/CD

以前はCircleCIでCIを行い、JenkinsでBuildやDeployを行っていました。インフラのCI/CDはPacker + Ansibleで実施しており、温もりあふれる手動実行でEC2を起動したりする場面もありました。

2020年ではKubernetes化に合わせてシステムのソースコードのCI/CDをCircleCI + Skaffoldで行うように変更をしました。パイプラインの概要図は以下のようになっています。

f:id:ksugahara08:20210104130059p:plain — デプロイのイメージ図

今回は使い慣れたCircleCIを選択しましたが、今後はGitOpsにしたいのでArgo CD等のツールを採用することも検討しています。

インフラのソースコードのCI/CDはTerraform + Kubernetesに移行したことで、変更点を確認した上でapplyできるようになりました。しかし、terraform applyに関して手動実行なので、今後はGitHub ActionsやTerraform Cloudを使って自動化していきたいと考えています。

監視・検知

メトリクス監視

Kubernetes移行を機にDatadogへ監視機能を移行しています。理由としてはDatadogは高機能で、AutoDiscoveryに対応しているためKubernetesの監視にフィットすると判断したためです。

Prometheus + GrafanaやElastic Cloudも当時検討しましたが、少人数のSREチームで運用していくコストであったり料金面を比較した結果Datadogを選択しました。

アプリケーションのエラー検知

Sentryを利用しています。エラーはSlackに通知され、タスク管理ツールのmonday.comに自動登録されるように設定してあります。

ログ収集

ログはFluentdを使ってS3に保存、Athenaで確認する方法を取っています。以前はElasticsearch + Kibanaを使っていたのですが、検索の柔軟性や運用コスト、料金的にメリットを得難かったため廃止しました。

OnCall

DatadogにTwilioを設定して、担当者に連絡が飛ぶようになっています。

現在の課題

EKSの運用も始まったのですが、SREチームではまだまだやりたいことがたくさんあります。箇条書きですが簡単に紹介したいと思います。

システム構成

現在既存のシステムをKubernetesへ順次移行しています。今後はメインシステムだけでなく他のサブシステムやStudyplus for Schoolの移行など横展開させていきたいと考えています。

それだけでなく以下も検討していきたいと考えています。

スポットインスタンスの活用
サービスメッシュの導入
Progressive Deliveryの導入

etc

また開発環境と本番環境が同じAWSアカウント内に混在してしまっているため、間違って本番リソースを変更/削除してしまうリスクがあります。それだけでなく権限の複雑化、Terraform構成管理の複雑化を招いてしまっています。今後はAWSアカウントの分割を進めて、複雑性の解消を行っていきたいと考えてます。