インフラエンジニア勉強会hbstudy#7に参加してきた

勉強会

勉強会サイト
最近インフラ周りを仕事でもやり始めた事もあり、インフラエンジニア勉強会に参加してきた。

一コマ目：Google App Engineの勘どころ

事例
  • オンライン市民会議でのオバマ大統領への質問募集：Google Moderator

数時間で7000あまりの質問が登録され、その質問に対して24万もの投票が集まったらしい。
閲覧のみの数も考えるとかなりのアクセス数であったにも関わらず問題なくスケールしたらしい。

日本での事例であり、相当数のアクセス数があったが問題なく機能したらしい。

ただ、この２件は同時接続数30というGAEの制限が外された例。

その他

うまくまとめられないので自分が気になって拾った部分だけ。

  • SaaSとPaaSも共にクラウドサービスだが、その違いはビジネスロジックの有無。
  • マルチコアのハイパフォーマンスのCPUはあるが、ディスクI/Oなどがボトルネックになりそのパフォーマンスを使い切ることは難しい。
  • ならば、低いパフォーマンスのCPUを積んだマシンを並列に使う方が効率が良い。
  • 課金体系を見ても、ハイパフォーマンスなものは高価なCPUやそもそも資金のかかる帯域の使用に関するものは比較的課金金額が高く、年々安価になるHDDのためかディスクの使用に関するものは安い。
  • GAEのDatastoreはSerial型をサポートしていないため、独自にトランザクションを設計しカウントアップするなどが必要だが、Slim3はSerial型をサポートしている。
  • 比較的に単純に設計されたWebアプリ、WebサービスであればGAE上では本当にリニアにスケールしてくれる。
  • JavaとPythonの選択肢があるがPythonがおすすめ。とにかく楽に作れる。
  • Pythonは他言語に比べて圧倒的に予約語が少ないシンプルな言語。
  • JavaとPythonでは単純にロード時間が異なるため、Pythonで作ったアプリの方がリニアにスケールする可能性がある。スケールしていく際の読み込み時間が少ないから。
  • 単純なアプリとしてはやはりGAE上でもJavaの方が早い。
  • 同時接続数30制限は解除してもらうための専用フォームがあるらしい。

二コマ目：システムの命綱、バックアップ(仮)

増分バックアップと差分バックアップ
- バックアップ リストア
増分 前回のバックアップからの差分を保存する。=> 速い フルバックアップ時の原本に対してパッチのように全ての増分バックアップを適用していく必要がある => 超遅い
差分 フルバックアップ時の原本からの差分を保存する。 => 遅い 最後の差分バックアップをフルバックアップ時の原本に適用すればよい => 遅い
Amanda
  • 1991年頃から開発されている歴史の古いバックアップソリューション。オープンソース。
  • テープ時代に開発開始なので基本はテーブだが、ディスクに対してやAmazonS3に対するバックアップも可能
  • NASAやAmazon、Sunなど多くの企業で使用されている実績がある。
  • Baculaという対抗オープンソースがある。
  • インストールはyum一発。
  • 設定ファイルが超大変。。
  • 商用のEnterprise版ではGUIで設定・管理ができる。
  • バックアップはamdump
  • リストアは２種類ある。amrestoreとamrecover
  • amrestoreはバックアップ全リストア
  • amrecoverは対話式で、バックアップから特定の日時、ファイルを抜き出してリストアできる。超便利。
  • amcheckでテープやディスクの空き容量をチェックしてくれる。
  • 増分・差分バックアップとしてはDAR(DiskArchiver)というバックアップ手法も存在する。
  • スナップショットは便利。
  • ZFSはバイナリスナップショットもできる？
とにかくバックアップはやろう。

ハードウェアが壊れるということは本当に少なってきたが、人為的ミスでデータが壊れると言うことはなくなることはない。きっと、やっといて良かったという時がきます。
それからUpdate文流す前にはかならずSelectしようね。

懇親会

自分が行く勉強会の中では異例の40人ぐらい居た懇親会。主催者さんのお話によれば初の飲食代が10万円超えだったとか。とはいえ3000円でけっこう飲み食いできてとっても安かった。
席の移動はしなかったので最初に座った周りの方たちとお話していたが、とてもいい情報がもらえたのでメモ。

バックアップ
  • LTOのテープは1.6Tのがある。
  • 16Tぐらいのバックアップもやってるらしい。
  • テープは保管に便利。かと言って10年も保存しても10年後に復元できる機器があるかな。
  • やはり最近はディスクバックアップも多い。
  • テープバックアップの場合も一度別のディスクに保存した後でテープという流れが多いらしい。DtoDtoT
  • それはサービスのダウンタイムとかにも影響するから。何よりバックアップ中に本番機に負荷をかけたくない。
rsync・DRBD
  • デプロイに使うのは便利
  • やっぱり負荷は高い。
  • lsyncdも用途によってはrsyncよりも軽くなるが、大規模なファイルストレージとかではキツイ。
  • やはりディスクI/Oがネックになる。
  • 次の選択肢はやはりDRBDになる。
  • rsyncよりは断然負荷も少ない。
そもそもバックアップって？
  • ある時点に復元する必要があるかどうか
  • 例えばDRBDでミラーリングしてくと、ダウンした時点のデータが待機マシンに残っているわけだが、それで構わないのならばバックアップはそもそもする必要はない。
  • ただし、人為的なミスなんかも戻せなくなるのでその辺も考慮にいれる。
フルバックアップと差分バックアップ
  • 差分バックアップは高価な商用製品でも無い限りは、例えその中に人為的なミスが含まれていてもリストアされる。
  • とはいえ、データ量が大きくなれば毎日フルバックアップは現実的ではない。
  • 容量よりも数が大量の場合は、バックアップするためのReadもとてつもなく、tar作るのも一苦労。その場合は、イメージでバックアップしてしまえばいい。イメージはセクター単位なので個数は関係無い
MySQL・PostgreSQL
  • 日本ではPostgreSQLの方が早く使われ始めた。
  • 世界的にはMySQLの方が多く使われているらしい。
  • 日本では、単純な台数だとMySQLの方が多そうだが、サービスやアプリ単位で言えばPostgreSQLを採用している方が多いかもしれない。
  • MySQLはレプリケーションの機能をデフォルトで備えているため強い。
  • PostgreSQLはこれまでレプリケーション等の機能はあえてデフォルトではつけない戦略だったが、8.5でついにサポートするらしい。
  • ハートビーツの馬場さんは日本PostgreSQLユーザ会の理事だそうです。

その他で熱く語られていたのは、インフラの上に乗るソフトウェアを作るプログラマに対するもの。メモリが安くなった事で平気で「増設すれば動くよ」とか言うが、それはイニシャルコストだけで電力も含めたランニングコストは全然見積もれていない。平気でメモリリーク起こすようなプログラマには電気代の事から懇切丁寧に説明すべき。などなど。笑いアリ、涙有りであっという間に日付が変わっていました。

後、関係無いけど、たまたま懇親会で隣に座った人がうちの社員のうち二人が以前所属していた企業の人だった。しかも超仲イイらしい。「世間は狭い」と爆笑した。

本当に楽しかったです。主催者のハートビーツ社の方々、プレゼンしてくださったお二人、懇親会でお話しくださったみなさん、ありがとうございました！