Studyplus Engineering Blog

スタディプラスの開発者が発信するブログ

スタディプラスを支えるインフラ技術(2020年)

AWS EKS Kubernetes Terraform インフラ Datadog CircleCI SRE

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

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

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

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

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

tech.studyplus.co.jp

はじめに

弊社には大きく分けて以下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アカウントの分割を進めて、複雑性の解消を行っていきたいと考えてます。

構成管理

Terraformでの構成管理を進めて来ましたが今後は以下に取り組みたいです。

  • Terraformへ移行できていないシステムへの横展開
  • GitHub ActionsやTerraform CloudによるCI/CDの検討
  • TFLint,​checkov,tfsec等の導入検討
  • GCPリソースのTerraform管理
  • SREチーム以外のメンバーにもTerraformで構成変更を行ってもらえるように社内勉強会を開催

CI/CD

今回CircleCIを選択した理由が

  • ファーストリリースはできるだけミニマムの構成にしたかった
  • チームの学習コストの関係で現在使っているCIツールにした

というものなので今後はGitOpsができるArgo CD等のツールを検討・導入していきたいと考えています。また、開発環境をGitのbranchごとに作成したいという要望もあるため、実現にむけて検討していく予定です

監視・検知

Datadogへの移行を行っていますが、今後は以下に取り組みたいです。

  • Datadogへ移行できていないシステムへの横展開
  • APMによるパフォーマンス監視の設定
  • SLOの社内導入とDatadogのモニタリング設定
  • Deployした日時をDatadog上からわかるようにする

最後に

2020年はKubernetesやTerraform、Datadogなど新しいツールの導入を行い、インフラ技術の刷新を行ってきました。社内に知見が無い状態からのスタートでしたが、チーム内で話し合いながら進められたことは個人的にも大きな学びがあった１年間になりました。

2021年も2020年同様にStudyplusユーザーが期待するサービスの信頼性向上や価値提供のスピードを上げるためのインフラ技術をBlogで紹介できるようにしたいです。