SHOWROOMインフラのマネージドサービス移行
こんにちは。SHOWROOM事業本部開発部テクノロジーソリューショングループの中村です。
今回ライブ配信サービス「SHOWROOM」のインフラのマネージドサービス移行が様々な制限・仕様に翻弄されつつも一通り完了したので知見を共有したいと思います。
SHOWROOMインフラの背景
SHOWROOMは株式会社ディー・エヌ・エー（以下DeNA）の一事業としてスタートし（その後SHOWROOM株式会社として分社化）、インフラは当初DeNAのオンプレミス環境及びDeNAのインフラ関連ツールセットを利用していました。
その後DeNAのオンプレミス環境廃止に伴いSHOWROOMもサーバーをAWSへ移行しました。
しかしこの際の移行はEC2への置き換えが中心であり、AWSのメリットをあまり享受できておらず、この状態ではSHOWROOMにおいてはインフラコストや運用負担の大きさ、将来的なインフラ関連ツールセットの保守などに課題がありました。
そこでマネージドサービスの活用を中心としたAWS環境への最適化が本プロジェクトの目標でした。
SHOWROOMインフラに要求される負荷耐性
SHOWROOMへのHTTPSリクエスト数は標準的な日で日間約2億リクエスト（HLSによる映像配信やCDNを経由した画像配信は除いた数値）に上り、さらにサービスの特性上配信開始が集中するピーク時間帯の毎時0分などに負荷がスパイクする傾向があるため、それを想定して設計する必要があります。
加えて事業特定上、平時の範囲を大幅に超える負荷が想定される大型案件に対しても短い準備期間で対応できることが要求されます。
（過去にあった大型案件としては 乃木坂46 幻の２期生ライブ@ SHOWROOM や 星井美希初SHOWROOM配信 などがありました。）
以上から詳しくは後述しますが多くの場合問題にならず話題に登らないような制限がSHOWROOMの場合問題になることがありました。
各コンポーネント移行の課題と対応
OpenSearch Service
EC2上で動作させていたElasticSearchからの移行です。
SHOWROOMではElasticSearchについてはあまり高負荷な利用はしていないこと、EC2上で利用していたElasticSearch互換のバージョンを選択したことから特に問題なく移行できました。
Route53
EC2上で動作させていたMyDNS ( MySQLプロトコルで名前解決を行う仕組み ) からの移行です。
Route53の移行においては、「EC2インスタンスがAmazon提供DNSサーバーに送信できるパケットは1秒1024パケットまで」という制限があり、こちらが問題となりました。
AWSから案内されている対応策としてdnsmsqなどのDNSキャッシュサーバーをインスタンスに導入することが挙げられています。しかしSHOWROOMの場合導入してもなお制限にかかってしまったため対応策として（本来責任分解点を考えると適切ではないとの意見が社内でもありましたがやむを得ず）アプリケーションの側でDNSキャッシュを行うことで解決しました。
ElastiCache for Memcached
EC2上で動作させていたmemcachedからの移行です。
ElastiCacheへの移行では、時間当たりの新規接続数が一定以上の値になると接続エラーが頻発する、スループットがドキュメント記載よりも低い値で頭打ちになるという問題がありました。
新規接続数については、従来環境ではwebリクエスト単位で接続を開始し終了していたものを接続を使い回すようにアプリケーションを変更し新規接続数を大幅に削減し対応しました。
スループットについての問題は長時間の負荷試験にて余裕を持って必要な性能が出せることを確認したインスタンスタイプ・台数を選択することで対応しました。
SQS, DynamoDB
EC2上で動作させていたQ4M ( MySQLをキューとして利用できるストレージエンジン ）からの移行です。
キュー自体はSQSへの移行ですが、キューに対する処理が冪等になっていない箇所が多くあったため、重複処理を防ぐための処理にDynamoDBを利用しました。なお重複処理を防ぐ方法としてSQS FIFOキューを使うという手段もありますが、移行当時のFIFOキューでは秒間のTPS数の上限が問題となったためSQS標準キューを利用しています。
SQS, DynamoDB共にNAT GatewayでErrorPortAllocationが増え接続エラーになる問題がありましたが、VPC Endpointを利用しSQSやDynamoDBへのアクセスがNAT Gatewayを経由しないようにすることで解消しました。
当初：(VPC内のアプリケーション)-(NAT Gateway)-(グローバルのEndpoint)-(SQS/DynamoDB)
改良後: (VPC内のアプリケーション)-(VPC Endpoint)-(SQS/DynamoDB)
またDynamoDBでテーブル作成後最初の負荷で500エラーが頻発する問題がありましたが、AWSサポートに問い合わせたところパーティション分割が発生した際に500エラーの割合が増えるとのことでした。
前述のようにスパイクが多い負荷特性を考慮しオンデマンドキャパシティでの利用を想定していましたが、本番投入前に一度大きなキャパシティをプロビジョンしパーティション分割を発生させた後にオンデマンドキャパシティに変更し利用することで対応しました。
なおかつてはDynamoDBのパーティションが過度に分割されてしまうことによる問題がありましたが、現在はadaptive capacity機能により解消されたので同様の問題は発生しません。
Aurora2 for MySQL
EC2上で動作させていたMySQL5.6.20からの移行です。
Aurora2自体では大きな問題は発生しなかったのですが、DB移行のための作業で以下の問題が発生しました。
過去の障害対応の反省から万が一切り戻しとなった場合にも長期間の予定外停止やロールバックといった事態となることを防ぐため、移行後Aurora2→MySQL5.6.20のレプリケーションをしばらく行うこととしていました。しかしこの箇所で、MySQL5.7(及びその互換であるAurora2)からMySQL5.6.20へのレプリケーションは2つのバグ( #74683 と #75772 )によりエラーで停止してしまったり、エラーは出ないがレプリケーションされなかったりするという問題があることがわかりました。
移行時点でMySQL5.6系最新版であったMySQL5.6.51ではこれらのバグは修正されていたため、Aurora2→MySQL5.6.51→MySQL5.6.20 という2段階のレプリケーションを行うことで解決しました。
その他課題と対応
Botや外部ツール利用者が想定より多かった
負荷試験では想定される負荷より大幅に高い負荷を想定したシナリオで行ったにもかかわらず、リリース後の本番負荷が負荷試験を上回る箇所がありました。
調査の結果Botや外部ツール利用者が想定よりも多くそれらの影響で負荷が想定よりも高いことがわかりました。その後の負荷試験ではBotや外部ツールを想定した負荷を加えるとともに、特に負荷上問題となるBotや外部ツールに対しては正規のユーザーにできるだけ迷惑をかけない範囲で対策を行いました。
終わりに
今回の移行において廃止することになった旧環境ですが、移行作業においても技術力の高さに改めて驚かされることが何度もありました。
移行完了までSHOWROOMを支えてくれたことに感謝したいと思います。
そして今後利用し続けることになるAWSの各種マネージドサービスのさらなる改善にも期待したいと思います。
SHOWROOMインフラのマネージドサービス移行は一区切りしましたが、まだまだインフラ面で改善すべき課題も多く残されています。また現在ほとんどがPerlで書かれているSHOWROOMのサーバーアプリケーションのGo言語への移行プロジェクトも進行中です。
ご興味持たれた方は以下の求人情報をあわせてご参照いただけますと幸いです。
SHOWROOM株式会社では、エンジニア職を絶賛募集中です。
・ライブ配信サービス「SHOWROOM」
・バーティカルシアターアプリ「smash.」
以下の求人内容をご確認の上、ご興味あればご応募ください。
心よりご応募お待ちしております。
■求人は以下になります
SHOWROOM株式会社採用情報
■その他SHOWROOM株式会社の情報
・ note（代表前田取材記事です！）
・ 社員インタビュー記事
・ SHOWROOM
・ smash.
・ SHOWROOM最新記事一覧（PRTimes）
参考情報
Route53のパケット上限について
Memcacheについて
他社様が同様の問題に遭遇した事例として以下がありました。
DynamoDBについて
MySQL5.7→5.6のレプリケーションについて
この記事が気に入ったらサポートをしてみませんか？