DB起因のメンテナンスに対する取り組み

TVerのSREチームでインフラ周りを担当しています西尾です。前回に続き、今回はWEBサービスを運用する者にとって避けられない永遠の課題であるメンテナンスについて書いていこうかと思います。

メンテナンス時間について

WEBでサービスを提供するにあたって、その構成されるアーキテクチャーがオンプレやクラウドに限らずハードウェアに起因するもの、セキュリティ的な問題に対処するものなどにより、どうしてもその対応でサービスを止める必要がある場面に出くわす事があります。無論オンプレより利用するクラウドサービスによってはあるサービスはフルマネージドにより利用者が意識しないでその対応が行われるものも存在します。ただ今回に関しては私達のようなインフラ運用に責任を持つ者が、メンテナンスを必要とする事案にどの様な対応を取れるのかを考えていきたいと思います。まずは具体的にサービスに影響を与えるような作業に対して、メンテナンス時間を取れるのか？若しくは取れない場合どのような選択があるのかを見ていくことにします。

サービス時間の定義 - WEBサービス 0:00-24:00

以上、WEBサービスに関しては常に動かしているので提供時間は24時間365日になります。ただこれでは話が進まなくなりますので、TVerのサービスである配信種別にフォーカスしていくことにします。

動画配信種類

VOD - TVer内で見逃し配信と呼ばれるコンテンツ、配信期間内であれば常時視聴可能。
RealTime配信 - 地上波の放送と連動し、地上波の放送開始時間と同じタイミングで視聴可能となるコンテンツ。
SpecialLive - 特別なコンテンツ、スポーツイベントなどのリアルタイム配信など。RealTimeと違い、TVer独占など地上波の放送時間に縛られないコンテンツ。

VODなどはいつでも視聴出来るのでカバーすべき時間は24時間ではありますが、他の２つにつきましてはゴールデンタイムなどある程度対象となるコンテンツ、提供時間は絞れます。

*ただし24時間ニュースなど常にSpecialLiveで配信しているコンテンツは存在します。

メンテナンス実施すべき時間の定義

視聴ユーザーが少ない時間 - 顧客の満足要件
RealTime配信/SpecialLiveが放映されていない時間帯 - サービス提供要件
定期バッチやBackupなどが行われていない時間帯 - システム要件

考慮すべきは、視聴するユーザーへの影響が一番少ない時間帯であることは間違いないので、この時間帯を導き出しメンテナンスの作業時間にするのが適切になるかと思われます。ではその時間をメンテナンス時間として前もってアナウンスする事によって作業を実施出来るでしょうか？

*AWSのサービスを利用していればmaintenance windowを設定出来るものがあります。これに関してはTVerでも設定しておりパフォーマンス影響が僅かであると想定していますので、サービスの利用者が少ない時間を前もって指定を行っています。

サービス影響の縮小を目指す

メンテナンス時間を取れるサービスであれば、上記のようにユーザー影響が少ない時間に実施することになるでしょう。ただTVerに関しましては、特にSLOなどは公表していませんが実質メンテナンス時間無しのダウンタイム0のサービス提供を目標にしております。そのためメンテナンスを必要とする対応に関しては、サービス影響を与えにくい時間かつそれをサービス提供の裏で人知れず完遂する必要があります。これを実現するためにどのような対応を取ったか、具体的につい最近ありましたAmazon Auroraのバージョンアップ対応について取り上げていきます。

サービス影響の洗い出し

最初に取り組むべき内容は、DBのバージョンアップ時に発生する僅かなダウンタイムがサービスにどの程度影響を与えるかの確認でした。

*補足 Amazon Auroraのバージョンアップに関してはブルー/グリーンデプロイの機能で今回実施していまして、ここで取り上げているダウンタイムとはそのグリーンからのスイッチで発生する接続断の時間のことになります。切り替えは通常1分以内で完了すると公式ドキュメントには記載されていましたが、2年程前に実施した時に3分ほどTVer環境では時間がかかりましたので、今回は安全マージンを取って5分程度影響を与える想定で作業を進めることにしました。

このサービス影響の特定にあたり、開発チームを含めて何度かDev環境でDBがダウンした時の挙動の洗い出しを行う事になりました。ただこれが思いの外大変で、ユーザーが利用する端末の種別により呼ばれるAPIエンドポイントなども違い、かつ画面遷移のフローやエラーの挙動も異なりDBに繋がらない事象は全て共通なのに最終的な影響は各々の端末で微妙に異なる結果になりました。そのため今回は全ての機能を救うことはできない前提で、再生までの動線が最低限担保されている状態まで持っていき動作確認をすることにしました。すなわち、TVerのHomeと番組詳細、再生がDBが落ちていた場合にどうなっているかという点にフォーカスして調査したことになります。

