LocoPartnersでのSRE（Site Reliability Engineering）的な取り組み
こんにちは。
エンジニアの古田です。
ポケgoをいまだに続けてます。希少な黄色です。
今週初めてEXレイドに当選しましたが、人が集まらず倒せませんでした。
この記事はRelux Advent Calendar 2017 19日目の記事です。
表題にある通り弊社でもSRE的なものへの取り組みが動き始めました。
その経緯と、どうやって進めているかについて紹介させていただきます。
SREとは
最初はGoogleが提唱した考え方ですが、日本でも既にメルカリやfreeeなど導入企業が増えています。そのため少しググれば様々な情報がありますし、オライリーからも書籍が出ています。原点は「信頼性はあらゆるプロダクトの基本的な機能である」という考え方にあり、この運用チームが考慮することはインフラに留まらずソフトウェア領域へのアプローチや不要な手作業の自動化まで含まれます。
ベンチャーの多くが、今後も使われるか分からない機能やソースコードのメンテナンスよりもスピードを優先してサービスを構築していきます。そして生き残り、3年ほど運用を続けた頃から技術的負債との付き合いが始まります。Googleは、信頼性を担保するために専属のチームを作りリソースを確保して可用性を向上していくという方針を取り入れました。
なぜやるの？
弊社が運営するReluxというサービスは2013年にローンチしたサービスです。 この4,5年の間、スピードを重視しながら様々なチャレンジもしてきました。その結果、会員数が100万人を突破するまでに成長することが出来ました。
ここまで来るために、開発もスピード重視で進んできました。体制もシステムの内側もなかなかにカオスな状態です。これに対する打ち手として、先日弊社の鈴木が書いたブログにある通り、ここ１、２年で体制を改善してきたことで新しい負債は抑制されてきています。
その他にも、月に1日だけ開発者の判断でやりたいことに取り組むCLEARという日を導入しました。日々の開発タスクではなかなか優先度が上がらない『重要だけど緊急度が低いタスク』に取り組む時間です。今まで15回ほど開催し、多くの改善が生まれ一定の成果を上げています。
ただ、1日ではシステム設計を根本から見直すといった打ち手は実行できず、大きくなった負債の元本まで返済するには至らずでした。。
そんな中で引き続き、会員登録が出来ない・予約に失敗する・メールが届かない、といった致命的な不具合もちょこちょこ起きてしまっています。こういったエラーは０にすべき。これだけ多くの方に使っていただけるサービスになりましたので、これからは今で蓄積されてきた負債を減らしたりうまく付き合いながら信頼されるサービスにしていくことが必要です。ということで、一定の成長を遂げたベンチャーでは運用保守への重要性が高まってくるため、このタイミングでやり方を変えていきます。
Locoの違うところ
SREの考え方では本来、専門のチームを組成します。そしてDevチームとSREチームの意見を合わせるためにエラーバジェットという考え方が提唱されています。バジェットを使い切るまでは通常通り開発し、使い切ってしまった場合には開発を止めるというやり方で、バッファを明確にすることでどの程度開発側の無理を許容するかを事前に合意を取るものです。
今回の取り組み、Locoでは別チームは作りません。一定の工数を意図的に確保するだけです。現状でも運用はみんなでやっています。上記のような認識合わせが必要なのは、立場の違いによる利害関係の不一致です。自分が開発し、それを自分で保守メンテするとなれば、認識を合わせる必要がないのでエラーバジェットは必要ないと考えています。
チーム人数は十数名とまだ少なく、話し合いながら全員の認識を合わせることが可能なのでSRE領域のwhyとwhatを全員で認識合わせて一緒に目指します。人も固定化せず、アクションに対して得意な人がリードしていきます。
どんなことに取り組んでくか
以下のようなことをやっていけたらなーと考えています。
リファクタリング
Reluxでは４つのシステムが動いています。
現在は、いずれもCakePHP2系で動いており、一部の共通機能をLaravel5.4で内部APIとして実装しています。
この中でも特にCakePHP側のソースコードには技術的負債が蓄積されています。例えばスピードを重視したためにコピペコードが散見されるだとか、フロントエンドでも不要ファイルや処理の読み込みが残っており、不具合や表示速度低下を招くといったリスクを抱えています。 この状態を打破するために、根幹のアーキテクチャーを見直していく予定です。
具体的には、改めて現在の機能をオブジェクト思考で綺麗に設計した上でLaravel部分へ徐々に移行していきます。検索や施設情報の参照といった機能は同じような動作となるので共通化していきます。
監視
現在はNewrelic,CloudWatchを活用し、通知はSlackへ流しています。Newrelicで無料の機能がいくつかなくなり、今後もどうなっていくのか不明なのでこの機会に別のツールも検討します。
インフラ、DBのメンテナンス
スロークエリも放置すると障害の温床となります。今までは問題が起きてから見ることが多かったのですが、時間を確保して継続監視していきたいと考えています。またスケールアップを省力化したり、プロビジョニングツールを導入したりと管理負荷を下げるといったことも検討しています。
トイルの撲滅
SREでトイルというのは『プロダクションサービスを動作させることに関係する作業で、手作業で繰り返し行われ、自動化することが可能であり、戦術的で長期的な価値を持たず、作業量がサービスの成長に比例するといった傾向をもつもの』だそうです。
弊社でもデータ変更作業をエンジニアが手動でやっているところや、キャンペーンやランキングなど定型開発を自動化できそうです。
ゴールの設定
リファクタリングに関しては、最終的にどんなシステム全体像になるかをチームで話し合って決めました。あと足りないのは具体的な進め方とスケジュールです。
また、それ以外の打ち手も含めてSLO（サービスレベル目標）がまだ決まっていません。この辺りは合宿などを行い話し合います。
やる人が決める。みんなで意見をぶつけてチームが納得感を持って取り組むことを大事にして、Reluxの信頼性を高めていきます。
