アソビューSREでこの１年間で実際に実施した各種効率化について

Transcript

1. この１年間でSREが実際に実施した各種効率化の視点ついて ~剰余リソースの見つけ方の視点~ 2023/12/6 アソビュー株式会社　SREユニット 鈴木剛志
2. © ASOVIEW Inc. 2 About Me Name :　鈴木剛志（すずきたけし） Company：アソビュー株式会社 SRE ユニット Twitter: @takesuzu90 前職では、給与計算や、販売調達管理の業務アプリケーションの開発などを 経験した後、アプリケーションのパフォーマンスチューニングも実施したりして その後インフラよりの仕事をするようになる。2022年3月よりアソビューにジョ インして、アソビューのインフラの保守やCI/CDを担当するSRE部門で仕事し ています。
3. © ASOVIEW Inc. 3 本日のお話の概要 メインは、このバランスをどう取っていくかみたいな視点のお話です。 残りの時間で他にこういう部分に着目すると、この部分のリソースって無駄だなみたいな ことを気づける視点みたいなのをご紹介していければと思います。 システム安定稼働 リソース効率
4. © ASOVIEW Inc. 4 本日お話しすること 下記のような内容を話していこうと思っています。 1. 安定稼働する上での、余剰リソースを見つけていくための視点 a. アソビューにおける安定稼働をする上での余剰リソースの定義の仕⽅ b. 余剰リソースをどのような⼿法で削減していったか 2. （時間があれば）その他の最適化した手法の紹介 a. Kubernetesのリソースの使われ⽅を⾒てノードのインスタンスタイプを最 適化 b. Datadogの料⾦体系を⾒て、コストの最適化を実施 c. CircleCIの実⾏環境を意識して最適化する d. Cloud Native BuildpacksのBuildキャッシュの動きを⾒て最適化する
5. © ASOVIEW Inc. 5 会社概要 会社名
 アソビュー株式会社 - ASOVIEW Inc. -
 設立年月日
 2011年3月14日
 10億円（資本準備金含む） 
 資本金
 所在地
 東京都品川区大崎1-11-2 ゲートシティ大崎イーストタワー 8F
 従業員
 約220名（2023年7月時点）
 Zキャピタル株式会社 / フィデリティ・インターナショナル
 三井不動産株式会社 / 株式会社ジャフコ
 株式会社グロービス・キャピタル・パートナーズ
 JICベンチャー・グロース・インベストメンツ株式会社
 地域創生ソリューション株式会社
 新生企業投資株式会社 / きらぼしキャピタル株式会社
 南都キャピタルパートナーズ株式会社
 三生キャピタル株式会社　他
 株主

6. © ASOVIEW Inc. 6 ミッション 生きるに、
 遊びを。 モノ消費からコト消費の時代へと 変化した現在。 物質的、金銭的な豊かさだけではなく 心の豊かさ「well-being」を実感できる社会を “遊び”を通じて実現します。 © ASOVIEW Inc. 6
7. © ASOVIEW Inc. 7 サービスの全体像 “遊び”市場に特化したプラットフォームを中心に4つの領域でサービスを展開
 ゲスト
 遊び予約サイト
 業務DX
 ソリューション
 次の休みは何しよう？ 
 パートナー
 遊び体験を提供!
 遊び体験をプレゼント 
 アソビュー!に
 遊び体験を掲載
 アソビュー!で
 遊びを予約
 ウラカタで
 業務管理・分析
 地方の観光
 活性化をサポート
 地域ソリュー
 ション
 商品開発
 販路整備
 販売促進
 遊びプラットフォーム
 アソビュー!
 ギフトで
 知人に
 遊び体験を
 プレゼント
 service 1 service 2 service 3 service 4 企業
 顧客満足度を高めたい !
 顧客への販促物として 
 体験ギフトを利用
 地方自治体
 観光を活性化したい !
 休日・週末
 旅行
 体験事業者
 レジャー施設

