「家族アルバム みてね」のSREチームの紹介と取り組み
こんにちは、みてね事業部 開発グループ SREチームの清水 @isaoshimizu です。
この記事では、「家族アルバム みてね（以下みてね）」を支えるSREチームはどんなチームで、普段どんなことをやっているのかを紹介していきたいと思います。チームの行動は頻繁にアップデートされていくので、定期的にブログ記事にできたらと思っています。
みてねのSREチームはこんなチーム
まずは、みてねのSREチームの紹介と毎日の仕事の流れについて紹介したいと思います。
ちなみに、SREチームは2018年2月1日に作られました。この時のチームメンバーは3名でした。
ここから徐々にメンバーが増え、2021年6月時点でのSREチームメンバーは5名となっています。
SREチームが作られてから3年以上経過し、当初からスクラムというスタイルで変わらず運用していますが、1週間におけるスクラムイベントの時間の使い方は何度も変えてきました。一時的にSREチームを分割して、それぞれのミッションを進めるといったやり方をしたこともありました。
SREチームの1週間の過ごし方
SREチームの1週間はこんな感じです（作画: Atsushi Sakai）。
この絵にあるそれぞれのスクラムイベントについて軽く紹介したいと思います。
バックロググルーミング（1時間 毎週 月曜日）
まずSREチームメンバー全員で、この1週間に健全性を阻害するものがなかったかどうかの確認をおこないます。具体的には、他の開発者やチームが問題なく業務にあたれていたのか、障害に対して適切な対応ができていたのか、セキュリティの懸念に対応できていたのかについて話し合います。その後に、仕事を進めていて困ったことや相談事項などをチーム内で話し合います。必要に応じてストーリーを追加することもあります。
POレビュー（30分 隔週 火曜日）
隔週でSREチームの成果をプロダクトオーナーである笠原さんにレビューしていただく場を設けています。コストレビューや優先事項の相談、インフラのメンテナンスの相談などもここでやります。
バックログリファインメント（1時間 毎週 水曜日）
今後新たにやるべきことを各自Iceboxに追加し、ストーリーのポイントをつけます（プラニングポーカー）。ストーリーを説明する際にはHowについては深く議論をしすぎないように気をつけています。最後に、ポイントが付けられたストーリの優先度を決めて終わります。
スクラムセレモニー（1.5時間 毎週 木曜日）
図にある通り今までは2時間でやっていましたが、いろいろと効率化して現在は1.5時間に短縮できました。
スクラムセレモニーでは以下の順番でファシリテーターが進めていきます。
- スプリントの成果を各自発表＆スプリントレビュー。未完了のものには基本的に触れません。
- 1週間におけるKPT。各自KPTを10分以内で書き出して、みんなで10分議論します。
- 次スプリントの計画。リファインメントで優先度付けされたストーリーを再度確認します。
- セキュリティチェック。Dependabotを利用してレポジトリの脆弱性が放置されていないかチェックし、あれば担当者を割り当てます。
- チェックインミーティング。今後4週間の予定（例えばキャンペーンイベントなど）を確認します。例えばサーバーの負荷が高まるようなイベントがある場合にはそれに備えるためのバックログを追加します。
- 目標への進捗や自信度を共有。各自の進捗具合や達成度をチーム内で共有し合います。
- 直近のポストモーテムの確認。事業部内で記載されたポストモーテムをチェックし、状況の確認や再発防止策が適しているのかどうかを議論します。
これらを一通り進めた後は、次回のスプリントのファシリテーターを決めて終わります。
（番外編）全体朝会（10〜15分 毎日）
毎日午前11時からみてね事業部全体で朝会をやっています。参加人数は40〜50名くらい。PO笠原さんから各種KPIや事業方針などの共有があり、その後各チームから10〜20秒ずつくらい今やっていることなどを共有していきます。これによって事業部全体や他のチームが毎日どんなことをやっているかをざっくりと把握することができます。
この辺りは、2020年11月26日にYouTubeでも紹介しているのでお時間がある時にぜひご覧ください。
ここからはSREチームの技術的な取り組みについて紹介していきます。
みてねの技術要素とSREチームの技術要素
YouTubeで紹介したページからの抜粋ですが、みてねの技術要素はこんな感じです。
メインのサーバーアプリケーションにRuby on Railsを使っている関係で、SREチームとしてよく使うプログラム言語は圧倒的にRubyが多いですが、iOSやAndroidのコードに手を入れることもありますし、GoやTypeScriptでツールを作って運用しているものもあります。Terraformのコード(HCL)やKubernetes向けのHelm Chartを扱う関係でYAMLを書くことも多いです。CIはCircleCI以外にもGitHub Actionsを多用していることや、iOSアプリ向けにはBitriseを利用しています。
インフラを大刷新！AWS OpsWorksからAmazon EKSへ
みてねが作られた2015年頃、インフラのオーケストレーションとして採用されたのはAWS OpsWorksでした。
Get Isao Shimizu’s stories in your inbox
Join Medium for free to get updates from this writer.
OpsWorksはEC2に対してChefを使ってソフトウェアのインストール、Railsのコードをデプロイ、負荷のモニタリング、CloudWatchメトリクスと連動したオートスケールなどができるサービスです。サービス発足当時より便利に使ってきて非常にお世話になったAWSのサービスですが、ユーザー数が伸び、インフラの規模が大きくなるにつれ問題が増えてきました。
- Chefによるインストールやデプロイ処理が遅い、オートスケールも遅くなる。
- Chefのアップデートが困難になる。
- Cookbookのメンテナンスと動作確認が大変。Try＆Errorや動作確認に時間がかかる。
- OpsWorksの制約により、スポットインスタンスを使うのが厳しい。が、できないわけではないがLambdaと連携させるなど複雑になるなどの課題も。
- ChefをアップデートしないとALBと連携できない（CLBのみ使っていました）。
- EC2のAMIのアップデートが放置されやすい。
- オートスケールや、EC2上で動くプロセス数の調整、CPU/メモリのチューニングが職人化しやすい。
少し簡略化した表現になってしまいましたが、これらの問題をできるだけ解決するためにインフラの刷新をすることを決めました。そこで新たなオーケストレーションツールとしてKubernetesを採用しました。
より信頼性の高いインフラへ
Kubernetesに移行した後も安定したインフラを運用できています。いくつか代表的なメトリクスを紹介します。
EC2インスタンス数の推移
このグラフはある週のEC2の台数を表しています。グラフの期間では30〜230台くらいの幅ですが、多い時で400台くらいまで増加することがあります。負荷に応じてスムーズにオートスケールしています。
さまざまなタイプのEC2インスタンスをオートスケーリンググループごとに分けて運用しています。
メインで利用しているオートスケーリンググループは5つあります。
- c5.4xlarge, c5d.4xlarge, c5a.4xlargeのスポットインスタンス群
- c5.9xlarge, c5d.9xlargeのスポットインスタンス群
- c5.12xlarge, c5d.12xlarge, c5a.12xlargeのスポットインスタンス群
- c5.4xlarge, c5d.4xlarge, c5a.4xlargeのオンデマンドインスタンス群
- c5.9xlargeのオンデマンドインスタンス群
上のグラフでは、赤と緑の部分がオンデマンドインスタンスとなっていますが、オンデマンドの割合は非常に少ないことがわかるかと思います。実際のところ9割以上のインスタンスをスポットインスタンスとして運用しています。
スポットインスタンスの価格はインスタンスのタイプや時期によって変動します。実際の価格推移はマネジメントコンソールから確認できます（この時はスポットの方がオンデマンドより約68%安くなっていました）。
このようにスポットインスタンスはオンデマンドインスタンスの半額以下の料金で済むことが多いため、オンデマンド中心だった従来と比較して非常に大きなコスト削減を達成できました。
全てがスポットインスタンスではないのには理由があります。オンデマンドの用途としては、
- 万が一スポットインスタンスが確保できなかった場合のフォールバック先（Priority based expanderを利用しています）
- 中断に弱いワークロード用
の2点があります。この辺りの実装の詳細は別途紹介できたらと思っています。
Pod数の推移
このグラフはネームスペースごとのPod数を表したものです。この日のピークタイムでは約5,000個のPodが起動していました。Cluster AutoscalerとHorizontal Pod Autoscaler(HPA)により負荷に応じてPod数が増減している様子がわかります。
GitOpsによるデプロイ
EKSに移行する前のOpsWorksにおけるデプロイのフローは
- AWSマネジメントコンソールにログイン
- OpsWorksの画面に遷移
- デプロイしたいアプリケーションを選んでDeployボタンをポチッ
というフローでデプロイしていました。
WebのUIがあるにせよ手作業で複数のページに遷移してデプロイをおこなうのはなかなか手間がかかっていました。
EKSに移行した今では、以下の図のようなデプロイフローになっています。
こちらの仕組みについては、別途どこかのタイミングで詳しく紹介したいと思っていますが、簡単に流れについて書くと… 開発者はGitHubでPull Requestをmasterブランチにマージすると、 GitHub ActionsでDockerイメージがビルドされ、Kubernetesクラスタ内で動作するアプリケーションがGitHub Appsからの通知を受け、ArgoCD Applicationのパラメータの一部（イメージのタグ）を書き換えることで、Dockerイメージがデプロイされます。
GitHub以外のUIを触ることなくデプロイができ、あとはSlackへのデプロイ通知やデプロイ後の変化をNew Relicでモニタリングするだけなので非常に簡素化されました。
オブザーバビリティ
先ほど掲載したグラフはGrafanaによるものですが、他にもNew Relic OneやPrometheusといったプロダクトを活用してオブザーバビリティの向上に努めています。Kubernetesにおける異常検知やリソース効率の最適化などについて、先日のNew Relic主催のウェビナーでお話しているのでこちらをぜひご覧ください。リンク先にスライドと動画があります。
色々他にも書きたいことはあるのですが、あまりにも盛り沢山すぎてしまうので、別の記事で順次ご紹介できればと思います。
みてねのSREチームでは信頼性向上のために様々な課題と向き合ってますが、優秀なチームメンバーに恵まれ、そして非常に良い雰囲気の中、日々課題解決に取り組んでいます。
そんなSREチームも含め、みてね事業部は各ポジションで積極的に採用中です。
転職前提でなくてもざっくばらんにお話しする機会を作ることもできますのでぜひご連絡ください。「家族アルバム みてね」カジュアル面談お申し込みフォーム」からお申し込みいただけます。
「家族アルバム みてね」は日本のみならず世界でまだまだ成長し続けています。一緒により良いサービスを作っていきましょう。
最後まで読んでいただきありがとうございました。
