2024.10.10
将来は卵1パックの価格が2倍に? 多くの日本人が知らない世界の新潮流、「動物福祉」とは
リンクをコピー
記事をブックマーク
時田理氏(以下、時田):「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.11.13
週3日働いて年収2,000万稼ぐ元印刷屋のおじさん 好きなことだけして楽に稼ぐ3つのパターン
2024.11.11
自分の「本質的な才能」が見つかる一番簡単な質問 他者から「すごい」と思われても意外と気づかないのが才能
2024.11.13
“退職者が出た時の会社の対応”を従業員は見ている 離職防止策の前に見つめ直したい、部下との向き合い方
2024.11.12
自分の人生にプラスに働く「イライラ」は才能 自分の強みや才能につながる“良いイライラ”を見分けるポイント
2023.03.21
民間宇宙開発で高まる「飛行機とロケットの衝突」の危機...どうやって回避する?
2024.11.11
気づいたら借金、倒産して身ぐるみを剥がされる経営者 起業に「立派な動機」を求められる恐ろしさ
2024.11.11
「退職代行」を使われた管理職の本音と葛藤 メディアで話題、利用者が右肩上がり…企業が置かれている現状とは
2024.11.18
20名の会社でGoogleの採用を真似するのはもったいない 人手不足の時代における「脱能力主義」のヒント
2024.11.12
先週まで元気だったのに、突然辞める「びっくり退職」 退職代行サービスの影響も?上司と部下の“すれ違い”が起きる原因
2024.11.14
よってたかってハイリスクのビジネスモデルに仕立て上げるステークホルダー 「社会的理由」が求められる時代の起業戦略