Migration to a Better Datastoreの要点メモ・その１

appengine blogにポストされたMigration to a Better Datastoreの要点をピックアップしてみました。間違い等ありましたらご指摘ください！

• Googleは「マルチホーミング」を追求している
  • データセンター単位でのダウンに対応する
  • リードオンリータイプのアプリなら簡単だが、Gmail/Calendar/App Engineのようなリアルタイムに読み書きのあるアプリでは難しい

• 現在のApp Engineにおけるマルチホーミングの仕組み
  • Datastoreサービスは個々のアプリについて1つのデータセンターで提供
  • Bigtableの（訳注：その下のGFSの？）レプリケーション機能により、データはデータセンターAからデータセンターBにバックグラウンドでレプリケーションされる
  • （データセンター規模の障害やメンテによる）データセンターの切り替え時の動作
    • AのDatastoreのリードオンリーモードに切り替え
    • AからBへのレプリケーションが終わるのを待つ
    • Bにてリード／ライトモードを開始する
  • この仕組みは通常はうまく動くが、AとB双方のBigtableセルがhealthyなこと（問題なく動作していること）が前提

• 7月のDatastoreダウンの原因
  • Google内で共有されているGFSセル（なにこれ？）で深刻な障害が発生、復旧に時間を要した
    • GFSセルは強力なサービスだが障害時には利用サービスすべてに影響する
  • 上記例で言うと、Aがunhealthyな状態であり、切り替えにデータセンター間切り替えに問題が生じる
    • AからBへのレプリケーションにはわずかな時間差があり、切り替え前にすべてのコピーが終わるのを待つ必要がある
    • しかしAで障害が起きていると、データの取得に長い時間がかかる。よってAのBigtableがある程度復旧してコピー可能になるまで待たなければならない
    • 今回は、Aがいつ復旧するか見込みが立たなかった
  • もっとすばやく切り替える方法はないか？ Aの復旧を待たずにBに切り替えたい
    • ほとんどのデータはAからBにコピー済みだが、わずかなデータが失われてしまう
    • Aの復旧後はすでにBが読み書きされており、Aのデータを戻すことはできない
    • Bigtableの行単位のCRUDはトランザクショナルだが、レプリケーションはカラム単位で実施
      • 途中でBに切り替えると、行内の整合性が失われる可能性がある
      • そのため、7/2の障害時にはBへの切り替えに時間を要した

（後半につづく）