インフラの整備、SLIとSLOの設定、セール対策　Railsアプリケーションのユーザ体験を支えるSREの取り組み

自己紹介と今日話すこと

時田理氏（以下、時田）：「SUZURIにおけるSREの取り組み」というタイトルで発表します。よろしくお願いします。自己紹介です。「SUZURI」というサービスのモバイルと、Webアプリケーションエンジニアをやっています。

今日話すことです。すみません、最初におことわりなんですけど、最初の仮のタイトルではFlutterに関する登壇をする予定だったんですが、今日はちょっとFlutterの話はしないでSREの話をしようと思います。

まず話すことは、ふだんSUZURIでSRE活動をやっているんですが、その活動の内容とか、あとはSUZURIは年に数回セールをやってるんですけど、そのセールのパフォーマンスの対策とか、ふだんのパフォーマンス改善のこと。あと、これからやりたいことについて話したいと思います。

SREの活動とその目的

ではまず、ふだんのSREの活動から話したいと思います。まずSREについてですが、一応、知らない方もいるかもしれないので、あらためて説明しておこうと思います。

SREはSite Reliability Engineeringというもので、簡単に言うとサービスの信頼を高めることで、ユーザーの体験や満足度を向上させることを指します。

具体的にはサービスにちゃんとアクセスできるとか、快適にアクセスできる。これは、例えばページが表示されるまで遅くないとか、そういったものを指します。

あと、障害が発生しないようにはもちろん運用していますが、万が一発生した時に、迅速に対処できる体制を作るのを目的としてます。

SRE活動1：インフラ環境の整備

では、ふだんやっているSRE活動の一環について説明していきます。まずはインフラ環境の整備です。（スライドを示して）これがSUZURIのインフラ構成になっています。

すごく簡単に言うと、RailsアプリがHeroku上で動いていて。SUZURIはアイテムに画像を貼りつけて、それをグッズにできるってものですが、その合成の部分をやっている画像合成サービスをLensといいますが、これがプライベートクラウド上と、あとGKEの上で動いてます。

あと、Elasticsearchがあったり、画像はAmazon S3に保存したり、そんなことをしています。あとは、なんかHeroku上のアドオンをいくつか使っていたり、パフォーマンスの監視などに「Datadog」や「New Relic」を使っています。

SUZURIのアプリはRailsで作られていて、それはHeroku上で動いているんですが、一部のサービスがプライベートクラウドで動いてます。画像配信サービス、先ほど説明したlensと、あとElasticsearchです。

インフラ環境の整備でもともとlensはプライベートクラウドで動いていましたが、それをKubernetes上で動かすように移行しました。これはハイブリッドクラウドの構成を取っていて、プライベートのKubernetesクラスタ、NKE（Nyah Kubernetes Engine）と社内では呼ぶんですが、プライベートのKubernetesクラスタ、それとGKE（Google Kubernetes Engine）のハイブリッドクラウドで運用しています。ハイブリッドクラウドにすることで、より高い障害耐性と可用性を確保しています。

あと、Elasticsearchもプライベートクラウドで動いていますが、これはちょっとバージョンが古いので、今バージョンアップをやっている途中です。将来的には、マネージドサービスへの移行とかは検討していますが、まだ検討段階なので、これから先、検索体験や検索の速度などを向上させる時に、このあたりの選択肢を採る可能性はあると思います。

SRE活動2：SLIとSLOの設定

次はSLI（Service Level Indicator）とSLO（Service-level objective）の設定です。これはSUZURIの主要なエンドポイント。SUZURIではトップページ・商品詳細ページ・検索ページの3つに対して、レスポンスタイムに対してSLIとSLOを決めています。これらの情報をNew RelicとかDatadogからパフォーマンスを取得してGrafana上で可視化しています。

スライドの下のグラフは、そのSLOの達成率です。ちょっと見づらいんですが、上に2本線があって、トップページと商品詳細ページになってます。これは達成率はほぼ100パーセントに近いような状態で動けています。

ただ、その下の青いグラフは検索のエンドポイントですが、検索はトップページや商品詳細と比較すると、ちょっと今、パフォーマンスがいまいちよくない状況なので、これは引き続き改善していこうかなと思っています。

SRE活動3：セール対策

次はセール対策です。SUZURIは年に数回大きなセールをやっていて、2021年は1月の「新春セール」と、4月の「7周年記念BIG SALE」。あと、5月末にあった「SUZURIのTシャツセール」をやりました。

特にこの夏のTシャツセールというのは、SUZURIのセールの中でもとても規模が大きくて、だいたいふだんの10倍ぐらいのリクエストが来ます。スライドの下に出ているグラフがリクエスト数ですが、右側にトゲが立っていて。これは、そのセール最終日のかけ込み需要で、突発的に大きなリクエストが来るような状況になっています。

先ほども説明しましたが、SUZURIはRailsで動いていて、Heroku上で動いています。なので、基本的にスケールアップはHerokuのオートスケール機能に任せていますが、セール開始の直後とか、最終日の最後の時間は突発的にリクエストが増えて、Herokuのオートスケール機能では間に合わないことがあるので、手動でスケールアップを行っています。

画像合成サービスのLensもスケールアップをする必要はありますが、Railアプリと比較すると間に1枚CDNが挟まります。リクエストの増加がRailsと比較するとちょっと穏やかなので、ここはKubernetesのオートスケールの機能に任せています。

HPA（Horizontal Pod Autoscaler）という機能があるので、それでポッドの数を増減させて対処しています。

それ以外にも、Active Recordのチューニングとか、キャッシュの活用をしてパフォーマンスの改善を行っています。

あとはBusy Modeというものを機能として持っていて。SUZURIには一部ユーザーによって表示する項目を変える機能があるんですが、そういった部分を負荷が高い時のみ非表示にするような、退避モードみたいなものがあります。ただ、最近はなるべくこの機能を使わないように運用しようとしているので、これは本当にやばい時だけ使っています。

パフォーマンス改善以外にもいくつかやっていることがあって、その中の1つにエスカレーション体制の確立があります。SUZURIはサービスの死活監視に「Mackerel」を使用していますが、このMackerelとエスカレーションの仕組みをいい感じにしてくれる、「PagerDuty」というサービスをつなげて、サービスダウンを検知したら担当者に通知するような仕組みを取っています。

なので、もしサービスがダウンしたら、その日の担当者に連絡が行って、すぐさまその障害を直したりする体制を取っています。

（次回につづく）