2015/11/18

インフラチーム改め Site Reliability Engineering (SRE) チームになりました

Author:: kazeburo

インフラチーム改めSite Reliability Engineering チームの @kazeburo です。この記事ではまだ馴染みの薄い Site Reliability Engineer とは何かについて紹介したいと思います。

SREとGoogleのSRE

Site Reliability Engineerは日本語にすると「サイト信頼性エンジニア」となりますが、あまりキャッチーではないので普段は略語の「SRE」を使用しています。SREという職種は日本ではあまり聞く事はありませんが、FacebookやAirbnb、Dropboxなどの企業でSREが募集され、それぞれのサービスを支える重要な役割を担っていると思われます。中でもSREのパイオニアとしてGoogleのSREチームが有名です。

GoogleのSREチームはGoogleの検索、広告、Gmail、YouTube、App Engineなどのサービスの可用性やパフォーマンス、拡張性などに携わっています。もし、これらのサービスで問題が発生すれば、SREがソースコードを追って原因を特定し、パッチを充ててリリースをすることもあるようです。GoogleのSREの特徴として、ソフトウェアエンジニアとしての業務の比重が大きい事が挙げれます。業務時間の20-80%は開発の業務に関わっているようです

GoogleのSREチームについては以下の記事が参考になります。

Google AI Blog: Site Reliability Engineers: “solving the most interesting problems”

Google – Site Reliability Engineering

www.reddit.com

このようにSREには、サイトの信頼性の向上のためにインフラストラクチャの自動化、障害対応、システムの維持などの運用業務、サーバ管理者的な役割に加えて、ソースコードに手を加えることでサイトのパフォーマンスを改善し、可用性、スケーラビリティを向上させるソフトウェアエンジニアとして役割の２つが求められます。

インフラチームからSREへ

メルカリのアプリが日米で展開され、ダウンロード数を飛躍的に伸ばしていく中で、インフラチームの役割や求められることも多くなってきました。当初はAnsibleを使ってのサーバセットアップ、Zabbixによる監視の設定、ログ収集用のFluentdのインストールなどが中心でしたが、今では取り扱うデータの増加に伴うデータベースサーバの分散、頻繁なリリースにより機能追加の頻度をあげたいというニーズからChatOpsとGoogle カレンダーを連携したデプロイ環境の構築、さらにはログ分析基盤の構築やPUSH配信サーバなどのミドルウェアの開発と検証、サーバの冗長化、APIサーバのパフォーマンス向上にも取り組んでいます。

以下はこの1年間のメルカリのAPIサーバの平均レスポンスタイムのグラフです。

f:id:kazeburo:20151117164812p:plain

SREチームとアプリケーションエンジニアのさまざまな取り組みによって大幅な改善を実現しています。

このようなソフトウェアエンジニアとしての業務とともに、日米両方での開発のサポートやアラート対応を行う当番制の導入など運用業務の改善も行っています。さらに、VagrantやDockerを活用した開発、QA環境の整備といった取り組みも進めています。このように業務が広がっていく中で、既に「サーバ周りの業務を行うインフラ」という枠に収まっていないのではないかという疑問があがり、実態により合っているSREへの名称変更が議題となりました。

他社での事例の他に、SREの日本語訳に「信頼性」という文字が含まれるのも、インフラよりも適切であるとした理由のひとつです。メルカリをお客様に5年、10年と使って頂くためには、何よりもメルカリへの信頼性が重要です。スマホアプリでは、24時間使いたい時に使える、取引したい時に取引出来るというが重要となります。頻繁なメンテナンスやレスポンス速度が悪ければそれだけでお客様の信頼性を損ねる結果となります。いつでも快適に安全にサービスを利用できるという信頼性の提供を私たちのチームが責任をもつことを確認し、SREへのチーム名変更を行いました。

現在のSREチームの主な業務は次のようになります。