【新連載】リクルート流、SREコトハジメ：SREって、具体的にどんな仕事する人たちなの？ (1/3)

インフラ構築や運用に必要なコストが変わってきている昨今、運用技術者に求められる役割が変わりつつあります。それが「SRE」です。日本ではまだまだ一般的ではない概念ですが、本連載ではリクルートグループの例を通じて、その実態をお伝えしていきます。

　ITインフラにおけるクラウド活用が一般的になりつつある昨今、インフラにおける日々の運用業務は、クラウド事業者に任せられるようになりました。インフラを使うために必要な設定は、クラウドであればツールやAPIを介して使えます。

　アプリケーション開発者でもインフラ構築や運用ができる――今、運用技術者に求められる役割が大きく変わろうとしています。そんな中、Google発で「SRE」というキーワードが出てきました。

　SREとは「サイト・リライアビリティ・エンジニアリング（Site Reliability Engineering）」の頭文字を取った略称で、Webサイトやサービスの信頼性向上に向けた取り組みを行い、価値の向上を進める考え方および方法論です（この取り組みを行うエンジニアそのものを指すケースもあります）。

　既に取り組んでいる企業も少なくないとは思いますが、SREは、まだまだ日本では理解が進んでいない概念です。この連載では、リクルートグループにおける実例を通じて、SREの実態をお伝えできればと思っています。

SREって具体的に何をするの？　本家Googleの取り組みとは

　リクルートグループの話をする前に、まずは本家GoogleにおけるSREの取り組みを紹介しようと思います。同社のエンジニア組織のトップであるベン・トレイナー（Ben Treynor）によれば、SREを端的に説明すると、運用をソフトウェアエンジニアに依頼したときに生まれる仕事を指します（参照リンク）。

　運用と言うと、人間が行う手作業が多いイメージを持たれるかもしれませんが、それをソフトウェアエンジニアに依頼するのですから、運用そのものを“ソフトウェアの問題”として捉え、対処してもらうわけです。

　SREを行う組織は、基本的には運用部隊が行ってきた作業全般を請け負います。ソフトウェアエンジニアであるなら、手作業を自動化するモチベーションはあると思いますし、そのスキルも備わっているはず。「たとえサービスの拡大で作業量が増えたとしても、自動化でカバーしてくれ！」というのがSREへの期待なのです。

　では、SREは具体的にどういった取り組みをしているのでしょうか。本家Googleの事例を見てみると、大きく4つの活動を行っていることが分かります。

1.SRE組織と方針

　Googleは、ソフトウェアエンジニアとシステムエンジニアでSREチームを編成しました。彼らは、可用性やレイテンシ、パフォーマンス、変更管理、モニタリング、緊急対応、キャパシティプランニングに責任を持っています。

　組織で取り組む業務の方針として、「トイル（Toil＝労苦）」と呼ばれる、自動化できるにもかかわらず、手作業で行う運用作業にかける労働時間を「全体の50％まで」と制限しています。残りの時間で、自動化を目指すコーディングやサービスレベル向上に関連するプロジェクトに対応するというわけです。

GoogleのSREでは、受動的な作業で時間が圧迫されないよう、時間の使い方を制限している

　仮にトイルが増えすぎた場合、トイルの優先順位を変更したり、取り下げたりといったことをサービス関係者と調整するため、適切なコミュニケーションを行う必要があります。四半期に一回のペースで「サービスレビュー」と呼ばれる、トイルに要した時間の棚卸しを実施し、トイルに50％以上の時間を要しているなら、組織の方針を変えたり、場合によっては、組織を解体したりといったことまで実施するという徹底ぶりです。