Netflixの運用データ移行におけるレジエンス構築 - Sangeeta Handa氏のQCon SFでの講演より

米国ベイエリアで開催されたQCon San Franciscoで、Sangeeta Handa氏が、多岐のユースケースにわたる運用環境の移行においてレジエンスを確立したNetflixでの経験から得た教訓について講演した。主な教訓は次のとおりだ – マイグレーションにおいても知覚上ないし実際のゼロダウンタイムを目標とすること。信頼構築のため早期のフィードバックループに投資すること。顧客のインタラクションをサービスから切り離す手段を見つけること。自動データ比較および照合を使用して独立的なチェックとバランスを構築すること。

Netflixで料金請求インフラストラクチャのエンジニアリングマネージャを務めるHanda氏の講演は、データ損失やデータ重複、データ破損など、データ移行には機能や運用要件の変更に伴ういくつかの既知のリスクがある、という議論から始まった。これらのリスクは、移行中の予期しないシステム動作、移行後のパフォーマンス低下、あるいは予期しないダウンタイムにつながる可能性がある。このような結果は、すべてが顧客に悪影響を及ぼすため、移行計画においては、これらの問題を軽減するための明示的な試みを行う必要がある。

地理的に分散した大規模な顧客ベースでは、いかなるメンテナンス手順でもシステムを完全にオフラインにすることはできない。従って“ゼロダウンタイム”マイグレーションは実行可能な唯一の変更手段である。Netflixチームがマイグレーションで使用したのはこのアプローチの亜種で、“知覚上”ゼロダウンタイム、“実際に”ゼロダウンタイム、状態移行なし、という3つのデータを含むものだ。Handa氏は講演で、これらのアプローチを実践した3つのユースケースについて説明した。

最初に論じたユースケースは、料金請求アプリケーションインフラストラクチャ内の移行である。このアプリケーションは定期購読を処理し、請求履歴のプレビューの閲覧を可能にするなど、多くの請求関連の機能を提供している。Netflixの1億3000万人を超える加入者は世界中に分散しているため、料金請求インフラストラクチャは24時間365日使用されている。従って、移行中のダウンタイムは許されない。この最初のユースケースで計画されたのは、基盤であるデータストレージオペレーティングシステムとデータベースを、Netflixデータセンタで運用されているOracleシステムから、AWSクラウド内で動作するMySQLサービスに移行することだった。マイグレーションの対象は数十億行で8TBを越え、データは絶えず更新されている。

データのスナップショットと再ロードによる最初の試験、およびApache Sqoopを利用した試験は、無駄であると判明した。最終的に採用されたのは、日常のワークロードの一部として行われる運用上の読み書きと並行して、テーブルからテーブルにレコードレベルでデータをコピーする、“知覚上ゼロダウンタイム”の移行アプローチだ。このアプローチでは、移行を任意の時点で一時停止することと、失敗を(ビジネス)レコードのレベルで捉えることが可能になる。新たなターゲットデータベースを唯一の情報源として完全に切り換える前に、ソースとターゲットデータベースからの日毎の自動スナップショットを比較し、行数をチェックし、ターゲットデータベースでテストワークロードとレポートを実行することによって、移行のレジエンスに対する信頼性を確立した。

“最終的な切り替え”の間は、アプリケーションの書き込みを継続する前に、新しいターゲットであるMySQLデータベースをソースデータベースに完全に同期する必要があり、結果として実際のダウンタイムが発生する。しかしチームは、同期プロセスの実行中も新たなMySQLデータベースへの読み取り専用アクセスを許可し、(AWS SQS)キュー内で書き込みをバッファリングすることで、知覚上のゼロダウンタイムを実現した。切り替え後にデータベースの状態が同期されると同時に、キューの内容がアプリケーションに再実行され、結果的に適切な書き込みが新たなターゲットデータベースに対して実行された。

次に説明されたユースケースは、バランスサービスの書き換えである。これにはCassandraデータベースからMySQLデータベースへの、比較的単純な構造の少量のデータを移行する作業が含まれていた。この移行は、該当サービスのクエリ特性に対して、MySQLがより適しているために実施された。

この移行は、アプリケーションサービスと基盤データベースとの間のデータアクセスレイヤとして“データインテグレータ”サービスを最初に作成し、プライマリのCassandraインスタンスから新しいMySQLデータストアへの書き込みを効果的にシャドーすることで達成された。データインテグレータはまた、2つの書き込み間の予期しない結果やデータのミスマッチに基づいたメトリクスを報告する役割も担っていた。

移行プロセスの第2部では、通常のCassandraスナップショットからMySQLへ、非同期なデータ“ハイドレーション”が行われた。データインテグレータはMySQLからのデータ読み込みを試行し、もしデータが移行されていなければ(依然として正式データである)Cassandraにフォールバックする。書き込みについては、両データストアへのシャドーを継続する。予期しない問題の基準がここでも適用され、データストア間での定期的な比較と調整が実施される。矛盾のあるデータはすべて、CassandraからMySQLに再移行された。ひとつでも問題のあるMySQL内の顧客データは、完全に書き換えられた。

このハイドレートとシャドー、そして比較というプロセスは、必要とされる正確さへの信頼性に到達するまで継続された。この移行での“最後の切り替え”は、単にデータインテグレータ内の正式データをMySQLに変更して、基盤にあるCassandraデータストアを削除すればよかった。

講演で論じられた最後の移行ユースケースは、Netflixの請求システムを書き換えることだった。これには、まったく新しい機能のパスと、それに対応して、同じく新しいデータストアを必要とするサービスの作成が必要であった。この既存の請求書データセットは非常に規模が大きく、変更率も高かった。計画されたのは、請求書発行機能を利用する顧客に影響を与えることなく、既存のMySQLデータベースから新たなCassandraインスタンスにデータを移動するという方法だ。

分析と何回かの設計議論を重ねた結果、今回の移行では、対象となるデータそれ自体を“移行”する必要はない、という認識に達した。そこで新しいCassandraデータベースを使用して新たなサービスを構築し、“従来の”サービスおよびデータストアと並行して運用する、という決定が下された。2つのサービスの前に“請求ゲートウェイ”を配置することで、顧客の請求データが移行されたかどうかに基づいて、どちらの請求サービスを呼び出すかをプログラム的に決定できるようにした。

Handa氏と氏のチームは、データの小さなサブセットを旧システムから新システムに段階的に移行する(小さな国の全ユーザの請求データをコピーする、というように)ことで、新サービスを“カナリアリリース”した。2つのサービス間で書き込みがシャドーイングされ、結果がデータストアのレベルで比較および調整されるという“シャドーモード”によるテストで、移行のレジエンスに対する信頼性が高められた。予期しない動作や状態の存在を捉えるためには、広範囲な監視とアラート処理が使用された。実際のデータ“移行”は、通常の請求機能の運用の一環として1年以上かけて実施されたが、ダウンタイムはゼロで、顧客に影響を与えることはなかった。

講演のまとめとしてHanda氏は、氏のチームが得た教訓を公開した – データマイグレーションにおいてもゼロダウンタイムを目標とすること、信頼構築のため早期のフィードバックループに投資すること、顧客のインタラクションをサービスから切り離す手段を見つけること、自動データ照合を通じて独立的なチェックとバランスを構築すること、カナリアリリースで機能を“小さくロールアウトし、学び、繰り返す”こと。

Sangeeta Handa氏のQCon SFでの講演で使用されたスライド“Building Resilience in Netflix Production Migrations”(PDF)が、カンファレンスのWebサイトで公開されている。ビデオ記録は数ヶ月内にInfoQで公開される予定だ。