hbstudy第7回「システムの命綱、バックアップ(仮)、Google App Engineの勘どころ」へ行ってきた

Event

土曜の夜、株式会社ハートビーツさん主催のインフラエンジニア勉強会へ行ってきました。

今回のテーマは「システムの命綱、バックアップ(仮)、Google App Engineの勘どころ」…なのですが、じつは、当日まで「GAE上のシステムのバックアップ」の勉強会だと自分はカン違いしてました。GAEとバックアップは別々の話題だったんですね。

どちらも濃いお話が聞けて、楽しかったです。というわけで、備忘のためにメモをアップしておきます。

Google App Engineの勘どころ（柴田淳さん）

GAE事例紹介

これらのシステムは、すべてGAE上で動いている。

GAEはPaaS

PaaSとは何か。PaaSは、IaaSとSaaSの間に位置する。IaaSと同じくインフラは提供されているが、SaaSのようなビジネスロジックは持たないのが、PaaSである。

# IaaSとPaaSの違いを聞き逃したので補完・・・Linux によるクラウド・コンピューティング

GAEの特徴

特長の一つは、運用が手軽なこと。サーバセットアップをはじめとする低レイヤの運用が不要である（ただし、監視は必要）。修正を反映するデプロイの手順もカンタン。

特長のもう一つは、スケーラブルであること。このことは、GAEがKVSを使っていること、冗長化の仕組みを内蔵していること、負荷に合わせて自動でスケールアウトすることによって、実現されている。

GAEの勘所
  • DataStore
    • リレーションを使った設計に不向き
    • アンチ正規化
    • SQLに慣れた人のためにGQLがあるが、あくまでも簡易問い合わせ言語に過ぎない

Joinがない。これは、データが増えたり、インデックスが汚れたりしていくと、Joinがボトルネックになるため。単一クエリを高速に実行することが、スケーラブルなシステムを実現する。

Serial型がない。これは、テーブルのロックがボトルネックになりがちなため。ロックのかかる部分を分散して、ロックの機会を最小にすることが、スケーラブルなシステムを実現する。

  • RDBMSとDataStore
    • RDBMSは、1つのデータベースに押しつけるイメージ
    • DataStoreは、沢山のデータベースを使うイメージ

いまのマルチコアのマシンでも、CPUを100%使い切ることはむずかしい。チープなマシンを大量に使うことが、スケーラブルなシステムを実現する。

このことは、GAEのサービス提供価格表からも見てとれる。高価なのは、CPU > ネットワーク帯域 > データサイズの順。CPUは進歩が鈍化しており、ネットワークの帯域はかんたんに増やせない。CPUリソースの不足をハードウェアのサイズでサポートできるのであれば、シングルコアマシンを並べて処理した方が、効率がよい。

  • 非RDBMS
    • ObjectStore（オブジェクトDB）
      • 例：Amazonでも使われている
    • Cache
      • 例：医療分野のXMLデータなど
  • Pythonオススメだよーという話
    • 言語の設計がシンプル。例：予約語は31個（c.f. Perlだと220個ある）
    • Googleで断りなく使ってよい言語の3つのうちの1つ。残り2つは、C++とJava。
    • Googleでは2002年頃から使われている。Googleのコードの30%がPythonといわれる。
      • 例：Youtube、Google Group、アカウント取得時のシステム
    • この1年半で、Pythonを使うプログラマは世界で45%増えた。GAEの影響といわれている。
GAEの利点・欠点

利点。

  • Googleが運用するサービスと同じベースのインフラを使える。
  • スケーラブルなWebサイトを作るための費用対高価が高い。
    • facebookアプリやmixiアプリに使われることがある
    • 開発コスト、運用コストを抑えられる
    • 大量のアクセスを集めるアプリに向く
  • 運用が手軽
    • 開発環境でテストもちゃんとできる

欠点。

  • 非RDBMS
    • RDBMSの習慣が使えない
      • ユニーク属性、Serial型の機能がない
      • トランザクションをまとめるためにがんばらないといけない

