Studyplus Engineering Blog

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

スタディプラス SREチームの2019年の取り組みまとめ

SREチームの栗山(id:shepherdMaster)と菅原(id:ksugahara08)です。

年末ということもあり、弊社SREチームが2019年に行ってきた取り組みの中で大きめのトピックを紹介したいと思います。
本来ならもっともっと書きたいことがあるのですが、今回はスタディプラスのSREチームが何をやってきたのか概要がわかるように書いていきたいと思いますのでぜひ最後まで読んで頂けるとありがたいです。

SREチーム発足

2019年はSREチームの発足をしたというのが大きなトピックでした。発足にはインフラを担当していた1名とサーバーサイドから1名が参画し、2名で発足しました。
元々SRE経験者を社外から採用してから発足を考えていたのですが、SREは転職市場でも希少で採用が難航していため、それなら自分たちでSREを始めてしまおう!とSREチームを作ることを決めました。

SREという職種の共有会

www.oreilly.co.jp

発足当初、SREという職種について経験者もいなければ、SREという職責について理解が足りていなかったためとにかく他社事例を見ることからはじめました。
その際に活用したのがYouTubeに上がっているSRE関連の動画でした。動画視聴会は開催しやすく学びも多いということで弊社では割と頻繁に行っております。

次に、オライリー・ジャパンから出版されているSRE サイトリライアビリティエンジニアリング――Googleの信頼性を支えるエンジニアリングチームをSREメンバーそれぞれが読み、30分程度のプレゼン形式で社内のエンジニアにSREという職種はどんなものかを共有する『SRE共有会』を開催しました。

輪読会という形式も選択肢にはあったのですが、

  • SREメンバーが2人で経験者もいないということ
  • スピード重視
  • SREではない周りのエンジニアにも理解してもらいたいという想いがあった

という理由でサクッと概要を掴める共有会形式を取りました。
結果としてSREという職種について理解と協力をしてもらえるようになったと思います。今後も何らかの形で社内への理解を深める活動をしていきたいと考えています。

ポストモーテム導入

前述のSRE本に載っているポストモーテムを弊社でも導入しました。
弊社では以前から障害報告書を書く習慣はあったのですが、障害対応した人がその障害を見るような形でチーム全員で振り返るという事はしていませんでした。
障害報告書をポストモーテムに変えるにあたって内容の変更や振り返りを全員で議論する場を設けるようにしました。
ポストモーテムを導入した結果、弊社では以下のようなメリットがあったと思われます。

  • 時系列で何が起きていたかわかりやすくなった
  • チーム全員で障害を振り返るようになった
  • 障害後、取るべきアクションをきちんとみんなで話し合うようになった
  • 「障害から学ぶ」という意識が広がった

ポストモーテムを導入後の2019年8月23日にはAWSの大きな障害が起きましたが、ポストモーテムで記録に残し、コミュニケーションを取りながら障害対応ができました。導入してすぐにメリットを痛感できたのも機運が高まった要因かもしれません。
今後もポストモーテムを続けていくということだけではなく、振り返ることで障害に強いサービスに変更していきたいと考えています。

脱AWS Elastic BeanstalkとKubernetes移行

弊社ではメインのマイクロサービスはAWS Elastic Beanstalk上で、その他のマイクロサービスはEC2上で動いています。
Elastic Beanstalkはメリットもたくさんあります。しかし、デプロイが遅かったりElastic Beanstalk自体の仕組みが独特で学習コストがかかったりで、他のなにかに移行したいという話が上がっていました。
またEC2のほうは歴史的経緯からEC2インスタンスを増やすためには手動作業(EC2インスタンスを立ち上げてからAnsibleを実行するという作業)が必要という課題がありました。
その他の要望として

  • カナリーリリースを楽にしたい
  • 簡単に言語やライブラリのバージョンアップをするためにコンテナを導入したい
  • インフラ作業コストを下げたい
  • 耐障害性を高めたい

というものがありました。
それらの課題、要望を解消するためにKubernetesに移行することを決めました。現在はまず一部のマイクロサービスのKubernetesへの移行を取り組んでいます。

Terraform移行

www.terraform.io

弊社では前任者がAWSサービスをAnsibleで管理している状況でした。
AWSリソースからEC2の設定まで全てAnsibleで管理するのは、いくつもIaCツールを使うより学習コストを抑えられるという点でメリットがあります。しかし一方でAWSの新規サービスや最新バージョンに追従できないことが多々ありました。
その際は自分たちでPythonのAnsibleモジュールを自作していたのですが、サービス数が増えるに連れ運用コストが比例して増えるようになってきました。
そこで弊社ではAWSリソースの管理をTerraformへ移行することを決めました。
Terraformを選択した理由としては以下があげられます。

  • AWSの新規サービスや最新バージョンに比較的早く追従される
  • 宣言的に記述することができるため直感的にわかりやすい
  • 利用できるProvidersが豊富なこと

もちろんデメリットとしてAWS CloudFormationに比べて新規サービスや最新バージョンに対応するラグありますが、今のところ対応は早く不便に感じていません。
またTerraform学習コストもありますが、新規ツールに対してキャッチアップする姿勢が強いメンバーが揃っていたため問題になっていません。
社内でTerraform共有会を定期開催するなどお互いの知識を教え合う場ができている状態です。
現在はAmazon EKS周りのリソースをTerraformでコード化していますが、これからは現状のリソースもコード化したり、CI/CDの自動化をしていく予定です。

ログ収集基盤改善

ログ収集基盤をAmazon CloudWatch LogsからAmazon S3 + Amazon Athenaに変更しました。
CloudWatch Logsには以下の課題がありました。

  • 料金が高い
  • ログ保存期間が短い
  • UIが使いづらい

