2024.10.01
自社の社内情報を未来の“ゴミ”にしないための備え 「情報量が多すぎる」時代がもたらす課題とは?
リンクをコピー
記事をブックマーク
時田理氏(以下、時田):「SUZURIにおけるSREの取り組み」というタイトルで発表します。よろしくお願いします。自己紹介です。「SUZURI」というサービスのモバイルと、Webアプリケーションエンジニアをやっています。
今日話すことです。すみません、最初におことわりなんですけど、最初の仮のタイトルではFlutterに関する登壇をする予定だったんですが、今日はちょっとFlutterの話はしないでSREの話をしようと思います。
まず話すことは、ふだんSUZURIでSRE活動をやっているんですが、その活動の内容とか、あとはSUZURIは年に数回セールをやってるんですけど、そのセールのパフォーマンスの対策とか、ふだんのパフォーマンス改善のこと。あと、これからやりたいことについて話したいと思います。
ではまず、ふだんのSREの活動から話したいと思います。まずSREについてですが、一応、知らない方もいるかもしれないので、あらためて説明しておこうと思います。
SREはSite Reliability Engineeringというもので、簡単に言うとサービスの信頼を高めることで、ユーザーの体験や満足度を向上させることを指します。
具体的にはサービスにちゃんとアクセスできるとか、快適にアクセスできる。これは、例えばページが表示されるまで遅くないとか、そういったものを指します。
あと、障害が発生しないようにはもちろん運用していますが、万が一発生した時に、迅速に対処できる体制を作るのを目的としてます。
では、ふだんやっている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もプライベートクラウドで動いていますが、これはちょっとバージョンが古いので、今バージョンアップをやっている途中です。将来的には、マネージドサービスへの移行とかは検討していますが、まだ検討段階なので、これから先、検索体験や検索の速度などを向上させる時に、このあたりの選択肢を採る可能性はあると思います。
次はSLI(Service Level Indicator)とSLO(Service-level objective)の設定です。これはSUZURIの主要なエンドポイント。SUZURIではトップページ・商品詳細ページ・検索ページの3つに対して、レスポンスタイムに対してSLIとSLOを決めています。これらの情報をNew RelicとかDatadogからパフォーマンスを取得してGrafana上で可視化しています。
スライドの下のグラフは、そのSLOの達成率です。ちょっと見づらいんですが、上に2本線があって、トップページと商品詳細ページになってます。これは達成率はほぼ100パーセントに近いような状態で動けています。
ただ、その下の青いグラフは検索のエンドポイントですが、検索はトップページや商品詳細と比較すると、ちょっと今、パフォーマンスがいまいちよくない状況なので、これは引き続き改善していこうかなと思っています。
次はセール対策です。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」というサービスをつなげて、サービスダウンを検知したら担当者に通知するような仕組みを取っています。
なので、もしサービスがダウンしたら、その日の担当者に連絡が行って、すぐさまその障害を直したりする体制を取っています。
(次回につづく)
関連タグ:
2024.10.29
5〜10万円の低単価案件の受注をやめたら労働生産性が劇的に向上 相見積もり案件には提案書を出さないことで見えた“意外な効果”
2024.10.24
パワポ資料の「手戻り」が多すぎる問題の解消法 資料作成のプロが語る、修正の無限ループから抜け出す4つのコツ
2024.10.28
スキル重視の採用を続けた結果、早期離職が増え社員が1人に… 下半期の退職者ゼロを達成した「関係の質」向上の取り組み
2024.10.22
気づかぬうちに評価を下げる「ダメな口癖」3選 デキる人はやっている、上司の指摘に対する上手な返し方
2024.10.24
リスクを取らない人が多い日本は、むしろ稼ぐチャンス? 日本のGDP4位転落の今、個人に必要なマインドとは
2024.10.23
「初任給40万円時代」が、比較的早いうちにやってくる? これから淘汰される会社・生き残る会社の分かれ目
2024.10.23
「どうしてもあなたから買いたい」と言われる営業になるには 『無敗営業』著者が教える、納得感を高める商談の進め方
2024.10.28
“力を抜くこと”がリーダーにとって重要な理由 「人間の達人」タモリさんから学んだ自然体の大切さ
2024.10.29
「テスラの何がすごいのか」がわからない学生たち 起業率2年連続日本一の大学で「Appleのフレームワーク」を教えるわけ
2024.10.30
職場にいる「困った部下」への対処法 上司・部下間で生まれる“常識のズレ”を解消するには