とはいえ、DataStoreの制限は、スケーラビリティとトレードオフなので仕方ない面もある。RDBMSの高速化は、バッドノウハウのかたまり。

# このくだりが、よくわかりませんでした。バッドノウハウとは、何をさしているんだろう？

  • データやソースコードをGoogleに委ねなければいけない
    • データの場所が明確にわからない問題
      • 内部統制的にアウトの場合も
    • アベイラビリティ、ダウンタイムの問題
      • 急に止まることもあるし、その原因が不明なこともある
  • 箱庭的な窮屈さがある
    • 利用できるライブラリに制限がある
      • ソケット通信や、ネイティブ言語を利用するライブラリなど
    • 長時間に渡るリクエストは、途中でキャンセルされてしまう

まとめ：箱庭的な環境で、スケーラブル＆チープなシステムを作るのが、GAEである。

質問タイム
  • 質問(1)：30秒ルールで引っかかるのは、JavaもPythonも一緒？
  • 回答(1)：一緒。DataStoreへのクエリで引っかかる。
  • 質問(2)：スケールって、実際どんなふうにするの？
  • 回答(2)：システムの設計やデータに依存するが、DataStoreへのクエリで引っかからなければ、完全にリニアにスケールする。
  • 質問(3)：同時に30リクエストまで、というGAEの制限は、大きいサービスだと外してもらうのか？
  • 回答(3)：外してもらう。依頼には専用のフォームがある。
  • 質問(4)：「インスタンスを暖める」という話を聞くが、本当か。使い始めてすぐは遅いけど、だんだんスケールする、など。
  • 回答(4-1)：インスタンスを暖める、だけ聞くと、都市伝説かなと思うが・・・
  • 回答(4-2)：（tmatsuoさん補足）Pythonは、AppサーバにロードされるのがJavaより速いため、スムーズにスケールするが、Javaがそれと比べて時間がかかる、という意味では。
  • 質問(5)：DataStoreのインデックスを管理画面から削除しようとしたら、エラーで削除できなくなる現象がときどき起きる。
  • 回答(5)：（tmatsuoさん補足）Googleに連絡して削除してもらう。
  • 質問(6)：GAEはじめたばかりの人は、知りたい情報をどうやって得ていけばよい？
  • 回答(6)：英語のMLに、GAEの情報がたくさんある。
感想

質問し忘れたこと、疑問、あとでしらべることなど。。。

  1. 「GAEで作れるアプリは、1アカウントで3個」とおっしゃっていた（スライドにあった）けど、1アカウントあたり10個じゃなかったっけ。Pythonアプリだと違うのかな？
  2. 柴田さんの「RDBの高速化は、バッドノウハウのかたまり」という発言の意味（真意）を知りたかった。# 今まさにそのあたりの仕事をしているので。たとえ詰んでるとしても、必要な仕事なのでやるんですけどね…(^^; どんなご意見なのか、お聞きしてみたかったです。
  3. Slim3はシリアル型をサポートしてる？ あとでしらべる。
  4. CPUの進歩がゆっくりになってるよね、という話を聞いて、GPUについて知りたくなった。
  5. 質問にあった「どういうふうにスケールするのか」が、自分もとても気になる。

システムの命綱、バックアップ（坪井義浩さん）

# 後日、発表資料をアップしてくださるそうです :-)

バックアップは人為的ミスに対処するために取る

今時のハードディスクは壊れにくいし、たとえ壊れても、冗長化されているためにサービスの運営には影響を及ぼさないケースが多い。しかし、人為的なミスでデータを論理的に壊したときに、修復するには、バックアップを使ったリストアが必要である。だから、バックアップを取る。

バックアップ方式の違い：増分と差分
増分バックアップ
前回のバックアップから変更された分を取得する
差分バックアップ
フルバックアップから変更された分を取得する

バックアップの作業が速いのは、増分バックアップ方式である。増分バックアップの方が、差分バックアップよりも、1回に取得するバックアップの量が少ない。

