公式note2023年5月に入社し3ヶ月ほどホロプラスのパフォーマンスチューニングや開発環境の整備をしてきましたので、今回はそちらについてご説明します。ホロプラスとは?ホロプラスは「推しをもっと好きになる!」がコンセプトの、ホロライブプロダクション公式アプリです。先日8月29日に正式リリースされました。以下の二つの体験を提供します。V2を使用しています。ホロプラスの課題ホロプラスのアプリやその開発には2つの大きな課題がありました。Test)をおこない、事前登録いただいた約1.1万人のみなさまに使っていただきました。そのCBTでの大きな課題の一つがシステムのパフォーマンスです。percentileで4秒程度ととてつもない値を示していました。これに対してコストをかけたインフラの増強や機能制限によってなんとかしのいでいる状況でした。そのためインフラの料金が高額になっていました。当時はホロプラスのチームにSREがおらず、開発環境に課題を抱えていました。CI/CDが十分に整備されておらずデプロイが手動で行われているAPIのリリースのために常にメンテナンスを入れる必要がある監視の自動化が足りておらずエンジニアの監視コストが高いソフトウェアテストが動いていない分散負荷試験環境がないパフォーマンスの改善パフォーマンスの課題についておこなった改善をご説明します。私が入社時点で当初予定されていたリリース日が差し迫っていました。クローズドテスト開始前の想定よりもパフォーマンス改善に対する課題が根深く、正式リリースの規模に耐えうるパフォーマンス改善の目処が立っていない状態でした。パフォーマンスについてどのような状態になっていればリリース可能かというリリース判定基準を定めました。Objective)とコストの目標値を設定しました。SLOSLOはレイテンシや可用性といった測定値に対して、外部からシステムに対して期待されるものとして設定された目標値です。SLI.引用元:GoogleSLOはレイテンシと可用性について一般的な目標値を設定しました。・可用性CUJにおけるAPIの可用性が99%CUJはユーザにとって重要な体験を指します。ホロプラスではCUJを以下のように定めました。投稿へのいいね料金インフラの料金の目標は、シンプルな性能検証を行った際に必要な料金をもとに概算しました。V2を使用していますが、その料金の目標は下記の記事を参考にさせていただきました。engineering.dena.com記事の内容から10,000QPSさばくには少なくとも16ACUは必要なので、それにバッファをもたせて目標としました。パフォーマンスチューニング次に実際におこなったパフォーマンスチューニングをご説明します。V2のCPU使用率が100%に張り付いており、これがボトルネックであることはわかっていました。Insightsで高負荷のクエリを特定してひたすらインデックスを貼りました。以下のようなアプリケーションロジックの修正もおこないました。大きなテーブル間のJOINの削減その過程で、使用していたORMのbunに修正を入れてそれが取り込まれました。percentileで4秒から1.5秒程度まで下げることができました。Provisionedへの移行の検討レイテンシを1.5秒まで下げることはできましたが、まだ目標には届いていません。V2からProvisionedへ移行し、コストパフォーマンスを上げることを検討しました。結論としては移行しませんでしたが検討内容をご説明します。V2のライターをProvisionedに替えるご提案を頂きました。V2のライターを強制フェイルオーバーさせます。これにより、Provisionedのリーダーがライターに昇格します。Multi-Masterでライターの可用性を高めることを検討する必要があります。みなさん、こんにちは。ジャパン、シニアエバンジェリストの亀田です。percentileが100〜200msに改善したため移行は保留しました。アプリケーションの設計変更Provisionedへの移行と並行して進めたアプリケーションの設計変更についてご説明します。Insightsを確認したところ以下のクエリがDBに大きな負荷をかけていました。クエリ内のテーブル名やカラム名は仮のものです。10ホロプラスの投稿一覧における投稿毎のいいね数を取得するものです。BYによってDBに負荷がかかっているため、いいね数の集計を非同期処理に移しました。いいねを押すとSQSにイベントがキューイングされ、時間経過かイベント数がある程度たまったら、Lambdaでいいね数の総数を集計してDBに書き込まれるようになっています。BYを使う必要がなくなり、DBへの負荷が改善されました。10以上の改善でリリース判定基準のSLOを達成し、料金においても当初の1/3まで下げ、目標を達成することができました。開発環境の改善CI/CD私がチームに入った当初はECSへのデプロイやCDKのデプロイが自動化されていませんでした。そんな中リリース日は迫っており他にもやるべきことは多くあったため、理想形は意識しつつもリッチなパイプラインはつくらず、とにかく使えるものを早くつくることを意識しました。Actionsはこのようになっています。Updateしています。デプロイの前にDBのマイグレーションやマスタデータの投入をおこなう必要があります。Definitionでマイグレーションのコマンドを実行するTaskを起動しています。Blue/Greenデプロイなどはできていませんが、短い実装時間でデプロイを自動化することができました。APIのリリース時に毎回メンテナンスを入れていたオペレーションもなくなりました。監視がほとんどなかったため以下の監視をDatadogで作成しました。SLOのレイテンシ、可用性におけるエラーバジェット、バーンレートの監視APIの外形監視ALBでの死活監視、5xxエラー監視ECSのCPU、メモリー監視RDSのACU使用率、CPU、メモリー監視ElastiCacheのCPU、メモリー、キャッシュヒット率、レプリケーションラグ監視また異常に至る傾向を確認できるように主要なメトリクスを集めたダッシュボードを作成しました。その他の改善その他にもGoのソフトウェアテストが動いていなかったため、CIでテストを動かすようにしてテストを書く習慣を取り戻しました。AWSを使うことにしました。AWSは扱いやすく負荷試験を回す速度は向上しました。まとめ今回はホロプラスにおけるパフォーマンスチューニングや開発環境の整備についてご説明しました。パフォーマンスや開発環境の改善に興味のある皆さまの参考になれば幸いです。こちらの改善内容について原因究明から設計、対策の主導をおこないましたが、実装などはチームの方々に多くのサポートをいただきました。AWSの方々にもオフィスアワーなどでご支援をいただきました。この場をかりて感謝を申し上げます。最後までご覧いただきありがとうございました。カバー株式会社ではエンジニアを積極採用しております。こちらの記事を読んで気になっていただけましたら、以下リンクよりご応募をお願いいたします。公式noteフォローこんにちは。世界が愛するカルチャーを。