この記事は、カケハシアドベントカレンダー2021の5日目の記事です。

SREチームとCorporate Engineeringチームのディレクター兼スクラムマスターをやっています、尾形です。今回はカケハシのSREチームが、今どのようなことに取り組んでいるのか、そして今後どうしていこうと考えているのかについて書いていこうと思います。

そもそもSREとは

Site Reliability Engineeringの略で、もともとはGoogle社が提唱したものです。Site Reliability Engineeringというそのままの題名の書籍が、英語版・日本語版それぞれあり、英語版は無償で読むことができます。SREという言葉の提案者によれば、「SREは、ソフトウェアエンジニアに運用チームの設計を依頼した時にできあがる」と述べています。では運用とはなんでしょうか。サーバーやネットワークの構築・設定、監視や通知の設定、各種メトリクスの測定、障害対応…などが思い浮かびます。つまり作ったソフトウェアが提供する価値を、安定してユーザーへ届ける、それが運用であると言えます。

従来のシステム運用では手作業によるミス、人員増加によるデプロイ数の上昇とそれに伴う障害率の上昇、サーバー増加による故障率の上昇など様々な問題が発生します。SREとはそれらの問題を、エンジニアリングの力で自動化・効率化し、システムの信頼性をできるだけ高く保つためのチームであると言えます。

カケハシのSREの現在

さてカケハシにおけるSREですが、ディレクターの自分を含めて3人しかおりません。したがってSREチームが障害対応の一次請けをする、といった運用（いわゆるオンコールローテーション）はしていません。現時点での主な業務は以下の通りです。

開発の困りごと全般の支援
GitHub ActionsによるCI/CDパイプラインの構築支援と改善
MablによるE2Eテスト、リリースパイプラインの構築支援と改善
Datadog/PagerDuty/Sentryなどによるモニタリングやアラートの最適化
Four Keys metrics等を使った組織パフォーマンスの測定/改善
開発ドキュメントの改善
セキュリティの担保・改善
アーキテクチャレビューの実施
リリース前レビューの実施
開発チームのDX改善にむけた支援
各プロダクトの障害訓練の定期的な実施

このように、各チームと協調して業務を進めていくことが多いチームとなっています。この1年くらいは主にセキュリティや監査に注力しており、AWSのアカウント分割・IAMの権限見直し・踏み台サーバーの撤廃・SecurityHubの活用といった成果を挙げてきました。医療情報という非常にセンシティブな情報を扱うプロダクトなので、セキュリティは非常に重要です。しかし開発者の体験を著しく損ねるようなセキュリティ施策は、できるだけ避けたいものです。そのバランスを上手く取りながら進められたのではないかな、と思います。

もちろんここに挙げたもの以外にも、様々なことに関わっています。中には「それSRE関係なくない?」と言ったものも散見されますが、それが許容されるのがいいところかなと思います。

カケハシのSREの今後

現状をご紹介したところで、今後どのようなことをやるのか、どのような課題が残っているのかについても書きたいと思います。

カケハシではすべてのプロダクトにおいてサーバーレスアーキテクチャへ移行しており、ほぼ完成しつつあります。一方でそれに伴うペインも発生しているため、その解消をしていくことが必須です。具体的にはクライアント側も含めた分散トレーシングの導入・複数のモノリス化したLambdaの分解・サーキットブレーカーの導入などです。当然各開発チームの工数も確保しなければならないし、実施する前段階として超えるべき壁がいくつもあるため、なかなか難易度の高い作業になりそうです。

また、セキュリティに関しても自動化が進んでいないため、各種インフラ作業のChatOps化なども含めて効率を上げていく必要があります。さらに各プロダクトのリリースにおいて、カナリアリリースを簡単に実施できる仕組みを用意する必要もあります。細かいことを書き始めると終わらなくなってしまうのでこの辺にしておきますが、やるべきことはまだまだ山積しています。