一方、リストアの作業が速いのは、差分バックアップである。差分バックアップは、直前のバックアップをフルバックアップに一気に追加すればよい。増分バックアップは、パッチを当てるように、フルバックアップに対して1つずつ増分を加えていく必要がある。

Amanda概要
  • 1991年から開発されているOSS
  • 2009年11月時点でバージョンは2.6.1P2

バックアップのスケジューリングやデータ管理の機能を持つ。特長として、ネットワーク上の複数マシンからバックアップを取ることができる。

Amandaの使い方

まず、バックアップの設計。

  • ポリシー：何を・どのタイミングで・どこに
  • 容量：データの更新量、使用するテープやディスクのサイズ

ネットワーク越しに各クライアントからdumpを集めるときは、それをどこに置くかも検討する必要がある。（holding disk）

次に、設定ファイルを書く。Amandaは設定ファイルを書くのがちょっと大変。なので、サンプルを参考にして書くとよい。書いたら、amcheckコマンドで、設定の記述の正当性を確認する。

そして、手動でバックアップを実行してみる。成功したらメールが自動送信される。手動で上手く取れたら、cronで定期実行を設定しておく。なお、Amandaには、バックアップ先のテープの容量が足りているかどうかを確認するコマンドも存在する。

最後に、Amandaを使ったリストア。方法は3種類ある。

  • amrecover
    • （コマンドラインのリストアツール）任意のファイルのバックアップが取れる。
  • amrestore
    • ディスクまるごとバックアップが取れる。
  • mt, dd
    • ddでイメージを取って、mtでリストアする。イメージの先頭にリストア方法が入っている。
    • 最悪の場合、Amandaがなくてもリストアができる。
ところで、GAEのバックアップは？

# この話題では、坪井さんの発言に対して、会場から@tmatsuoさんが回答してくれました。

  • （坪井さん）GAEのバックアップは、どのようにするのか？
  • （tmatsuoさん）GAEでは、データが必ず3台以上のマシンに自動的に保存されるので、それでよしとする人が多い。よしとしない場合、サーバ側からデータをクライアントに落とすことができるので、それでバックアップを取る。Bigtableも落とせる。
  • （坪井さん）COUNT関数を使いたければ、ローカルにデータを落としてきて、カウントすればOKでは？と思ったのだが。
  • （tmatsuoさん）それも一つの方法でOK。でも、30秒ルールに引っかからないように、自動でトランザクションを分割してくれるので、GAE上でもCOUNTはできる。
DBのバックアップ
感想

Amanda初めて知りました。面白かったです。

「バックアップは人為的ミスのため」は、たしかになあと感じました。実際、少し前に身近で本番機のディスクが壊れましたが、冗長化のおかげでサービスは停止せず、メーカさんによる機械の交換だけで済みました。

個人的には、最近は物理マシンのサーバよりも仮想マシンのサーバを使うことの方が多く、バックアップはもっぱらスナップショットかイメージファイル（VMwareでいうとVMDK）です。で、ログの切捨てやバックアップ自体のログ出力といった処理は、参加者の大多数の方と同様、シェルとPerlでやっています。このへん、Amandaだとどうなんだろう？ バックアップセットごとに設定ファイルにでも書けば、機能としてできるのかな？ それとも、外出し？ あと、バックアップ先のテープ容量のチェックまでコマンドでできるのは、ベンリだなぁと思いました。

そうそう、この日のメインテーマだと勝手にカン違いしていた「GAEのバックアップ」について、話題に上がって嬉しかったです;-)　GAEのバックアップ方法は、セキュリティの維持・確保の方法と合わせて、とても気になります。

懇親会

懇親会にもお邪魔させてもらいました。顔見知りの人がいなくて緊張していたのですが、お話ししてくださった方、ありがとうございました。

右も左もPythonistaという自分にとって新鮮な状況の中、凄い人のお話をいっぱい聞けて、楽しかったです。仕事の半分は基盤系なので、もっと早くに知っていればと思いました。また参加したいです :-)