こんにちは。フォルシア株式会社SREチームの小孫です。
フォルシア株式会社ではこの春からSREチームを始動しました。今回は、なぜこのタイミングでSREチームを始めることになったのか、具体的にどういうことをやっていくのかを紹介します。よく耳にする大規模サービスのSREとは違う、弊社の課題をふまえたSREを目指しているので、私たちの話が少しでも参考になれば幸いです。
SREってなんだっけ
まず初めに、SREとは何かという話を簡単にします。
SRE（Site Reliability Engineering）とはGoogle社が提唱し、世界中の多くの企業で実践されてきたシステム運用に関する概念です。システム運用の課題をソフトウェアで解決し、開発やリリースのサイクルとサービスの信頼性を両立させるための方法論、マインドセット、それに関わるエンジニアのことを指すもの、と私は理解しています。
これだけだといまいち掴みどころがありませんが、SREはGoogle社が大規模サービスを成長させていく中で培ったノウハウを他社でも活かせるように共有したものなので、ある程度抽象的な概念になっているのだと思います。そういう意味では、世の中にたくさんあるSREの具体的な方法論を真似ることよりも、SREの概念を理解して自社に合わせた形で実践することの方が重要だと考えられます。
実際のところよく耳にするSREの方法論は、Google社をはじめ自社で大規模なサービスを運用している企業のケースが大半です。見聞きする分にはとても楽しいのですが、なかなか自社に当てはめづらい部分もあります。
たとえば、弊社では受託開発が多く、最近急成長しているwebコネクトというプロダクトも、SaaS型ではありますが完全な自社サービスというわけではありません。そのため教科書通りにSLO（サービスレベル目標）やSLA（サービスレベル合意）だけでリリースサイクルを決められるわけではなく、顧客の都合に合わせてリリースタイミングを決めることになります。
また、Dev（開発者）とOps（運用者）が連携するという意味のDevOpsにしても、弊社ではDevとOpsがはっきりと分かれていないので、DevOpsの文脈で語られる課題感を実感しにくい面があります。
大規模サービスを運用する企業のような、インフラ周りは専任のSREチームが面倒を見て、アプリエンジニアはアプリ開発に集中する、という形にもあてはまりません。
なぜSREチームを始めるのか
ではそんな弊社でなぜSREチームを始めることになったのか、その背景を説明していきます。
従来弊社では、顧客がホストするサーバにアプリをデプロイしてサービスを運用することがほとんどでした。しかしここ数年のビジネスの成長や変化に伴い、AWS環境に自社でインフラを用意して、Kubernetesを中心にサービスを運用することが増えてきました。これによりビジネスの幅が広がり、機動力も上がってきました。
弊社にはエンジニアの分業はできるだけ行わず、顧客対応からアプリ開発、インフラ運用まで含めてフルスタックで行うという方針があります。これは、ビジネスやサービスの全体観をもって活躍するエンジニアを育てたいという目的によるものです。そのため、AWSやKubernetesの運用に関しても基本的にアプリエンジニアが行っています。これはシステム運用の課題をソフトウェアで解決するというSREの考え方にもとてもマッチしていると思います。
ただ、現時点ではいくつかの課題があります。たとえば、Kubernetesはある程度のキャッチアップコストがかかるため、運用負荷を減らすはずのツールがかえってエンジニアの負担になり、不安を抱えながら運用に携わるケースがあります。また、サービスの成長に伴ってインフラ費用が青天井になったり、AWSやKubernetesに関する知見が属人化するなどの課題も出てきました。
これまではコンテナやクラウドに興味のある有志でこのような課題に取り組んできましたが、今期からSREチームとして組織的に対応していくことになりました。
SREチームで取り組むこと
私も含めSREチームのメンバーは、これまでアプリエンジニアとしてそれぞれ特定のアプリを担当してきたため、自分が担当していないアプリにおける課題はいまいちわかっていませんでした。そこで、Kubernetesを利用しているアプリを中心に担当エンジニアにヒアリングを行い、そこで出てきた課題やSREチームに期待することをふまえて、今期具体的に取り組んでいくことを決めました。
取り組みの内容は、「1. エンジニアのスキルアップや情報共有」「2. 運用負荷の軽減」「3. インフラコストの削減」の3つに大きく分かれています。
1. エンジニアのスキルアップや情報共有
ノウハウを属人化させず、対応できる人を増やすという意味でこれは特に重要だと考えています。もちろんアプリエンジニアがインフラの専門家になるというのは想定していませんし、アプリエンジニアとしてやるべきことは他にもたくさんあります。しかし先にも説明した通り、弊社ではアプリエンジニアがインフラの運用にも携わっているので、インフラに関する知識を増やすことは大きなメリットになります。
SREチームを発足するにあたって、アプリエンジニアとSREチームの境界をどうするかという話をしたところ、インフラ周りをSREチームに丸投げしたいというアプリエンジニアはおらず、むしろインフラに関する知識を増やしたいという意見を多く聞きました。そこで、SREチームが中心となってコンテナやクラウドに関する知見を取り入れて、アプリエンジニアに還元することで会社全体のスキルアップにつなげようと考えています。
スキルアップの方法としては、Kubernetes環境に特化したオンコールトレーニングや、コンテナやクラウドに関する情報共有ミーティングを予定しています。
オンコールとは夜間や休日の障害発生に対応できるように、エンジニアがシフトを組んで備える運用のことです。弊社ではアプリエンジニアがオンコール対応を行っており、担当外のアプリでも一次対応ができるようにオンコールトレーニングが行われてきました。ただ、Kubernetes環境のオンコール対応については担当エンジニアへのエスカレーションが基本になっています。そのため担当エンジニアの負担が大きい一方で、担当外のエンジニアはKubernetesを触る機会がなかなかありません。そこでKubernetes環境に特化したオンコールトレーニングを行い、オンコール担当者もある程度対応できるようにしようと考えています。また、担当していないとなかなか触る機会がないKubernetesを、オンコールトレーニングの中で操作してみるという体験にも大きな意味があると考えています。
情報共有ミーティングについてはすでに始めていて、Kubernetes利用アプリの担当者や興味のあるエンジニアに隔週で集まってもらっています。年に数回あるKubernetesのバージョンアップに関する情報や、コンテナやクラウド周りのトピックを共有しています。話を聞いて終わりではなく、今後何かあった時に活かせるよう、前提知識があまりなくても理解できるように気をつけて話をしています。
情報共有ミーティングのほかに、コンテナやクラウドに関する社内勉強会やハンズオンも計画しています。
2. 運用負荷の軽減
DevとOpsが分かれていない弊社では、Opsの負荷軽減がそのままDevにとってのメリットにもなります。もちろんこれまでにもCI/CDや自動化ツールの充実が図られてきましたが、まだまだ改善の余地があります。
特にデプロイ周りはアプリの特性もあり自動化しきれていない部分があるので、ワークフローツールの見直しから取り組んでいます。
また、Kubernetesに関してはYAMLの定義ファイルでの管理がアプリエンジニアの負担になっているので、cdk8sというツールを使って、普段から使い慣れているTypescriptでKubernetesリソースの定義を管理し始めています。
cdk8sについてはこちらでも紹介しているので、ぜひご覧ください。
3. インフラコストの削減
弊社ではこの数年でAWSの利用が急増してきました。当然のことながらインフラコストの増大は会社の利益に直接影響します。当初はあまり問題になっていなかったインフラコストも、事業の拡大により無視できない金額になってきています。
SREチームとしては以下のような対応を始めています。
- アプリ担当者にインフラの利用状況を確認し、利用方法を見直して不要なリソースは削除。
- AWS Load Balancer Controllerの機能を活用して、KubernetesのIngressと同じ数だけ作成されていたALBを削減。
- リソース可視化のためにGrafanaを再整理して、KubernetesのPodに割り当てるリソースを最適化。
一つ一つは地味ですが、塵も積もれば銀の弾ということで、一歩ずつ取り組みを進めています。
おわりに
今回はフォルシア株式会社でSREチームを始めた理由と、具体的に取り組んでいく内容を紹介しました。
SREというと大規模サービスの事例がよく紹介される一方で、中小規模のサービスの事例を見聞きする機会はあまりありません。
SREの考え方はサービスの規模によらずもっと活かせるはずなので、今後も弊社のSREの取り組みを紹介していきたいと思います。
最後までお読みいただきありがとうございました。
この記事を書いた人
小孫 一浩
2017年新卒入社
SREだけでなくAREがどうなるのかも気になりますね、はっきり言うて。
Discussion