8. © ASOVIEW Inc. 8 概要
 休日の便利でお得な遊び予約サイト
 月間PV数※
 3,800万 会員数
 1,000万人 掲載プラン数
 28,000件 何度も使いたくなる 3つのポイント point 1 point 2 point 3 お得に遊べる!
 ポイントやキャンペーンが満載!
 いつものお出かけスポットもお得に !
 遊びが見つかる!
 次の休みに行ってみたい
 人気の遊びや新しいスポットが見つかる !
 カンタンWeb予約・並ばず入れる!
 事前Web購入により現地での購入が不要に !
 窓口に並ぶ必要が無いから、
 当日の時間が有意義に!
 ※2022年8月実績
9. © ASOVIEW Inc. 9 主な利用技術(本日お話しするもの) • Amazon EKS • Amazon Aurora • Cloud Native Buildpacks • CircleCI • Datadog
10. © ASOVIEW Inc. 10 本日お話しすること 下記のような内容を話していこうと思っています。 1. 安定稼働する上での、余剰リソースを見つけていくための視点 a. アソビューにおける安定稼働をする上での余剰リソースの定義の仕⽅ b. 余剰リソースをどのような⼿法で削減していったか 2. （時間があれば）その他の最適化した手法の紹介 a. Kubernetesのリソースの使われ⽅を⾒てノードのインスタンスタイプを最 適化 b. Datadogの料⾦体系を⾒て、コストの最適化を実施 c. CircleCIの実⾏環境を意識して最適化する d. Cloud Native BuildpacksのBuildキャッシュの動きを⾒て最適化する
11. © ASOVIEW Inc. 11 システムを安定稼働させるために意識しておくべきこと 前提： システムというものは、無限に処理を受け付けられるということは絶対になくて、必ず、性能限界とい うものにぶつかります。 ＝＞性能限界をきちんと意識しておくことというのは非常に大切 リソース上限例） Amazon　Aurora:　１ノードあたりのスペックは最大.24xlarge 　　　　　　　　　　最大Connection数：最大16,000
12. © ASOVIEW Inc. 12 １年前のアソビューの課題 課題： インフラのスペックの見積もりに根拠がなく、なんとなく多めに見積もって負荷に対応しようというよう な状態だった。これにより、本来必要なリソースよりも過剰なリソースで運用してしまっていた。 また、スペックも一部AWS上の最大スペックでの運用で実施していたために、サービスの成長ととも にいつか限界が来るのだが、実際にあとどれくらい成長したら性能限界を迎えるのかという値の可 視化ができておらず、リスクのある運用が続いてしまっていた。
13. © ASOVIEW Inc. 13 ビジネス上重要な指標を性能限界を示す指標と必要なインフラスペックの相関を見る 弊社では、システム上重要な機能は、チケットを購入して、そのチケットを表示して施設に入場するというのが重要な機能であるために、そこ の処理性能を測るための指標を定めることが非常に重要になります。 具体的には、弊社では、負荷テスト実施時に、下記のような指標を定めてこの値がどの程度までパフォーマンスを出せるかというのを観察し ています。 • 購入動線前分間最大アクセス数（チケット種別毎） • 分間購入成功数 • 分間着件処理数（施設入場者処理） • 分間電子チケット表示数 • 非同期処理遅延時間（チケット関連処理、ポイント付与処理など） 負荷テスト限界値記録シート このインフラスペックなら、この程度の処理をさばくことができるというのをきちんと記録 していけるようになりました。
14. © ASOVIEW Inc. 14 （例）目標性能指標 下記のように、目標となる指標とそれに必要なリソースを記録して、性能限界を把握していき ます。 入場制限 1000 購入動線前分間最大アクセス数 20000 前提条件 最大指標 DB serverless 20% DB指標 前提条件 ※DBはAWSのACUなど負荷テスト実施時に記録されたもの を記録 Pod名 Pod数上限 最大Pod負荷率 Pod A 20 20 Pod B 10 15 ※Pod負荷率は、後述のものを負荷テストを通じて計測して記 録する
15. © ASOVIEW Inc. 15 各マイクロサービスの１Podごとの性能限界を見極めた上で負荷率を表現する 負荷テストを実施していく上では、こちらも重要です。 弊社の場合には、下記の指標を全ての Podで計測しています。 　(秒間リクエスト数)✖(p99レイテンシー) (Pod数)✖(1Pod秒間処理可能数※) ✖100 （Pod負荷率）＝ ※ 1Pod秒間処理可能数は、Javaないのリソース上限などに依存して別途定める。 リソースのWait処理が目立つような時間が、処理可能数の限界値になる。
16. © ASOVIEW Inc. 16 必要なバッファを定めていくスパイク傾向を把握する視点 弊社の場合には、人気のチケットの発売などがあると、発売開始直後に負荷が集中するということがよく発生します。 実際のある人気チケット発売時の負荷動向 直前の５倍くらいのリクエストが来ている状況になります。スパイク傾向に注目して、ほとんどの人気チケットが５倍内に収まっている ことを確認しています。
17. © ASOVIEW Inc. 17 スパイクを事前に予測する視点 人気チケットを購入しようとする人たちは、一定の比率で発売日の少し前に様子を見にくるという行動を取るということが普段の観察結果か らわかりました。この事前にくるトラフィックをベースにしてどの程度のスパイクになるかというのを予想して多くことにより、スパイクに必要な リソースを準備するというフローも作成しています。 日付 30分前 １５分前 １０分前 最大瞬間分間訪問者 チケット名 2023/5/15 50 65 109 412 チケットX 2023/6/10 409 1928 2166 8500 チケットY 2023/7/5 224 300 315 840 チケットZ スパイク実績表ー記録例 ３０分前にこれくらい来ている時は、この程度スパイクするというのをデータとして蓄積して、その 傾向をベースに予測値を立てます。５倍以上のスパイクが予想される場合には、手動で直前に Podの増強などを行い、高負荷に対応するための事前処理を実行します。
18. © ASOVIEW Inc. 18 本日お話しすること 下記のような内容を話していこうと思っています。 1. 安定稼働する上での、余剰リソースを見つけていくための視点 a. アソビューにおける安定稼働をする上での余剰リソースの定義の仕⽅ b. 余剰リソースをどのような⼿法で削減していったか 2. （時間があれば）その他の最適化した手法の紹介 a. Kubernetesのリソースの使われ⽅を⾒てノードのインスタンスタイプを最 適化 b. Datadogの料⾦体系を⾒て、コストの最適化を実施 c. CircleCIの実⾏環境を意識して最適化する d. Cloud Native BuildpacksのBuildキャッシュの動きを⾒て最適化する
19. © ASOVIEW Inc. 19 ここまでの要素から安定稼働基準を確定する 基本指針： • スパイクは、５倍以内に収まることがほとんど（当社の場合）ということから、通常運用時は、５倍のスパイクに耐えられるように常に準 備しておく。 安定稼働基準： Pod負荷率＝通常時20%以内 DBのACU＝通常時２０％以内 ※ACUはAurora Serverless v2の利用単位、通常時は、スパイクを除くの意味 ⇨通常時にここに収まるリソースは、安定稼働上は過剰なリソースとして可用性を維持しつつ インフラコストの最適化も目指していく。
20. © ASOVIEW Inc. 20 最適化のために検討した技術候補 時間帯や日付でアクセス数のトレンドが変わるので、そこらへんの流動性の高い仕組みとして、最初に、下記を検討していくことにしました。 データベース Aurora serverless v2 Kubernetes HPA（Horizontal Pod Autoscaler）
21. © ASOVIEW Inc. 21 AuroraをServerlessに切り替えた時のコスト比較 単純化のためプロビジョニングの CPU利用率が、大体ACUと同じとして比較 Aurora Mysql db.r6g.8xlarge 損益分岐点 （CPU利用率平均） プロビジョニング $5.01 19.58% RI(1年前払い) $2.79 10.88% RI(3年前払い) $1.87 7.31% Serverless $25.60 （128ACU時の価格） • CPU利用率が常に２０％以上ならプロビジョニングの方が有利 • CPU利用率が常に１０％が1年以上継続する見込みならプロビジョニン グRIの方が有利 • CPU利用率が常に７％が３年以上継続する見込みならプロビジョニン グRIの方が有利 弊社の現状： 夜間と日中帯に２０％以内にする前提。夜間のアクセスは少ないので、平均する と、１０％以内におさまりそう。 繁忙期（GWや夏休み）には、負荷がさらに上乗せされるので、その期間だけ、ス ペックを変更するというオペレーションもそこそこ運用負荷になる。 ⇨Serverlessに変更することにより、 Aurora Mysqlのコストの最適化を行う指針にす る。 ※サーバレスに変更すると利用メモリが減るという副 作用はあり、実際には、この点も考慮して選定する必 要があります。ここらへんのお話を、弊社テックブログ にも近日中に公開予定！！
22. © ASOVIEW Inc. 22 参考）実際のとある1日のDBの負荷推移 平均すると１０％をきっており、このような挙動では、 Serverlessの方が優位ではないかと判断。
23. © ASOVIEW Inc. 23 Podの数のHPAの導入 前述のPodの負荷基準をDatadogで取得して、それをkubernetesにExternal metricで取り込む。 目標の負荷量をキープするように Podの数を変動させることにより、余剰なリソースを抑えるようにしました。 詳細は、弊社のブログを参照 https://tech.asoview.co.jp/entry/2023/08/31/100000
24. © ASOVIEW Inc. 24 参考）実際のとある1日のPodの負荷率推移（Pod数固定化時） 5/3（繁忙期）の実績値 Podの数は２４時間一定（ 54台を常時起動）の 夜間帯は、利用率がすごく少なく、朝の１０時と夜中に上昇するみたいな動向。 夜は、チケットの販売の負荷、朝は、着件の負荷など負荷の内訳は異なっている。 ⇨前述の安定基準に従い、夜間の Pod数を減らすようにHPAを導入を実施する。
25. © ASOVIEW Inc. 25 参考）実際のとある1日のPodの負荷率推移（Pod数変動時） 8/12（繁忙期）の実績値 Podの数は２４時間変動（ 10~68台を負荷に応じて変動） 常に、負荷率が２０程度になるように Podの数を前述の仕組みで自動調整。 夜間帯は、Podの数が最低の１０で稼働ピーク時は、 68台で稼働 導入結果として、利用率が極端に小さい時間帯を減らすことができている。
26. © ASOVIEW Inc. 26 ここまでのまとめ 下記の順番で決めていく 1. 性能を測るための指標を決める 2. 目標の性能を出すために必要な、インフラのスペックを定める。 a. その際には、スケールアウトできないリソースに関しては、インフラのスペックの上限は気にしておく 3. スパイクを観測して、スパイク許容量を定める a. 許容量を超えるようなスパイクが来る場合には、それも検知できるような運⽤は⽤意しておく 4. これを守れるようにリソース計画を立てる。 a. ⾃動的に縮退できる仕組みは可能な限り⼊れる
27. © ASOVIEW Inc. 27 (参考)高負荷状態でも運用が継続できるような仕組みを考える ソリューション例 • 仮想待合室 • 流入制限（一定の割合のみトラフィックをとおす） • Rate -Limitの導入（負荷の偏りをなくす） 前述の通り、システムには、処理可能な上限があるためにそれを超えないようにするための仕組みを用意する必要があります。 弊社の場合には、購入処理というのは、内部的には、処理が複雑で、一定の数を超えると入場を制限する機能を設けていたりしています。 弊社の場合だと、特定のチケットに負荷が集中した時に、そのチケットだけ購入しずらいという状況にしないと、システムへの不満が広範囲 に及んでしまうことから特定のチケットのみ購入数を制限するなどの対応が必要になります。 この閾値は、負荷テストなどで、システムの負荷をシミュレーションした上で、調整して、処理性能を超えないように制限するというのが重要 になります。
28. © ASOVIEW Inc. 28 本日お話しすること 下記のような内容を話していこうと思っています。 1. 安定稼働する上での、余剰リソースを見つけていくための視点 a. アソビューにおける安定稼働をする上での余剰リソースの定義の仕⽅ b. 余剰リソースをどのような⼿法で削減していったか 2. （時間があれば）その他の最適化した手法の紹介 a. Kubernetesのリソースの使われ⽅を⾒てノードのインスタンスタイプを最 適化 b. Datadogの料⾦体系を⾒て、コストの最適化を実施 c. CircleCIの実⾏環境を意識して最適化する d. Cloud Native BuildpacksのBuildキャッシュの動きを⾒て最適化する
29. © ASOVIEW Inc. 29 KubernetesのDaemonSetのリソースとノードのインスタンスタイプを見る視点 (変更前)現在の状況を下記の視点でみてみるとこのような状況だった。 割り当て可能なCPU: 3.92 (AWSインスタンス上は、CPU4つのインスタンス) DaemonSet(各ノードに必ず配置されるPod) CPU request aws-node 25m ebs-csi-nod 30m datadog 0m argocd 0m fluentd-cloudwatch 100m kube-proxy 100m Deployment 上記の状況だと、主要 Pod Aはノードの1台しか配備できないと言う構図になってしまう。 CPU request 主要Pod A 2000m 主要Pod B 1000m 主要Pod C 2000m 主要Pod D 1000m
30. © ASOVIEW Inc. 30 KubernetesのDaemonSetのリソースとノードのインスタンスタイプを見る視点 (変更後)現在の状況を下記の視点でみてみるとこのような状況だった。 割り当て可能なCPU: 7.91 (AWSインスタンス上は、CPU4つのインスタンス) DaemonSet(各ノードに必ず配置されるPod) CPU request aws-node 25m ebs-csi-nod 30m datadog 0m argocd 0m fluentd-cloudwatch 100m kube-proxy 100m Deployment 上記の状況だと、主要 Pod Aはノードの3台まで配備できる構図になる。 つまり１つあたりのノードを倍にしたら３倍の Podが格納でき効率的になる。 CPU request 主要Pod A 2000m 主要Pod B 1000m 主要Pod C 2000m 主要Pod D 1000m ※１.1つのノードの同じPodが立ちすぎるとSpotインスタンスが終了した場合に、影響が大きくなるので、 topologySpreadConstraintsなどで 別途立つ数を調整する必要はあります。 ※２.Grpcを使っていると、デフォルトのスレッド数は、ノードの CPUの数に依存して決まる関係で、ここら辺もノードを増やすと、 Java側の DirectBufferなどは増加する傾向にあります。この点も必要に応じて調整は必要になるかもしれないです。
31. © ASOVIEW Inc. 31 Datadogの無料枠と監視対象を意識する視点 DatadogのAgentは、基本的には、デフォルトで全ての Podを監視対象にします。 １ホストあたり、無料枠という概念があるので、こちらを意識して最適化するのは大事かもしれません。 CPU request aws-node 25m ebs-csi-nod 30m datadog 0m argocd 0m fluentd-cloudwatch 100m kube-proxy 100m Datadog自身を除く、全てのコンテナは、監視対象になり、無料枠を 越えたコンテナは別料金になります。 対応方法：DD_CONTAINER_EXCLUDEを調整する。
32. © ASOVIEW Inc. 32 CircleCIのビルド場所とBuildイメージの格納場所を意識する視点 こちらは、CircleCIのBuildするためのイメージを自分で管理している場合に必要な視点です。 CircleCI のジョブ実行インフラストラクチャは us-east-1 リージョンにあることを意識して、イメージの場所を us-east-1に起きます。（こちら は、CircleCIのベストプラックティスにも書いています。） https://circleci.com/docs/ja/using-docker/ こちらによる効果： CircleCIの初期処理のオーバヘッドの削減：　３０〜６０秒＝＞数秒 ダウンロードにかかる通信コストの削減：月額 $5300くらいの削減
33. © ASOVIEW Inc. 33 Cloud Native BuildpacksのBuildキャッシュの動きを⾒て最適化する視点 まず、DatadogのMonitor機能を使って、Buildの速度の監視を行っています。 Cloud Native BuildpacksのCache機能を有効化していると、Buildを繰り返していくうちのこのCacheのイメージが大きくなりすぎて、こ のCache処理のオーバーヘッドがCacheの高速化を上回ってしまう、損益分岐点が存在します。
34. © ASOVIEW Inc. 34 最後に ご清聴いただきありがとうございました。 アソビュー株式会社では、一緒に働く仲間を募集しています！ 詳細は、「アソビュー　採用」まで https://hrmos.co/pages/asoview/jobs?jobType=FULL&category=1 365974533843193856,1615960404461129729