DBダウンタイムの影響

端末	Home画面の表示	番組詳細	再生ボタン(クリック時)	番組視聴中
端末A	エラー	エラー	エラー	正常（エラーなし）
端末B	エラー	エラー	エラー	正常（エラーなし）
端末C	エラー	エラー	エラー	正常（エラーなし）

対応策

上記の表のように何も対応策を取らなければサービスをまともに提供できない状態になる事がわかりました。そのため今回はとりあえずDBが呼ばれるAPIのエンドポイントとそうでないものを分けて考え、前者に関しては特に対応が必要になるため以下の方法を対応策として実施しました。

APIエンドポイント(DBアクセス必要)

CDN側でCacheする時間を伸ばす(TTL)
DBアクセスを伴わない、重要コンテンツを静的に返すAPI（以下 Dummy API）の用意

APIエンドポイント(DBアクセス不要)

DBアクセスがないエンドポイントに関しては、通常のルーティングを実施

dummy APIに関しては、DBアクセスが必要なパスに関してはとりあえず静的なものでもいいので通常時に構成されるコンテンツをjsonで返すサービスをECS(fargate)で作り、ALBでそれの振り分けを実施しました。上記の対応により、一部の端末に関してはDBが落ちている状態でも一見問題なくサービスが提供されているように見えるとこまではなんとか持っていくことができました。ただ一部と言った通り、この対応によってもサービス影響がまだクリティカルな箇所もあり、それに関しては抜本的な対策が必要な事がわかりましたので残念ながら今回は諦めることにしました。

DBダウンタイムの最小化施策を行った場合

端末	Home画面の表示	番組詳細	再生ボタン(クリック時)	番組視聴中
端末A	正常（エラーなし）	正常（エラーなし）	正常（エラーなし）	正常（エラーなし）
端末B	正常（エラーなし）	エラー	エラー	正常（エラーなし）
端末C	正常（エラーなし）	部分的にOK	部分的にOK	正常（エラーなし）
端末D	エラー	機能なし	エラー	正常（エラーなし）

TVerに関してはWEB(PC)やiOS、Android、CTV (コネクテッドTV)などで視聴可能になります。バックエンドのAPIに関しては共通の部分が多いですが、実際のユーザーがアクセスする画面のフロント部分に関しては各環境毎の開発チームが存在し、各々の実装になっている箇所が少なからず存在しています。そのため実装面の差異、また端末OS側の制約によって同じ事象でもユーザー側から見える挙動の違いとして現れることになりました。

メンテナンス作業

メンテナンス日は上記の対応のほかに、バッチ処理が動いているものがあったのでそれの停止と再実行などの作業もありなかなか慌ただしい中で行いました。

上記のメトリクスから分かるように作業時にエラーに関してはその数が跳ね上がっていました。そして少なからずサービスを利用されているユーザーに影響を与えていることも確認できましたが、当初の想定よりはその範囲は少ないと個人的には感じました。

目指すべき先

本心を言えばメンテナンス時間は欲しいですし、なんならDBに関してもフルマネージドなDBを利用して全くメンテナンスを意識しないで過ごせればどんなに楽かと憧れてはいます。ただそれを言ったら話が進まないので、現在の構成の中でこの箇所がダウンしたらどのような影響を与え、それに対してどの様に対応すればサービス影響を抑えることになるか知ることが大切でした。サービス提供の最初から全てに関わっていればそこら辺の勘所はなんとなくわかりそうな気もしますが、実際サービスを長く運用していると関わってくる関係者の数も増え、システム側も複雑になりどの箇所が全体にどの程度影響与えるか不明な部分が存在するのはある意味避けられないかと思われます。そのため、今回のDB対応に関しては己のサービスを知る一歩となり各チームの開発者も共通認識を持つことができたのでなかなか有益なものになりました。本来であればカオスエンジニアリングを定期的に実施し、課題を炙り出しそれに対して日常的に向き合って対応するのが望ましいと思いますが、いかんせんどのサービスでも同じことだと思いますが新規の機能追加などに目が向きがちになり既存機能に関してはおざなりになっていました。インフラ側としては、新規サービスの追加構築以外に既存サービスの改善を開発者側にフィードバックできる仕組みを整え、問題を具体的に捉えれる様に貢献できれば少しは優先度が上がりサービス品質の向上に寄与できるかと思っています。そのためTVerサービスを支えていただける方SRE業務を幅広く求めています。