それを解決するためにログをS3に保存しAthenaで検索できるように基盤作りをしました。
最初は、Amazon Kinesis Data Firehoseを使ってFirehose自身の変換機能でParquet形式でS3に保存していたのですがFirehoseは料金が高くて諦めました。
JSON形式で保存してAthenaで検索してもそれほど検索速度に影響がなかったので、現在はFluentdから直接ログをS3にJSON形式で保存しています。

Rubyバージョンアップ

弊社では早くからマイクロサービスを採用しており、Rubyを使っているサービスは全部で9サービスあります。その中で2020年3月31日にEOLを迎えるRuby2.4を使っている5つのサービスを2.6にバージョンアップしました。
またついでに使っているGem(Rails含む)のバージョンアップも行いました。

作業自体はどのサービスも概ねスムーズにいったのですが、一部のサービスでPumaのGemのバージョンアップを行ったらゾンビプロセスが発生するバグを踏み抜いてしまい焦りました。

speakerdeck.com

最初は原因が分からなかったのでひとまずGemのバージョンアップをrevertし調査しました。
Pumaの直近のリリースノートに「ゾンビプロセスが発生するバグを修正した」というのがあったのでPumaのGemを最新にしてリリースしたところゾンビプロセスが発生することはなくなりました。

バージョンアップ作業はなかなか大変ですが、非常に重要なので定期的かつ計画的に行っていきます 。
今後コンテナ化を進めていったら新しいバージョンのRubyを入れた新しいサーバーを用意する必要もなくなるのでバージョンアップ作業が楽になるのではないかと期待しています。

jemallocの導入

詳しくは Rubyアプリケーションのメモリ使用量上昇問題をjemallocを使うことで解決しました をご参照下さい。

tech.studyplus.co.jp

勉強会開催

SREチームでは知識、知見をインプット/アウトプットすることを重視しており、定期的に勉強会を開催しています。2019年に行った勉強会を紹介します。

Kubernetesハンズオン

GCPを使ってKubernetes上にアプリケーションを動かしながら、Kubernetesの各機能の説明をするハンズオンを開催しています。Kubernetesを浸透させたいのでエンジニアが新しく入ってくるタイミングでハンズオンを実施しています。

Kubernetetsの各機能の勉強会

Kubernetes完全ガイド本をもとにKubernetesの各機能について紹介する勉強会を7回に分けて開催しました。

コンテナ監視ツール勉強会

Kubernetesを本番サービスで運用していくにはObservabilityを上げていく必要があり、CNCFのTrail Mapにも4番目に載っています。弊社でもKubernetesでの監視をどのようにしていくべきか検討する必要があり、主要な監視ツール9つを比較し、勉強会を行いました。

検討の結果、今後はDatadog等のService Discoveryに対応したツールを利用してKubernetesの監視を設定していきたいと考えています。

サービスメッシュ勉強会

サービスメッシュのIstioの勉強会も開催しました。 その時の資料はこちらです。

qiita.com

CI/CD勉強会

Kubernetesへのデプロイツールとしてどのようなものが最適なのかを知るためにいくつかCI/CDを各自調べ、勉強会を開きました。
以下が調べたツール、サービスになります。

AWS Black Belt動画視聴会

AWSには多くのサービス多くの機能があるため、「自分たちが使っているサービスをより知るため」「使ってないサービスの概要を知るため」という理由でYouTubeに上がっているAWS Black Beltの動画をみんなで視聴する会を定期的に開催しています。(スタディストさんでやっている活動を参考にさせてもらいました)
動画を見ながら「この機能は使えそう」「機会があれば使ってみたい」とみんなでわいわい話しながら見ています。
今年観た動画は Aurora、Athena、Amazon Personalize、Key Management Service、CloudFront、Lake Formation、AI Services、Config です。

監視周りの設定見直し

弊社では主にMackerelを使ってサーバーメトリクスを取得し、Slackにアラートを出したり、Twilioで電話通知を行ったりしていました。
しかしDBが高負荷による障害時に監視やログ取得が足りていないと痛感することがありました。そのため以下のような設定を行い、監視周りの設定見直しを行いました。

  • Amazon Auroraのパフォーマンスインサイト導入
  • Amazon RDS、Auroraのスロークエリを出すようにする
  • 各サービスの死活監視強化

改善はしたものの、まだ現状でも課題があります。CPUやメモリー等のResource Metricsは監視できているものの、スループット等のパフォーマンス周りのWork Metrics、そして設定変更の監視周りであるEventsが弱いと感じています。
今後は Datadog社のMonitoring Modern Infrastructureを参考に監視の改善を行っていきたいと考えています。

深夜メンテナンス手順書の整備

今年何回か深夜メンテナンスを行ったのですが、私たちSREチームが初めて深夜メンテナンスの準備をするときにメンテナンス手順書が存在しないことに気が付きました(あったのは前任者が残した簡単なメモ書き)。
これはメンテナンス手順書を作る機会だと思い、メンテナンスモードにするための必要な手順を1つ1つ社内Wikiに書き起こしました。それ以降の深夜メンテナンスでは毎回メンテナンス手順書を作っています。
事故なく深夜メンテナンスを行うには手順書は非常に重要で、その手順書のレビューやリハーサルもしっかり行っています。

最後に

インフラチームからSREチームに変わりメンバーも増え、様々な改善ができた一年でした。

2020年も弊社サービスのユーザーの皆様により良い価値を提供するためサービス基盤、開発環境、パフォーマンス等の改善など行っていきたいと考えてます。SREチームとして弊社サービスをより愛して頂けるように全力を尽くしていきたいと思います。